4 ms·

> I'm nowhere near you, but I think it's absurd that someone with 26 years would still need to pass some graph traversal trivia Two more perspectives to this:

by yobbo 2y ago

> I'm nowhere near you, but I think it's absurd that someone with 26 years would still need to pass some graph traversal trivia Two more perspectives to this: 1) it's the ability to learn/prepare/improvise quickly that is being tested (... or have insane recall of past experience.) 2) to be respected by juniors and peers, everyone has to pass through the same gauntlet. The job itself can be trivial for most candidates, but employees still need to have respect their for job positions and colleagues. It needs to feel like an achievement for everyone.

johnnyanmac 2y ago
> It needs to feel like an achievement for everyone. But that feeling won't be equal. There's code I was proud of as a junior that current me would tear to shreds with hindsight (even if I empahize with myself for the conditions it was made in). I thought it was neat some decade ago when I did my first LC hard with no assistance. Today that would simply be "well that was an odd puzzle, when would I be in this situation?" It's also that your time/energy decades later is different from a would-be juinior studying fundamentals full time. Someone who may not even know what part of CS they want to be in yet, fresh out of their algorithms course. It's bad enough some companies expect you to keep up with projects outside of work, but they also expect us to study these brain teasers as well, to a point where you can solve them in 30-40 minutes in an interview setting? That just tells me they either can't identify what they need for their job or that the actual role doesn't require 80% of all the fancy tools/systems/domain knowledge the job description listed and they just needed any kind of coder instead of an actual "staff" engineer. .
- yobbo 2y ago
  I agree with this from the perspective of the candidate. From the perspective of the employer and current employees, picking randomly among a set of 50 candidates (who are all adequate relative the "real world" requirements) trivialises the job and the current staff. Requiring everyone do LC and other tests creates prestige, up-values the current employees, creates camaraderie, loyalty, etc. When there is more than one adequate candidate, the selection process is a ritual that affects mainly the employees. It should be obvious in companies where there is no meaningful payback in a "long tail" of competence.
phibz 2y ago
We use the LC exercises to screen people who can't program. They are on par with day 10 to 15 of advent of code exercises. An experienced, _practiced_ programmer should have no trouble with them. I manage a devops team. We do ever thing from writing ansible, fixing broken services, to digging in to open source code and fixing sasl gssapi kerberos Auth. You would be surprised how many senior people we talk to who can't don't code regularly. Building rock solid tooling is very much part of the job. It really depends on what you're hiring for. Bit leetcode exercises can be practiced. You'll discover common patterns and themes. Being able to spot these and know how to solve them will save you time. Also programming takes practice. I learned a ton of languages, but everytime I would use one I hadn't used in a while I needed to go to the docs. It was only after doing things like Advent of Code or forcing myself to code for an hour every weekend, that I became faster and more prolific. This has only intensified as I moved in to management and my role shifted.

by yobbo 2y ago

johnnyanmac 2y ago

> It needs to feel like an achievement for everyone. But that feeling won't be equal. There's code I was proud of as a junior that current me would tear to shreds with hindsight (even if I empahize with myself for the conditions it was made in). I thought it was neat some decade ago when I did my first LC hard with no assistance. Today that would simply be "well that was an odd puzzle, when would I be in this situation?" It's also that your time/energy decades later is different from a would-be juinior studying fundamentals full time. Someone who may not even know what part of CS they want to be in yet, fresh out of their algorithms course. It's bad enough some companies expect you to keep up with projects outside of work, but they also expect us to study these brain teasers as well, to a point where you can solve them in 30-40 minutes in an interview setting? That just tells me they either can't identify what they need for their job or that the actual role doesn't require 80% of all the fancy tools/systems/domain knowledge the job description listed and they just needed any kind of coder instead of an actual "staff" engineer. .

yobbo 2y ago
I agree with this from the perspective of the candidate. From the perspective of the employer and current employees, picking randomly among a set of 50 candidates (who are all adequate relative the "real world" requirements) trivialises the job and the current staff. Requiring everyone do LC and other tests creates prestige, up-values the current employees, creates camaraderie, loyalty, etc. When there is more than one adequate candidate, the selection process is a ritual that affects mainly the employees. It should be obvious in companies where there is no meaningful payback in a "long tail" of competence.

phibz 2y ago

We use the LC exercises to screen people who can't program. They are on par with day 10 to 15 of advent of code exercises. An experienced, _practiced_ programmer should have no trouble with them. I manage a devops team. We do ever thing from writing ansible, fixing broken services, to digging in to open source code and fixing sasl gssapi kerberos Auth. You would be surprised how many senior people we talk to who can't don't code regularly. Building rock solid tooling is very much part of the job. It really depends on what you're hiring for. Bit leetcode exercises can be practiced. You'll discover common patterns and themes. Being able to spot these and know how to solve them will save you time. Also programming takes practice. I learned a ton of languages, but everytime I would use one I hadn't used in a while I needed to go to the docs. It was only after doing things like Advent of Code or forcing myself to code for an hour every weekend, that I became faster and more prolific. This has only intensified as I moved in to management and my role shifted.