Tag Archives: interview

How To Hire Great Developers

2 Replies

In a previous set of posts I talked about how the difference between an average developer and a great developer is enormous, how bad developers can effectively cancel-out your good developers, and why you therefor need to hire just the very best.

So how do you tell if someone is good? or bad? What are the core competencies and key indicators of an ‘A’ player developer? And how do you interview for them?

Great Developer Key Indicators

The following is a list I’ve accumulated over time. It’s never complete, and certainly up for discussion, but in my experience is a pretty good set of indicators for whether a developer is an ‘A’ player or not.

Great developers:

  • Can deal with many levels of abstraction simultaneously.
  • Are masters at managing complexity.
  • Know space and time trade-offs of the major data structures.
  • Understands multi-threading, resource locking, and how it’s implemented.
  • Understands that simple is better than complicated, every time.
  • Has used a DVCS (git, mercurial, etc).
  • Are masters at managing expectations.
  • Plays with new technologies and languages and stays aware of upcoming developments.
  • Understands what TDD is and why it’s a valuable practice.
  • Is likely to develop iteratively and incrementally, adding value with each release.
  • Understands how to accomplish loose-coupling and encapsulation, especially in things that are likely to change.
  • Is not a lone-coder who goes dark for long periods of time.
  • Knows how to communicate well, not just with developers, but all levels of management and stakeholders, and can adjust communication vocabulary/style per context.
  • Knows SOLID principles and practices them effectively.
  • Recognizes that code reviews are excellent ways to improve yourself, both as an author or reviewer.
  • Can grasp the bigger picture.
  • Doesn’t just accept work items and marching orders, but also proposes alternatives and improvements.
  • Knows 1 procedural language, 1 object-oriented language, 1 functional language, 1 scripting language, 1 statically typed language, and 1 dynamically typed language. (There is much overlap between these categorizations)
  • Fluent in major design patterns and how/when to implement them.
  • Knows most of these books:  Code Complete, Pragmatic Programmer, Clean Code, Mythical Man Month, Design Patterns by the Gang of Four, Programming Perls, Code: The Hidden Language of Computer Hardware and Software, C by K&R.
  • Keeps up with development blogs/twitter/podcasts.
  • Is highly passionate about software development.

Bad Developer Red Flags

There are some simple things you can do to immediately weed out the really bad developers in an interview scenario.

  • Have them write FizzBuzz; believe it or not most developers do poorly on this, and it’s a great way to identify them early on in the process.
  • Ask them what the last new language or development environment they learned was. If it’s been a long time since they’ve learned a new one, that’s a red flag.
  • Ask them what they think a great developer’s best attributes are. If the answer isn’t in the list above, it’s probably a red flag.
  • Have them explain dependency injection to you, and a simple example. If you get a deer-in-headlights response, it’s a red flag.
  • Ask them to solve problems that involve in-place manipulation of a linked list or string. If they don’t understand pointers or space/time complexities of a problem, that’s a concern. ‘Reverse a linked list’ is a good one to ask.
  • Find out if they have a GitHub/BitBucket/Codeplex/SourceForge.  Look for evidence of development both inside and outside of work.

What NOT To Do

  • Don’t ask questions that are just quick facts. A programmer that knows what port IMAP runs on isn’t going to be a better programmer than one who doesn’t. Knowing little C compiler optimizations doesn’t make you a better programmer.
  • Don’t just ask questions with verbal answers, or open-ended answers. Actually have them write code on the whiteboard. A lot.
  • Don’t use questions that are common enough to where they could be googled before hand or memorized.
  • Don’t just be satisfied that someone answered something correctly. Talk to them about their solution. Ask them to modify it. Ask them to test it. Challenge their thinking.

This is an organic post, and I suspect I’ll add many suggestions from readers.

 

Why You Need To Hire Great Developers, Part 2

18 Replies

In my last post I talked about why you need to hire great developers, and how the difference between average and great developers is easily 20x.

Recently, Robert X. Cringely found and restored an hour long interview with Steve Jobs from his days at NeXT. He’s put it up on the web as Steve Jobs The Lost Interview. In this video, you really get to see first hand a lot of Steve Jobs thinking. What I found interesting, in a deja-vu sort of way, is the following remarks from Steve Jobs about teams and the dynamic range of software developers:

