Comment by johnnyanmac | Hacker News Reader

Comment by johnnyanmac | Hacker News Reader

Parent Full thread

>Interviewing is an inexact, unfair process. Keep trying, doing as many as your sensitivity to rejection allows.

I have a pretty high tolerance, but this year just plain sucks, full of gaslighting about roles that dont exist and disrespect from recruiter gatekeepers.

>Leetcode exercises aren't fun and they're a time sink. You can and should practice for them.

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 instead of anything actually relevant to their experience. Especially a staff/principal level that is probably super specialzied in a specific few topics.

I know they are too lazy to do proper domain questions, but you can do coding exercise without pretedning that Big O notation and solving some random "twists" in real time. If you have 20 years and can casually code up some for loops and branches in your given language, you probably prove your coding as much as some leetcode hard question. At most else, you may want to test pointers and memory management in as well, but "coding" 99% of the time is those above 3.

> 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.

> 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. .

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.

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.

Reply on news.ycombinator.com