Take-Home Interview Assignments

I worked for a company that did a 3-day, challenging take-home problem. It was a big ask, but it was amazing for getting a sense of people's problem solving and coding abilities. (The final result would only be 1000 lines of code or so, but 3 days provided time to think and experiment with different approaches.)Maybe paying people for the time if you end up saying "no" is a nice compromise?If you are potentially serious about hiring the candidate and they are serious about p

I've participated in a lot of interviews on both sides of the process.In my experience, the whole process goes a lot smoother when there's a take-home exercise. It turns the in-person interview portion into a technical discussion about a recent mini-project unencumbered by NDAs and trade secrets.If you can't quickly determine if an applicant "cheated" on the take-home exercise through a simple discussion, then you may want to recuse yourself from performing interv

You're implying they're trying to make you work for free?I think it's a rather simple test to see if you're up for the job. Understanding the problem is already half the solution; to me, this sort of a qualifier seems to be much more appropriate than a 4h take-home of a random task where it's not even entirely clear now it'll be judged, or what the problem statement really is.

When I was interviewing in the past I was usually refusing any take home projects, if you don't want to spend 30 minutes talking to while watching me code it tells me something about your priorities.However whiteboarding is also terrible.I prefer getting a real world / work related scenario problem, and solving it TOGETHER with the interviewer: if I'm stuck, as opposed to a hackerank codility challenge, there is a good chance they will let me know and hint in the right direc

I'm a senior engineer and lead developer with 16 years experience.>Take-home technical assignment (~4h) or similar at candidate's choosingYeah, I'm not doing that. I don't feel like spending four hours doing unpaid work in my free time, nor do I really feel like setting up a dev environment on my personal computer in the first place. It's probably actually more than four hours too and my time is valuable.I am extremely confident that I have no problem getting

I would immediately end my interest in a company if I was asked to do this. This is far too general a problem, which will harm the interviewer as much as it will harm the interviewee.Contrast it to giving a candidate some slightly broken code in a framework related to the role and then asking them to a)fix it and b)implement a new feature of their choosing and document it.The advantages of the latter approach:* The interviewer doesn't need to prep beforehand as they already know bo

Yah, I've been interviewing a little lately, and while I understand the need to see if the person can code, white-boarding isn't really it. I've been doing this long enough that i've been the guy on the other end of the table more often than not.Anyway, over the past couple years I've steadily moved into the take home test camp. These can be tweaked such that its apparent if someone tried to google an answer and use it.But that said, I'm not sure I want to be

It's been surprising to me to read through the comments posted here and seeing how most people seem to really despise take-home assignments during the interview process.Speaking as someone who absolutely hates live-coding something during an interview (unless, maybe, by chance it's a practical exercise ... something like "build up this simple CRUD web service" ... not "solve this leetcode problem" ... but this is pretty uncommon in my experience, unfortunately),

You don't simply fire off a 6-hour paid project to everyone who applies. You do some screening and conversation before-hand.It always seems strange to me that people won't bat an eye at taking a day (or more) off work to come on-site for technical interviews, yet the idea of giving someone a 6-hour project do at home, at their leisure, is somehow a bridge too far.In real-world hiring experience: I gave candidates a choice between on-site interviews and take-home projects for a wh

I've hired dozens of developers and I do use take home assignments but primarily to weed out obviously unqualified candidates. My objective is to keep good developers interested through the entire process but arrive at a "no" decision as early as possible. My take-homes typically take qualified developers 15-20 minutes to complete but require some amount of research to complete (e.g. third-party API documentation). I've found that if you ask too much of candidates too early i