Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should refuse to participate in coding interviews

quora.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Why you should refuse to participate in coding interviews

#31

Post by davidbanham »

werty1 wrote: post #26
davidbanham wrote: post #17

I think the answer to this problem is take-home coding tests. They do the best job of simulating actual working conditions and minimising associated stress and anxiety. I've had this confirmed by multiple candidates I've used this approach with. I'm actually launching a product to streamline the process if anyone is interested. https://takehome.io

Hi I just looked at your site. I found this very odd. RESPECT YOUR CANDIDATES Strictly timeboxed tasks ensure candidates don't feel pressured to devote silly amounts of time to interview coding exercises. The biggest issue I've found as an dev looking for work is that, employers often want a full functioning, production grade, api, with tests, and some integration tests. These requirements cause the issues, and timeb…

The strictness of the time limit works both ways. They'll be comparing you against other candidates who had the same amount of time. If nobody got a complete solution done, nobody is advantaged or disadvantaged.

The employer onboarding is designed to guide them towards the best practices I've discovered. 40 minute time limit and a clear expectation set in the challenge instructions that a "perfect" response is not possible in the time provided, so just do what you can and submit what you've got.

That avoids clustering responses near the top of the curve.

It also provides talking points for the interview. "So, given unlimited time and budget, where would you go from here to make this code production ready? If you needed to scale it to an OOM more throughout, where would you start optimising?" Etc.

Re: Why you should refuse to participate in coding interviews

#32

Post by CodeWriter23 »

ryandvm wrote: post #16
steego wrote: post #7

