Hacker News Reader

Comment by onion2k | Hacker News Reader

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.

View on HN

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.

How do you expect to measure their ability to code after hiring though? They could just be getting chat GPT etc to write everything.

Use the same process you do for your existing employees.

How do you know that someone who passes a whiteboard interview won’t just be churning out LLM slop because it’s easier?

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.

Reply on news.ycombinator.com