Hiring Software Developers

I’ve been reflecting recently on my past few years working as a software developer. During those years I’ve had a lot of job interviews. I got many rejections, a few job offers and never heard back from some companies.

This is a review, from my own perspective, of what works and what doesn’t work when it comes to interviews and hiring processes for software developers.

The Programming Quizzes Interview

In this kind of interview you have to solve ACM kind of problems, brain-teasers, or general Computer Science quizzes. Things like finding the shortest path to traversing a graph. Any good Computer Science fresh graduate will probably be able to go through such interviews with ease. A few years later though you’ll struggle with answering most questions, simply because they have absolutely nothing to do with what you actually do in practice. Can you even remember when was the last time you had to write an algorithm to traverse a graph? Those interviews are the worst as they give absolutely no indication about how good or bad someone is going to be when they get hired.

You Seem Nice, Here’s a Job Offer

No technical interview, no tasks, absolutely nothing. This has actually happened a couple of times with me and they just left me baffled. If that’s how you have picked the rest of the team I will be working with, then thanks, but no thanks, I can’t work for you.

I’m not really sure how some companies decide to hire people entirely based on how nice their CVs look, or based on a short conversation they had. You’d be surprised by how often people make things up in their CVs.

Go Do a Task and Get Back to Us

I have encountered 2 different kinds of tasks that fall under this category. Some companies give you a generic task that they give to all candidates. Those tasks are usually designed to test your understanding about specific parts of the technologies they are using, your coding style, and how scalable and maintainable your code is. I like those kind of tasks as they show my skills in a much better way than answering some stupid questions on the spot.

What’s even better is the second kind. Your task is actual work on one of the company’s projects and your code might be used in production at some point. This not only shows your technical skills more accurately, but also shows how you communicate with the rest of the team, how you approach the problem and understand the logic business behind it. Most companies that do this kind of tasks pay you for it, whether you get accepted or not.

Come Work With Us for a Few Days

Some companies invite you to come work with them for a few days. You don’t have to be at their office 8 hours a day, but you have to show up at least a few hours everyday for 2 to 4 days. I believe this is the best way for a company to get to know candidates and see how they fit with the rest of the team, it’s also great for candidates to know the people they will be working with and see if they are comfortable working together and also get to experience everything about the work environment of the company. The only problem with this is that it’s often hard to do for candidates already working full-time at another company.

Finally…

If you’re hiring a developer, specially in a startup, I urge you to ditch CVs and traditional interviews. Ask people for their Github accounts. Ask them to tell you about a personal project they have been working on recently. Invite them to come work with you for a few days. Whatever you do just make sure it gives you a meaningful indication about their skills, not how good they are with word processors or solving Computer Science quizzes.

Update: Thanks for the tree vs. graph heads up.

There have been some nice discussion about the article over at Hacker News. Make sure you check it out.