I give coding interviews and I try to take the original concern (Questioner can't think fast enough or freezes) into account, but I can't really say with any certainty if I'm successful or not. About 10 years ago, I gave a woman a coding interview question and her hands were literally shaking. She got through it, but I felt terrible because clearly she was the type of person who gets really nervous when under that ty…

I think the test that is the least stressful as well as most closely simulates the work they'll actually be doing is to give interviewees some "homework" that they should be able to knock out in a few hours before their interview. Maybe write a few API endpoints or whatever. This allows them to tackle the exercise at their own pace and do it at a level of quality that they're comfortable with. If you're concerned the…

I would reject that as well, it indicates the company thinks nothing of giving me a half day of work to do for free.

Re: Why you should refuse to participate in coding interviews

#33

Post by davidbanham »

david-gpu wrote: post #23
davidbanham wrote: post #17

I think the answer to this problem is take-home coding tests. They do the best job of simulating actual working conditions and minimising associated stress and anxiety. I've had this confirmed by multiple candidates I've used this approach with. I'm actually launching a product to streamline the process if anyone is interested. https://takehome.io

As a job seeker I would need to be pretty desperate in order to spend time doing homework assignments knowing how little they cost the interviewer. Before I spend time as a candidate I want to make sure the interviewer is seriously considering me for the position.

Sounds like a vote for a usurious per candidate pricing model!

Oooohhhh or pay-what-you-want where the candidate sees what you paid. Use it as a signal to the candidate of how much you're interested in them.

Personally I only ever assign a code challenge after an initial general interview. Then code challenge which gets taken into a technical interview.

Re: Why you should refuse to participate in coding interviews

#35

Post by pseudalopex »

ryandvm wrote: post #16
steego wrote: post #7

I give coding interviews and I try to take the original concern (Questioner can't think fast enough or freezes) into account, but I can't really say with any certainty if I'm successful or not. About 10 years ago, I gave a woman a coding interview question and her hands were literally shaking. She got through it, but I felt terrible because clearly she was the type of person who gets really nervous when under that ty…

I think the test that is the least stressful as well as most closely simulates the work they'll actually be doing is to give interviewees some "homework" that they should be able to knock out in a few hours before their interview. Maybe write a few API endpoints or whatever. This allows them to tackle the exercise at their own pace and do it at a level of quality that they're comfortable with. If you're concerned the…

What about letting people provide code they've already written? It might take more effort to come up with good questions, but the answers should be more interesting.

Re: Why you should refuse to participate in coding interviews

#36

Post by qudat »

ryandvm wrote: post #16
steego wrote: post #7

I give coding interviews and I try to take the original concern (Questioner can't think fast enough or freezes) into account, but I can't really say with any certainty if I'm successful or not. About 10 years ago, I gave a woman a coding interview question and her hands were literally shaking. She got through it, but I felt terrible because clearly she was the type of person who gets really nervous when under that ty…

I think the test that is the least stressful as well as most closely simulates the work they'll actually be doing is to give interviewees some "homework" that they should be able to knock out in a few hours before their interview. Maybe write a few API endpoints or whatever. This allows them to tackle the exercise at their own pace and do it at a level of quality that they're comfortable with. If you're concerned the…

I'm going to go against the grain and say homework assignments work for me. If I know that I would perform better at them instead of a whiteboard code test then I would take the time. But I think you can see the bias here, the people that are interested in taking a homework assignment over in person interviews are ones that prefer them.

Re: Why you should refuse to participate in coding interviews

#37

Post by jstewartmobile »

steego wrote: post #11
jstewartmobile wrote: post #6

My experience is that knowing who's a good programmer is like knowing what's art: you know one when you see one. That's why I don't get the coding interview. Just an everyday conversation with a coder will give you a better idea whether he's any good or not, and it will do this without stressing him out or impugning his integrity (which is exactly what you're doing when you ask someone a bunch of trick questions on a…

I'm skeptical. There's always a set of programmers who sound erudite because they are erudite. It's typically not that easy to fake being erudite, so it naturally follows that programmers who sound and behave like they're competent are usually competent. A simple strategy would to always select from that pool. It might even be a relatively optimal strategy too if you account the time and effort to interview people. H…

Whenever I've had a problem with a hire, it has never been a competence problem. If I gave those people code problems, they would have knocked them out of the park, I still would have hired them, and I still would have had the problem.

Re: Why you should refuse to participate in coding interviews

#38

Post by jstewartmobile »

koverstreet wrote: post #15
steego wrote: post #11

Earlier quoted context omitted.

I'm skeptical. There's always a set of programmers who sound erudite because they are erudite. It's typically not that easy to fake being erudite, so it naturally follows that programmers who sound and behave like they're competent are usually competent. A simple strategy would to always select from that pool. It might even be a relatively optimal strategy too if you account the time and effort to interview people. H…

It's not about being erudite, or knowing lots of things. What you pick up on when you're having a conversation with another programmer about writing code is whether or not they give a crap about their craft and doing it well, and what kinds of things they think about and worry about in their code and the code they work with. The really good programmers are the ones who want to make the world of software a better plac…

Thank you koverstreet for putting it into words better than I could.

Re: Why you should refuse to participate in coding interviews

#39

Post by ryandvm »

CodeWriter23 wrote: post #32
ryandvm wrote: post #16

Earlier quoted context omitted.

I think the test that is the least stressful as well as most closely simulates the work they'll actually be doing is to give interviewees some "homework" that they should be able to knock out in a few hours before their interview. Maybe write a few API endpoints or whatever. This allows them to tackle the exercise at their own pace and do it at a level of quality that they're comfortable with. If you're concerned the…

I would reject that as well, it indicates the company thinks nothing of giving me a half day of work to do for free.

Oh I don't think it should be free. They should definitely compensate you at a reasonable market rate for a couple hours of effort.

Re: Why you should refuse to participate in coding interviews

#40

Post by qudat »

I think blanket statements aren't going to work in a diverse field such as software development. Certain jobs require strict skills and those skills need to be measured by all potential employees.

On my team we aren't doing anything particularly crazy beyond a large crud application. We feel confident enough in our development process that we can hire interns and make them productive. We are more interested in knowing they want to learn and are able to learn our application. Culture fitnisnlore important to us.

As a result, having a conversation with the applicants is much more valuable than a coding challenge. It works for us.

Post reply on HN