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

11–20 of 47 posts

Re: Why you should refuse to participate in coding interviews

#11

Post by steego »

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.

However, my experience has show me that assumption has been wrong on a number of occasions. People have both surprised me and disappointed me. I wish I could say it's been the rare case, but it's happened a lot more than I would have liked.

I've considered I'm not the best judge of people, but I can't help but notice a lot of my colleagues aren't the best either. Some are and I envy their talents to notice some set of heuristics I haven't picked up yet.

Re: Why you should refuse to participate in coding interviews

#12

Post by Apocryphon »

RandomOpinion wrote: post #9
jkchu wrote: post #3

While I fully agree with the author that coding interview questions are not great, I think something important to keep in mind is that "fixing" programming interviews it is an incredibly difficult problem to solve. I think the best way to gauge a candidates programming ability is to work on a small project with them, similar to Automattic's approach [1]. Unfortunately, this method is extremely expensive, to both the…

I think there's a business opportunity here. Imagine something like ETS's system for administering the GRE: Come into a location in your city at a particular date/time, sit down at a computer pre-loaded with various editors / IDEs for common languages, and run through an 4-hour coding exercise specified by the hiring organization, and, at the end, your code is provided to the hiring organization for examination. Inte…

Sounds like what Triplebyte promises, but doesn't quite offer yet.

Re: Why you should refuse to participate in coding interviews

#13

Post by dragonwriter »

jkchu wrote: post #3

While I fully agree with the author that coding interview questions are not great, I think something important to keep in mind is that "fixing" programming interviews it is an incredibly difficult problem to solve. I think the best way to gauge a candidates programming ability is to work on a small project with them, similar to Automattic's approach [1]. Unfortunately, this method is extremely expensive, to both the…

> I think something important to keep in mind is that "fixing" programming interviews it is an incredibly difficult problem to solve.

Only because the formulation of the problem is wrong in a manner that precludes the solution; you can't fix the programming interview because an interview is not, no matter what you do to it, a good way to assess practical programming skill. It might be a useful way to assess other skills that are relevant to the work of someone being hired as for a job that involves programming, but not the programming part.

Re: Why you should refuse to participate in coding interviews

#14

Post by g9yuayon »

Coding interviews make sense for great companies like FB and Google. Such companies receive probably tens of thousands of applications every week, and all the candidates who can get an onsite interview have impressive resumes. How do they pick the best and brightest from the best and brightest? Code interview at least sets a higher bar for minimum requirements for two types of candidates: - If a candidate is a genius, the candidate can solve those interview questions easily - If a candidate is not a genius but is truly passionate about CS, the candidate should have read or practiced enough to solve the interview questions too.

Either way, the candidates who pass coding interviews meet the minimum hiring bar.

And don't forget the historical context when Microsoft popularized brain teasers and algorithmic puzzles in its haydays. In the 80s and 90s, there were few interview prep books. There was no leetcode or any other pre site. Those so called teasers are cleverly disguised math puzzles. Remember the questions about pirates dividing up gold coins? Classic math problem. Remember the one that asks how many unfaithful husbands there are in an island? Putnam question solvable by mathematical induction. Similarly, the so-called algorithmic puzzles came from classic CS books or from real projects. Those who can solve the puzzles are either super smart or super geeky. Either way, they were likely to be great hires for Microsoft.

Re: Why you should refuse to participate in coding interviews

#15

Post by koverstreet »

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…

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 place, without concern for ego or who wrote what.

Re: Why you should refuse to participate in coding interviews

#16

Post by ryandvm »

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 they'll cheat and have their friends do it for them - you needn't be. As long as the interviewer is knowledgeable enough to ask good questions (e.g. "Why did you use that auth strategy?" or "What performance problems do you anticipate?") you'll quickly be able to tell if they fully understand the problem space. That's a much more useful test than asking someone to implement a red/black tree.

Re: Why you should refuse to participate in coding interviews

#17

Post by davidbanham »

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

Re: Why you should refuse to participate in coding interviews

#18

Post by steego »

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 would like to add the reason I continue to use my current method is that it creates so many diverse points of data (using that term loosely) because so much happens in the hour we're together.

There is something incredibly revealing when it comes to collaboration, especially if the objective is slightly open-ended. People have very different styles of approaching ideas and a lot of the time, it's revealed when the objective hasn't been overconstrained. Simply asking people, "What would you do here?" and "What's your approach?" in a non-judgemental way that actually conveys you're interested in their ideas goes a long way. Also, phrasing your questions so they come off as genuinely curious rather than pointed goes a long way.

Most of all, letting people take you somewhere you didn't expect to go is an interesting way to learn about someone. When your agenda is open enough to allow a person to solve a problem with tools or ideas they're comfortable with, it can be eye opening.

However, if I see them doing something where I feel like I improve it, I offer to show them a trick and this gives me a tiny peek to see how they learn. Do they get it right away? Do they ask good questions?

I think all those things are important aspects of collaboration. You need to have a genuine interest in each other's ideas and receptive to teaching each other new ideas and making each other's work better by adding your insight as well as absorbing their insight.

That's why I'm hesitant to simply interview and ask questions. I actually enjoy coding with other people and it's hard for me to see if I'm going to like working with this person if all I'm doing throwing questions at them so they can wax poetic about their last job, thoughts on tech/methods, etc.

Again, I'm still not convinced my method is optimal.

Re: Why you should refuse to participate in coding interviews

#19

Post by steego »

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…

Do you think I should ask people if they prefer the homework format? That answer might be eye-opening itself.

Re: Why you should refuse to participate in coding interviews

#20

Post by RandomOpinion »

Apocryphon wrote: post #12
RandomOpinion wrote: post #9

Earlier quoted context omitted.

I think there's a business opportunity here. Imagine something like ETS's system for administering the GRE: Come into a location in your city at a particular date/time, sit down at a computer pre-loaded with various editors / IDEs for common languages, and run through an 4-hour coding exercise specified by the hiring organization, and, at the end, your code is provided to the hiring organization for examination. Inte…

Sounds like what Triplebyte promises, but doesn't quite offer yet.

Triplebyte seems to angled toward doing pre-screening; the hiring organization still does a full interview loop afterward. What I proposed would be more along the line of handling the mechanics of administering a coding interview for a hiring organization while allowing their hiring manager & HR full control and also making the candidate as unstressed as reasonably possible.
Post reply on HN