More Than Coding

Because machines still need humans

Category Archives: Interviews

How to phone-screen programmers and not go insane

Technical phone screens are hard to do right. Yet, they serve an important role. They are the primary filter that ensures you only bring in appropriate candidates to spend valuable hours meeting your team. If you don’t phone-screen correctly, you’ll end up bringing in some real timewasters who don’t even come close to having the technical chops or the personality to make it through your in-person interviews.

Your hiring process is a classic funnel and the phone screen phase is near the top of it. That means that a ton of resumes will land on your desk (along with a boatload of eager emails and voicemails from your recruiters), and at each stage you will cast aside a very large percentage of them.

We just finished hiring for four engineering positions here at TimeTrade. Here are the metrics we saw at each level of the funnel:

  • 120 resume reviews
  • 53 one-hour technical phone screens
  • 22 four-hour first-round interviews
  • 9 four-hour second-round interviews
  • 4 actual hires

As any sales or marketing person will tell you, the more you put into the top of a funnel, the more results you’ll get out at the bottom. That’s just as true of recruiting, too. Your challenge therefore is to figure out how to do lots of phone screens without compromising their quality or your sanity. Here’s how.

Schedule Efficiently

The seemingly simple act of setting up the phone screen is usually where you will find your free time disappearing, and fast. As a hiring manager, you almost certainly have a calendar full of existing meetings and commitments, and trying to get dozens of extra appointments with candidates requires a lot of calling, emailing, chasing and waiting. Sometimes the recruiters or candidates will get things wrong and end up double-booking you, causing even more hassles for you to reschedule around the conflicts.

But that’s not everyone’s experience. In fact, it takes me all of 30 seconds to set up an entire two weeks’ worth of phone screens.

It’s not magic that allows me to do that – it’s technology. Instead of me doing all the negotiation and scheduling, I simply use TimeTrade’s online appointment scheduling tool to share my open times for phone screens (for example, 2-4pm every weekday) and it gives me back a single URL that I can email in bulk to all my potential candidates and recruiters. That email might look something like this:

I’d like to phone screen you for the engineering position here at TimeTrade. Please click here to choose one of the available times to speak with me.

– Brian

The product is integrated with my Outlook calendar, so the moment a candidate chooses a slot it drops onto my calendar without any effort on my part (and they can add it to their own calendar too, of course).  I’ll admit I am biased since I work for the company, but I can’t imagine going back to spending hours scheduling appointments the old, manual way I did before.

Be Prepared

Now that you’ve scheduled your phone screens, you need to run them efficiently and learn as much as you can about the applicant’s skills and personality. Unless you’re extremely experienced in this area, you won’t be able to “wing it,” at least not without sounding like you aren’t very prepared. Having a list of potential questions and areas to probe is an absolutely necessity, and it will give you more confidence to run the phone screen properly if you’re new to doing them.

Importantly, you should make sure to have a number of alternative questions available for each area you would like to probe, and use different ones each time. It’s quite common for friends or colleagues to apply for the same position, and they might share their questions to give their buddy a better chance of being brought in for an interview. If nothing else, it can bring a bit of variety to the process that keeps you interested in it when you’ve just completed your 30th phone screen in 4 weeks.

Code Online

The most important thing to test with a software engineering candidate is their ability to solve problems by writing code. After all, that’s what they’d be doing if they got hired.

Sadly, most phone screeners never tackle this area because they believe they’re limited to questions that can be asked on the phone. That means lots of questions about the details of software (such as, “What class library would you use for socket I/O?”) but almost none that would help you gauge their problem-solving and programming abilities. Of the few people out there who do make people code over the phone, some of their proposed methods (like having the candidate write their code on paper and dictate it back to you) are pretty clunky.

Enter the free and simple online collaboration tool TypeWith.Me. Problem solved.

Right before the phone screen starts, I email the candidate a URL to a new “document” hosted on that site. When they click on it, they’ll see an empty document in their browser, but anything they type in it will be immediately visible to me. In addition, anything I type will show up on their side too. Think “Google Docs without any registration required”, and you’ve got the idea.

I’m able to paste in a few lines of text from my script that outlines each problem I’d like them to solve (reverse a linked list, compute the Nth Fibonacci number, etc.) and sit back and watch them code in real-time. Since they’re also on the phone, we can easily discuss their overall approach or I can interrupt them to tell them to reconsider that if (a = 0) statement they just typed in.

