10 ms·
Two years ago when I was applying for a job, every application requested a take-home test. After doing a few of these, I decided I will NEVER do them again. I w
by Oras 4y ago
Two years ago when I was applying for a job, every application requested a take-home test.
After doing a few of these, I decided I will NEVER do them again. I will not spend hours coding only to be (at best case) reviewed for a few minutes by someone from the other end.
I know you're saying it is a minor roadblock, but how do I know that you're not going to ghost my application like most of other companies do? That's why most people will not bother to do your test, not something about you, but the broken system.
- intelVISA 4y agoFizzBuzz isn't quite a take-home. A good screen is something that takes under 1minute so it doesn't disrespect the candidate's time whilst also being vaguely useful -- sure passing FBuzz means nothing but failure is pretty much the red flag of red flags for SWE hiring.
- throwaway2037 4y agoIf they paid you 100 USD / hour (say, max 2-4 hours), would you do it? I would. In some places, Amazon gift cards could be used. To me, they should do at least one solid hour on the phone/vid/in-person technical interview. If OK, then proceed to take-home test.
- zeroonetwothree 4y ago$100/hr is a low salary for contract work (at least for software engineers in the US). Maybe for $300 I would do it. Of course if I were unemployed and didn’t have other options I’d do it for free…
- CoastalCoder 4y agoAt least for me, I wouldn't need that hourly rate to match my normal hourly rate. Offering $100/hour for a take-home problem would signal that they respected my time, which goes a long way.
- throwaway2037 4y ago300 USD per hour implies you make at least 600K USD per hour. Really?
- PainfullyNormal 4y agoI much prefer the take home test to a live coding exercise. Different strokes for different folks.
- TulliusCicero 4y agoTake home tests create a perverse incentive, live coding interviews don't. Specifically, a company can blast out a bajillion take home tests to a bajillion candidates for one position without a care in the world, but for live coding interviews it requires their own employee's time, so they're incentivized to only do it with candidates they're serious about.
- PainfullyNormal 4y agoAs an interviewee, I don't care. Most take home tests aren't that difficult and don't take that much time. And it's coding, which is much more enjoyable than meetings. Plus, there's the fact that I don't do well in live coding interviews. I get a version of "stage fright" where my mind goes blank and thinking becomes impossible for a bit. I don't experience it anytime on the job, either. Just in interviews.
- TulliusCicero 4y ago> As an interviewee, I don't care. You don't care whether you have almost no effective chance to actually get a job? Yeah, something tells me you're not being entirely truthful here.
- PainfullyNormal 4y agoI'll try again using shorter words. > You don't care whether you have almost no effective chance to actually get a job? Grug care. Grug can't pass live coding interview. Grug freeze. Grug ask for take home test instead. Grug not care about "perverse incentive." Grug want job.
- jlokier 4y agoFizzBuzz is a very small roadblock - a couple of minutes. If you have your choice of language, it'll probably take less time than thinking of a creative answer to a form question like "what do you find interesting about our company?". Perhaps the form should say "do not spend more than 5 minutes on this question", so that people who get stuck don't end waste a long time. It's really just a captcha to filter out people who can't program at all and also don't know to Google for an answer to paste in.
- tempestn 4y agoYeah, we definitely keep the work minimal up front. My process is to filter applications down to anyone who's completed the little 5-minute problem. Then I'll send each of them a quick note thanking them for their application, and asking a question about the answer they submitted. (Generally I can just pick from a small set of questions, since there are a very limited number of ways to solve it given the simplicity.) That starts a dialogue where I can learn a bit more about how they think, and they can see that I'm actually interested/invested. From there we make a shortlist based on those discussions and résumés (and cover letters if present), and move on to a few more involved programming tests, which try to replicate the actual kind of work that would be done here. (Each was taken from actual development or bug fixes we did in the past, then simplified and encapsulated to make a reasonable assignment.) We start with one of these and ask that the applicant pull the assignment repository, create a branch, make some commits as appropriate to solve the problem, and then start a pull request, which we review much like we would an internal code review. We also encourage them to ask questions and share thoughts throughout the process, as they would as a member of the team. Through all of this the goal is to show both sides what it would be like to actually work together. (As well as to demonstrate to the applicant that we are as invested in this process as they are.) I'm sure we do lose some good applicants with the initial quick question on the application, but it does serve to filter out essentially all of the really bad applicants, which gives me the freedom to give real attention to those who remain.