Comment by onion2k
1 day ago
I think there's a lot of developers who can ace a live-coding interview but who lack the understanding of engineering systems at scale so they'll make your whole codebase worse over time by introducing tech debt, anti-patterns, and inconsistencies. These are the people you really want to avoid, but very few interview processes are set up to filter them out.
There's an assumption that the company's existing senior architects and developers will stop a new person from making the code worse, but also devs at every company thinks their codebase is terrible so it obviously isn't working.
I've seen lots of devs who think their codebase is the only correct way to do things. Lots of overconfident people out there. Inconsistencies are fine as long as there's file level consistency. All that really matters is if you can relatively quickly understand what you are working with. What you really want to avoid is having functions doing 20 different things from 5 different contexts.
Exactly. One negative productivity technical tornado can cause more damage than 10 people who lied about their coding ability.
What engineering interviewing process catches things like this?
Most coding interviews are accompanied by work experience discussions which CAN identify stuff like this, although obviously people can BS.
Work experience discussions are the best I’ve come up with.
What I’m suggesting is hire experienced people based on that and resume verification and behavior interviews like nearly every other job on the planet.
And if someone lies about their ability to actually code, fire them quickly.
1 reply →
I agree. Live coding always has a much smaller scope than real software, and after a few interviews it is easy to learn to read the room, even for the worst developers.
I think we can leave companies who don't care about quality out of the discussion, but for those who do, the time to detect those developers is in a probational period, which is not something that most companies really use on their favor.
The problem is this requires a good management that is able to actively paying attention to the work of the developer. Which is often not in place, even in companies who want to prioritize quality :/
Have you interviewed people recently? The "worst developers" absolutely cannot solve basic problems.
Yes, I agree. Good point.
A fizz buzz or something similar is often already too much for these.