Coding assignment as interview: how much is too much?
October 17, 2014 8:30 AM Subscribe
Experience-based opinions from fellow techies especially appreciated!
I was asked to interview for a somewhat high-flying position with an extra schmancy title that basically boils down to "senior web developer". The interview confirmation email came with this pre-interview coding assignment:
Ask candidate to build the following within next couple days and submit their Github account
- Single page web app but if a mobile developer, i am fine having them build a native app but would leave that choice to them
- Communicate with an API and showcase results - for example, showcase the NBA results from yesterday but you choose whatever you want
- Allow users to submit any information and save it - for example, input your name or any other data
Several questions about this:
1. How long would you personally estimate for something like this? And would you allot more time (e.g. because you code will be scrutinized by the interviewers), or would you allot less time (e.g. because you don't know enough about the job at this stage)?
2. In your personal estimation, is this an easy assignment? An annoying but still relatively reasonable assignment? An onerous assignment? (Keep in mind this was in addition to a full day of interviews, including a 2-hour technical interview with the dev team).
3. Should the company choose not to proceed, how typical would it be to receive a rejection letter or email, and what would be the time frame? Or would you just expect not to hear? I would like to hear what actually happens, not what should happen.
Details: assume this is not the only job in town and the kind of people they are hiring have lots of options. The company is a huge American brand name (if you are from around here and have heard the phrase "shiny happy plastic people" in regards to a certain corporation, you know the one). Salary range is not stated upfront but likely to be good.
I was asked to interview for a somewhat high-flying position with an extra schmancy title that basically boils down to "senior web developer". The interview confirmation email came with this pre-interview coding assignment:
Ask candidate to build the following within next couple days and submit their Github account
- Single page web app but if a mobile developer, i am fine having them build a native app but would leave that choice to them
- Communicate with an API and showcase results - for example, showcase the NBA results from yesterday but you choose whatever you want
- Allow users to submit any information and save it - for example, input your name or any other data
Several questions about this:
1. How long would you personally estimate for something like this? And would you allot more time (e.g. because you code will be scrutinized by the interviewers), or would you allot less time (e.g. because you don't know enough about the job at this stage)?
2. In your personal estimation, is this an easy assignment? An annoying but still relatively reasonable assignment? An onerous assignment? (Keep in mind this was in addition to a full day of interviews, including a 2-hour technical interview with the dev team).
3. Should the company choose not to proceed, how typical would it be to receive a rejection letter or email, and what would be the time frame? Or would you just expect not to hear? I would like to hear what actually happens, not what should happen.
Details: assume this is not the only job in town and the kind of people they are hiring have lots of options. The company is a huge American brand name (if you are from around here and have heard the phrase "shiny happy plastic people" in regards to a certain corporation, you know the one). Salary range is not stated upfront but likely to be good.
1) I would allot the time I needed to do the bare minimum plus an extra three hours to fiddle with layout, adjust user interface, and document my code thoroughly. Your interviewers know you don't have a lot of time; if you have ideas that would take more time, include that in your writeup "With another day's work I would do x, y and z by building this module/function/class/calling this API".
I would also be very favorably inclined toward with a candidate who submitted code with a test or two in it, but that's just me.
2) Easy in any mature web development language; much less than a day's work for the bare minimum.
3) This varies a great deal, but I think the rule of thumb is that you can contact them if you don't hear back after two weeks.
posted by rhythm and booze at 9:04 AM on October 17, 2014 [1 favorite]
I would also be very favorably inclined toward with a candidate who submitted code with a test or two in it, but that's just me.
2) Easy in any mature web development language; much less than a day's work for the bare minimum.
3) This varies a great deal, but I think the rule of thumb is that you can contact them if you don't hear back after two weeks.
posted by rhythm and booze at 9:04 AM on October 17, 2014 [1 favorite]
This shouldn't be difficult for a senior web dev. I'm a software development manager, and if I made that assignment I'd be expecting to see proper structure in the code (eg: MVVM aka Knockout/angular/whatever), not just a quick-n-dirty job (You could probably get it done in half an hour if you rushed it).
That being said, as a former programmer, I wouldn't spend more than 2 hours on something if I wasn't explicitly being paid for it. You can generally tell with 20 lines of code whether someone is competent at writing code. Being a senior dev should be more about problem solving skills, time management, and whether you know how to put togethers solutions rather than if you're good at quizzes.
posted by blue_beetle at 9:10 AM on October 17, 2014 [5 favorites]
That being said, as a former programmer, I wouldn't spend more than 2 hours on something if I wasn't explicitly being paid for it. You can generally tell with 20 lines of code whether someone is competent at writing code. Being a senior dev should be more about problem solving skills, time management, and whether you know how to put togethers solutions rather than if you're good at quizzes.
posted by blue_beetle at 9:10 AM on October 17, 2014 [5 favorites]
My husband is a senior developer. I can't tell you anything about the code but I can tell you when he's applied for jobs a few places have had similar requests and none of them were particularly a big brand names. One of them asked because he was kind of reaching a little in his skillset on paper. None of the assignments took him more than half a day, most he did in an evening.
It has taken him up to 2 weeks to hear back after submitting the info one way or the other. Between hearing back & actually getting an interview time can take a while though, usually because they are trying to line up the schedules of a few people. Once he's finally gone in for the half day/day interview he usually hears back pretty quickly, I can't remember him waiting more than a few days.
This is in a smallish town though with a small pool of developers to choose from & everyone tends to know everyone. Also as I said none of the businesses were well known except maybe in their specialist areas so I imagine less competition for the jobs.
Good luck.
posted by wwax at 9:35 AM on October 17, 2014
It has taken him up to 2 weeks to hear back after submitting the info one way or the other. Between hearing back & actually getting an interview time can take a while though, usually because they are trying to line up the schedules of a few people. Once he's finally gone in for the half day/day interview he usually hears back pretty quickly, I can't remember him waiting more than a few days.
This is in a smallish town though with a small pool of developers to choose from & everyone tends to know everyone. Also as I said none of the businesses were well known except maybe in their specialist areas so I imagine less competition for the jobs.
Good luck.
posted by wwax at 9:35 AM on October 17, 2014
I think many developers will already have one or more applications that encompass all of the requirements, and this assignment would largely be a matter of making a copy, trimming it down, and probably sprucing up the comments, etc.
posted by doctor tough love at 10:17 AM on October 17, 2014 [3 favorites]
posted by doctor tough love at 10:17 AM on October 17, 2014 [3 favorites]
I evaluate an extremely similar coding task every week or two. I hope candidates aren't spending more than 5-6 hours on it, but if they're stretching their skills or polishing it obsessively, I can see spending a full day on it.
Here's what people lose points for pretty routinely: not following some vaguely appropriate style guide; not validating inputs; not handling errors or unexpected return values; not even trying to keep HTML/CSS/JavaScript cleanly separated; not using their chosen framework appropriately (e.g. jQuery in Angular controllers); not even trying to use some sort of templates for repeated output; not leveraging included components (e.g. if your widget library includes Knockout and you don't use it, I wonder if you really understand your widget library); use of global variables; obviously redundant code; etc., etc.
In short, I really don't expect an awesome app. I expect a clean and simple app based on libraries and boilerplate that make this stuff easy, and I expect to not wince at the code. The design/layout isn't important to me as long as it's not awful (e.g. pretty generic, slightly customized use of Bootstrap in a simple layout is fine), but doing something nice there is smart both for showing that you care about the whole package and in case a non-dev sees it.
posted by Monsieur Caution at 10:25 AM on October 17, 2014 [2 favorites]
Here's what people lose points for pretty routinely: not following some vaguely appropriate style guide; not validating inputs; not handling errors or unexpected return values; not even trying to keep HTML/CSS/JavaScript cleanly separated; not using their chosen framework appropriately (e.g. jQuery in Angular controllers); not even trying to use some sort of templates for repeated output; not leveraging included components (e.g. if your widget library includes Knockout and you don't use it, I wonder if you really understand your widget library); use of global variables; obviously redundant code; etc., etc.
In short, I really don't expect an awesome app. I expect a clean and simple app based on libraries and boilerplate that make this stuff easy, and I expect to not wince at the code. The design/layout isn't important to me as long as it's not awful (e.g. pretty generic, slightly customized use of Bootstrap in a simple layout is fine), but doing something nice there is smart both for showing that you care about the whole package and in case a non-dev sees it.
posted by Monsieur Caution at 10:25 AM on October 17, 2014 [2 favorites]
If you're communicating with a JSON API, you could probably write this in AngularJS in a couple hours. I wouldn't worry about making it "pretty", but I'd use Bootstrap or Foundation and make it responsive.
I hire developers, and I hate code tests. That said, I acknowledge that they're ingrained in people's heads as somehow a valid way to assess competency. To that end, I'd make sure:
- Your code is broken out into separate files/libraries, as per the best practices of whatever framework you're using.
- You trim out stuff from the basic framework templates you don't need.
- You comment relevant stuff, but don't overkill. Your code should largely speak for itself.
- You include a test or two.
posted by mkultra at 10:30 AM on October 17, 2014
I hire developers, and I hate code tests. That said, I acknowledge that they're ingrained in people's heads as somehow a valid way to assess competency. To that end, I'd make sure:
- Your code is broken out into separate files/libraries, as per the best practices of whatever framework you're using.
- You trim out stuff from the basic framework templates you don't need.
- You comment relevant stuff, but don't overkill. Your code should largely speak for itself.
- You include a test or two.
posted by mkultra at 10:30 AM on October 17, 2014
Best answer: #1/#2 are fairly appropriate/reasonable-ish and typical from my perspective. Even in a tight labor market, the cost of potentially turning away impatient good candidates is going to be less than the cost of hiring a poor candidate. Also, I want to work for a place that screens technical people well, because it means my co-workers are more likely to be good. So I'll totally spend time on an exercise that's a few hours, even a day or two if I really want to work somewhere.
As for #3, it's unfortunately pretty common -- it's not right, but it's all too typical to get no substantial feedback (either a cursory response or no response).
I totally understand that in the job/employee search dance everybody is busy and nobody has all the time they want (and I've been guilty of not responding as fully as probably deserved to all the employers who've invested time in interviewing, so maybe it's karma). Also, often it's not about you -- sure, maybe you were good, but there's always someone better. But I've gotten weary of a certain scenario where I'll put hours into an exercise and not get even a hint of substantial feedback in return.
So while this isn't directly relevant to your question, one thing I've started to do is apply a few screening rules when deciding whether to invest time in an exercise/code challenge:
* If they send you the exercise and a deadline without first asking if it's OK and when you might have time to do it, don't bother (you probably won't have time unless you're doing nothing, your work probably won't get a fair level of attention, and you probably don't even want to work there).
* Ask them if they have a reference solution or other rubrics that someone in-house has recently completed, how long it took them to complete that, and if they'll be willing to share those with candidates who submit work (if they don't have something like this, it's likely that haven't thought about evaluation, and they may not even know what success looks like or how much time it will take).
* Ask them straight up what kind of time they're planning to devote to evaluating submitted work and what kind of feedback they're planning to give to candidates who submit work (they will likely be optimistic/diplomatic, but you may be able to tell something from how prepared they seem to answer that question).
* Does the exercise involve the Facebook API? (Working with the FB API for money is aggravating, working for free is unlikely to be better unless you're already an expert.)
posted by weston at 10:43 AM on October 17, 2014 [3 favorites]
As for #3, it's unfortunately pretty common -- it's not right, but it's all too typical to get no substantial feedback (either a cursory response or no response).
I totally understand that in the job/employee search dance everybody is busy and nobody has all the time they want (and I've been guilty of not responding as fully as probably deserved to all the employers who've invested time in interviewing, so maybe it's karma). Also, often it's not about you -- sure, maybe you were good, but there's always someone better. But I've gotten weary of a certain scenario where I'll put hours into an exercise and not get even a hint of substantial feedback in return.
So while this isn't directly relevant to your question, one thing I've started to do is apply a few screening rules when deciding whether to invest time in an exercise/code challenge:
* If they send you the exercise and a deadline without first asking if it's OK and when you might have time to do it, don't bother (you probably won't have time unless you're doing nothing, your work probably won't get a fair level of attention, and you probably don't even want to work there).
* Ask them if they have a reference solution or other rubrics that someone in-house has recently completed, how long it took them to complete that, and if they'll be willing to share those with candidates who submit work (if they don't have something like this, it's likely that haven't thought about evaluation, and they may not even know what success looks like or how much time it will take).
* Ask them straight up what kind of time they're planning to devote to evaluating submitted work and what kind of feedback they're planning to give to candidates who submit work (they will likely be optimistic/diplomatic, but you may be able to tell something from how prepared they seem to answer that question).
* Does the exercise involve the Facebook API? (Working with the FB API for money is aggravating, working for free is unlikely to be better unless you're already an expert.)
posted by weston at 10:43 AM on October 17, 2014 [3 favorites]
I think it's more than what most companies do in their hiring process, but I wouldn't say that it's really onerous. I think it's more typical to do the code test as part of the interview — in other words, stick the candidate in a room with a clean PC and tell them to code something up in Eclipse in an hour or so. But some people do really poorly in those scenarios for reasons that don't have anything to do with their actual abilities (it's a sort of high-pressure thing, the setup isn't what they're used to, it's an artificially short timeframe to do any sort of nontrivial work, they don't have some tool or editor they like, whatever).
So it seems like a pretty decent compromise to me. You get to do it from home without somebody breathing down your neck, using your own PC, and the requirements are loose enough to let you do something that is at least borderline interesting and maybe demonstrate a little panache.
As for question 3, it's rare for companies to give much substantial feedback to candidates that they decide not to hire. It's perceived, rightly or wrongly, as a risk and a potential source for argument. You don't want someone coming back and trying to nitpick with your reasons for not hiring them. Plus, HR departments tend to be really risk-averse in saying anything to rejected candidates in case they decide to lawyer up, so rejection responses tend to be bland as all hell. It would be a rare company, in my experience anyway, that let technical staff write anything that would get passed along to a rejected candidate. Comments on the candidate's code might get put into a file somewhere in case the company was ever asked to justify the non-hiring (say, on discrimination grounds), along with interview notes and the like, but the candidate wouldn't get to see it.
Of course, the smaller the company the more fast-and-loose things tend to be; I could totally imagine some startup replying to a candidate with a "your code sucks and here's why..." email, but no large company is going to do that, at least officially.
posted by Kadin2048 at 10:55 AM on October 17, 2014
So it seems like a pretty decent compromise to me. You get to do it from home without somebody breathing down your neck, using your own PC, and the requirements are loose enough to let you do something that is at least borderline interesting and maybe demonstrate a little panache.
As for question 3, it's rare for companies to give much substantial feedback to candidates that they decide not to hire. It's perceived, rightly or wrongly, as a risk and a potential source for argument. You don't want someone coming back and trying to nitpick with your reasons for not hiring them. Plus, HR departments tend to be really risk-averse in saying anything to rejected candidates in case they decide to lawyer up, so rejection responses tend to be bland as all hell. It would be a rare company, in my experience anyway, that let technical staff write anything that would get passed along to a rejected candidate. Comments on the candidate's code might get put into a file somewhere in case the company was ever asked to justify the non-hiring (say, on discrimination grounds), along with interview notes and the like, but the candidate wouldn't get to see it.
Of course, the smaller the company the more fast-and-loose things tend to be; I could totally imagine some startup replying to a candidate with a "your code sucks and here's why..." email, but no large company is going to do that, at least officially.
posted by Kadin2048 at 10:55 AM on October 17, 2014
Best answer: I would do this, I guess, if I really wanted the job. But the way that the requirements are laid out would make me feel less good about the job-is this unclear, ungrammatical vague spec characteristic of the ones you'll be getting on the job?
I would respond with some questions trying to nail down some specifics about whatever it is that you're supposed to be delivering here--for all I know, they're trying to test whether you'll do that instead of blindly charging forward on a vague spec. As in:
Some people in the thread thinks you ought to include a test. Some people think you'll obviously be using an MVVM framework. Some people think the expectation is that you'll already have something done that you can submit.
Everything about the users can submit 'any' data could use some clarification.
Monsieur Caution has a whole list of specific expectations that he'd have, but he's not evaluating this project, it's somebody else. I would never ask a candidate to do something like this, but if it were me evaluating, you'd score points by writing more vanilla js and less framework. Frameworks come and go--a lot of the ones mentioned in this thread barely existed the last time I was on the job market in 2010. Javascript itself isn't going anywhere, and you'd score points with me for demonstrating some familiarity with ECMAscript 5 and 6 specific features.
But I'm not evaluating this either. Ask questions.
posted by Kwine at 12:29 PM on October 17, 2014 [3 favorites]
I would respond with some questions trying to nail down some specifics about whatever it is that you're supposed to be delivering here--for all I know, they're trying to test whether you'll do that instead of blindly charging forward on a vague spec. As in:
Some people in the thread thinks you ought to include a test. Some people think you'll obviously be using an MVVM framework. Some people think the expectation is that you'll already have something done that you can submit.
Everything about the users can submit 'any' data could use some clarification.
Monsieur Caution has a whole list of specific expectations that he'd have, but he's not evaluating this project, it's somebody else. I would never ask a candidate to do something like this, but if it were me evaluating, you'd score points by writing more vanilla js and less framework. Frameworks come and go--a lot of the ones mentioned in this thread barely existed the last time I was on the job market in 2010. Javascript itself isn't going anywhere, and you'd score points with me for demonstrating some familiarity with ECMAscript 5 and 6 specific features.
But I'm not evaluating this either. Ask questions.
posted by Kwine at 12:29 PM on October 17, 2014 [3 favorites]
I'm barely a programmer, and I've put together all of that during a weekend of googling and following tutorials for a personal project. I have to believe that somebody who knew what they were doing could knock it out in 4-5 hours.
posted by empath at 12:37 PM on October 17, 2014
posted by empath at 12:37 PM on October 17, 2014
In my experience, this kind of "pre-interview" screening is just that - a screening to make sure you can actually do the basic things that this position requires. It's a slightly more involved type of FizzBuzz test. I bet they only ask this of people who don't already have similar proof of ability, e.g. representative projects on GitHub.
They look like simple guidelines to get you started on what's basically a "build something simple that demonstrates your relevant skills" project. If they really care, they'll look closely at your code to see what your style is like, if you've written robust code or dangerous code, etc.
If it were me, I'd first do some research on the company (or, more likely, the department or team within the large company) to find out what tools and frameworks they're using right now, and write my demo site with those tools and frameworks. I'd also reply to the confirmation email asking for clarification on what they'd prefer.
To me, that description looks like it was written by a developer and sent to someone in hiring, who then, having little idea what it all meant (or just being lazy), copy-pasted it into your email rather than trying to reword it to look a little more professional. Asking for clarification might initiate forwards and CCs with the developer (who you may interview with in the future).
posted by WasabiFlux at 3:23 PM on October 17, 2014
They look like simple guidelines to get you started on what's basically a "build something simple that demonstrates your relevant skills" project. If they really care, they'll look closely at your code to see what your style is like, if you've written robust code or dangerous code, etc.
If it were me, I'd first do some research on the company (or, more likely, the department or team within the large company) to find out what tools and frameworks they're using right now, and write my demo site with those tools and frameworks. I'd also reply to the confirmation email asking for clarification on what they'd prefer.
To me, that description looks like it was written by a developer and sent to someone in hiring, who then, having little idea what it all meant (or just being lazy), copy-pasted it into your email rather than trying to reword it to look a little more professional. Asking for clarification might initiate forwards and CCs with the developer (who you may interview with in the future).
posted by WasabiFlux at 3:23 PM on October 17, 2014
I forgot to mention: this is pretty commonplace these days, even on top of a full portfolio. Some interviews consist entirely of sitting down with the interviewer and pair-programming on a specific small project.
posted by WasabiFlux at 3:26 PM on October 17, 2014
posted by WasabiFlux at 3:26 PM on October 17, 2014
It's rare to be able to get a dev job without doing a coding test.
posted by kinddieserzeit at 3:38 PM on October 17, 2014
posted by kinddieserzeit at 3:38 PM on October 17, 2014
I would also be very favorably inclined toward with a candidate who submitted code with a test or two in it, but that's just me.
For what it's worth, I do a lot of reviewing of code challenges, and I would pass on a candidate who submitted code with only a test or two in it (assuming this refers to individual tests and not whole suites). This depends a lot on the engineering culture of the place you're applying to, but it's worth keeping in mind.
But to answer specifically:
1. We give people a week. We're not expecting them to be putting in hours a day for the whole week working on it -- like people said above, six hours is on the high end of how long I'd expect it to take.
2. I think it's both easy and annoying, to be honest. If you've already got code on hand that you can and would be willing to show them, it might be worth asking them if that would be a sufficient indicator of your abilities (I wasn't asked to do this for my current position thanks to having some representative stuff up on Github). The sort of place that says no because they expect that you'll always be able to make time for more programming is not likely to be a fun place to work at unless you're into that type of atmosphere.
3. I would expect not to hear. I would wait 7-10 days and then shoot a diplomatic email to the recruiter asking if they need any further info from me, and would take a lack of prompt reply to indicate that they had eliminated me from the running.
posted by invitapriore at 3:41 PM on October 17, 2014
For what it's worth, I do a lot of reviewing of code challenges, and I would pass on a candidate who submitted code with only a test or two in it (assuming this refers to individual tests and not whole suites). This depends a lot on the engineering culture of the place you're applying to, but it's worth keeping in mind.
But to answer specifically:
1. We give people a week. We're not expecting them to be putting in hours a day for the whole week working on it -- like people said above, six hours is on the high end of how long I'd expect it to take.
2. I think it's both easy and annoying, to be honest. If you've already got code on hand that you can and would be willing to show them, it might be worth asking them if that would be a sufficient indicator of your abilities (I wasn't asked to do this for my current position thanks to having some representative stuff up on Github). The sort of place that says no because they expect that you'll always be able to make time for more programming is not likely to be a fun place to work at unless you're into that type of atmosphere.
3. I would expect not to hear. I would wait 7-10 days and then shoot a diplomatic email to the recruiter asking if they need any further info from me, and would take a lack of prompt reply to indicate that they had eliminated me from the running.
posted by invitapriore at 3:41 PM on October 17, 2014
This thread is closed to new comments.
G'luck!
posted by isauteikisa at 8:40 AM on October 17, 2014 [1 favorite]