“I observed something fairly early on at Apple, which I didn’t know how to explain then, but have thought a lot about it since. Most things in life have a dynamic range in which average to best is at most 2:1. For example if you go to New York City and get an average taxi cab driver versus the best taxi cab driver, you’ll probably get to your destination with the best taxi driver 30% faster. And an automobile; What’s the difference between the average car and the best? Maybe 20% ?  The best CD player versus the average CD player? Maybe 20% ? So 2:1 is a big dynamic range for most things in life. Now, in software, and it used ot be the case in hardware, the difference between the average software developer and the best is 50:1; Maybe even 100:1. Very few things in life are like this, but what I was lucky enough to spend my life doing, which is software, is like this. So I’ve built a lot of my success on finding these truly gifted people, and not settling for ‘B’ and ‘C’ players, but really going for the ‘A’ players. And I found something… I found that when you get enough ‘A’ players together; when you go through the incredible work to find these ‘A’ players, they really like working with eachother. Because most have never had the chance to do that before. And they dont work with ‘B’ and ‘C’ players, so its self policing. They only want to hire ‘A’ players. So you build these pockets of ‘A’ players and it just propogates.”

 

Why You Need To Hire Great Developers

52 Replies

The difference between a bad developer and an average developer is small, but the difference between an average developer and a great developer is enormous. It’s an ocean of difference. A great developer is 20x more valuable than an average developer, easily, and so it’s critical to hire one great developer, instead of 20 average developers.

A recent coworker of mine once worded it this way:

“You have entropy creators and entropy reducers”.

Both groups will add value (at 20x differential), but the rate at which entropy is added to the system needs to be as low as possible, otherwise the entropy reducers won’t ever get past just removing entropy from the system, in the form of bugs, poor code design, etc.

Great developers know about this ocean of difference, and so they tend to gather at organizations that have a reputation for hiring great developers. Average or bad developers demoralize the great ones, because they can’t keep up with the entropy. A line from Pirates of Silicon Valley captured this well:

“What we do is like opening doors every day, you open the wrong one, all sorts of bad things will come in. You have to be careful which door you open.”

If you let a bad developer in the door, you’ll sap the productivity of the great developers because they will just spend a ton of time cleaning up the messes. And maybe the bad developer is just a really nice person, so you can’t just get rid of them without causing a stir. Nothing good comes this mistake, and the negative impact can’t be understated.

We’re Awful At Distinguishing Great Developers

Software engineering has no qualification standards, and the people who need developers are very poor at identifying/recognizing what a great developer is. The result of this is that there are legions of terrible developers. Our industry is packed with developers who have no business even being in the industry. It’s common to find resumes overflowing with acronyms and claims about their knowledge, which more often than not are extremely exaggerated or just outright falsehoods.

If after you interview a candidate you find that you aren’t completely sure about them, don’t hire them. If you can’t tell if they are good or not, don’t hire them. If 2 out of 6 people on the interview loop are either ‘no’ or ‘maybe’, don’t hire them. The consequence of letting a bad developer in the door is far greater than maybe missing a good one.

In a future blog post I’ll discuss techniques to use when figuring out whether to hire someone.

Number System Interview Questions

Leave a reply

The following 2 interview questions can help gauge whether a candidate understands number systems.

//converts string '123' to numeric 123.
private static int Atoi(string number)
{
    int result = 0;
    int multiplier = 1;

    for (int idx = number.Length - 1; idx >= 0; idx--)
    {
        char digitChar = number[idx];
        int digitValue = digitChar - '0';
        result += (digitValue * multiplier);
        multiplier *= 10;
    }

    return result;
}

//determines the number of bits turned on in a number
private static int BitCount(int number)
{
    int bits = 0;
    while (number > 0)
    {
        bits += (number % 2);
        number /= 2;
    }

    return bits;
}

Find the intersection of 2 arrays

Leave a reply

The following is an interview question used to determine if you understand pointers, even if your primary managed language doesn’t support the traditional notion of a pointer.

public static T[] FindIntersectionOfSortedArrays(T[] a, T[] b) where T : IComparable
{
    T[] answer = new T[a.length + b.length];

    int aptr = 0;
    int bptr = 0;
    int answerptr = 0;

    while (aptr < a.Length && bptr < b.Length)
    {
        if (a[aptr].Equals(b[bptr]))
        {
            answer[answerptr++] = a[aptr];
            aptr++;
            bptr++;
        }
        else if (a[aptr].CompareTo(b[bptr]) < 0)
        {
            aptr++;
        }
        else
        {
            bptr++;
        }
    }

    return answer;
}