As a professional software engineer with two decades of experience, I have dealt with literally hundreds of recruiters over the years. I've seen it all: The good, the bad, and the unflatteringly hilarious. On any given day, my inbox is flooded with emails and voicemails from recruiters looking to poach me from wherever it is I might be. Given the amount of demand in the market for my talent, I can afford to pick and choose the companies and people I want to deal with. And no, I've never been accused of being too humble.

Even if you don't go above and beyond, there are still very easy steps you can take to attract the top talent. You can be the recruiter that everybody comes to because they know you can reel in the big fish.

It has been my observation that most recruiters and hiring managers tend to make the same common mistakes. That is why I've decided to write this new series, "Dev Recruiting 101". In it, you will have the unique opportunity to view your industry from the perspective of a veteran developer. You'll learn the secrets that will win us over and the pitfalls that will make us run for the hills. My goal is to give you the "inside scoop", as it were, about how to attract the best talent in our industry.

Now that the boilerplate is out of the way, let's get to the topic for this inaugural article: Interviews. Since the first Neanderthal needed help porting his cave paintings to Fortran, the dev interview has been a critical linchpin of the IT hiring process. And yet, for all its importance in telling businesses what kind of employee the candidate will be, most hiring managers fail to realize that they, too, are being interviewed by the candidate. As a result, businesses all too often make mistakes that cause their preferred candidates to say, "I appreciate the offer, but...."

To help, I have compiled a list of the top 10 things you should not do when conducting an interview, whether it be in-person, over the phone, via Skype, etc. These are all based on my own personal experience; every single one of the mistakes in this list are things I have actually encountered that caused me to decline to pursue a job offer.

#10 - Discourage the candidate by telling them how lousy the job is.

Have you ever worked in a funeral home for puppies? Yeah, neither have I, but I can't imagine it being any more of a downer than what this guy was describing.

I once had a very depressing phone interview with a gentleman at a newspaper publisher for a senior web developer position. He was very nice and professional, but one thing became very obvious as the call progressed: He was far more interested in seeing just how much discouragement I could take than in evaluating my skills and experience.

"This is a newspaper," he said, gruffly, "which sucks because all the newspapers are going the way of the dinosaur." That was his introduction to telling me about the company I was applying to.

He continued: "We're practically broke and the owners don't have a clue what they're doing. If you want to work here, expect there to be long hours with fairly little pay and you should assume that things will only get worse."

We then talked a little about my background and I casually asked about the existing codebase I'd be working with. "It's crap," he replied. "It's a bloated, unworkable nightmare and the powers that be have decreed that we must keep using it. Your task will be to keep it from blowing-up in our faces while we desperately find some way to convince people to pay for online news that they can get elsewhere for free."

Have you ever worked in a funeral home for puppies? Yeah, neither have I, but I can't imagine it being any more of a downer than what this guy was describing. At the end of the call, after telling me about how he's looking for the right candidate who can tough it out and work in what he described as the most unfulfilling job I would ever hold in my soon-to-be miserable existence, he asked me, "So, are you still interested?"



I politely answered, "No."

There is a simple moral to this story: Don't try to sell the bottom of the barrel to the guy at the top of the ladder. If the job stinks, tailor your talent search toward more junior-level candidates who are eager to take any work they can get. If you do want the best talent, then you have to be prepared to sell the job to them. That means not trying to discourage them from pursuing the job further as a test of their fortitude. In this market, the top talent doesn't need fortitude. There are plenty of non-depressing jobs to choose from.

Of course, at the end of the day, if the position is really lousy, there's only so much you can do to sell it. A cook is only as good as his ingredients. If the company just isn't giving you much to work with, you should probably lower the candidate expectations.

I've already paid my dues. Find a more green developer who hasn't yet and you'll be surprised how much they're eagerly willing to tolerate in order to get some of that much-needed experience.

#9 - Don't show-up for the interview or initiate the call at the agreed-upon time.

