Interviewing developers always poses a challenge. You can’t rate their skills at writing code without seeing them write code, and most of the code they’ve written probably belongs to someone else. Writing anything non-trivial takes time, which both the candidate and the interviewer may not be willing to spend. Even then, it’s not always representative. And let’s not even talk about whiteboard programming.

Douglas’s company makes a compromise- they’ll give a time-boxed programming challenge. A developer is given two hours, access to the Internet, and a moderately complex problem. A smart developer might make some mistakes on the trickier parts of the problems, which is great, because it doesn’t fail them- it shows how they think. One candidate, Steve, never quite got that far.

At one point in the process, the code needs to determine if two dates are within 90 days of each other. Even in Java, this is a trivial task, worthy of one line of code. Possibly two, if you want to be super clear:

long days = TimeUnit.MILLISECONDS.toDays(d1.getTime() - d2.getTime());

Steve did this:

public Map<TimeUnit,Long> computeDiff(Date date1, Date date2) {
    long diffInMillies = date2.getTime() - date1.getTime();
    List<TimeUnit> units = new ArrayList<TimeUnit>(EnumSet.allOf(TimeUnit.class));
    Collections.reverse(units);
    Map<TimeUnit,Long> result = new LinkedHashMap<TimeUnit,Long>();
    long milliesRest = diffInMillies;
    for ( TimeUnit unit : units ) {
        long diff = unit.convert(milliesRest,TimeUnit.MILLISECONDS);
        long diffInMilliesForUnit = unit.toMillis(diff);
        milliesRest = milliesRest - diffInMilliesForUnit;
        result.put(unit,diff);
    }
    return result;
}

Now, we see the use of the same objects and methods- getTime and TimeUnit, but obviously Steve didn’t know anything about them. In fact, I suspect that Steve found this code in a tutorial on Java date times, saw that it calculated the difference in every possible unit, and just said, “Yeah, that sounds good.”

If that were the case, that would also mean Steve was a terrible researcher, because this was where he spent most of those two hours. For further proof that Steve hadn’t a clue, we can also look at how he called this method. Keep in mind the signature of this method- it’s a Map<TimeUnit,Long>, leveraging Java’s generics system. 

Map m = computeDiff(inputRecIn.date,inputRec.date);
Object o = m.get(TimeUnit.DAYS);
long l = Long.parseLong((String)o);

It might be stored that way, but Steve decided to catch the number of days as an Object, and then cast that to a string so that he could parse it back into a Long. Everything about this is wrong.

This is an example of something I think is a true: coding challenges won’t help you find good candidates during your interview process, but it’ll definitely identify the bad ones.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!