But it’s not generally tolerated. You end up optimizing for sub-prime candidates because those are the only ones desperate enough to take 4-6 hours out of their free time for a company that hasn’t even bothered interviewing you, yet.
If they want to turn the onsite into one big work sample, by all means, that sounds very effective (and something I’ve seen work well). But in my experience, you’re going to deter qualified candidates by forcing them to do take-home assignments.
Again: this is true of "work sample" tests in their mainstream implementation in our industry (spend 6 hours jumping through a hoop for the privilege of running a standard, nondeterministic interview gauntlet), and those hiring processes are a scourge.
But there's a right way to do it: give work sample challenges and then, at least for the most part, end the technical qualification part of your process there. You spend 4-6 hours at home instead of spending 4-6 hours in front of a whiteboard doing dumb coding challenges.
If I was looking for a job right now, I'd probably refuse to interview anywhere that gave me take-home problems that couldn't promise that a strong result on those problems would take me all the way through technical qualification. But a company that could offer me take-home problems and conclusively make the technical part of the decision on whether to hire me based on those problem would be a strong prospect.
We subscribe to the work sample test as your best option for technical validation, but we also limit ourselves to a small window of time, on site. We pick something we recently worked on, distill it down to something we can knock out in 15 minutes, and give the candidate about 45 minutes to work through the distilled problem and then we explore for about 15 minutes their solution and how they would make it production ready (as a conversation). We then have another 45 minutes of designing a solution to something more complex we recently had to work on, again distilled down. It involves a white board and boxes and arrows. The last 15 minutes is time for them to ask whatever they want of us. We have two interviewers on this technical portion to level out false reads by the other interviewer (I thought this part was a poor answer, but the other interviewer has a different view of it).
I really like it so far. The part I'm battling on it is if the current coding part selects against Java developers. Part of the code we want right now requires a unit test with dependency injection to match an interface. So many of our Java candidates simply can't set up a running unit test. They are used to layers of framework already set up in the IDE and just clicking on stuff. They have full access to Google. Maybe it is good we are filtering out these candidates, but I'm not sure. Still thinking on it.
> The part I'm battling on it is if the current coding part selects against Java developers.
Yes, it does. And let me put it this way: I've used C# and Java at most of my jobs, those theoretically would be my comfort languages, yes?
I do not use those languages on interviews. I often just use C++ (!), or Rust (free unit tests!) if the company tools allow for it, or worst case I'd learn some Python basics. C#/Java are very awkward and boilerplatey in such a small time frame as 45 minutes.
Interesting. To clarify, you are saying that these boiler-platey languages, it is not fair to write a unit test in a 45 minute time block with access to Google? I'm not a Java guy. All the languages I've used, this would not be an issue. Again, I'm wrestling with it because it I feel it should be easy but like 80% of our candidates who chose Java struggle with it.
It sounds like this is a pick-your-own-language type test. I'd suggest scoping down to one, or at most, two, simple allowable options that your team is already pretty comfortable handling.
I've been on the reviewer side of a handful of "choose your own language"-style take-homes recently and found that it's really not good for the candidate if they actually end up using something that wouldn't have been the interview committee's first or second choice. There have been cases where choosing a less-trendy-but-still-totally-viable toolkit has effectively disqualified a candidate, with several committee members not even considering it necessary to look at the code. This is very unfair and lame but an unfortunate reality. I asked that the test be changed to constrain the options at least to a list that wouldn't be immediately disqualifying.
You could advise the candidate ahead of the interview something along the lines of "you'll be asked to write a code sample in either Ruby or Python -- you'll have full access to Google, but you may want to brush up on the basics of these languages if you haven't used them recently".
This does two things: first, it prevents the issue you have, where you're essentially not sure if you're correctly scoring the samples produced. Secondly, it really requires you to constrain the problem to things that someone who has barely used language X or Y can do within 45 minutes.
The theory with pick your own language is they should be able to feel fully comfortable (interviews are already stressful enough). If they picked Rust, Scala, or a lisp dialect, (or anything the interviewers are unfamiliar with), it can even be a better interview because we get more insight on how the candidate communicates and their ability to walk someone else through their solution. A potential other bonus is less biases leak through from an interviewer on "that is a strange way to do that in language X."
> The theory with pick your own language is they should be able to feel fully comfortable (interviews are already stressful enough).
Ah, but there's the rub. Candidates are trying to please the interview panel. If you don't provide guidance, the odds that they'll just use whatever they think the interviewers most prefer are just as good, if not better, than the odds that they'll actually use whatever makes them most comfortable.
You said yourself that since some candidates pick a language that you don't know well, you can't really tell if the failure of a large number of those candidates is reflective of a bad test or just a mismatched candidate pool. IMO, if you're going to stick to the "pick any language" thing, you should at least find out and ensure that any language the candidate picks will have a fair shot.
> it can even be a better interview because we get more insight on how the candidate communicates and their ability to walk someone else through their solution.
You can still get the candidate to communicate and explain his choices if you give an option: "either Ruby or Python" or "either JavaScript or Visual Basic", etc. The problem with having this happen in a language that the interviewers don't know reasonably well is that they are much more vulnerable to the smooth talker who can present incorrect information confidently, and they won't have enough background/anchoring in the subject matter to know the difference.
> A potential other bonus is less biases leak through from an interviewer on "that is a strange way to do that in language X."
I would say that if you're worried that interviewers will load in biases toward their preferred shortcuts etc in a specific language, that you should be equally worried that some good candidates are being excluded for choosing the "wrong" language in an any-language-goes test.
Above, you mentioned that there'd be a positive response if a candidate used "Rust, Scala, or a lisp dialect" -- these are all relatively trendy. What if the candidate used nim, Pony, or some other language that hasn't pulled in to the hype superstation yet? What if the candidate used a language that's not-so-trendy anymore, like Visual Basic, Cobol, or bash? What if the candidate used a programming language of their own design, and brought a copy of the compiler with them on a flash drive?
I'm asking because I've seen this in practice. Candidates for a devops position who chose to use bash to implement the very simple take-home task they were given were laughed off by several other members of the interview committee, despite being potentially high-value senior people -- they were at least senior enough that they're more comfortable performing sysadmin-style tasks in a shell, rather than using a massive CM framework or an awkward amalgamation of Python scripts running os.spawn.
It feels like this type of thing happens a lot, in the same sense that very often, "unlimited PTO" just means "guess whatever amount of PTO is acceptable around here and hope you get it right".
I guess it depends how far back you're starting from. I suspect most Java developers don't spend that much time creating projects from scratch (I do, but the work environments I'm used to suggest I'm an outlier).
I tend to give candidates a simple project already to go, with junit and hamcrest, possibly mockito already available, and ask them to go from there using a provided IDE (which I attempt to get set up as near as they prefer to work as I can). This generally works out fine. I certainly don't feel the boiler-platiness of the language gets in the way, mostly because the IDE is generally capable of doing most of the lifting with that respect anyway, but also because over the timescale of an interview question, we're generally only talking about a couple of classes at most.
It starts from scratch. Familiarity with one's tooling is important. Setting up a project seems like it should be part of the basics. Would it not be unfair to others who choose a different language if Java gets hand holding in terms of initial classes?
For 20% of Java candidates, they do it just fine. Heck, a few echew the IDE and are fine working completely from the terminal (these tend to be particularly very solid at coding). Still wrestling with the idea.
The folks that already work with us (who wrote Java in a former role) see no problem with setting up a project nor do the folks that we hired recently (seeing as they likely passed that technical interview). But that all could be bias.
Maybe you are right. Maybe the next candidate or five in Java will get a base project and we can see how it goes.
Do you give them "their" tooling? I can set up a project of the type you describe in about five seconds, because I have a template for it in my IDE. The best defaults for this that I've seen are provided by IntelliJ (do you provide this in interviews? It seems legally challenging to do) and would probably take me 5-10 minutes to navigate.
I think Java depends much more heavily on powerful tooling to do the heavy lifting, and my experience of using that tooling when I haven't had a chance to configure it in advance has been pretty miserable.
If they're coming in, I'll hand them a laptop with the project set up and ready to go, with IntelliJ running. If they're normally an Eclipse user I'll swap to Eclipse shortcuts and help them manage the IDE as we go.
If it's remote, I'll ask them to share their screen with me with a project set up and ready to go, having emailed them a copy of the interface we're going to implement about 30 minutes before the interview.
It depends on context as well. Where I currently work, they wouldn't have a chance. The corporate firewall will prevent them talking to Nexus, for example. It just wouldn't be fair to expect them to navigate that sort of thing in an interview.
In general, if I'm asking them to code on my (or the company's) hardware, I'd start from an existing project, if only because I wouldn't expect them to be familiar with the installed tools (oh, you use maven? I'm a gradle user ... etc.) On their own laptop, I'd expect them to be more comfortable.
I'm doing a remote interview on Wednesday. That'll be on the candidates machine (because screen-sharing is easy, getting them inside the corporate network, not happening), and they've been told they'll need an IDE ready to go. I'll expect a project set up and ready to go before the call even starts.
On your own hardware, I'd expect you to be able to have a blank project up in minutes, so yes, I expect somebody who's not travelling to our site to be able to take 5 minutes out of their busy day to create a blank project.
> Familiarity with one's tooling is important. Setting up a project seems like it should be part of the basics. Would it not be unfair to others who choose a different language if Java gets hand holding in terms of initial classes?
Also, how much of their day-to-day work is going to be setting up new projects? I sometimes feel a better test is to be thrown into an existing code base and asked to make a change. It's far more indicative of the sort of work somebody is likely to actually be doing.
We ask that the code they write have a unit test. The nature of that unit test is that it has a dependency. They can mock however they like, but passing in an object that represents the dependency (dependency injection) is the easiest and most straight forward way to do that. That object should have a method on it (a know method, with a known signature, also known in some circles as matching an interface).
If I was doing this at Google, I would spend a lot of time thinking about test fraud. At a 40-50 person company? Not so much. We do simple follow-up things that raise the amount of effort you'd have to put in to fraudulently submitting work sample tests, and we know pretty exactly how we'd randomize our work sample tests to make it hard to cheat (at least, hard to cheat without doing something we'd be interested in anyways) --- but it's just not worth it right now.
Work sample test fraud is one of those things that sounds like a huge deal on message boards, but when you game through what would be involved in doing it in real life, it makes very little sense.
To my mind, the simplest and most straightforward way to combat any fraud is also beneficial because it gives you even more information about the candidate:
Talk to them about the code they wrote.
Have a conversation, as if they were already your co-worker, with the exercise as the subject. Go through it, ask them -- non-adversarially -- why they did X, what they thought about requirement 2, how they could get better test coverage for Z. If you see something that seems to be a mistake, talk about it. If you see something awesome, discuss it. I can't imagine someone incompetent being able to bullshit their way through detailed discussion of code they were supposed to have written.
And this provides valuable info about how this person thinks and communicates about the work you want them to do.
That seems like a good idea, but does somewhat detract from the notion that once a candidate does the work-sample he is done with the technical part of the process.
A nice approach I liked (back when I was interviewed by Thoughtworks years ago) was that one of the interview stages was to take the assignment you'd done and apply some new requirements to the story. It rapidly makes it clear if the candidate actually did the assignment or not.
If majority doesn’t, why create a process that punishes everyone? People are lying on the resumes is a very common argument made by creators of insane interview processes. It feels weird to start a relationship with a company with assumption that I’m a cheater.
Who said anything about punishing anyone? 1) tptacek advocated for a specific kind of interviewing, 2) I asked him if he had ever seen a problem that I thought might be an issue with that method, 3) he explained that he wasn't worried about it because of X, Y, Z but acknowledged that for other companies it could be a problem, 4) I thought his answer was very reasonable. Also wool_gather and swish_bob added some useful ideas.
I'm not sure why you felt the need to come out guns blazing.
I agree with that. Sounds like a good process. Although, I am too cynical to believe any company that tells me this will be the only technical part. Too often do recruiters lie/misrepresent the recruitment process. Some seem to operate on the sunk cost fallacy, where you just see it through because what's one more round after already doing several?
I understand your cynicism but: who's got two thumbs and can offer an existence proof that there are companies that really do hire this way? :)
My best guess is that there aren't going to be many companies that will give you definitive statements about what their process will be after challenges who are lying about how they digest work-sample responses. But I don't know and am prepared to be wrong about that.
I've only had one take home assignment task that really worked like that. I did pretty good at it and the interview.
I was co-owner of a startup at the time, the guy I interviewed called me up and said you did really good but I think you really don't want to work here - my wife said 'Wow, that guy was really smart' considering how some things went later it might have been better if I'd said no I really really do
The extremely obvious problem with this is that there's no way of preventing someone from completely blowing a hole in your interview process by simply paying for or hiring another developer to do the take-home problem for them. At that point they've gotten past the technical requirements and now only need the soft skills to execute on it once the rest of the interview process continues.
This is why take-home problems are almost completely irrelevant except for filtering out good candidates. Eventually those problems optimize for perfection which help out those who 'cheat' at the process and people that otherwise put in earnest efforts are rewarded with denials. This is something I've experienced before in my job search where I would put in an honest effort and get 90% of the problem solved, but get denied because my solution wasn't flawless.
So allow me to call bullshit on your own claims that this is the right way of determining technical qualifications.
Not all companies handle it like this. I had a take-home exercise as part of an interview last year. I hit a real snag on a fairly small part, I couldn't figure it out, and I ended up leaving a bug in my submission because I simply ran out of time. Very frustrating.
It was raised at the interview; I admitted that I knew it was there, and that I hadn't been able to figure it out. We discussed possible causes: it actually turned into a pretty interesting, though minor, technical conversation. The interviewer eventually told me that he had figured it out after a little investigation (and I expressed my gratitude for the explanation!)
I ended up getting an enthusiastic offer from them.
I'd couple the take-home with a substantive discussion following submission. Harder for a fraudster to talk about how they came up with or tested their solution and how they'd improve it in a real production version.
> I would put in an honest effort and get 90% of the problem solved, but get denied because my solution wasn't flawless
It's possible that the company stated the take-home work in terms of non-negotiable deliverables, and their baseline for allowing a candidate to move forward is 100% of those, and they prioritize candidates who take initiative and do more work beyond the base requirements.
... not that I would agree with such a process (it biases towards people with more free time, like people with fewer dependents and people who are currently out of a job / underemployed), but it's very possible that this is what you faced.
As a new immigrant, my wife had trouble finding work as a designer until she was given a take home work sample test. After that, the company that gave her the test hired her quickly and she has been doing well with them ever since.
I’m currently doing the gauntlet thing myself, but none of the interviews I’ve done have asked any technical questions pertaining to the role that they actually want to hire me for. It’s all generic stuff that frankly I would have done better on 20 years ago.
The best interview I ever had was a 2-hour onsite work sample, followed by 1/2 an hour discussing what I'd come up with. I was offered the job the next day.
Surely most people would prefer this to whiteboard tasks?
The best interview I had was a few hours of friendly conversation about the details of my resume.
Then I was hired under probation, as everyone there was, and the understanding was that I could be easily dismissed if it was clear that I wasn't working out.
There is no way in hell I'd ever sign up for that. To be expected to quit your current job on the hope that the probationary period works out is insane.
Yes, I've learned that the hard way. Provided they give you payment in lieu of notice, they don't need much of a reason to let you go.
Myself and a co-worker were once let go for "performance reasons" at 10 months - just after project completion (successful). It was beyond my probationary period, and no issues where raised in the 2 performance reviews.
Their notice period was just 1 month. We were effectively cheap contractors.
My advice now is to treat offers with a low notice period (of them telling you) as a red flag. The norm is 3 months, after probation.
This is only true in the most extreme case. Many companies have formal procedures around firing people for performance issues. Short of hr violations or literally refusing to do anything, I can't imagine someone being fired before 6 months.
Yes, above a certain size, companies typically have some formal procedures. But typically those are a fig leaf.
In many labour markets, there's a legal 90-day probation or equivalent. You bet your boots some people get dismissed at 80 days. Or the job was contract-to-hire, and the contract doesn't "get renewed".
But on top of that, literally every company I've worked at or any of my friends have worked at (including lotsa startups, two of FAANG, and some in-betweens) will terminate when they want to terminate. In most non-European labour markets that I'm aware of, there's a penalty for doing so, and the company just pays that penalty and gets on with it.
Sometimes there's more security than that, I've heard (but not experienced). And sometimes the company puts in large effort to cultivate the underperforming employee first (had that happen to me once; they tried and I tried but it didn't work out). But the overwhelming majority of cases of my first-hand and second-hand experience, dleslie's summary is about the whole story:
Most places I've worked at in the US have a 90-day probationary period. There's still red tape, but not as much. More common now, however, is to hire people on as contractors for 3 to 6 months. If you work out well, they'll fast-track you to becoming full-time without a second thought. Otherwise, your contract is up and they choose not to renew it. Which makes things less dramatic if there are issues.
Fair enough. It's to some extent a cultural thing (there's no need for explicit probation in the US since most employment is at will), but I too wouldn't necessarily like a probationary period, even though I don't foresee it actually being an issue.
In the US there often is a formal probationary period at larger companies which mainly accomplishes one thing: reduce the HR red tape if a new hire isn't working out. During the probationary period it's generally easier to make a case (i.e. little or no documentation needed) that 'they're not working out' and HR will be OK with it vs. after the probationary period, you typically have to 'document' them out of the company.
I'm in the USA, and this (probationary period) has been the case with every job I've had in the past 30 years. I've never heard of a company not doing this in fact.
Same here. Though many mid-size / smaller companies might not advertise this fact (their HR policies are often a bit more ad hoc than larger companies if they haven't been involved in as many labor lawsuits)... but pretty much if there's an HR department, the probationary period exists.
I'm not sure how much this is considered but in my state, which is an at-will employment state, being unable to preform job tasks due to lacking the knowledge or technical skill is explicitly defined as NOT a demonstration of cause for termination that would absolve the employer of their financial responsibility toward unemployment compensation.
I suppose you do sort of feel a little stressed during the trial period but I've never seen anyone fail it and it applies at every company, so there's no escaping it anyway. When it was introduced some people got quite upset but I can't really say I think it's had a bad effect.
I guess from the companies perspective if they realize they made a grave mistake they can back out of the hire, but they are still very careful and rigorous in the hiring process just like always. It also allows the candidate to bail if they realize the company wasn't what it said it was. It goes both ways. Again, in practice it seems mostly harmless.
Perhaps the US wouldn't do so well with a similar policy maybe even just due to the crazy healthcare situation going on over there. I couldnt say.
> I suppose you do sort of feel a little stressed during the trial period but I've never seen anyone fail it and it applies at every company, so there's no escaping it anyway.
I'm not sure what you mean by "it applies at every company". Getting hired and then fired a week later is virtually unheard of. This is not a fear I have, at all.
But if you told me it's probationary, that is totally a fear I'd have, I'd get paranoid, so I'd rather work somewhere else. You're basically telling me it's not a real offer in my eyes, and I should not expect stability.
> Again, in practice it seems mostly harmless.
It's extremely harmful in a place with poor labor protections that is the US, for reasons that I don't feel like expanding on and that you can educate yourself on if you wish.
By "it applies at every company" I mean it's part of the contract no matter where you work because by law the employer is allowed a 90 day trial period, so they all put it in the contract, so one offer is just as real as the next and it's just something you have to go through and yeah I guess it's probationary in nature.
Not everyone likes it or agrees with it, and I can only comment on the software industry here and not other industries but it's not the end of the world and the sky doesn't at all fall. When they introduced it a lot of people tried to make arguments like it would be abused etc and as far as I can tell there hasn't really been any drama. YMMV depending on country.
The best I had was a guy asked me to bring in my laptop and show him some code. We talked about it, he asked me to add a simple feature. I think it worked well for both side. Not much of my time wasted. No gotchas because of some configuration issue of setting up a project for the first time.
I had perhaps the most amazing interview experience recently where it was an open discussion. It wasn't a technical drill down but more a Q&A where you discuss topics relevant to the area you claim to have knowledge of and how it relates to the job you're interviewing for. It was the complete opposite of code this technical problem and a missing semicolon will get you a flat out rejection.
What clicked was I was finishing their sentences and knew precisely what they were asking. It was an incredibly rewarding experience which led to a same day offer.
As a junior I’d much prefer a whiteboard where I just need strong CS fundamentals and reasoning to a work sample where there are 10+ different dimensions I could be judged on like style, maintainability, whether I used the latest language features, how I solved the problem ( use libraries or from stratch?) there are just way too may variables and potential bias in the judges VS did you correctly turn the problem in a DP algo.
Hah, I had a sample test that I had to do after first being met on-site, which I thought was great.
Then they said my work sample was amazing, and they’d like to do an on-site Q&A about it, but when I arrived the engineer hadn’t even seen my work, and proceeded to just quiz me on obscure JS trivia.
Which I promptly failed.
They then rejected me even though they were happy about my work :/
In addition to covering all interview expenses such as travel food and lodging, candidates need to be paid for their time interviewing by the companies interviewing them.
Six hour take home tests is fine, but I want $1350 for that in advance as a consultation fee, and if I hit 6 hrs and it's not done yet they can keep paying until I am done or we can just end it, no refunds.
The idea that I should spend six hours doing free programming for random companies that say they are desperate to find anyone qualified is absolutely absurd and insulting. No one should put up with that, particularly anyone with an established and verifiable career.
It's even worse when you're a consultant. At the moment I'm faced with scheduling my fourth round with a company, and of course it's 5 hours onsite. I have the option of skipping the free lunch, they said. It's nice of them, but my monetary loss for that time (including commute) is enough to pay lunch for a number of people. All that, and they can still can you a few weeks or months into the job if you're a dud.
It's employment, not marriage, guys, lighten up with your strenuous and time-draining processes. We senior employees aren't as, is the word excitable, as the entry-levels about joining your workforce.
That does sound excessive. I've never had more than 2 rounds of interview, and even at that the first round was typically over the phone and the second on-site.
This is pretty silly. Candidates routinely spend integer multiples of six hours running interview gauntlets for tech companies that are notorious for negging candidates. None of them expect to get paid for interviewing. An at-home work sample challenge is strictly less onerous than an interview gauntlet, but because it has the appearance of something people have heard other people get paid for, it's commonly suggested that they should be paid, too.
why are you even interviewing for these "random companies desperate to find anyone qualified" if you are so disgusted by them?
The elitism of some engineers is mind boggling, instead of being grateful working in an industry that has so much demand that you can easily find a job at anytime, you complain about the process being insulting to your oh-so-important persona.
If i really want to work for a certain company because what they are doing excites me, then yes, i'd do a 6 hour take home test where I can probably also learn a thing or two and I am willing to bet a lot of other developers would too. As an interviewer, someone charging >$1000 for a take home test would be an immediate red flag and our mindsets probably don't match up.
It's good to see a full gamut of opinions on here. I'll say that mentalities like yours are why I'm a contractor in the first place -- you should be grateful for the opportunity, etc and so forth. No. I exchange my time for your money. If that's entitlement to you, we come from opposite worlds.
I'm not the guy who says he should be compensated for take-home tests above. I am however a senior engineer. I'm spurning any long interview processes because they cost money. I don't think it's entitlement, but if that's what you want to call it, so be it. It's called hours worked, hours paid, and in the West it's been a concept since at least the 18th century.
I agree with the statement "they cost money for both parties" but I disagree with "in that sense it's fair."
Individual consultant: loses 5 hours of interview time (and commute time) or take-home exam. Let's call it $800 for the sake of argument.
Company: loses 5 hours of interview time, plus the time it takes to "quiz" the exam.
Individual loses money that he / she uses to pay their mortgage.
Company loses profit because the time spent interviewing the candidate could have been spent working on feature Y of the application. So shareholders / VC's lose.
So you're saying it's fair that the individual contributor who loses half a day's pay in your interview process is equivalent (you DID use the word "fair" so that's an equivalence argument you made) to a company's loss of a few hours out of the many thousands of man-hours they rely upon? It's a .0001% of their profit, assuming the employers don't work a few hours more to make up for the lost time, because they will (they're salaried!)
Consultants also do not get paid vacation, or paid sick leave. They also don't get any of the benefits that a lot of regular employees get. But that's part of the game, they have to account for all of that which is why they earn much more per hour. A lot of those "customer acquisition" tasks cost time and may not necessarily yield a return, but that's part of the extra risk consultants have to assume and why not everyone is willing to do it.
Maybe all true with regards to cost considerations, but it doesn't support the notion above that a candidate's wasted time and money (vacation time and sick time costs money for an FTE) and a company's wasted time are somehow .. 'equal'.
That sounds like disorganization and poor internal communication, two traits of the organization probably not just evident in their evaluation of you. You may have dodged a bullet.
Gotcha, yes that makes more sense. I find a lot of unicorns are already doing this sort of interview, anyway. While I have never observed studies, it seems to provide better signals than white-boarding.
If they want to turn the onsite into one big work sample, by all means, that sounds very effective (and something I’ve seen work well). But in my experience, you’re going to deter qualified candidates by forcing them to do take-home assignments.