As Director of Engineering you'll be interviewing a lot of Engineers - my average is more than 2 interviews per week for the last few years.

Filter candidates early

The interview process changes according to the company and situation, but there'll be some combination of the resume screen, the phone screen, the coding interview and the personality interview.

Be very strict in the early stages, and don't waste your time. Rejecting half the applicants from looking at their resume and LinkedIn profile alone will save you a lot of time and heartache.

Even if you are desperate to fill a position, don't cut corners. You'll regret it and end up with a sub-standard team or have to fire them later. Either way is very costly.

Undoing previous bad hires is never good for either party, but here's one extreme example that I witnessed. A large company was so scared of legal action from employees that it implemented long and cumbersome HR processes to fire someone. Extensive documentation, verbal and written warnings, review boards - so much that one new hire cleverly played the system by never showing up for work and was paid for 6 months while they went through the offboarding process.

Ultimately, what you're looking for is enthusiasm, confidence and honesty - not "Expert in Java, C#, C++, C, VBScript, Javascript, JQuery, Cobol, Fortran, Angular, HP/GL, 8080 assembler, blah, blah.."

Hire impressive people. Hire for personality, not expertise. They'll be learning new technologies throughout their career, but to paraphrase Ron White, "You can't fix assholes".

The first step is looking at their resume - but before you do, have HR review it first.

You can document some simple rules, like "they must have used C#/ASP.NET MVC as their main focus in last 3 years", or "If they list MS Office under Skills, reject them".

Over time, give HR feedback and update your documentation so they reject more and more before you see them.

Resume and LinkedIn review

This sounds obvious, but candidates should want the job you are offering.

Not just any job at any company, your job. Don't accept bland generic resumes from bland generic candidates. Don't accept "phoned-in" resumes without cover letters.

If you receive a resume with typos, grammatical errors, generic filler content, buzzwords, old technologies or anything that sets off your BS filter, reject it immediately.

Look at their LinkedIn profile. Obviously they must have one, even recent graduates. There must be a photo - this is the beginning of an open and honest relationship. Let's start on the right foot.

In fact, I'll go further. It better be a happy smiling photo - what sort of personality would put a grumpy photo on their profile? (I've seen some that look like serial killers)

Look for content and a complete history on the profile - ask about gaps - and look at length of employment. If you see 10 years of 3 month engagements then make sure short-term contract is what you are looking for in your hire.

Look for LinkedIn recommendations and endorsements from others - it shows that they made a positive impression on their co-workers.

Seeing a short list of skills with few endorsements for a 10-year veteran is not good.

The phone screen is dead?

I may diverge from the norm here, but I've given up phone screens for a while now. I used to do them but I realized that I rarely rejected anyone from the phone screen.

What really killed the phone screen was that 9 candidates out of 10 are failing my coding test. It became more efficient to do the coding test first, followed by the final personality interview.

This may seem contrary to my assertion that personality and team-fit are more important than technical expertise (they are), but this does assume a "table-stakes" level of coding ability.

Coding standards for candidates has dropped significantly since the early 2000's. Back then the majority passed coding tests. Now it's a very small minority.

I suspect the cause is higher-level languages. I'm not a language snob by any means but Java, then C# and now Javascript have lowered the barrier to entry significantly compared to C and C++.

Many more people are trying to become programmers than ever before, even getting jobs in the field. However it's not uncommon to have "8-year senior developers" fail truly simple problems.

Frankly, at many companies it's easy to hide or become a professional peer-reviewer or meeting-attendee, with few coding skills.

The coding test

Once their resume and LinkedIn pass muster, it's on to a one hour coding test. I'm tempted to explain the test here, because it probably wouldn't help most candidates that I see, but I'll be restrained and share that privately.

Suffice it to say, it's a very well known coding test, with a few wrinkles. Since you're reading this you would probably recognize it - and may even think it's jokingly simple. It is.