Update 2: Sunil Sadasivan has recently published a very interesting article about the hiring process at Buffer. Check it out on Medium.

  • http://www.danielbough.com/ Daniel Bough

    You can learn a lot more about a person by asking them to solve a problem through research. Quizzes won’t tell you anything meaningful about that person, and a CV is a good reference for talking points (at best.)

  • Pingback: Hiring Software Developers | Enjoying The Moment

  • zerexim

    Oh, please… stop this “github is your CV” BS…

    Lack skills to verify whether I’m lying in my CV or not? Well, that’s your problem… At least hire someone who has those skills.. oh, wait, you can’t hire…

  • airtonix

    lack skills to understand how a github account reflects what kind of programmer you are? well that’s your problem… at least hire someone who has that skill. oh wait you can’t.

  • ranman96734

    github/bitbucket/etc may not be a CV but it is a generic portfolio. It gives an employer a schema and context to evaluate your work in.

    There are plenty of examples where an engineer may not have a github/bitbucket/etc but in that case they should be able to offer up code samples. You want to find people who have a large code radius and have created something from scratch before… so they should definitely have something on their hard drive that they’ve written and that they can share.

    If they don’t have anything at all that they can share… then they just do programming for the money, which is fine, but you probably don’t want to hire them — let them go back to a bank and enjoy the other parts of their life.

  • zerexim

    There is BIG difference in doing some side-coding self-enjoyable stuff, proof of concept codes, learning some topic, etc… VS real finished product the community can benefit from.

    Sorry, but I don’t have a time to come up with a lot of finished, real value projects for the open source world. And I don’t want to pollute the above mentioned world with my side musings.

  • Jon

    For all you folks that think an excellent programmer is defined by their github profile… you’re a lost cause.

  • ranman96734

    I think this has a lot to do with code-ego… I’ve found, in hiring, that ego is the most dangerous thing a programmer can have. Otherwise amazing programmers become impossible to work with or around.

    While it’s noble of you to want to prevent polluting the open source world I would argue that very comment reveals ignorance, at some level, of how open source works.

    Projects are often released on shaky foundations because it solved a one-off ad-hoc problem for the author. People realize it can be generalized and it takes off from there on a fork or a completely different repo.

    Moving back to the original topic, it need not be github or bitbucket but I need to be able to see some examples of previous work or I simply won’t hire you. I can’t go solely on a recommendation and I can’t go off of coding interviews. I need people who know things I (and the other people on my team) don’t already know how to do and the only questions we can ask are things that we already know the answer to. That’s why some kind of portfolio or code sample is such a huge boon.

    False negatives happen all the time in hiring engineers. False negatives are cheap. False positives on the other hand can cost the company a lot more than just one employee’s pay and benefits.

    Hopefully that clarifies my opinions on why it’s important to see the code an engineer has written previously if you’re hiring them to write more code.

  • ranman96734

    I don’t think anyone claims that a programmer and their github account are synonymous. Also I sincerely doubt they’re a “lost cause”…

    It’s just that we live in a modern world and we should start hiring with the new tools we have available since they allow us to make more informed decisions.

  • zerexim

    Well, I believe I can better judge which one of my personal stuff will benefit the community. And I’m not quite sure how this is relevant to your premature diagnosis about code-ego-ness.

    Asking for some examples is not a problem. But some people really go too far and ask a LOT of code. But if the interviewer can’t deduct by talking whether the person is lying in mentioned past projects and experience, something is really wrong with that interviewer.

    Also, interesting post:

    http://ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community

  • ranman96734

    I suppose my point is that the fact that you think you’re the best judge of whether or not your code is useful is part of code-ego. Often times people are unwilling to submit themselves to public scrutiny for fear of being revealed as incompetent or an impostor (these fears are often unfounded) — oh and to clarify I’m not saying “you” specifically (I don’t even know you) — I’m saying “you” generally (I’m just thinking of examples of people I’ve interviewed). When people aren’t willing to have their code reviewed either because of 1) insecurity or 2) overconfidence it leads to a “code-ego” situation where one has to navigate both technology and psychology and that’s something I’m personally not fond of.

    I agree that some companies ask for a lot. If it’s already written it shouldn’t be a problem. My sole point here is that while github/bitbucket/etc is not your C.V. — it’s a very convenient portfolio, and in order to properly understand and evaluate a candidate regardless of their background or endorsements I really have to be able to see things they’ve worked on in the past.

  • zerexim

    I see your point but if we follow that line, you’re arguing that when it comes to personal stuff, everything should be dumped for public consumption. And, well, I don’t agree with that :)

    Your description of “code-ego” person more looks like introvert and/or shy person. I’d avoid creating psychological portraits of interviewees, at least because we’re not specialists in this area. Also this creates huge prejudices which is not what we want. You might had some issue with a shy person in the past, but that doesn’t mean you should disqualify all possible shy persons in the future.

  • Jon

    I have nothing against using Github as a tool to make an informed decision. Sounds great.

    But statements like the one below are inexcusable.

    “If they don’t have anything at all that they can share… then they just do programming for the money, which is fine, but you probably don’t want to hire them — let them go back to a bank and enjoy the other parts of their life.”

    I don’t see how you can try and act all measured and diplomatic in your response to my comment, yet you spew trash like the paragraph above in your article.

  • ranman96734

    1) Not my article.
    2) Do you disagree with the statement? Do you have a counter statement? If someone has literally no code to share with me then I can’t hire them. I have to be able to see things they’ve worked on in the past end of story. I’m sure there may be ad-hoc exceptions but in general I would need to see their code.

    You’re pretty abrasive — not sure if you’re just trolling or are genuinely that defensive but either way maybe you can tone it down.

  • ranman96734

    I’m not saying literally everything but definitely more than a lot of people share — do you have shell scripts to open up tickets in your bug tracker from the command line? That’d be a great thing to share in a gist or a wiki or anything at all, it could be 20 lines or 200.

    That was just one example — I’ve also experienced the other extreme where people are extremely resistent to changing their code during a review. I definitely agree with your point about creating psychological profiles of interviewees but I disagree that we can’t learn from mistakes employees have made in the past and let those influence our hiring decisions for the future.

    I definitely have learned that there are personality types and while I’m no expert in the field my experiences with the abrasive personality types and watching them corrode teams from the inside have definitely left me extremely hesitant to hire someone who manages to exhibit similar characteristics during a 1 hour interview. Does that make sense? I sort of coined the term code-ego and I’m not sure if it’s been around before but I think it’s just a valuable metric to have on candidates.

  • Jon

    Specifically.. “If they don’t have anything at all that they can share.. you probably don’t want to hire them”. Oh and apparently they work or use to work at a bank. That statement is fraught with falsehood! This we can both agree on, I’m sure. Feel free to disagree, but we’re not going to see eye to eye on anything if you think biased/opinionated generalized statements like that one are OK.

    No, you don’t have to see things they’ve worked on in the past! If that’s your ‘I must have this or else!’
    criteria for hiring someone, you’re bad at hiring. What you want is to get a sense of this persons skills and abilities, and you’re using their previous code as a measuring stick. Great. But if you think the only acceptable way to do this is to see their past code, you’re wrong. Stop limiting yourself and trying to limit the rest of the world to the only way that *you* are able to accomplish this.

    Yes, a coding task, new code, now we’re thinking. Why say it so sheepishly?

    Of course if someone comes in to your interview process and you say hey, this is how our process goes, the steps are A, B, C and your candidate says I refuse to do A, then regardless of what A is, that’s absolutely grounds for not hiring them. Maybe that A is an initial phone screen, maybe its a coding task, doesn’t matter, obviously it sounds like a very extreme and unusual situation for someone to refuse to do a part of the interview, and for you to not have a viable alternative to offer them. How many times have you encountered this?

    Instead of asking them about code they’ve already written, why not ask them about code/problems that you’ve faced in the office, or that they might face coming into the role and have them think on their feet, see how they would approach the problem. You have months if not years of problems that have been solved in your office, throw a few at them from a high level and see whats up! This does not need to be a coding exercise! A technical discussion can tell you wonders.

    Don’t call me a troll again. Yes maybe I can tone it down.

  • zerexim

    But what I don’t agree with you is that you made a false correlation between nbr of lines pushed to github vs abrasiveness or “code-ego”-ness of person.

    Maybe that one person you had conflict had less code on github, but that doesn’t mean any other person who has similar “shiny” github or doesn’t have at all, will be an issue as well.

  • ranman96734

    I guess I did imply # of lines. What’s actually a lot more important are the conversations around those lines which are frequently visible on github. I will use our friend Jon above as an example though. Apparently he’s worked at Oracle, Amazon and Microsoft and is a Brown grad. Can’t find a github or bitbucket for him anywhere though and it’s not listed on his LinkedIn — that’s fine I’m not evaluating him for hire. You’ll perhaps notice though that he’s incredibly abrasive and rude. Coincidence? One data point definitely isn’t enough to tell.

    Yes I’m aware that every person should be evaluated on their own. However, if I’m walking down a dark street alone and see two tall men in hoodies and sweatpants look at me, then each other, and then start walking more quickly towards me I’m not going to wait around to find out if they want directions. I could be 100% incorrect but I can’t afford the false positive in that situation.

    In interviewing false negatives are cheap, false positives are incredibly dangerous. It may also be prudent to point out that I am most often hiring for a position making open-source software.

    I’m certain that we’ve turned away good people for the wrong reasons — some of those people have been my friends — that said, I am also certain that, at least in the past two years, we haven’t hired any engineers that I object to. That’s the price of growing a company when you can’t afford mistakes.

    I’ll get back to my core point so we can avoid any tangents.

    This is my thesis and feel free to refine it:
    In the same way that you would not hire a photographer, artist, contractor, etc. without a portfolio of their previous work you should not hire an engineer who cannot show you examples of previous things that they’ve worked on. Github or bitbucket are useful tools in the candidate selection process because they provide an excellent medium for evaluating a person’s code.

    One might argue that a photographer, artist, contractor, etc. all have end products that are visible but you don’t get to see the process that goes into it. I would argue two things to counter that. First, most reviews of these people include the phrase “throughout the entire process Ginny made it clear what was happening and what we were paying for” which should speak for itself with regards to process. Second, programming is not like construction or photography, we never make the same thing twice because if we were doing that we would just use copy + paste. That’s why it’s important to see the way someone goes about coding.

    You can argue the various merits and demerits of using github to evaluate someone but if you disagree fundamentally with my above statement that past work is, in most cases, necessary for proper evaluation then I’d enjoy hearing why because I can’t immediately conjure up a valid scenario.

  • ranman96734

    Note the use of words/prhases like “probably”, “often”, and “I’m sure there may be one-off exceptions” that are littered throughout the things that I have written. There are numerous examples that contradict the points I’m making — I just think there are *many* more that agree with the points I’m making and that’s a relevant and useful observation. I’m not making hard and fast rules for any situation — I’m describing, what I believe, are useful guidelines.

    Life is opinion and bias. We evaluate the world around us entirely based previous experience. What’s important is whether or not those opinions are malleable and whether or not they are informed by data or by sentiment. I think this is a statement that is self-evident but I’m open to hearing why you might disagree.

    “Feel free to disagree but we’re not going to see eye to eye on *anything*”

    “If this is your criteria for hiring … *you’re bad at hiring*”

    While you’re dishing out statements about generalizations I’d ask you to follow your own advice and drop the ad hominem.

    Regarding a coding task. That’s often another medium for evaluation post phone screen. Keep in mind however, candidates are busy, they have lives of their own. If I’m going to give someone a coding task I’m going to need to compensate them for the time. The result of the task is also not likely to be immediately useful to us. Evaluating code they’ve already written and offered up as an example of their work? That only requires an investment of time on my end — not theirs. It’s not like our interview consists entirely of going over their old code. More often that’s a 10 minute part of the conversation about their experience at other companies and then we move into technology discussions.

    re: interviewees refusing to do task N, I have encountered that infrequently but I also don’t specifically understand the relevance of the statement or question, sorry.

    Regarding asking a candidate about problems we’re currently facing, we do this, but normally during onsite interviews and not before — mainly because in order to talk about these problems, even in a reduced case, you need a certain amount of context that is hard to provide both efficiently and remotely.

    I’ll reiterate: github/bitbucket/etc. are individual tools in a greater toolbox of hiring practices. Effective hiring will normally involve more than just one tool. I think we’re in violent agreement on that statement — just not about which tools to use. I find github/bitbucket/etc. have historically been great indicators of how successful an engineer is going to be. I have limited data to work from but it’s also the only data I have to work from. If you have data to the contrary then I’d really enjoy hearing about that or discussing it in a calm manner.

    Also the original statement you took issue with was: “If they don’t have anything at all that they can share… then they just do programming for the money” allow me to rephrase please.

    If a candidate has no code to share with you, regardless of medium (ok well not papyrus), they will most likely not succeed in the company or the interview process.

    I think that is an accurate and defensible statement.

    I don’t have a lot more time to devote to this unfortunately but I appreciate you guys all taking the time to share your thoughts and it’s caused me to think some as well. I’m going to write a followup post on my own blog and maybe we can move the conversation there. I look forward to your response but may not be able to respond in a timely manner. It might help if we avoid tangents going forward and try to just focus on the core issue of using github as a tool for hiring.

  • zerexim

    I haven’t analyzed posts of another user here, but again, your conclusion is wrong. Replace you sentence with:

    “He’s pink* and he’s incredibly abrasive and rude. Coincidence?”

    * – instead of pink, put any of your favorite skin colors… now you see…

    I mean, it is fine to say: “with github, I’m more confident with the person, but without it, I just *don’t know* “, so you choose the easier path, I understand…

    But saying that those are abrasive persons who don’t have github – that is plain wrong.

    Agree, that you can find out some personal characteristics, when you can browse the github message logs or mailing lists. Like we know about a couple of open source celebrities that are real ass*oles…

  • ranman96734

    I’m asking the question and clearly stating that one data point isn’t enough to draw a correlation. Correlations are useful in the real world though.

    These aren’t physical characteristics of a person we’re discussing though — that would be a different argument entirely. These are visible choices a person has made over time and a person can and should be evaluated on some of those decisions.

  • zerexim

    The most important thing with correlations is that you can correlate anything with absolutely anything. You can as successfully state that someone is abrasive because she ate food X and not food Y this morning. Or how she named these functions (if you prefer code-related choices).

    OK, no matter how you articulated earlier, later you formally stated that one data point isn’t enough so I guess we have some point of agreement :)

    One meta note:
    Not having something is not a pro-active decision. I mean, some person might even haven’t thought about the subject (be it github or food X) at all.

    While having/acquiring something – that is the real decision making.

    So e.g. if you find one million serial killers who deliberately ate food X every morning. There might be some correlation. But if none of them had rainbow-colored t-shirts (or github!) that means absolutely nothing.

    Thanks for the discussion!

  • Jon

    You know what your problem is? “I’m sure there may be one-off exceptions”.. That’s your problem.. no there are not one off exceptions, because whatever you’re saying is not the rule!

    I shall avoid responding to the rest of your response, because as you claim I generalized earlier, we won’t see eye to eye on anything. Seems to be turning out to be true.

  • Pingback: Top 3 Non-Technical Interview Web Developer QuestionsSupacoderz Blog