Hacker News Reader

Comment by PacifyFish | Hacker News Reader

There's a lot of contempt for take-home coding tests in this thread. They aren't a perfect solution by any means (1), but much closer to an engineer's real responsibilities than a whiteboard session.

For this reason and this reason alone, I will continue to advocate for take-home coding challenges.

(1) IMHO, the best practical solution is a pair-programming interview using a real bug or feature the company has already solved.

View on HN

Challenges administered via pair programming can be useful if your team/company operates predominantly in that mode. If most of your actual day-to-day work is done individually, though, I think your challenge should mirror that reality.

Interviewing all candidates in a pair programming setting risks weeding out all the people who are great at the job, but get anxious in a paired interview scenario.

A job interview is already pretty stressful and anxiety inducing. Adding somebody looking over your shoulder while you type into that mix can be really rough on some people.

I also prefer take homes. I find whiteboard interviews are much worse, because I have to relearn a lot of things in detail that aren't useful in my previous job or my next, just because these are classical whiteboard problems. Take homes are actually about job skills, not some how good are you at memorizing 100s of algorithms you should never program metric.

Whiteboarding is only good for those who are fresh out of college.

No. Talk to them, get a feel, if they are a fit, hire them for a 3 month contract. If they aren't any good, don't hire them. If they are really bad, cut the contract short.

You will never know what someone is capable of in a few hours. People who think that works are just fooling themselves and turning away good talent.

> You will never know what someone is capable of in a few hours.

I guess the goal is to fine tune your interviewing process based on how past candidates turned out.

I'd bet dollars to doughnuts the people doing this are collecting zero data to analyze to see if this new process improves or hurts the number of good candidates they actually hire.

The irony of it is putting processes like this is actually turning away good talent, but they wouldn't know, because they aren't doing any analysis; they just read an article somewhere.

You can certainly do analysis on the hires you make, but it's pretty hard to analyze the hires you didn't make. Very few will come back and reinterview.

Sure you can, but my point was I'll bet most people don't. They just get this crap from an article they read because they don't think about all the ramifications, or don't think about it much at all.

For some businesses, they aren't hiring a ton of developers, so doing an analysis on 2-5 data points isn't going to yield anything significant.

Why would the introduce such a radical break from traditional interviewing without testing to see if it works?

> Why would the introduce such a radical break from traditional interviewing without testing to see if it works?

Has "traditional interviewing" undergone any scientific study for determining if it "works"?

I don't know, I'm sure there is something on Google if you are interested.

Sorry about the late reply, but you are wrong about "collecting zero data". Without saying too much I can assure you at least one company does.

And what of people who don't want to leave existing full time employment for a three month contract that might turn into a job if things work out well? Similarly, I doubt most people would be willing to move to a city for a temporary contract.

Usually if people are looking around, they are pretty fed up with the place they are at for one reason or another. If it's a good developer, they would know they would make the cut, so they would take it if it were a decent company with decent pay.

Also, there is no distinction between a full time job and a temporary contract in terms of survivability in the US. Most states are at-will states, and not being able to do the work is a fire-able offense. Just about everyone knows this.

Most people who have been in the business a while aren't willing to move to a new city, again unless you are willing to pay ungodly sums of money. If you are hiring right out of college and junior-mid's, this technique is better suited, but still, you're competing poorly in a seller's market.

I mean, just because you are hiring and paying a salary doesn't mean 20 other companies in your area aren't doing the same. What makes you better? Certainly not market rates and certainly not your exhaustive and mostly ineffective interview process.

You want a good person, ask your tops if they know anyone good, then try to lure them away with an offer of 1.2x - 1.5x market rates, depending on the return you expect from them. Trust your tops and don't put them through this silly process. Have the top interview them with you in the room. Spend about an hour with them to make sure they aren't some weirdo. Trust me, they'll respect you more if you respect their time.

I agree. I think take-home coding challenges are great. I have conducted take-home challenges and taken them. To me this does a better job measuring actual competency than a white board challenge.

I get that other developers get paid well to program so a lot of them are put-off by doing their job for "free." However, There's a simple solution of which has already been mentioned: cater the challenge to be completed within a few hours. Time-lock it and urge the applicants to only spend X number of hours on the challenge.

Like I have mentioned in another comment, I've been part of in-person interviews that lasted all day on top of an HR and technical phone interview. If I could cut down the in-person interview to just "personality fit" then that would be my preference.

Part of what I like about take-home challenges is that you can do them on your own time without anyone watching over your shoulder. Because in-person technical interviews tend to last for such a long time, they can be incredibly draining. The candidate's experience really depends on the interviewer's ability as well.

Two take home "challenges" I've done in the recent past stand out for me:

1) I spent 6 hours on it. I didn't do some of the "optional" parts (unit tests specifically) because I felt like 6 hours was enough to "show I can program" i.e. what it was supposed to do worked. Result: I got grilled over why the optional parts weren't there and didn't get an offer.

2) I spent 15 hours on it. I did everything I could think of on it including 50ish unit tests and more than what was asked for. Result: I got and accepted the job. (note: I had laid out my salary requirements before hand).

Is this "great"? I have an active github/open source profile. To me in both cases they basically wanted to waste my time and mental effort, and see if I would do it. That.. can't be ideal.

It's a good test to see if you'll balk at doing the kinds of shit they're going to throw at you once you're hired.

Oh, you had dinner plans tonight? You want to see your kids before they go to bed? Sorry, our engineering team generally works 11am-8pm. You need to be in the office.

Did either interview time lock the challenges?

These are good data points. I think the amount of time you should spend often depends on where you are in your career.

I know many companies don't explicitly require tests, but for them if a candidate submits a take-home challenge without them, its an automatic rejection. Do you think that if you had included tests in that first challenge that you would have gotten an offer?

Reply on news.ycombinator.com