Published in


Are you hiring the right person to the job?

Looking for a new job is always an interesting opportunity to get some insight into the human mind. Lately I've been going through some recruiting processes and coding challenges, and two of them stroke me as particularly good at making no sense.

The fashion company

This is a big company in the online fashion retail industry. They have a quite interesting positioning of their platform, advertise themselves as a quite serious agile practitioner, and a couple of friends that work there always give me positive impressions about it. I had already applied to work there about an year ago, failed it, but thought "why not trying again? maybe it was just bad luck the first time, was too nervous, didn't get along well with the interviewers, etc". And so I decided to apply to a new job with them.

The first step in the process is an online coding challenge hosted on c0dility. I'd have 90 mins to solve two problems. That got me thinking… One and half hour to solve not just one, but two problems? This can be tricky, because quite often companies advertise they'll focus on your strategy and train of thought, but end up requiring that you provide production-ready software as outputs of their coding challenges. How could I ever do that in 90 mins? Anyway, I went ahead with it.

The first problem was alright. I don't really remember what it was about, but after 45 mins I was able to deliver a code that passed all unit tests.

Then came this:

Now read it once again. How long did it take you to really grasp what is to be done here? Are you absolutely sure you got everything right? Now I ask you: in your opinion, what does the person at the other end of the line is looking for? After reading and re-reading this question (remember, the clock was ticking), I couldn't really answer that question. I wonder if anyone took the candidate's cognitive effort into consideration. Let's deconstruct this question, just for the sake of doing it.

First: in which solar system does John live? I mean, we're talking about a concept that is well defined and lives deep down in our minds: the four seasons of the year. The problem starts by tearing this apart and stating there are only two seasons, to hell with autumn and spring. First mental adjustment you need to make while the clock ticks.

Second: have you ever been to Brazil during winter? The problem says winter ends at the moment where all temperatures are higher than all of the previous ones. Ok, but reality tells us it's not that simple. Those tiny irrelevant things called nature and reality tell us there are natural phenomena like El Niño that might make temperatures get close to 40 degrees on winter (especially if you come from Rio de Janeiro, like I do). How do you tell winter from summer like that? Ok, let's try to ignore El Niño for a moment, let's assume the candidate lives in the northern hemisphere. Such a person is used to kinda have winter "twice a year": you have some winter in the beginning of the year, and then again at the end of the year. And now that person has to completely ignore that for the next 45 mins and immerse herself in a world where winter only takes place once a year (by the way, it's in the beginning of the year).

And now, all of a sudden, you have ~45 mins (at least, that's how much time I had left) to tear deeply rooted concepts apart and accept that: (i) there are only two seasons in the year; (ii) those seasons only take place once during the year; (iii) El Niño doesn't exist.

I like to think I'm not that stupid, so I presented this to a few fellow developers and we spent an hour discussing it on Slack just to reach an agreement on the requirements. Imagine having 45 mins to do it on your own. Ok, enough for cognitive exhaustion. Let's move on.

Skip the cognitive bias for a second, let's focus on something more technical, closer to the job description. Let's talk about coding practices. Imagine you're in a real project in whatever company you like (not necessarily the one you're applying to), working a regular day and reviewing someone else's code. Would you honestly agree with someone that'd propose a method signature like this?

public int solution(int[] T)

First, what kind of name is solution? What intentions does it reveal? What should you expect from its outcome? What does the returned int represent?

Second, have you ever seen a Java codebase where an upper case single letter parameter name would ever be considered a good naming standard? Besides, in Java terminology, T is usually a character particularly associated with generics, not regular parameters or variables names. What concept is T supposed to represent? Would a pull request with these contents ever get approved in a real world situation?

Which leads to my last-but-not-least-point: Is anyone in the company ever working on this kind of problem? According to my buddy who works at this company, no. Most people do the regular stuff: HTTP APIs, admin screens, lots of forms, message queues, etc, not much for people interested in splitting arrays.

Ok, let’s try a different angle. Now let me change my hat. I’ll take off my usual hat of SW architecture lover and switch to the algorithm lover hat. Just for now, I love this kind of problem. I don’t care about reality, I don’t care about naming conventions or revealing intentions, all I care about is splitting arrays and coming up with optimized ways of doing it. This problem is just too easy for me, I just solved it in 10 mins and got approved all along the recruiting process. I loved the recruiting process and got assigned to a project.

And as soon as I start, none of those things are in place anymore, as my buddy that works over there had already told me. I have to put up with colleagues that complain about my code being cryptic to understand, despite excellent performance and optimal complexity. My pull requests always take too long to get approved and merged, because my colleagues keep asking me to split my code into smaller portions and refactor further and further and further. Eventually I hate my job.

