Hacker News Reader

Comment by beliu | Hacker News Reader

We're trying a different approach at Sourcegraph. In addition to looking at a candidate's prior work in open source if available, we ask them to complete tasks that approximate the job as closely as possible (i.e., coding on a computer): https://sourcegraph.com/blog/programming-interview

Would love to hear people's thoughts and feedback!

View on HN

Yours sounds like an approach that measures how well someone codes in a vacuum, instead of how they operate on a team. It very much skews the results...

Not to mention for a qualified professional candidate, it feels an awful lot like you're asking them to work for free.

In addition to asking them to write some code, we also have each member of the team interview them onsite to get a sense of how they'd interact as a member of the team. The challenge does take a few hours, which is longer than a typical phone screen or single onsite interview, but because it lets us focus on getting to know the person onsite rather than go through a gauntlet of whiteboarding interviews, we think it actually saves time for everyone and is a win-win. Obviously, every candidate is different; we think of this not as a rigid template, but a better default option than whiteboard interviews. Thanks for your thoughts!

If I write working code, do I keep ownership? If you use my idea for improving your product, will I be compensated, even if you don't hire me?

From your blog post:

> The code is reviewed by the interviewer > but probably never run.

This is what surprised me during an interview with Facebook. I tend to write a little code, run it to test it out, write a little more, test again, and so forth, you know, rapid iteration or whatever the fancy industry term is these days. The interviewer gave me these silly little shell scripting problems (silly in that they ought to have been easy and clearly had nothing to do with real life work) but instructed me _not_ to run the code. How the heck am I supposed to know if I've solved the problem? How will I know if I even have the right approach? I don't consider myself an expert software engineer and so probably not a fit for the position, but that style of interview definitely hamstrung me.

For what it's worth, being able to run programs "in your head" is a very common skill required of Computer Science undergraduate programs, where you're required to write programs of medium length on paper during exams. You should be able to write out, follow along with, and reason about the correctness of a program that can fit on a single piece of paper without having to run it. Programming hyper-iteratively is not really a good thing, especially not in environments where rebuilds or test runs can potentially take hours.

Another reason not to have candidates run the code is that they tend to get really hung up with debugging trivial errors. I've conducted a fair number of interviews either way, and the white board interviews were usually more pleasant experiences for all parties than the interviews where the interviewee was expected to execute the correct solution in front of me. The latter almost requires giving them some kind of web or library API access, which then just makes the distractions worse. I don't want someone worrying about what the exact name of a sort function is; that's not what I'm trying to evaluate in an interview.

I would never do a take home test for an interview. I did that once and it was such a waste of time.

i've done three over the years, complete and utter waste of time.

i also had some wierd binary tree questions when i interviewed at yahoo, was a total turn off as i was interviewing for web/front end related job. which probably would not have used any of this type of logic, ever.

Reply on news.ycombinator.com