Unmonitored Challenges, aka The Take-Home Assignment

The trend in our industry over the past few years, especially for entry-level developers, is some sort of take-home assignment. No matter how well someone does on a phone screen, it always amazes me how often a take-home assignment will weed out people who are non-confident about their programming skills, or folks who think it’s a waste of time or just don’t want to bother. When I post a job I might get 200 applications, which I narrow down to maybe 10-15 applicants to call and I might only get 5-8 assignments handed in on time. This is just my own experience and may not reflect other industries.

There was some discussion in late 2016 between some online personalities who believed that applicants who are asked to perform some sort of assignment should be paid for their work whether they get hired or not. I feel this is only warranted if the assignment is meant to take more than one day of effort; if you really want to work for my company, you shouldn’t have a problem investing 4-6 hours of your time over the next week working on some code for me to prove you’re hungry for the job.

Ask Questions Sooner than Later

If I send you an assignment, I expect that you’ll read through the instructions and examine the problem and ask me questions relatively soon after sending the assignment. That is, if I send you an assignment on a Thursday afternoon with a due date of Monday morning, I don’t want to be getting questions from you Sunday night to clarify something about the assignment. Aim to ask all questions within the first 25% of your due date if something is unclear – sometimes companies document things vaguely to see what assumptions you make or what questions you ask when unclear instructions are given.

How to Handle Deadlines

How you manage your time is important to me. By giving you a deadline, I’m giving you the opportunity to show me what you’re going to be like as an employee if I hire you. The assumption many entry-level developers make is “if I’m the first one to hand in the answer, I’m more likely to get picked for an on-site interview.” While this may not be a bad assumption, there are risks at play.

When I give out assignments I usually let candidates know that I’m going to be sending it on a Thursday afternoon around 3pm local time, with a due date of 9am local time Monday morning. I hope I wake up to an Inbox full of clarifying questions from candidates on Friday morning, but often times I see candidates hurrying through the assignment and submitting code, and of course I’ll have candidates handing in code Monday morning as well.

Submitting Code Too Early is a Warning Sign

When you hurry through an assignment, quality usually suffers. This is your chance to impress me with your coding ability, so make it your best effort. Writing code quickly will typically mean that you’ve made assumptions without asking questions, leading you in a wrong direction or missing details. Many of the assignments I hand out come with a scoring rubric outlining bonus points, and hurried code usually skips most or all bonus points.

Takeaway: Handing in early usually signals me that you’re going to rush through everything I give you at the expense of quality. I want someone who cares about quality, and you might not be it.

Coming in Last is Worse

Likewise, if you submit your final code Monday morning at 9am, it signals that either the assignment was way too difficult and took you longer than most developers, or that you had “better” things to do than prioritize a potential new job. I’ve had many submissions show up at 9am saying “this is all I could get done” and deal with incomplete code.

Takeaway: If you submit code right at the deadline, it tells me that as an employee you’re going to wait until the last minute to get everything done. I don’t want people cramming to get things done at the last minute.

Suggestion: Aim for 70%

If you are given multiple days to complete an assignment, aim for about 70% of the deadline to submit the code. If I give you the assignment on Thursday at 3pm and it’s due Monday morning at 9am, that gives you 90 hours to work on something that I’ve suggest should take 4-6 hours to complete. 70% of 90 hours is 63 hours, which would mean you’ll submit code some time Sunday morning.

This isn’t a hard and fast rule, but it gives you plenty of time to ensure you’re submitting your very best work. Remember: your job right now is to be the very best candidate at all times.