Sounds familiar to you too?

Then I ask: why trying to make developers go through the “one size fits all” approach? Why not just asking the candidate to work on a real world situation and judge her by the same constraints and values she'd find in daily routine?

I do get that maybe the company is just too big and maybe they need something that will eliminate candidates without a minimal set of programming skills.

But, on the other hand, you force a candidate to go through a massive cognitive effort, you provide her with code that doesn't actually help her overcome that effort, you give her an unrealistic amount of time to overcome all of that, just to later on get this person to work on something completely unrelated. Why?

After all, what kind of professional are they looking for? Someone good at algorithm complexity that also happens to enjoy developing RESTful API's? I must say, I haven't found such kind of professional yet. This is not to say I'm right and everyone else is wrong, maybe I'm the one refusing to see this is everywhere. But in my experience, these are very different skill sets and often don't mix up.

Oh, and by the way, as I couldn't make a sense out of this challenge, I decided to give it up. I could definitely think of better things to do with my time.

And a few days later, when you think things can't get any more awkward, I get an e-mail saying I've been approved to the next step… If I wasn't supposed to deliver this damn code to pass, then why putting me through it in first place?! (facepalm)

The publishing company

This is a leading company in their market, prints several different magazines and all sorts of publications, and they say agile is very important to them. Sounded quite interesting to be honest.

Again, the first step of the process was a coding challenge, and a quite interesting one. Its description said:

Things We Value

1. Working software

2. Tests

3. A clear build process

4. Small commits with good comments

5. A README containing build and run instructions, along with trade-offs

6. Code that is easy to read

7. As few libraries as possible

8. Functional constructs, good names and good modeling

9. Taking edge cases and errors into consideration (either in code or README)

And so I did my best to keep up with those values at all times during the development of my solution. I TDD'd all the way, strived to write small classes with small methods and self-explanatory method names, spent quite a lot of time committing (and writing comments for) small units of work, spent even more time re-inventing the wheel to avoid using any libraries, etc.

And then, a week later, I get an e-mail back saying they wouldn't proceed with my application. So far, so good. No one's supposed to like me or my code, it's life, all good.

But then they said the main concerns were the high number of classes, the high number of abstractions and "a very high number of commits". Let me highlight this last part, because it’s so funny: a very high number of commits.

Ok, let's go back to the values they defined, let's have a look at #4:

4. Small commits with good comments

I can't believe I got failed for something they asked me to do! Notice no one expressed any concern about the quality of the comments, all they said was I had submitted a "very high number" of them. Honestly, how much is good enough? How many commits are acceptable? How big a commit is a good enough commit? And why would anyone in the world fail a candidate for something you can easily agree on once hired? It’s no so hard to talk to a newcomer and say “hey, could we agree on restricting commits to something in between N to N’ classes?”, is it?

Now, let's have another look at the rest of their feedback once again: (…) main concerns were the high number of classes, the high number of abstractions and “a very high number of commits”.

Now have a look at their values again. Try to find anything about number of classes or abstractions. Got anything?

Now, let me get this right. They had 9 values. No one expressed any concern about 8 of them, which I assume to mean I nailed them. And yet I failed for something so important, just so important that won't even figure out on their list of values. Am I the only one struggling to understand what's the reasoning here?

I know, I've been on the other side of this. I get that picking a new team member is not an easy task. I get that there are many soft skills at play and you can't always put a number on them. But IMHO one must at least be consistent with the constraints they've set themselves for the task at hand.

I've been through other coding challenges where they clearly stated beforehand they expected the solution to be made of 4–6 classes. I disagreed, I couldn't deliver a solution that would have less than the double of it and obviously got kicked out, but at least it was fair. They had a constraint, I knew about it, didn't comply and hence got failed. That's fair. But failing a candidate for something you never talked about? Gimme a break…

And then again, what kind of candidate are you looking for? Someone who's able to stick to the rules you set? Or a mind reader? I can tell I'm no mind reader, so I guess their recruiting process works like a charm and they avoided hiring a person that clearly doesn't fit their implicit job description….

Where to go from here?

If you're interested in the subject of hiring processes for hiring software developers, I dearly recommend you read these two articles:

I have a very soft spot for this article, as it defines a really easy to follow method to better recruiting processes, made of 4 ridiculously simple guidelines:

Your interview process should follow the following four simple guidelines:

Resemble actual work the candidate would be doing in their job

Clear rubrics

Consistent and standardized

Don’t have an elite-candidate fast path

This article is more of an anecdote, but shows how hard can be the life of a developer looking a new job…

Comments? Similar experiences? I'd love to read what you have to share!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store