Comment by nallerooth | Hacker News Reader

Comment by nallerooth | Hacker News Reader

As a follow up to the first interview, we give promising candidates a quite simple task to solve at home and then send back via email the next day. This is used both for some basic evaluation of developers skills (whether they actually solved the problem, did they catch the small oddities hidden in the data set, did they document and write tests, etc.) and as something to discuss during the second interview, in which the candidate talks to one or two developers.

I also did a second code test, which I got to do alone on an offline laptop. The test had a time limit and it was designed in a way that you should NOT be able to finish it on time. This was communicated to me several times before I actually sat down in front of the laptop. The goal with this test is to see if a person can solve problems under stress, and if the person writes decent code that works, or just hacks something together and moves on to the next step - leaving a trail of bugs.

Overall, I think this has worked out great for us, but it might not be a good process for everyone.

Some time ago somebody mention in HN a process which sounded pretty good and fair. For promising candidates:

1) Meeting where you are presented a problem and asked to immediately give your thoughts on how you would approach it.

2) Some days, for example weekend, to work on the problem. Candidate gets a monetary compensation for this time.

3) Next meeting where you present the solution.

Yes, there's always a risk that somebody will get somebody else to write the code, but having to explain before and after reduces the risk. Paying for the work shows you are serious about the recruitment.

> Paying for the work shows you are serious about the recruitment.

In that case candidates should also pay companies to show they are serious about the position

You expect people to write documentation and tests for an interview coding challenge? I sure hope you mention that expectation or at least strongly hint that you're looking for a production-ready coding mindset. It would never in a million years occur to me to write documentation or tests for an interview coding challenge.

This honestly surprises me. The coding challenges are pretty much always simple enough for a junior to complete. The only way I've ever seen to set yourself apart from the bottom half of applicants is to include tests, comments and even documentation. I also wouldn't expect that to be in the instructions, otherwise everyone would do it and you'd be harder pressed to find candidates to eliminate. I'm curious to know if completing the challenges without tests etc is commonplace. Does anyone else think it's an odd thing to expect?

So the company gives you a limited amount of time and no access to the internet and expect you not to hack something together?

If I have a problem to solve "under stress", usually it's just a one off to fix something in production until I have time to write it, refactor it, put a unit test around it, and a code review.

Yeah why not just ask a surgeon to perform in a janitor's cupboard. No gauze? No problem, improvise with a mop. Remember, the aim is not to actually perform the procedure, just see if you solve problems under stress.

Reply on news.ycombinator.com