5 ms·

The take-home assignment seems to me a slightly broken system; it's easily gameable because there's zero supervision. Let's say there's two candidates for a po

The take-home assignment seems to me a slightly broken system; it's easily gameable because there's zero supervision. Let's say there's two candidates for a position who are both asked to complete the take-home assignment, Candidate A and Candidate B. Candidate A is the superior candidate and spends only two hours on the task (as requested), and Candidate B spends 2 days. Candidate B submits the better assignment and is more likely to land the job as a result, despite Candidate A being the better candidate.

TheOtherHobbes 5y ago
Sounds like there may be a niche for some kind of industry standard automated logging system. Nothing complicated - shouldn't take too long.
- rightbyte 5y ago
  Are you joking? Should candidates install spyware?
  - drstewart 5y ago
    Seems obviously a joke based on the project from the article
sverhagen 5y ago
When I've interviewed using homework like this, it was with the sole purpose of bringing it along and talking to it. That won't be gamed. And, by the way, that lends itself also very well for bringing whatever fitted in the time box, and having a discussion on the meeting about the tasks that remain, and about their prioritization process. You may like it when you see less production code, in favor of some tests! People coming in with a full-fletched solution, and then to tell me they didn't have time for a test, what am I to make from that?
- htrp 5y ago
  This is the right approach. You don't disqualify based on the take home (unless it doesn't work at all).
  - sverhagen 5y ago
    Unless it's a nonsense solution maybe, or you clearly demonstrate that you don't know what you're talking about. But otherwise it not quite working isn't even the greatest obstacle. (Though those tests working would be nice...)
nextlevelwizard 5y ago
If you have 2 hours to submit the task and you submit it after 2 days you are already out
- agent327 5y ago
  So... you select for people that can get home within two hours and still have enough time left over for the assignment, as well as people that are willing to do the assignment in the parking lot?
  - nextlevelwizard 5y ago
    Oh, we don't even meet face to face before you write code. We setup a time where you have X hours open and then we send you an email with couple different assignments to choose from. Then we expect to have your code email back to us within X hours.
    - jstx1 5y ago
      This might be the worst technical assessment format I've ever heard of. I really don't get the reason for adding time pressure to this. You're combining the worst elements of take-home assignments and whiteboard interviews. Why not send people the assignment and ask them to return it within a couple of days? What are you gaining by limiting it to hours and turning it into a remote exam?
      - Jensson 5y ago
        This way it ensures you only spend 2 hours on it without being penalized. If you are free to spend any amount of time you can be sure someone spent 40 hours working on it, you really don't want to compete with that. So another person would say that this combines the best from take home and white board, you don't have to travel anywhere for the interview, you get to do a project rather than algorithm, and it doesn't waste a lot of your time.
        5y ago
wccrawford 5y ago
We do a take-home assignment for junior devs where I work. The actual coding knowledge is pretty minimal. Few people fail based on the code alone. What we're actually looking for is if they can follow directions. A surprising number of people can't read a list of requirements and make sure they all get implemented. For junior devs, we don't actually care if they do it in 2 hours, 2 days, or the whole 7 days we allow them. There's no bonus points for turning it in the next day, and I don't think anyone has ever actually done that. But we're at the point that if they fail a single point in the requirements, we stop looking at them. This was a really hard decision, because there are candidates who are really nice and seem to otherwise do good work, but we've hired some of them and they inevitably continue to skip steps even in simple tickets. We end up letting them go after multiple warnings and months of wasted time, and having to do it all over again. Of course, if you can't code you aren't going to get in either, but that actually seems to be a lower bar than following directions.
- bambax 5y ago
  Very insightful and true. Even during a conversation, many people "translate" what they hear into something else, and will quote back, a few seconds later, a totally different sentence and think that's exactly what you said. Kids in school often don't read assignments properly either, and skip everything until the first question. I don't know if they think it saves them time or fear there's a trick somewhere that they will avoid that way. In life in general, people like ambiguity; it helps to smooth things out. But in programming it's a problem.
  - frazbin 5y ago
    I think it's a profound fear of ambiguity that drives these behaviors: the urge is to move past the 'understanding' part by finding some single interpretation and then move on to the 'doing' part, which is the satisfying part. I think formally writing down the specification for any kind of work starts with holding all the ambiguities in of it in your head. In this case, the approach depends on whether the student is more interested in 'computer programming' or 'software engineering'
rfrey 5y ago
I'd say selecting the candidate who will work for 2 days and only claim 2 hours is the system working perfectly.
cline6 5y ago
From a hiring standpoint, the problem imo, is that employers set the timebox thinking that it means something when comparing candidates' solutions. I couldn't care less whether somebody spends two hours or two days on it. I want to see the best solution somebody can produce. I have engineers that can do things quickly and others that can do them more slowly, and both are infinitely more valuable to me than someone who can't provide a quality solution under any circumstance. In my experience, if you're filtering out the slower engineers that produce quality work you're going to be in for a very long hiring process and miss out on a ton of great engineers.

