←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 2 comments | | HN request time: 0.547s | source
Show context
fishtoaster ◴[] No.42149357[source]
I recently ran an interview process for a relatively senior eng role at a tiny startup. Because I believe different interview methods work better for different people, I offered everyone a choice:

1. Do a takehome test, targeted to take about 4 hours but with no actual time limit. This was a non-algorithmic project that was just a stripped-down version of what I'd spent the last month on in actual work.

2. Do an onsite pairing exercise in 2 hours. This would be a version of #1, but more of "see how far we get in 2 hours."

3. Submit a code sample of pre-existing work.

Based on the ire I've seen takehome tests get, I figured we'd get a good spread between all three, but amazingly, ~90-95% of candidates chose the takehome test. That matches my preference as a candidate as well.

I don't know if this generalizes beyond this company/role, but it was an interesting datapoint - I was very surprised to find that most people preferred it!

replies(7): >>42149441 #>>42149536 #>>42149571 #>>42149636 #>>42150136 #>>42150254 #>>42151318 #
bhhaskin ◴[] No.42149441[source]
Why would you even do any of that for a senior role? I wouldn't waste my time with it, and it shows you don't know how to interview/evaluate for a senior position.
replies(6): >>42149512 #>>42149515 #>>42149540 #>>42149560 #>>42150471 #>>42151698 #
0xffff2 ◴[] No.42149512[source]
I've come around to the idea that all people who will be expected to write code as part of their job need to be evaluated for their ability to write code as part of the interview process. I've seen too many people write convincing and impressive resumes without a single ounce of technical ability to their name.
replies(1): >>42149685 #
bhhaskin ◴[] No.42149685[source]
You're hiring for a senior role, not a junior or mid.

Your candidates aren't fresh out of school or just starting their careers. They already have plenty of work experience. They already know how to code and have been doing it for years. A conversation will tell you much more about their approaches to problems solving, team work, and mentoring than a coding challenge will. Looking at their GitHub, their work experience and references will tell you the rest.

It's like asking a doctor to go over basic human anatomy.

replies(3): >>42149889 #>>42151583 #>>42151647 #
WillDaSilva ◴[] No.42151583[source]
Have you ever tried to hire developers? I have, many times. It's shocking how incapable most people with a history of working as senior developers for 10+ years are at basic programming questions. I'm talking about stuff at the level of Fizz Buzz, or barely more difficult, being solved in a language of their choice with ample time.

Through all of the technical interviews I've run on behalf of multiple companies, I've become convinced that our industry is full of imposters. A terrifying number of people who are employed as developers cannot code, beyond making tiny edits to existing code, or slinging StackOverflow answers and AI generated content around. They cannot think for themselves. They rely heavily on their coworkers to make any substantial progress. If anything, modern AIs have made these people more difficult to spot. I've found these imposters within the companies I've worked for too, and if it's not possible to move them to a non-technical role where they can be productive, then it's best to fire them. If that isn't possible, then keep them out of the way of any critical work, but know that they'll continue to be a drag on their team, and will decrease the moral of those on their team who have to keep covering for them.

Once I even worked on a team (as a junior) where only 3 members out of ~16 even knew the language that was exclusively used for the job. The remaining team members accomplished nothing every day. Those stand-up meetings were painful. Drawn out to 45+ minutes of standing in a circle while the unproductive team members found new ways to explain why they haven't made progress. Then I'd see them return to their desks, and not even open their IDEs for weeks at a time. They seemed to keep their jobs because their boss didn't want to fire them, and it cost him nothing personally to keep them around, offering them a sort of corporate welfare. Perhaps having such a large team even helped him politically, but it's unclear if he cared about that since he also spent almost all of his time slacking off, playing games in the break room, while the 3 productive team members carried the rest of the team.

replies(1): >>42196893 #
1. StartupSage1111 ◴[] No.42196893[source]
That sounds like a really challenging situation, and I can see how it would be disheartening to work in an environment like that. It makes me wonder if part of the problem lies in how companies approach technical growth and team dynamics. For example, instead of just identifying unproductive team members, do you think those people could have benefitted from structured mentorship or training programs? Or maybe clearer performance metrics that highlight where they’re struggling?

It’s also interesting to think about how managers could be supported better. If your old boss had been more engaged, perhaps they could’ve restructured the team or helped those who were falling behind find roles that suited their strengths better. Have you ever seen a company handle this type of situation well, or is this kind of dysfunction just too common?

replies(1): >>42197341 #
2. WillDaSilva ◴[] No.42197341[source]
I have seen team members fall below expectations, or burnout, or otherwise become unproductive, but then recover. In every case, their manager was a key part of the solution (and sometimes a key part of the original problem). If a person is really stuck on their current work, it can be demoralizing to have it taken away and assigned to others, but it can also be a relief. One thing that I've seen help is to let devs be more self-directed. Try to nudge them towards things that are important for the business, but focus on doing that by really convincing them of the value of that work. If they don't want to do that work, try to understand why, and consider changing plans based off of that.