3 ms·

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

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'

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'