I've never been asked to do a take home interview assignment, but I actually have the opposite attitude. I would much rather spend a few hours putting together that I feel good about than spend 10x the time cramming interview prep.
I prefer a take home over some LC as you can learn a lot more by seeing somebody's repo, tests, code, etc. than their rote ver of reversing a linked list ...but LC is cheap, a take home that respects the developer's time isn't.
Or, you know, you don't cram for the interview and just do as well as you can and let them evaluate on that. If you give me a meaningless take-home assignment, I have to actually write working code for it that looks good. If there's a trivial problem in an in-person interview, I can often "blah blah blah" through the more rote parts unless they really ask for details.
There's no wiggle room on a take-home. The code you write either does the thing or it doesn't. If you don't remember the exact way to do something in an in-person interview, you can express your general understanding to the interviewer and probably get some/all the credit of actually knowing it.
> Or, you know, you don't cram for the interview and just do as well as you can and let them evaluate on that.
Sure, depends how much you want the job and what your general approach is. If it's a competitive job then you want to optimize for the interviews. Last time I interviewed, the potential impact on my income and net worth over the next decade was significant, so I took it pretty seriously.
Oh sure, but then as the interviewer, your take-home is also likely to be gamed by someone cramming for that too. Motivated people can always do too much work for a project. Whether it's a live coding thing, a take home exam, or a whiteboard problem, none of them really give a solution where someone isn't going to spend 100 hours prepping.
I did one that was time limited (2 hours, automatically timed and enforced). The exercise wasn't hard, but it did have some tedious quirks which meant I wasted quite a bit of time. But I thought "fine, I can jump through this 2 hour hoop". After I submitted it, it turned out there were some previously undisclosed extra steps where I had to record videos doing the kind of things i'd expect to do in an actual interview (talk through my solution, and talk about a project I'm proud of). I immediately lost interest.
If the person requests it, we pay for interview time as long as the hourly is reasonable. Not a problem.
The real question I have for you is, how would you prefer to prove to me you can actually do the job? In person coding exercise? Isn't that more stressful?
I've always conducted interviews where I've given system design questions, and data modelling questions. Never found that coding exercises give good enough signal to justify the time investment on either side. If you want to catch someone in lie, i.e. they can't code at all, just give them something of fizzbuzz-level difficulty as a basic filter.
Depends upon how much proof I think I need to see. Both min/max are an hour but you can spend as long as you'd like on some. We take fun problems (github challenge projects I've spent days on just for fun) and give them as tests. We ask you just to spend as much time as you want to give us a sense that you can actually code and give us a sense of your coding style. We're mostly looking that you can 1) actually solve problems 2) write legible code 3) write maintainable code.
We don't give out dumb, tedious quizzes or anything. These are actual projects written to be fun. We don't get many/any complaints.
We also give out the coding test very late in the interview cycle. I'd say we hire 80% of the people we give tests to. We already have a pretty good idea you'll be a good fit by that point. So we're not wasting your time.
No issue with take home approach, I think it's incredibly valuable if done in a manner that respects everybody's time.
Personally I'd probably do some sort of FizzBuzz/LC easy type low filter and then a fast (i.e. no compiled langs) take home in an area adjacent to the job description paid at said job's rate with a time expectation so you don't end up getting billed 20hrs for a Node RESTful API.
We very infrequently get asked to reimburse for time but we do limit how much when we do.
We usually give various challenges as take homes which people find fun and engaging, projects that I myself have spent hours or even days trying to solve in my spare time. We want them to be fun. We rarely get complaints.
We're happy to accomodate if you'd rather do it in person or over zoom. It's really up to the applicant.
I can appreciate that and obviously what you're doing is working out for you :)
Guess I'm prob the odd one out here -- unless the job was incredible (like pair programming with J Carmack) I wouldn't be able to commit to any meaningful unpaid take home as I can spend that time programming for profit rather than solving challenges for a company that may or may not work out.
That's fine and up to you. Our interview process is extremely streamlined and requires 1/2 - 1/5 the time of most engineering interview processes. We do require someone to show they are capable of doing the work. How would you prefer to do that so I can take your feedback into account?
That really is the $1m question huh, wish I knew tbh. Even ignoring the unpaid work aspect the other Catch-22 is sure, you might filter a few "only good on paper" candidates but if you're hiring "top talent" what is a 5min Flask API going to prove?
For a coding eval like that to be useful beyond jr level it'd need to be decently complex which usually takes a while to develop. Maybe an open ended (upfront no expectation of completion) kinda "see how far you can get in 1hr on this complex thing" could be a fair middle ground as laying some good groundwork is a pretty solid insight into their coding process.