TheOtherHobbes 5y ago

Sounds like there may be a niche for some kind of industry standard automated logging system. Nothing complicated - shouldn't take too long.

rightbyte 5y ago
Are you joking? Should candidates install spyware?
- drstewart 5y ago
  Seems obviously a joke based on the project from the article

sverhagen 5y ago

When I've interviewed using homework like this, it was with the sole purpose of bringing it along and talking to it. That won't be gamed. And, by the way, that lends itself also very well for bringing whatever fitted in the time box, and having a discussion on the meeting about the tasks that remain, and about their prioritization process. You may like it when you see less production code, in favor of some tests! People coming in with a full-fletched solution, and then to tell me they didn't have time for a test, what am I to make from that?

htrp 5y ago
This is the right approach. You don't disqualify based on the take home (unless it doesn't work at all).
- sverhagen 5y ago
  Unless it's a nonsense solution maybe, or you clearly demonstrate that you don't know what you're talking about. But otherwise it not quite working isn't even the greatest obstacle. (Though those tests working would be nice...)

nextlevelwizard 5y ago

If you have 2 hours to submit the task and you submit it after 2 days you are already out

agent327 5y ago
So... you select for people that can get home within two hours and still have enough time left over for the assignment, as well as people that are willing to do the assignment in the parking lot?
- nextlevelwizard 5y ago
  Oh, we don't even meet face to face before you write code. We setup a time where you have X hours open and then we send you an email with couple different assignments to choose from. Then we expect to have your code email back to us within X hours.
  - jstx1 5y ago
    This might be the worst technical assessment format I've ever heard of. I really don't get the reason for adding time pressure to this. You're combining the worst elements of take-home assignments and whiteboard interviews. Why not send people the assignment and ask them to return it within a couple of days? What are you gaining by limiting it to hours and turning it into a remote exam?
    - Jensson 5y ago
      This way it ensures you only spend 2 hours on it without being penalized. If you are free to spend any amount of time you can be sure someone spent 40 hours working on it, you really don't want to compete with that. So another person would say that this combines the best from take home and white board, you don't have to travel anywhere for the interview, you get to do a project rather than algorithm, and it doesn't waste a lot of your time.
      - 5y ago

wccrawford 5y ago

We do a take-home assignment for junior devs where I work. The actual coding knowledge is pretty minimal. Few people fail based on the code alone. What we're actually looking for is if they can follow directions. A surprising number of people can't read a list of requirements and make sure they all get implemented. For junior devs, we don't actually care if they do it in 2 hours, 2 days, or the whole 7 days we allow them. There's no bonus points for turning it in the next day, and I don't think anyone has ever actually done that. But we're at the point that if they fail a single point in the requirements, we stop looking at them. This was a really hard decision, because there are candidates who are really nice and seem to otherwise do good work, but we've hired some of them and they inevitably continue to skip steps even in simple tickets. We end up letting them go after multiple warnings and months of wasted time, and having to do it all over again. Of course, if you can't code you aren't going to get in either, but that actually seems to be a lower bar than following directions.

bambax 5y ago
Very insightful and true. Even during a conversation, many people "translate" what they hear into something else, and will quote back, a few seconds later, a totally different sentence and think that's exactly what you said. Kids in school often don't read assignments properly either, and skip everything until the first question. I don't know if they think it saves them time or fear there's a trick somewhere that they will avoid that way. In life in general, people like ambiguity; it helps to smooth things out. But in programming it's a problem.
- frazbin 5y ago
  I think it's a profound fear of ambiguity that drives these behaviors: the urge is to move past the 'understanding' part by finding some single interpretation and then move on to the 'doing' part, which is the satisfying part. I think formally writing down the specification for any kind of work starts with holding all the ambiguities in of it in your head. In this case, the approach depends on whether the student is more interested in 'computer programming' or 'software engineering'

rfrey 5y ago

I'd say selecting the candidate who will work for 2 days and only claim 2 hours is the system working perfectly.

cline6 5y ago

From a hiring standpoint, the problem imo, is that employers set the timebox thinking that it means something when comparing candidates' solutions. I couldn't care less whether somebody spends two hours or two days on it. I want to see the best solution somebody can produce. I have engineers that can do things quickly and others that can do them more slowly, and both are infinitely more valuable to me than someone who can't provide a quality solution under any circumstance. In my experience, if you're filtering out the slower engineers that produce quality work you're going to be in for a very long hiring process and miss out on a ton of great engineers.