> It's usually easy to tell if the applicant is a quack or if they are skilled by how they talk about different technology: commiserating about familiar pain points, how they solved common problems. I almost feel at this point that it's unprofessional to hand out tests to people.

The problem with what you're describing is that it's using a proxy (discussion) to vet a particular skill (ability to program).

It's very easy to vet someone's programming skill by having them program, and it doesn't take much longer than a wide ranging discussion, so why not skip the proxy and test what we're actually hiring for?

Should a programming test be several hours (or several days) long? No. But an hour or two, I can't see how that's a terrible imposition.

When I was an industry analyst, I did a lot of writing (and still do). We absolutely needed to see writing samples from job candidates. If they had articles and so forth that had been published, great. But there's no way we would have hired someone without evidence that they could write.

> Should a programming test be several hours (or several days) long? No. But an hour or two, I can't see how that's a terrible imposition.

Agreed. However there are multiple comments discussing "5 hour assignments" and "take home quizzes", which I find to be insane, frankly. But if it's worth it to you, go for it I guess?

Maybe just ask applicants to spend an hour or two onsite without internet making them to solve project euler-type problems and discuss their solutions afterwards.

I’m sure you can somehow include technologies relevant to the position and keep the problems to the same scope.

Or these companies could begin creating actual value instead of just draining it from the world. Why don’t they expand their pipeline that converts intern/junior positions into more senior positions? And make it a big enough so they don’t need to hire as many ready-made 10x engineers from outside.

> Maybe just ask applicants to spend an hour or two onsite without internet making them to solve project euler-type problems and discuss their solutions afterwards.

I 1,000% do not care about someone's ability to solve a random programming puzzle without the internet.

Again, this is a (bad) proxy for the skill I'm actually trying to hire for. If I'm hiring a backend engineer, why would I ask someone to implement QuickSort? Wouldn't it be better to give them a realish application and have them add a feature or fix a bug?

> Why don’t they expand their pipeline that converts intern/junior positions into more senior positions?

My company has a very healthy pipeline of interns and junior developers. In a year or two, they'll be very good. In five to ten years, they'll be amazing. But I also have shit that I need to get done by the end of the month, and I need people with years of experience to complete them.

And regardless of which level I'm hiring at, I want to see them code, and I want it to be in an environment as close to how they will be working as possible. Google, Stack Overflow, an IDE, a build system, unit tests ... I want to see how they will perform as Software Engineers, not Euler-grinders.

Yeah; I think the whole "coding tests" thing is very much a Silicon Valley thing (which has of course been adopted by some non-SV companies, but its not the norm). I feel bad for HN readers who live there and that's all they know.

The best advice I've ever heard about interviewing is that you need to mentally reframe it from "I need this job" to "they need me, convince me to work here". A big part of this is building a network and finding jobs through that (which is how everyone has always found careers, mind you); when you're introduced positively through a third party the team trusts, the conversation inevitably biases more toward the team hunting you, not the other way around.

And if you can't do any of that then you should probably be happy that companies do big project coding/design interviews that give you a deep chance to show off your skills. Over half of what teams are looking for in candidates isn't the hard skills; its social aptitude, teamwork, networking, the soft skills. If you don't have a network and had to land this interview via a lowest-common-denominator recruiting page or email, then at least you can dazzle them with a great project, but you're already starting out behind.

My company tends to hire more junior developers, I've been pushing for years to raise our requirements for certain teams, but its a cultural understanding problem from people at the top. Coding tests are the only strong indicator I've found for the interviewing process. I've had candidates talk their way through all of the other steps, only to find they can't code their way out of a paper bag. I really think the only accurate way to tell how well someone codes, is by looking at their code, and a coding test is a good way of not only doing that, but also comparing code from one developer to another in a controlled manner. I'll take it over hackerrank and other similar shitty websites any day.

Am not in the USA, Netherlands actually.

For my internship I first had a good conversation with the lead developer. After it was determined that I was a culture fit and didn't bullshit them, I got a small simple assignment which I had to do on a whiteboard. Later found out it wasn't really meant to figure out whether or not I could write a simple function, but more to see what my thought process was. Like, did I instantly start writing one big function that did stuff - or did I break the problem down into smaller steps.

Anyways, the interview for my second job (for a fairly big consulting firm) was purely focused on culture fit, and questioning about stuff I've previously made.

Third and current job was the same as the second - only on my initiative I came by on another day to check out what the other developers were actually doing and trying to help them out.

I don't think a test is really useful, if I'm not up to par (or they don't meet my expectations) either of us can decide to end the contract in the first month. This focus on tests strikes me as silly, especially in the USA, since you can just be fired for no reason anyways.

edit: I do have an (outdated) github repo with some code, but not much else.

My team does a take-home coding test and we've found it to be very successful. The people we've hired as a result have been great and actually told us they preferred it to other interview methods they've encountered.

The challenge is coming up with a standalone task that demonstrates the skills needed for the job while _actually_ requiring the amount of time you say it should take. Seems like most commenters here are upset that a "2-hour test" really takes 6+ hours. That should never be the case and I wouldn't want to work for that place either.

Another key part of this is should a candidate pass the take-home test portion of the interview, the in-person interview should be fairly quick and mostly a judge of fit/character. It should not be loaded with more tech questions. The reason this works best for everyone is the interviewee doesn't need to waste a vacation day on-site unless they have a really good chance of getting the job.

I wish it were so, but it's not. I usually start interviews with 5-10 minutes of talking about a previous project of the candidate, digging in to see how sophisticated the work was, how they solved problems, etc. I've had plenty of examples where someone bullshitted well enough to pretty much convince me that they knew what they were talking about, only to have it become clear in the more hands-on part of the interview that they couldn't possibly. I admit I'm not a great interviewer, so perhaps a really good interviewer could tease those things out, but I maintain that it's not always easy.

I think the usual situation is that the candidate was on a team where some impressive work was being done by others, understood it enough to talk about it in detail, but didn't actually do any of the challenging work themselves and couldn't work at that level consistently.

I'd like to think most people aren't actively lying or bullshitting, but it's easy enough to implicitly take credit for work done by a team when you're trying to sound impressive.

Just my two cents, but as a candidate I much prefer the tests to a whiteboard. I've had interview tests for a majority of my recent (senior level) positions in NYC, but the questions generally aren't to this extreme, certainly not basis for a new startup level problems.

More like "we've laid out an API contract, implement these 3 endpoints in a language you like along with these few extra small requirements and some unit tests". Usually takes 2-3 hours and I think it's a more fair assessment of my work and at least I get to use my own environment and work on my own time with tools I know rather than with someone sitting over my shoulder and a marker. It also helps drive the discussion during in-person interviews away from the binary tree puzzle type questions and focuses more on design decisions and other considerations I took in to account.