This one sounds like a no-brainer. And yet, I couldn't tell you how many times I've found myself sitting with my headset on, staring at the clock 10 minutes after a recruiter was supposed to call me.

My high school band director, may he rest in peace, was a very wise man. He had a saying that he would make us repeat over and over again: "To be early is to be on-time, to be on-time is to be late, and to be late is unacceptable!"

I've never been fond of being a candidate in the interview process. It can be very time-consuming and mentally draining. That's time and mental energy I'd much rather spend coding. So you can imagine how frustrating it is when you've set aside some time during your lunch break to have a chat with a recruiter or hiring manager at 1:00 PM, only to be forced to wait.

The first thing any job coach will tell a candidate about being interviewed is to show-up on-time! You don't arrive to an interview 5 minutes late-- or even 1 minute late-- because first impressions are the most important. The same applies to interviewers.



Now, even the best of us will be late on occasion. Things happen. However, in my experience, they happen way too often when it comes to interviews. I would estimate that well over 50% of all the phone interviews I have done over the years have started late because the interviewer didn't call me until at least a few minutes after the scheduled time.

Perhaps you just want to err on the side of giving the candidate enough time to get ready. I can certainly understand and appreciate that. However, if the person you're interviewing is truly a professional, then such padding is not necessary because they'll be punctual. From my perspective, if I'm being punctual, I don't think it's unreasonable for the other person to be punctual, as well. If I'm late or my clocks are just too slow, that's on me, not you. Your only concern in that regard should be calling me at the time you said you would.

My high school band director, may he rest in peace, was a very wise man. He had a saying that he would make us repeat over and over again: "To be early is to be on-time, to be on-time is to be late, and to be late is unacceptable!"

That being said, calling too early could also be problematic. The best thing to do is be ready a few minutes early. That way, at the exact moment the clock hits the appropriate time, you can make the call. If the candidate is a true professional and there aren't any extenuating circumstances, s/he should be right there, ready to answer the call and begin the interview.

Of course, being a few minutes late isn't the end of the world. It's unprofessional and slightly annoying, but you probably won't lose a candidate by calling at 1:03 PM instead of 1:00 PM. However, anything more than 5 minutes late and you're getting off on the wrong foot. It sends a message that you don't think my time is worth all that much.

If you're 10 minutes late, as far as I'm concerned, you've missed the interview. When I'm sitting there, waiting, I can't start doing something else and risk getting distracted. I'm a hostage. All I can do is sit there and wait for a ring while keeping an eye on my inbox in case you sent me an email about the delay. When you're in that situation, time tends to move very slowly. That's why, if I hear nothing after 10 minutes, I walk away. Whether or not I agree to reschedule and risk wasting another 10 minutes of my time depends on your explanation and how much I want the job.

Things will happen from time to time. If you can't make it to an interview at the arranged time, send an email so your candidate knows s/he doesn't have to sit and wait. Don't presume to set a new date/time without first getting the candidate's agreement, as s/he might not be available an hour from now or the day after tomorrow. I've had recruiters try that with me before. The email will go something like this: "Sorry I couldn't make it! Something came up. I'll call you at 3 instead of 1." That won't fly; and, again, sends a message that you don't value my time at all. So instead, ask me when would be a convenient time to reschedule and offer your availability.

Even if you're running just a few minutes late, you should try to let the candidate know as soon as possible. If you're running 15 minutes late and you tell me, I'll forgo my usual 10-minute rule and wait if my schedule permits. If not, I'll email you back to reschedule.

As far as in-person interviews go, the same principle applies. If we agreed to meet at 3 PM, don't make me sit in your entry room until 3:25 PM. Only doctors can get away with that, and they at least have magazines I can read.

#8 - Don't speak clearly.

If you can afford to and your schedule permits, you should find a speech therapist in your area and make an appointment. It's nothing to be ashamed of and will almost certainly help you to better communicate with your prospects.