To make sure this whole process works, you need to inform your candidates ahead of time that they’ll be asked to use this kind of tool because they’ll need access to a speakerphone and the Internet. All of these instructions are visible when you click on my TimeTrade URL so each candidate gets to read them before picking their appointment time.

You’d be amazed at how many candidates refuse to even start writing code, indignantly claiming that their years of industrial experience mean that they shouldn’t have to perform these types of tests. By claiming as much they will have self-selected themselves out of the process, and I’m always happy to inform them of that fact.

Sell Something

Always take the time during the call to sell the company, the team culture and your products. Do this even if the candidate is terrible and would never, ever get hired for your team. A phone screen is as much of a marketing and networking opportunity as it is a chance to make the right hire. You never know when your paths will cross again, or what friends your candidate might refer to you.

Running a screen efficiently using the tools and techniques described earlier shows that you and your company are professional about hiring and take your phone screens seriously. Don’t underestimate what this kind of first impression means to a candidate.

Track Your Progress

Now that you know how to schedule and run phone screens properly, the last thing you need to do is figure out how to track the workflow for each candidate as they make their way through the funnel.

I’ve used a variety of tools for this (Excel, Outlook and good ol’ paper) but they all were all lacking in some way. Recently I stumbled upon Trello and discovered that it is a complete – and free – solution for my hiring tracking needs.

Trello finally gives my team and I the ability to track where each candidate is in the hiring process and to move them effortlessly through the funnel. We can also store their resume there and avoid having to email it around all the time, and since it’s an online SaaS tool there’s no chance of some team members seeing stale information.

Technical phone screens are hard to do right, but the tips above should take them from being a sanity-draining chore to become a regular, enjoyable and effective part of your hiring process. You’re welcome.

Hiring awesome software interns

What says “summer is here” more than the nice weather? It’s the flood of eager college kids who are keen to get hired for a few months to get some real commercial development experience.

The challenge for employers is in the interview process. Because the candidates are both young and inexperienced, it can be tough to gauge the skill level of somebody so “green”. Assuming they are being hired to actually write code, you should of course check their knowledge of fundamental algorithms and data structures. However that might not whittle down the list enough, so how can you figure out which of these fresh-faced kids are the best of the bunch?

Ask them two extra questions:

When did you start programming?

If they answer, “For my assignments in CS101”, put them at the bottom of the pile.

If they instead answer, “When I was 13, I started creating my own web pages and coding Javascript utilities to make them do more cool stuff, and I haven’t looked back since”, put them at top of the stack.

Do you write software in your spare time?

If they answer, “Yes, I just built this iPhone app to see if I could, and now I’m writing a Sudoko app for Android for fun”, well, you guessed it: top of the stack.

The answers to these simple questions tell you if the candidate chose to study computer science because it sounded like a good career choice, or if software was already their passion. And that can make the difference between a good internship and an awesome one.

The Programmer Pyramid

Newsflash: some programmers are better than others.

OK, I admit that’s hardly a revelation. But most companies use a grading structure that can obscure the relative strengths of each engineer on the team. There may be a 20-year veteran with the title Principal Engineer who regularly breaks tests and hacks his way through his day while a young intern may be writing some of the best code the team has ever seen.

I’ve built my own mental model of programmer strength and organized it as a pyramid:

Typist

At the lowest level of programming competence is the Typist. They hit the keyboard a lot but don’t produce anything that even remotely resembles professionally-written software. They are utterly lacking in their technical knowledge and have little desire to change that fact.

A software team cannot survive long with typists in their midst because they do more harm than good. They are at best anchors and at worst damaging to the momentum and morale of the other members.

Coder

This is the level that most programmers are at when they graduate from college. They have a good knowledge of data structures, algorithms and are proficient in at least one language. Due to their limited professional experience they typically don’t yet understand why they should make code maintainable or do refactoring (mostly because they haven’t yet had to fix someone else’s bugs).

Coders require investment from the stronger members of the team in terms of review and oversight, and if there are many of them on the team, that can weigh the others down.

Builder

A Builder is a Coder who has adapted to work in a professional environment. They create readable, well-organized code and always ensure that their tests pass.

Builders work best executing the designs of those above them in the pyramid. They write good tests, are self-motivated and have the word “solid” associated with them a lot. Most teams need at least some Builders to be productive, and most teams indeed already do have some of them on staff.

