The last time I had to do a test it was on site and I was just out of college. Most interviews just talk about the challenges of the team, my past work on similar problems, and how I solved them. I've been on the other side of the table too. 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.
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?
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.
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.
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.
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.
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 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.
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.