I was hesitant to include this one for fear it might be taken the wrong way, but it's been enough of a problem for myself and other candidates I've spoken to that I have to mention it. This is an issue that seems to occur primarily in phone interviews and voicemails.

There is a lot of wonderful diversity in our industry, including people who speak English as a second language. Unfortunately, with some of these recruiters-- and this is not meant to be in any way belittling or disrespectful-- I can't understand a word they're saying. Thick accents can make it difficult to comprehend, but when you combine that with things like mumbling and speaking too quickly, I can listen to the same message a dozen times over and have barely a clue what they're trying to say.

I do not believe this is a problem of race. We all come from somewhere, after all. The problem is with learning to enunciate with sufficient clarity and volume to be heard and understood by the person on the other end of the phone. I had a speech impediment when I was little (I'll leave it to your imagination how I pronounced the word, "fork") and had to undergo speech therapy to correct it. I still struggle with a bit of a lissssp to this day.

If I can overcome it, so can you. The thing is, you're putting yourself at a severe competitive disadvantage if you have this problem. Why? Because people will typically just ignore your message and move-on to the next recruiter if they can't understand you. That's what I do. I get so much volume as it is, I just don't have time to try to decipher the dozens of completely unintelligible voicemails I get on a weekly basis. I've gotten to the point now where I just delete the message and proceed to the next one.

If you have a really thick accent and people are having trouble understanding you, chances are you already know it. And if you do know it, I can all but guarantee it's costing you business. If you can afford to and your schedule permits, you should find a speech therapist in your area and make an appointment. It's nothing to be ashamed of and will almost certainly help you to better communicate with your prospects.

In the meantime, there are two simple things I can recommend that you practice: Speak more loudly and more slowly. Volume is generally looked upon as a sign of confidence in our culture, not rudeness. So don't be afraid to take a deep breath and belt it out! This is advice that can be just as helpful to many native English speakers with no accent to worry about. I've never been good at deciphering mumbles in any language. Also, it's ok if you need to take a little more time to clearly pronounce something. I certainly won't hold it against you and I doubt many of my colleagues would, either. So long as I can at least figure out what it is you're trying to say, I'm happy. Taking a little more time to enunciate certain words you tend to have more trouble with might just make the difference.

Finally, before we move-on to the next point, I'd like to give you a small sample of what it is I'm talking about. Since there's no way to embed audio into these posts, I'll give you the next-best thing: Google Voice transcripts. These are actual voicemails I have received from technical recruiters recently (accurate/intelligible personal info redacted by me). What you're seeing is the Google Voice software's best attempt to decipher what the caller is saying. Those of you who use Google Voice know that the transcription is usually surprisingly accurate. I just want you to see that I'm not the only one who has trouble understanding some of these callers....

Now, just to be fair to our hard-working(?) friends over at Google, here's an example of a voicemail transcript from a recruiter who spoke clearly:

And no, I don't know why it spells my name correctly in some transcripts but not others. Perhaps I should edit out that "hard-working(?)" jab until after they've fixed it....

#7 - "Okay, now we'd like you to write some code. Here's some blank printer paper and a #2 pencil."

We tend to save the actual code for the computer; you know, that electric box you've seen on most office desks since the 1980s but for some reason you can't procure for this interview.

Even in the poorest schools today, children are emailing homework to their teachers and taking tests on tablets. So why, then, in what should be the most cutting-edge of industries, are so many interviewers asking software developers to demonstrate their coding skills on a piece of scratch paper?!

In all fairness, this is not solely a recruiter problem. Many of the interviewers who have asked me to do this over the years were fellow software engineers. Maybe they just didn't have the hardware. Ok, fine. That lets the interviewer off the hook. But it also shifts the burden of blame onto the company they're working for.

Remember what I said earlier, about how we're interviewing you as much as you're interviewing us? Well, what do you think it tells us when the company we're interviewing can't scrounge-up any hardware invented in the last 400 years?

Yes, even a typewriter would be preferable to pencil and paper. We humans are creatures of habit. We develop most of our skills through repetition. So when you ask someone who has spent years or decades typing code on a keyboard to write code by hand, it's a little like asking someone to read a newspaper upside-down. It can be done, but it'll make even the most avid reader feel like they're in kindergarten again.

That's just how the human brain works. By making us write code on paper-- something we simply never have to do in the field-- you're taking us out of our element. That might sound like a good thing from an interview standpoint, but it's all about context: You want to challenge them in ways that test their coding ability, not in ways that test their ability to read upside-down. All you're doing is giving yourself a less accurate picture of the talent. Someone who adapts better to writing on paper might do better in the interview, only to demonstrate after you've hired them that they're a much weaker coder than the person you passed over.

At the very least, provide a whiteboard. That would at least be something that developers-- those who have experience working in group settings-- would have some degree of comfort with. Of course, you should still only ask for pseudo-code at most, as that's what most developers will write on whiteboards when brainstorming. We tend to save the actual code for the computer; you know, that electric box you've seen on most office desks since the 1980s but for some reason you can't procure for this interview.

If you're recruiting for a company-- especially a tech company-- you cannot stress with them enough how important it is for them to find something for the candidate to type on if they want to do code questions in-person. Tell them you don't care how small they are or how little money they have. They can set aside a laptop or a workstation or a freaking typewriter so that the candidate has something to work with.

Remember: If you ask a tech candidate to write code on paper, the message you're sending isn't, "We're a cool start-up." The message you're sending is, "We're cheap and we don't know what we're doing."

#6 - Spend 30 minutes giving a detailed history of the company, then say you've run out of time.

We have a limited period of time for the call and I'd like to accomplish at least something that will move the process forward.

This is most common in initial phone interviews with recruiters. They're so eager to tell me everything about this awesome company they work for and its rich history. This isn't a bad thing, mind you. But it becomes a problem when the recruiter gets so carried-away telling me how great the company is that they don't leave me any time to tell them how great I am.

You should also keep in mind that most developers-- if they're anything like me, at least-- have already had or are about to have the same conversation with about a dozen other recruiters from similarly awesome companies. Introductions are good, but there's a fine line between giving me a helpful overview of the company and TMI. Chances are, I'm not going to remember most of the anecdotes or I won't remember which anecdotes came from which recruiter, as it's generally not something I'll take detailed notes on at this stage of the process.

I suppose this comes down to a question of time management. We have a limited period of time for the call and I'd like to accomplish at least something that will move the process forward. Dedicating an entire call to telling me how No One's Around Consultants was founded by a man named John who was never around because he adopted twelve kids and the company's offices used to be located in a smaller office building in the mid-90s and they once had a softball team but don't anymore and..... I'm sorry, I forgot where I was going with that sentence. Looks like our time is up, anyway. Any questions before I let you go?

In the most extreme example of this I ever encountered, the recruiter literally spent the entire call talking about the company and its history, most of it relating to their fascinating struggle to find a neighborhood with more convenient parking. I barely got two words in the entire call. He was one of those non-stop talkers who doesn't pause between sentences, except with the occasional, "and, uhhhhmmm", to stall for time while collecting his thoughts.

After about a half hour and me falling half-asleep, he interrupted himself and said, "Well, it was great talking to you, but it looks like we ran out of time." I managed to squeeze in a "bye" at the end before he hung-up.

Now here's the funny part-- and this perpexes me to this day: He emailed me about 3 minutes after the call to say, "Based on our phone conversation today, I don't think your skillset will be a good fit for this company." I actually laughed aloud when I read that, since the most I said during the entire call was "hello" and "bye". The rest was just him talking about the history of the company. It wasn't one of my top choices, anyway, but it was still probably the most confusing interview experience I've ever had.

The only explanation I can think of is that I fell asleep while he was droning on without realizing it, then talked in my sleep about how I'm really a breakfast chef pretending to be a software engineer so I can go into outer space. Hey, it's as good a guess as any! People have told me that, when I talk in my sleep, it's always about what I want to fix for breakfast and/or going into outer space. Maybe he just didn't like my recipe for Buttermilky Way Pancakes.

#5 - "As you know, our site is an adult-oriented webcam service. How often do you watch internet porn?"

Yes, this has actually happened to me. Twice. I didn't do any better answering it the second time than I did the first time.

There are a lot of web-based adult entertainment companies out there. Most of them don't bother to mention that fact in their job ads. I really don't care, so long as what they're doing is ethical and legal. I don't seek-out these types of companies but I don't avoid them, either. I'm a professional. My job is to make whatever it is you're doing work.

So why, then, is this #5 on my list? Because many hiring managers and recruiters are in the habit of asking this question. Whether it be a sporting goods company recruiter asking how often I go mountain climbing or an adult entertainment company asking who my favorite porn star is, the question is irrelevant and tells you nothing about the kind of engineer I am. It also pries needlessly into my personal life.

If you want to evaluate whether someone would be a good fit for your industry, present them with a problem that you feel is unique to your industry and ask how they'd solve it. Feel free to let them talk through it with you.

I appreciate that it can be beneficial-- even, at times, essential-- to have an engineer who understands your industry. But they can have such an understanding of it even if it's not a personal passion of theirs. Maybe they worked in that industry previously, for example. In other cases, it might be worth getting the best engineer even if it means you have to train them in the unique ways of your particular business.

For example, I have no personal interest in property management. However, I would be more than qualified to build software for the owner of an apartment complex because I have gained that familiarity from past projects.

If you want to evaluate whether someone would be a good fit for your industry, present them with a problem that you feel is unique to your industry and ask how they'd solve it. Feel free to let them talk through it with you. That will give you a much better idea as to their ability to deal with your specific needs without asking intrusive and pointless questions about the candidate's personal activities outside of work.

#4 - Make the candidate spend 6 hours interviewing with virtually every single member of the engineering department.

It's a colossal waste of time; both the company's and the candidates'. It also places an undue burden on candidates who are still employed and can't afford to take a sick day every time they have an interview.

This isn't an exaggeration. I wish it were. It'd be nice to have those 12 hours of my life back. Well, actually, it ended-up being closer to 10, but I'll get to that.

There has been a small but growing trend in recent years toward expanding the "tag team interview" concept to make it an all-day event. An all-day event where you're sitting in a small room having to essentially repeat the same interview with about a dozen or so different people, most of whom are clearly much more comfortable writing code than conducting a job interview.

Let me tell you about the first time I encountered this. I took a sick day from work so I could attend the interview, since I was told it would be a 9 - 4 affair with an hour for lunch. I got there, bright and early, and met the hiring manager. She escorted me to a room with a table and chairs. I sat down and waited for the first of their engineers to come and interview me.

I honestly can't even remember most of that day. Most of it was small-talk. They'd start by going over my resume, asking questions about various things they highlighted on their printed copy. One asked me if I like XKCD (see the comic near the top of this article). Another saw my motorcycle helmet and wanted to know everything about my scooter. Three separate interviewers challenged me with a variation of the FizzBuzz test. Some asked me questions that had more to do with their jobs/skillsets than with mine and the position for which I was applying.

Lunch was great. They didn't provide anything so I hopped on my scooter and went to Costco for the free samples. I really just wanted an excuse to move around a bit.

By around 1 PM, the sun was heating-up the closed room I was in like a sauna. The table was extremely reflective, so I had to choose between sitting in the sunlight near the window and sitting by the door, facing the window, unable to open my eyes more than a squint without being blinded. That made the next 3 hours particularly fun.

At the end, the hiring manager came into the room and talked to me for another hour or so-- an extra hour I was not planning on. After all that, she made me an offer but said they didn't have the budget for the figure I had given to the recruiter. I was tempted to take the offer, anyway, just because I didn't want that 7 hours and sick day to be for nothing. But in the end, I just couldn't talk myself into it.

So, how does knowing this help you, exactly? After all, even though I didn't like it, I got through it and was even more inclined to accept the job because of it. Well, to answer your question, let me tell you about the second time I encountered this.

It essentially started out the same as the first time with the other company. This time, however, they at least provided me with a lunch, though it meant I had to eat while interviewing. About 3 hours into it, I realized I was only halfway-- or less-- done. I then remembered my previous experience and not only what a complete waste of time it was, but how the second half seems to go at about a fraction of the pace as the first. I then thought to myself, "Even if I accept this job, do I really want to put someone else through this every time a new candidate is considered? And do I really want to work on a team that's forced to sacrifice so many combined coding hours to this ritual?"

So, basically, I talked myself out of it. After I wrapped-up with the engineer I was with, I asked him to bring the hiring manager in. I told him I was very sorry but something came up and we wouldn't be able to continue the interivew. And then I left. I now have a policy that I will never take part in an "all-day" interview like that again. 5 hours? Maybe, if I really like the company. But that would be the exception. It's a colossal waste of time; both the company's and the candidates'. It also places an undue burden on candidates who are still employed and can't afford to take a sick day every time they have an interview.

It's worth noting that not everyone agrees with me on this point, though I feel very strongly about it. I should also mention that, in all fairness, I will still submit to this type of interview if I like the company and am really gunning for the job. But there's nothing to be gained by throwing up potential barriers like this. If you want to encourage the top talent to work for your company, you first have to encourage them to go through the interview process with you. That'll be a lot easier if you're not discouraging them with marathon interviews that don't reveal any more than can be gleaned from an hour-long interview that's conducted properly.

Perhaps my biggest complaint about this type of interivew, aside from the time and sheer boredom, is the fact that many-- if not most-- of the engineers interviewing you are from unrelated projects with completely different skillsets. I saved that one for last because it leads into our next interview no-no....

#3 - Ask niche-specific technical questions that are neither part of the job description nor the candidate's skillset.

I spent nearly an hour feeling like a complete idiot because I was trying to solve a complex problem in a language for which I didn't even know the basic syntax.

"Design for me a dynamic image conversion API in Ruby. Non-JPG images should be converted to JPG then sent to another API for word detection, which I'll have you do next. Sketch out all the classes and interfaces that would be involved, then I'll present you with some variations and questions regarding optimizing performance under different circumstances."

That was what one of them asked me during the first marathon interview I talked about in the previous point. At the time, I had never even looked at Ruby before, much less had any experience working in it, and my resume accurately reflected that. The position I was applying for was a senior PHP developer role, focused primarily around SQL integration. In other words, that nightmare of a question he asked me could not have been less relevant either to me or to the position for which I was applying.

Unfortunately, that was really the only question he could think of, so I did my best to walk through it with him. I later got him to tell me that this was just something he'd been working on recently so he used it. Turns out he was less-than enthusiastic about this new marathon interview process, as well.

At any rate, I spent nearly an hour feeling like a complete idiot because I was trying to solve a complex problem in a language for which I didn't even know the basic syntax. He was clearly unimpressed with my performance and didn't go out of his way to hide that. That, perhaps even more than the time wasted, was what frustrated me the most about this exercize.

When we take the time to research a job opening and apply for it, we have a certain expectation that we will be judged based on our merits as they pertain to the position. If you apply to be an HR manager but get negative marks after being interviewed for an hour by a gourmet chef on your knowledge of creole food, would that not be frustrating to you?

The same applies to us. For all the things I know, there's a lot more out there that I don't know. That's why I make sure to apply for positions that involve what I do know. The technical interview questions should more or less reflect that. If you want an engineer to interview me with tech questions, then you should make sure that person's skillset matches-- or at least overlaps with-- my own. Otherwise, both of our respective time is being wasted and you will not only get a less accurate picture of my abilities, but you'll also find me to be that much less amenable to accepting any offer you decide to extend because I'll know that you make developers waste their time interviewing candidates outside their skillset.

Fortunately, this problem can easily be avoided by requiring that the hiring manager approve all technical questions prior to the interview. This also has the benefit of screening-out duplicate questions. If you don't know enough about code to do that, delegate the task to the person who will be supervising the candidate if they get the job.

#2 - "If a plane crashes on the border between Russia and Ukraine, where do they bury the survivors?"

What really amused me about this was how impressed they said they were with my technical expertise after the interview when they made me an offer. I could actually have been a chef with a fake resume and they'd have never known it. I did have the opportunity to tell them many amusing stories about my cat, though.

Addendum (07.26.2014): This article was written and published at the end of May, 2014, more than a month before the crash of Malaysia Airlines flight MH17. At the time, I just modified an existing plane crash riddle to reflect what were then growing tensions along the Ukranian-Russian border. It's just a horrible, horrible coincidence that this innocent joke would become tragically prophetic. Please take it in that context, dear reader, and know that I grieve for the victims of this outrageous attack and their families along with the rest of the civilized world. Obviously, I would not have used this riddle-- certainly not with Russia and Ukraine as the bordering countries, at least-- had I known that there was any serious chance that something like this would actually happen so soon after the article was published. I will not alter it after the fact as a matter of personal ethics, so just please understand that this was not a joke made at the expense of the victims of MH17. Thank you for your understanding.



I enjoy riddles. I mean, who doesn't? And after a long and dry technical interview, there's nothing wrong with ending on a fun note.

So why, then, am I listing these nifty little brain teasers in this obituary to counter-productive interview blunders? As with most everything in life, it all comes down to balance. It's really not even so much about riddles, specifically.

Here's an example that should clarify what I'm talking about: Not too long ago, I had an in-person tag team interview. It wasn't excessively long, mind you; about 90 minutes or so. Everybody was friendly and professional. Nobody was late. They were all positive and gave me plenty of time to speak. Nobody asked what my favorite porn site is.

So what was the problem, then? Not one of them bothered to ask me a single technical question during the entire process. From start to finish, it was all just friendly chit-chat. Some were eager to hear stories about my scooter (I really need to stop bringing that helmet in with me). One was curious about my favorite places to eat in Seattle. Nearly all of them included some meaningless brain teasers. Three of them separately asked me the one about a rooster laying an egg on a roof.

The problem was a lack of communication between the various interviewers and, more broadly, a lack of planning. Everybody assumed that someone else would ask some coding questions, so nobody did. The senior developer who interviewed me even made a point of proudly telling me that she uses these interviews to "get to know" the candidate and see if they'd be a good culture fit, leaving all the technical screening to everyone else. Apparently, everyone else had the same idea.

What really amused me about this was how impressed they said they were with my technical expertise after the interview when they made me an offer. I could actually have been a chef with a fake resume and they'd have never known it. I did have the opportunity to tell them many amusing stories about my cat, though.

This can easily be avoided by having your interviewers communicate and develop a game plan ahead of time. It also doesn't hurt to make sure you're not asking the same question-- or posing the same riddle-- multiple times. Riddles are perfectly fine in moderation. Just be sure you don't forget to ask some questions that are actually relevant to the job and the candidate's skillset.

And now, for absolutely no reason, I am going to give you a description and you'll have to figure out what it is I'm describing: It is bigger than the universe and smaller than the smallest subatomic particle. Wealthy people are in need of it while poor people have it in abundance. And if you eat it, you will eventually die a slow and agonizing death.

What is it? Here's a hint in case you get stuck.

Oh, and you wouldn't bury the survivors because they're still alive.

#1 - Judge the candidate based on whether or not they're a telepath.

If I could read people's minds, I wouldn't have to go to job interviews because I'd already be filthy rich.

"I would like you to write a PHP function that determines whether the input string is a palindrome," said the interviewer as she handed me a pencil and paper.

"Does case matter?" I asked.

"Up to you," she replied.

That sounds easy enough. In case you don't know, a palindrome is a word or string that's spelled the same way forwards and backwards. "Noon" and "radar" are common examples.

Taking the pencil in hand, I quickly jotted down the answer:

"What is this?" she asked. "Why aren't you defining strrev?"

Evidently, she did not realize that this was among the core functions built into PHP. When I explained this to her, she seemed visibly annoyed and flustered.

"Oh, well, do it without that function," she said after a few seconds of awkward silence. So I obliged:

"Are you sure this is the only way?" she asked after I was finished.

"It's not the only way," I answered. "There are any number of different ways this can be done. Did you have something else in mind?"

"Yes," she replied. "Do it another way, please."

This went on for what seemed like forever. About 30 minutes into it, the lead interviewer told us our time was up. "Ok," she said. "This is how I would've done it."

They want so badly to find someone who shares their vision-- someone with whom they can "click"-- that they start evaluating candidates as potential soul mates instead of potential employees. And they don't even realize they're doing it.

What she wrote down was basically the same as my second attempt, except that she used a while loop instead of a for loop and used strcmp() instead of ===. I pointed out that using the equals signs yields slightly faster performance than strcmp(). She just shook her head disapprovingly without saying a word. And no, there is no benefit to using while instead of for in this case. One benchmark claims that while can be a few microseconds faster than for in certain circumstances, but not enough, in my opinion, to warrant the bulkier code, particularly given the fact that my hand was already starting to cramp as it was.

It wasn't until later on that I realized she wasn't testing me on my coding ability. She was testing me on whether or not we're "on the same page". You know, as in knowing what she wanted and how she wanted it done without having to be told. She wanted to know if I could read her mind.

If I could read people's minds, I wouldn't have to go to job interviews because I'd already be filthy rich. Unfortunately, I've found this to be one of the most common problems among interviewers. They want so badly to find someone who shares their vision-- someone with whom they can "click"-- that they start evaluating candidates as potential soul mates instead of potential employees. And they don't even realize they're doing it.

It is important to find someone with whom you can work effectively. However, you have to ask yourself what is more important: Finding someone who can do the job effectively or finding someone who can predict your thoughts. You don't want to lose out on some of the best talent out there based on such frivolous criteria. You're only hurting yourself and your company when you do that.

The next time you ask a coding question, remember that the candidate may surprise you with an answer you hadn't considered. Sometimes, it may even be better than what you were looking for. Evaluate the code based not on how closely it matches your mental image, but on how well it stands on its own. You can always train people in your preferred style of doing things after they're hired.

Final Thoughts

But by them having him buy me lunch after the interview, it generated a bond and made me feel valued. I took the job.

There is nothing more imporant in hiring the right candidate than conducting an effective interview. Not only does it help you narrow down your choices, but it's also an opportunity to show the candidate why they want to work for you and not someone else.

After one interview I had, their IT manager called me and invited me to lunch. I was still fairly new to the city and eager to discover the best places to eat. Besides, I've never been one to turn down a free meal. He wasn't one of the people evaluating me, either. But by them having him buy me lunch after the interview, it generated a bond and made me feel valued. I took the job. It was a small company with not the best long-term outlook or benefits, but sometimes it's the little things like that which make the difference. It caused me to like them on a personal level, and since we're all human beings at the end of the day, that counts.

Even if you don't go above and beyond, there are still very easy steps you can take to attract the top talent. You can be the recruiter that everybody comes to because they know you can reel in the big fish. By avoiding the 10 common mistakes I outlined above, you will be giving yourself a powerful edge against the competition.