Yet, most of today's candidates haven't even googled "coding tests" or done any homework. 1 in 20 recognize the test. Half the candidates fail to solve the first step.

I joke about writing a book with the code I've seen at this first basic step - here are some examples to give you an idea:

  • Forgot the syntax of a for loop, had to google it
  • Another added a semi-colon after the for loop and wasted 30 minutes trying to find the error, even though the screen was a sea of red squigglies telling them exactly what to do
  • When asked to pass in a list of values, they hardcoded p1, p2, p3, p4 and then wrote 4 if statements to use them. When asked what if there were 5 values, their answer was to copy/paste a fifth parameter and if statement
  • 40 minutes wasted because of a missing brace
  • Another was very puzzled with the concept of passing in a variable-sized list of data to his method. "You want to pass in 2 values one time and 6 another? That's very complex".
  • Couldn't work out how to reference his dll from another. Tried and failed with using, static, global vars, etc
  • Confused continue with break - but actually didn't need either
  • Asked me the key combination for copy/paste "in this environment".. Visual Studio.

I'm not making these up - I have many more. This list was created from skimming my notes from the last few weeks (I create a new Evernote note for every interview, paste in the questions and write notes inline).

The second step is to perform some simple refactoring; extract method, add parameter, abstraction, etc.

If we get past this, we're down to 10% of the people who started. The last question is "how would you unit test this?".. often resulting in blank stares.

Most fail, thank goodness

Yes, most fail the coding test, but that's ok. I do them over video conferencing, with the candidate sharing their screen so I can watch them code.

The beauty of this (at least if you have two screens) is that I can continue my work as they code. With the competent candidates I rarely can because they are chatting, asking clarifying questions and coding quickly (like it's no big deal).

But I can cheerfully leave some candidates floundering without wasting my time. No, I'm not being callous, I do stress throughout that they can ask questions and discuss what they are thinking. And if they are nervous I account for that too and help some more.

I rarely cut any interview short. They deserve a chance to find their feet and do their best. I remember stopping only once this year, when the candidate admitted they didn't actually know any C++ but "thought it would be a whiteboard test".

FWIW, I dislike whiteboard tests or pseudo-code; I feel you can get a better sense of a programmer from watching them actually code. Funny that.

But a few do pass

Of course, those who pass tend to do so convincingly, finishing in plenty of time and talking through their various design decisions and why they chose a certain route.

Some even ask permission to use TDD upfront, and usually sail through (although not always, there have been some notable and spectacular TDD fails).

But it's still not about the questions or the answers. They certainly need to be able to be comfortable coding, but it's far more about how they answer the problems, discuss them, give us options and know which to pick.

It's style over substance. It's not getting "the right answer" because there isn't only one. It's about them taking the interview seriously. Taking notes, asking questions and dealing with building pressure during the interview.

It's listening to your instructions and following them - not making you repeat something multiple times.

Plan for an escalating difficulty interview - you may find something they don't know.. how do they cope with that? They should be confident, honest and ask for help.

What's your first impression of them? That's usually correct.

Nervous? That's ok, especially for younger candidates. Try to put them at ease. Yes, this is important, but you can still tell if they can do the job, despite their nerves.

Likewise with arrogance - we've all had "that guy" strut into an interview without a care in the world and with no respect for you or your opportunity - have a "plenty more jobs like this one" attitude and I'll gladly let you go back out to find one.

Arrogance is not the same as confidence, and can appear at any age, from double-major graduates to PhD Architects. No thanks.

One recent example - their first words inside the interview room were "I generally don't agree with coding tests", followed by "No-one has bothered to interview me for 10 years". Sigh. Could they code? yes, up to a point. But not well enough to get over their personality.

It's their personality that's important.

Look for deference, respect, punctuality, culture fit, social ticks - and would you drink a beer with this person?

You and your team spend a lot of time together. Over time, you'll build mutual trust. Become friends.

Think about that while you're interviewing.