The majority of programmers reach this level during their careers, but not all of them will move upwards to Engineer.

Engineer

Ironically, almost all professional programmers have the word “engineer” in their job title, but many of them simply never live up to the name.

Engineers design scalable and reusable components, infuse others with their knowledge and are very disciplined. They keep abreast of industry trends and technologies but will only use the right tool for the job at hand rather than get distracted by the latest fun tool they played with.

Their code is impeccably written and very well-thought out, and they know exactly how it fits with the rest of the system. They are very good mentors and routinely assist others on the team. Every team should have at least one.

It’s not guaranteed that a Builder will eventually become an Engineer, because some of the traits required (creative design and problem solving, among others) are likely innate and can’t easily be learned.

Master

Masters are rare. These seasoned veterans produce software that is more than just engineered – it is crafted. Their software has aesthetic beauty. They are the Frank Lloyd Wrights of software and are worth every penny if you are lucky to find one on the market.

Whatever they create – be it a user interface, an API or a tool – is incredibly easy to use. It just never gets in the way because it just works, and works well.

Having a Master on your team quickly causes people at the lower levels of the pyramid to move upwards thanks to their positive influence. I was lucky enough to have one on the team that I joined after leaving college, and I’m forever grateful for the experience. The Master created a team culture that encouraged everyone to better themselves and to work like true professionals.

An unexpected attribute of a master is their humility. While there will always be plenty of alpha Engineers around, the Master is confident and secure in their knowledge and doesn’t need to brag or assert dominance. Their work speaks for itself.

Using The Pyramid

The pyramid is most useful at hiring time. Many employers think first in terms of the position they need to fill and then only consider the relative strengths of the candidates after they’ve interviewed them. I think that’s backwards. They end up completely discarding resumes without the “correct” number of years of experience. A better approach would be to think about the desired strength of candidate first and only worry about their grade when an offer is being prepared.

The pyramid helps prevent the kind of pointless discussions that begin with someone in management saying, “We must hire only top talent!”. That’s a fine goal, but you have to realize that you’re not going to find a team comprised only of Masters. You may need a few Coders to write an internal testing tool based on the design of some of the stronger members, and it would be silly to pay top-dollar for that work.

You may also look at your team and realize it’s staffed almost universally by Coders, and what it’s really missing is a strong Engineer to lead, mentor and inspire them to build better software and lead their growth up the pyramid levels.

When you are interviewing a programmer for a position, I’d suggest drawing the pyramid on the board, explaining what each level means and asking the candidate where they think they currently fit. You’d be surprised how much you can learn from their reply: some candidates shoot right for the top and proudly boast that they’re Masters while others take the time to really consider their own abilities and give an honest answer. I have even encountered candidates who, after hearing me explain the level of strength I’m looking for, candidly mention that they may not be right for the position.

And it’s so much better to find that out before they get hired.

A Fake Google Interview

Imagine an engineer being interviewed at Google:

“Have you seen our website?”

“Oh sure, I’ve been to goggles.com.”

“Do you know what we do here?”

“Something about searching, I think. You do some advertising too, right?”

That’s a ludicrous scenario only because Google is so well-known. Everyone interviewing there nowadays knows exactly what their website looks like and is aware that they are the world’s most popular search engine.

Sadly, the same conversation plays out every day in technical interviews around the world in companies smaller than El Goog. The candidate arrives armed with a smart suit but is lacking even a basic knowledge of the company’s products, goals or technology and the interviewer quickly realizes they are wasting their time.

You may think that’s harsh, but consider the candidate’s motivations. By not bothering to understand the company, they are implicitly declaring that they want a job purely to benefit them. They look at job descriptions for a few techie keywords that they recognize, and email across their resume. They don’t know — and don’t care — that their potential employer is looking for passionate people to become part of a team that will work together to build something revolutionary or make huge gains in the market. They’ll be a 9-to-5’er, doing exactly the minimum work required and no more. Unless the position is for mindless data-entry, the company is not going to benefit from having someone so self-serving on their payroll.

Therefore if a candidate hasn’t even bothered to look at what the company does before going there to ask for a job, they should be quickly shown the door. However if you’re like me and enjoy hearing dreadful answers to softball interview questions, you’ll always ask them one final thing before escorting them off the premises:

“So, why do you want to work here?”

%d bloggers like this: