41–50 of 391 posts
I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me. Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicate…
Earlier quoted context omitted.
But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.
Ya know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.
People out there who can’t code interviewing for SWE roles, I can’t speak to, but there are definitely folks being asked to be fluent in code for non SWE roles who aren’t SWEs, so it makes sense everyone gets put through the leetcode grinder rubric to calibrate their level. I don’t think this is about misrepresentation, but expectation misalignment and a crude tool being necessary to evaluate human skills against a baseline.
(nearing 40, 22 years in tech, getting out asap, ymmv)
Earlier quoted context omitted.
Most growth companies have an endless bucket of work. Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively. It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people. The most proficient and fast coders often write higher quality code too, in my experience. People who over index on com…
How do you actually measure 2x or 10x workload while keeping quality the same? It's _very_ easy to measure how fast it takes a ticket to go from "in progress" to "done" but measuring whether code has bugs, or leads to downtime or is just impossible to parse is a different problem. If you never need code to be readable or documented I can write it quite quickly. If you want something other humans can have a hope of ma…
In my experience the top 20% of employees do 80% of the work
I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me. Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicate…
If you are a no-name company paying whatever your HR department defines as "market rate" and you don't get hundreds of very qualified candidates for every role then interviewing like Google might not be a great idea.
I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting. I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.
But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.
I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting. I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.
But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.
This is a hyperbolic rhetorical question but consider how much of modern work really is CRUD API gluing, and how much of that work is not rigorous engineering, but tedious implementation as per documentation and wading through hastily-thrown together legacy cruft written during previous crunch time.
How much of that work involves novel programming and memorized understanding? Most of it requires study of existing codebases, not given a blank REPL to hash out something new.
Earlier quoted context omitted.
Most growth companies have an endless bucket of work. Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively. It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people. The most proficient and fast coders often write higher quality code too, in my experience. People who over index on com…
How do you actually measure 2x or 10x workload while keeping quality the same? It's _very_ easy to measure how fast it takes a ticket to go from "in progress" to "done" but measuring whether code has bugs, or leads to downtime or is just impossible to parse is a different problem. If you never need code to be readable or documented I can write it quite quickly. If you want something other humans can have a hope of ma…
That I can’t tell you to two decimal places exactly how much better the first list is than the second doesn’t mean I can’t tell who’s on which list with high fidelity/repeatability.
I usually give a data structure coding interview: Here's some data models, and here's how you can reference eachother by properties. Cool. Let's do 3 levels of nested loops to extract the relationships and map them. That's like 99% of what they'll be doing. The signals I'd look for are "do they start the entire thing by looking at structures or not", etc. But unfortunately this breaks down when you're interviewing 10…
Is it ironic or intentional? Seems like a great way to hide age discrimination under the guise of "fairness" (everyone gets the same test).
Earlier quoted context omitted.
But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.
Ya know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.