Hacker News Reader

Comment by chrisper | Hacker News Reader

>1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them.

A good reason not to work at your company. Why would I want to invest 4(!) unpaid hours into something where I am not even considered seriously yet?

I recently had a coding challenge, which was not only vague, but also took up two hours of my time. The end result was... nothing. Not even a "thank you, but we chose someone else." Since every then, I chose to not bother with long coding challenges anymore.

View on HN

Would you have preferred to spend a whole day on an inconclusive onsite interview? Or perhaps a phone screen during which you're asked to implement a hashtable for the umpteenth time?

As I said in another comment somewhere in this thread, one day people will learn to do this right. Hopefully this will happen before programmers as a profession have decided to never take code tests again.

You are right with that a whole day onsite interview is more time consuming.But personally, I think I can do better in a face-to-face evaluation than on a coding challenge where I have to guess the test cases from some vague description. In fact, face-to-face can show the interviewer how I think and what kind of questions I ask to figure out the way to solve an issue.

Maybe it is my lack of interview experience, since I only had like 3 or 4 so far, but I only 1 out of them left me with a good experience after the coding challenge (even if I did not get an offer yet).

Presumably you (the employer) have less time to do on-site interviews than to assign take-home projects, so landing a real interview is a much better indicator that my (the job-seeker) time will be well-spent. (Hiring is a two way street.)

At least an onsite interview typically includes expense reporting lunch, if not dinner, and maybe an opportunity to visit a city or a part of city you are less familiar with and possibly even sight-see a bit.

I don't think a phone screen is productive beyond a half-hour to an hour and anyone asking technical implementations over the phone is likely a worse interview than trying to whiteboard things (and that's still far and removed from actual programming).

Yes. The onsite means the company is investing just as much time and effort into the process as the candidate.

It's not just the investment. In a 4 hour take-home I learn close to nothing about the company I am applying for. In a 4 hour on-site I see the workspace, talk to employees, etc.

So if they do well in the take-home test, you give them an offer? Or do they still have to do the all-day on-site after that?

Do well in the take-home test? Come in, meet the team, do the culture-fit thing. Then you get an offer. And this doesn't need to be an all-day thing. Who wants to keep selling the company to a candidate all day long? :)

People usually have a coffee date first, before doing dinner. Here, you're doing dinner first, and then lunch. The first pass should be minimal in commitment, and give both sides a chance to get to know each other. They pass fizzbuzz or something doable in 15-30 minutes, you have a short convo about the company, and then you move on to the second pass.

Those other things being unpalatable doesn't change code tests being unpalatable.

As someone currently preparing to interview with Google I'd take 4 hours implementing real code over a (recommended) 2 weeks of basic algorithms, data structures, math, etc. revision.

You strike me as the type who would also balk at fizzbuzz and other 'typical' interview questions. What do you propose? Say you have to interview a candidate for your own startup? How would you go about it?

I agree with the parent that take home projects (as the initial filter) are a non-starter. It's because they're flat out abusive. The employer uses their position to offload the cost of their hiring onto job seekers. The fact that our first interaction is exploitative couldn't be a bigger red flag.

However I am completely fine with fizzbuzz tests, even take home fizzbuzz. But this literally needs to be something that will take no more than 10 minutes, and for most people a couple of minutes tops. And in the question have a disclaimer: if this takes you more than 10 minutes to do, this won't be a good fit, so save yourself the trouble.

I actually don't mind the idea of take home projects, but only after significant investment on the part of the company. They need to have something on the line as well if I'm to devote significant time to it. Paying a good hourly rate for the time to complete it is the most straightforward way.

I actually like fizzbuzz and stuff like that. My most recent and best coding challenge experience was one from Cloudera. It was 2 questions and I had 70 minutes time in total. The difficulty was not something crazy. To me it felt like something you would get as a homework in Uni, but slightly more complex. I was able to finish it in 40 or so minutes and even had fun doing it, because I did not get frustrated by lack of details in the problem description.

But when a company sends me 2 hours on some weird platform that tells me 3 out of 10 test cases work, but doesn't tell me why or what even the input is, I just get frustrated. One of the worst coding challenges was asking me to implement the cd (change directory) functionality. But the details were so bad that I had no idea if I have to invest time or not into edge cases etc. I basically had to guess the test cases, but eventually failed the test since I ran out of time.

Reply on news.ycombinator.com