Hacker News new | ask | show | jobs
by binarytox1n 2106 days ago
I'm a hiring manager and I start our technical interviews with coding problems. I have seen too many candidates who can't write code to ever be ok hiring someone who I haven't seen write code with their own hands.

I understand that you are highly compensated and may not want to spend time trying out for a new job when you already make so much money, but from my perspective: I have a team of highly compensated individuals who are evaluating a candidate for potential hire and I don't want to waste all of their time if the candidate can't even write a simple algorithm to rearrange the characters in a string.

Since it sounds like you're pretty happy where you're at you have the freedom to choose to participate or not. I am guessing that the only way to pull away a candidate like you is by referral anyway, so I am guessing there's not actually a problem here.

If I am getting someone via referral, then interviews can focus on what you find valuable - I can sell you on the role, I can ask you personality questions and make sure there is goal alignment. If I have someone to vouch for you. If you're a stranger? You better believe you gotta write some code.

I think that if you take a step back and ask yourself if you'd really like to work at a place where they hire people who they haven't seen code, you'd probably rather choose to just write some code for 30 minutes in an interview.

2 comments

You have set up a strawman -- I didn't say go hire people who haven't seen code, I didn't even say don't do skill testing questions. The question is: at what point in the interview process do you start dumping skill testing questions at them? And I think as the first gate to pass, this is just awful.

Further there's also a question of what kinds of questions, and how the question is asked, but that is a separate topic.

In any case, as a tangent: Most of the questions asked in these interviews have little to do with the day to day tasks of software engineers. So I'm not sure they give much insight into the performance of software engineers doing software engineering. But they do give preference to the skills obtained in CS algorithms courses, so there is an intrinsic bias towards hiring new grads.

I did address your question - I ask them to write code first. It may waste your time, but it saves time for my team. You can't code? Ok, the interview is over. Thanks for your time.

There's lots of debate on what kind of coding questions to ask. My questions are more fizz-buzz and less CS textbook. You'd be amazed how many people apply for senior level software engineer roles who can't demonstrate basic programming skills.

It's also super awkward to talk to someone and get a real good understanding of their experience, how they fit, what they've done, what they'd want to do.... and then find out they can't code. And this does happen. It's much nicer for all involved to do that early in the process and write it off as a formality because it's a humiliation to throw that at someone at the last minute. It's an insulting waste of time for any decent candidate, but there are always candidates who can do everything but code and you have to weed those guys out.
And from an applicant's perspective, I actually prefer getting the coding part out of the way up-front. It allows me to relax for the rest of the interview and just "be myself".
Found the person letting good candidates slip through the cracks. I literally just rescinded my application from a place when given a far too-open as far as choose-your-own-stack take-home assignment. I chose one very, very popular library that had unbeknownst to me, been slightly broken for some time. I fixed the library instead of doing the assignment and submitted an upstream pull. The recruiter's response was something along the lines of: "well, if you're having trouble completing the assignment, maybe you're not a right fit." I verbally handed the recruiter their ass, something more people need to start doing, and walked.

I've also been turned down for telling someone XML wasn't something people needed to really "know" to work with. The stack bias and navel-gazing of recruiters in their vainglorious attempts to prove that what they're doing is useful has reached peak.