Technical Interviewing – Part 1: Pitfalls

Technical Interviews

Anyone who’s conducted an interview can tell you that interviewing any candidate is difficult. The process can become even more difficult when conducting technical interviews. Technical interview difficulty is compounded by having the wrong interviewer to find your candidate or by having weak or unclear expectations about the requirements for the candidate. Perhaps you are a non-technical person interviewing someone for a technical position, or a technically skilled person conducting an interview for a position with a different knowledge domain (like a chemist trying to hire a data analyst). Maybe you have the technical skills for your domain, but you lack the valuable skill set required of a good interviewer. None of these situations are easy to overcome, but hopefully I can share some of my experiences to help improve the process of matching qualified candidates to desirable positions. First, a word of caution to job seekers that might be reading this series: This is how hiring should be. You should not expect potential employers to follow this process, but if they do, you’ll know that you’ve found a quality company. Also, this is generally written from the point of view of hiring a programmer, but the concepts can be abstracted and applied to particular technical domains.

The Purpose

Obviously the aim of interviews are to evaluate the candidate’s ability to carry out a job, but interviews also allow the candidate to understand the company from a perspective they are unable to get outside of the company. Initial interviews should handle the personality fit of a candidate, establish a mutual excitement (or at least interest) for both interviewer and candidate, and make sure that the candidate’s vision for the future and the goals and mission of the company are in alignment. Often a technical interview is one of the first face-to-face interviews conducted. From the interviewer’s perspective the technical interview should yield enough knowledge for the interviewer to say either “Yes, this person meets the technical requirements of the position”, or “No, this person isn’t able to do the required job”. More importantly, the interviewer should have many qualitative observations of candidates to allow them to find the best fit for the company from a field of candidates.

The Pitfalls

Non-Technical Interviewer

The non-technical person, like the owner of a small business hiring their first web developer, might merely rely on a list of questions found on the internet to throw at a candidate. The risk here is that the candidate might have searched the internet and found the same list of questions during interview prep. This only yields the information that the candidate does interview prep work, has strong Google-Fu, and probably doesn’t give the narrative of the candidate the interviewer is seeking. I would always encourage a non-technical person to have a “wing-man” during a technical interview that has at least a basic level of understanding of the technical issues being discussed to make sure that a candidate isn’t just blowing smoke and taking advantage of a non-technical interviewer.

Cross-Domain Technician

Quite often an organization will need to hire someone with similar skills to other technical people on their team, but dedicated to a different domain of applied knowledge. A great example is a game development company that needs to hire a web developer. There are many aspects of programming that are common to all developers, but there’s a huge difference in the experiences of a web developer and a game developer. A game programmer interviewing a web developer might falsely expect that a certain level of knowledge in a particular technique is required in a web development position and discount a person that is highly qualified in their domain due to a lack of knowledge in the interviewer’s own domain.

Subject Matter Expert

The opposite end of the spectrum from the non-technical interviewer is the small software engineering team that’s expanding to add another developer. They use their exceptionally knowledgeable team member to conduct the interview. Without interviewing skills these interviews generally end up making the candidate feel like they’re subjected to a haughty comparison or an inquisition as the inexperienced interviewer throws obscure technical questions at the candidate. These only serve to find people who revel in the obscure, not necessarily find quality candidates.


Here are some common traps that interviewers fall into when it comes to technical interviewing.

Quiz-Style Questions

Asking quiz-style questions tests the candidate’s ability to retain information and parrot it back – not exactly what defines a successful candidate. Examples include things like “Describe the Model-View-Controller pattern,” or “When is the OnAwake event fired?”. These questions are helpful, but not in the way that most people think. The place for these questions is in a questionnaire. A good interview tactic is to send out a “written test” before a technical interview. These quiz style questions can be on that test and don’t necessarily serve to exclude a candidate, but their responses should become points of discussion in the technical interview. The outcome of discussion of responses to quiz-style questions is much more valuable than a correct answer to a question.

Obscure Knowledge Questions

These types of questions are useful to explore the extent of a candidate’s knowledge, but should never be used to exclude a candidate. The thing you’re testing with obscure knowledge questions is generally experience, and even worse, specialized experience. It’s much more valuable to have someone who is an expert problem solver than someone who has solved a particular problem. These types of questions will favor the person that has solved the problem and not the expert problem solver.

A Bad Example

I was recently interviewed for a full-time C# developer position with a company that creates complex solutions that I imagine requires a good measure of technical competence to create. My interview was with two members of the development team. They fell into the first trap – asking nothing but quiz-style questions. The technical part of my interview involved questions like:

  • “Describe some programming patterns.”
  • “Define overriding and overloading.”
  • “What is an abstract class?”

From my responses to this evaluation I was pronounced to be “very knowledgeable” about C#. Now, there’s no problem with that final evaluation – I am very knowledgeable about C# – but that statement is not supported by the results of these questions. Sure, I gave them more than they actually asked for. I defined 4 programming patterns and gave examples of their implementation in recent projects (and I didn’t even pull out the Singleton pattern!). I not only defined overriding and overloading, but gave the conditions in which I have and would use each. I also illustrated when I used abstract classes in C++ and when and why I might use interfaces in C# instead of abstract classes. But for most candidates who don’t understand that in interviews you never merely give the answer to the question but also provide examples to show competency and experience, defining these terms would have given absolutely no insight into the candidate’s technical ability at all, just their memorization or searching ability.

A Better Example

Lets play pretend. Lets say that they wanted to find someone to add to their team for the long-term that could develop internally used web applications using C#. What should they have asked in the technical interview? The questions I was asked in the above example are perfectly fine light technical questions and are a great lead in to real technical discussions or as a pre-technical screening discussion. Here’s what I would have rather seen in this situation.

  • What components make up a great programming interface? Why?
  • Use the whiteboard to show a diagram for a particular system. Why did you choose this architecture/pattern?
  • Describe a system that solves a particular problem. Now what would change in your design with a change in requirements?
  • Solve a problem outside of your general domain of knowledge

These questions get all the answers to the previous questions and test the quality of any developer for any language. These questions don’t ask anything that’s particular to a knowledge domain within programming. These questions are all open questions that allow technical people to explain themselves to the interviewer and expose the thought processes of the technical candidate. The best part of these questions, especially when interviewers specify that the interviewee should think out loud and ask questions of the interviewer (“Use us as if we are Google”), is that they prompt two-way communication between the interviewer and the candidate allowing the candidate can ask questions of the interviewers and the interviewers can give feedback to the interviewee. These types of interviews allow candidates to relax a bit more (usually), expose their thoughts (a critical piece of information for an interviewer), and give them the opportunity to “wow” the interviewer by demonstrating unexpected solutions or creative thinking.


The candidate that makes it through the bad example has demonstrated:

  • The ability to define keywords

The candidate that makes it through the better example has demonstrated:

  • Understanding of general technical concepts (in this case programming concepts).
  • Their level of comfort presenting technical information.
  • Their level of technical ability.
  • The types of questions they ask to gain information.
  • Their understanding of how technical systems build off each other and interconnect.
  • How they approach problems for which they most likely have no existing knowledge.
  • Shows how they handle constructive discussion of their work.

It’s pretty obvious which results in a better source of information. You have much more information about a candidate that undergoes the second type of questions. This data is useful for the types of interviewer situations described at the beginning of this article. The non-technical interviewer gets to find a candidate that’s able to speak on the interviewer’s terms about technical concepts. The cross-domain interviewer gets to leverage their own technical knowledge to find commonality to validate candidate traits. The subject matter expert interviewer gets to ask follow-up questions to satisfy their level of curiosity and help prevent interview from degrading into an interrogation.


Part 1 has been an introduction to the challenges of interviewing technical candidates. The next section of this series discusses the first step fixing these problems. The solution starts before the interviewing even begins, with a great job description. Keep an eye out for Part 2: Requirements.


EntreLeadership: 20 Years of Practical Business Wisdom from the Trenches

interview Questions

Interview Your Interviewer

interview Questions

What’s an Interview?

Well now that’s obvious isn’t it? It’s the chance you get to convince someone you’re the person they should really hire, right? Well sure, that’s part of it, but the real purpose of an interview isn’t for you to say the right things and convince someone you should work for them, it’s a chance to get a view into a company most people don’t get, and to determine if you really want to lend your skills and abilities to these folks for a while.

I Have One! Time to Worry!

Quite often someone already knows you have the skills you need for the job because they’ve already looked at your resume and it’s passed the smell test. That’s how you got the interview. Now they need to know that you didn’t lie on your resume and that you’ll fit in with their team. That’s easy, just don’t lie on your resume, and be yourself. If you have an incompatible personality, you don’t want to force it because you’ll be miserable at work if you are hired, and if you lied on your resume, shame on you, you deserve to squirm. So don’t worry, be yourself, let “you” flow during the interview, and if they don’t like that, check yourself to make sure you aren’t a jerk, and then move on to a company that you’ll actually fit into.

Do I Want to Work Here?

That’s the right question to ask. Interviews are two way streets. You are interviewing the interviewer just as much as the interviewer is interviewing you. Ask a lot of questions. You need to know these answers. What do you wish you had known about your other companies before you went to work there? Don’t you wish you had asked someone about that before you started? Well, do it. As long as you aren’t asking about benefits, pay, and perks, it’s just fine.

What Shouldn’t I Ask?

Don’t ask about benefits, bonuses, paid time off, nap time, social media policies, flex time, and other wonderful things until there’s an offer on the table. These things are important, but not right now. First lets see if you actually want the job, and then we’ll see about whether they have the incentives to make the job lucrative.
Don’t ask what the company does. You should know this by the time you’ve earned an interview. Google the crud out of them. Used LinkedIn to search the company’s profile. Like the company on Facebook. Read the company’s press releases and the industry’s news about the company.
Don’t ask about what’s already in the job description. Certainly ask for clarification of any vague or non-specific elements, but if you are interviewing for a position as a PHP developer, don’t ask what the primary language is (but do ask if there are any secondary/scripting languages or JavaScript components they use).

So What Should I Ask?

Here are a few recommendations for questions to ask hiring folks. These will help you get a picture of what it’s like to work there and then give you some really good data to compare to other companies you’ve worked for or other companies you’re interviewing for. Most of these questions are for general interviews, not technical interviews. Just a quick note, these questions are here to help you learn some great information from an interviewer, not to manipulate them. Use this power for good!


Culture is a catch-all word that encompasses the vibe and flow of the employees of the business. It’s intangible and therefore cannot be listed adequately in a job posting. You need to pump employees for their experience to learn about this.

What’s the culture like?

This seems like a buzzword question, but it can give you some great insight. Listen to the response you get. It’s general enough that it will draw out someone’s thoughts on what life is like inside the company. Watch for hesitation and stumbling. You might get the feeling they’re trying to sell you on the company instead of giving you a look into the soul of an organization.

What brought you to this company?

This will show you what someone thought was a great selling point for the company and it might be a good one for you too.

What makes you stay at this company?

What makes the person stay here? You know what brought them in, but what keeps them loving their job?

What is your favorite part of the week?

If they say 5PM on Friday, you’re in for a rough experience with this company. Otherwise they might bring out something valuable that’s not generally known about the company.


You really need to know what your boss situation is going to be like. Some people can’t stand certain management styles, and it would be terrible to start a nice shiny new job and hate working there. Find out all you can about your new boss before they’re your boss!

Who will my manager be?

The person might give you a name. If they day, it’s time to use LinkedIn/Facebook to do a bit of stalking. Find out who the person is, what they post about and what other people say about them. Look for recommendations on LinkedIn.

What do the people that work for that person say about him?

You may not get an honest response, but if you do, listen well. This is much more effective if you are interviewing with team members. You can find out if your new boss will be a micro-manager, an absentee boss, or someone that really deserves a #1 Boss mug.

What is their management style?

Hope for an honest answer. Nobody is going to say, “Yeah, he’s a micro-manager and suffocates his employees”. Well, at least I don’t think they will. If you like being on cruise control and having daily meetings, you might enjoy having a micro-manager for a boss though.


It’s important to know what sort of things you’ll be doing and spending your time on. If you really can’t handle three two hour meetings a week, you don’t want to work at a company that has those sorts of things as a mainstay of its workflow.

What is a typical week like?

This may be a question for a hiring manager instead of an HR person, but a good question to get an answer to. Good answers will tell you the approximate percentage of time you’ll spend on your “real” work and how much time will be meetings, administrative tasks, etc.

How are new tasks obtained?

If your job will be task or project oriented and you aren’t the person making decisions on which projects will be worked on, it’s probably a good idea to find out how your next task is obtained. If you know the company has a formalized workflow, like Agile software development, don’t ask this question. They probably expect you to know, or be able to Google, how their processes work.

What tools do you use?

Sometimes a job posting is vague on the tools the company uses. If it is, ask them what they use in particular. In the software world, quite often we know what our compiler will be from the job description or languages requested, but other things like Continuous Integration tools, bug tracking, story management, code repositories, and all these other things are good to know.


If you have the luxury of being onsite for the interview, take the time to look around you and see who the people that will be your coworkers are. Try as hard as you can to feel like you’re a part of the team before you actually are. Project yourself into what you see or know about the people and see if you like what you see.

Who would my coworkers be?

Write these names down and maybe do a bit of Facebook/LinkedIn stalking. See what they think of their jobs and what they say about their industry. A great indicator of someone’s knowledge and productivity is if they post about their industry online somewhere. Some of my most knowledgeable colleagues have run IIS blogs and post about their experiences on social media.

What does the team do to unwind?

This is a great question to see how cohesive a team is if you care about that sort of thing.

Does the team usually go out for lunch?

If you don’t like to do this, it’s good to know up front. If you do, then it’s good to know you’ll fit in easily. One of the coolest jobs I had involved most of my coworkers playing Magic: The Gathering every day at lunch. I didn’t participate much, but it was really awesome, and some companies do that sort of thing. Also, asking about where the team goes is a great bonus follow up question.

Where is the team located?

If you’re the kind of person that would rather catch a glimpse of sunlight rather than languish in a dank dungeon reminiscent of “The IT Crowd”, you need to ask this question. A lot of companies are proud of their office setup, or they have a cubicle farm. Also, check to see how the team is organized. The team you work with might be spread around the office to help more people or you might be corralled together to facilitate communication. Another insight into the company.


Make sure to ask some questions which put you in the role you’re interviewing for and help the interviewers visualize you in their team, working. This helps them evaluate you and helps you evaluate them.

What traits does the person that takes this position have?

The interviewers probably have a particular skill set their looking for to augment the team. This is where they will say what is most important to them. This is valuable for you. If they want someone to translate between designers and engineers and you just want to be an engineer, this might not be the position you thought it is. Run now before you hate your job!

How will I receive feedback?

This is mostly just to establish that their management is mature enough to be providing you with feedback. You need to feel confident that your job is secure and that what you are doing is correct. Being fired when you had no clue anything was wrong is probably pretty crushing. If you still like the job and they don’t provide feedback, you can still be proactive and seek out feedback. It’s probably a good idea even if they do have a feedback system.


All good things must come to an end, and interviews too. Once you feel that the interviewer is getting bored answering your deluge of questions, fire off the most important ones to you, and then ask a few closing questions. You need these answers.

What is your timeline for making a hiring decision?

You might need to know if you can even consider this position. If they are hiring two months from now and rent is due in two weeks, it might not be the right timing for this company.

What did you hate about my resume?

Strange question right? They might give you some valuable insight on how to fix it for the next company.

What skill or trait made my resume stand out from others?

This will identify a skill that you might want to hit on for other interviews with similar companies.

What’s next?

You need to know when they intend to contact you next, and who to contact if they don’t. They will probably outline the remainder of the interview process. In some industries, like games, the process is lengthy, where you probably have your code test, HR Interview, team interview, and technical interviews at a minimum.

Now what?

The interview is done, and now you have a notebook (you did bring one for taking notes right?) full of information about this company. It’s time to make a decision. What did you think?

Loved it!

If you liked the company and are still interested, be proactive. Contact the hiring managers in a week or whenever they said to, and check in. Write a thank you note. These people just gave up at least a half hour of their day (or a few hours if you ask a ton of questions like I do) to spend some time sharing the heart and soul of their company. That’s worth a thank you email at least.

Hated it!

If the company didn’t live up to your expectation or you found some serious red flags, take some time to check those out. Some companies might have enough information on the internet you can confirm or deny suspicions. Having a contact in the company can be helpful. If you still can’t reconcile the issues you have, thank them for the time and consideration, and move on. This can be hard, especially if you are in need of a job, but sometimes, for your mental health, it’s okay to turn down an offer.


Have any questions or suggestions? Leave a comment and discuss!

Other Helpful Links

Pawn, A Greypine Novel, Chapter 17

Pawn, A Greypine Novel by Steven Beadle


A week or two ago I had the opportunity to read a partial manuscript for what promises to be an interesting book.  The book is Pawn, A Greypine Novel, by Steven Beadle.  This story kicks off a chain of 3 books taking place in the Greypine setting. I [pullquote align=”right” textalign=”left|center|right” width=”40%”]Pawn has been released!  You can get it on Amazon.

Pawn: A Greypine Novel
only had access to the first chapter of the book, but that was enough to pull me into this fantasy world that exudes realism.  The brief introduction to the main characters provides a lush field for story hooks and character development without hampering the flow of the narrative.  The pacing made me feel like I was strolling along with the characters through the windswept fields and watching their interactions from a few steps behind.


The story setting appears similar to the beginning of the Wheel of Time series.  Everything seems very normal and ordinary, but there’s an undercurrent of power and mystery. The main character in this excerpt is intriguing. Like all great first chapters this story hints at everything and reveals very little.  So far the book has provoked some excellent ideas, but confirmed nothing. The author’s descriptions provide enough to give the reader’s imagination a colorful picture of the world without bogging down the action. The glimpses into the minds of the characters are brief and informative. The picture below is a painting done by the author to illustrate the 17th chapter of the book.

Pawn, A Greypine Novel, Chapter 17



The book will be published on Kindle on June 28, 2013.  In the meantime, check out the Author’s new blog here and join me in following him for updates to the series. I’m really exited to get to hear the rest of the story. The first chapter is quite tantalizing.

The Author

Pawn is the first published work of Steven Beadle, my cousin. While I may be biased because of my family relation to him, I honestly would not be promoting this book if I didn’t think it has excellent potential. I’ve grown up reading his short stories and experiencing his storytelling ability first hand. He has a potent ability to take events and experiences from the real world and create compelling and entertaining stories from them.

From the Back Cover

The Moine Empire spans a vast tract of land, zigzagging between two mountain chains and an ocean, but in the distant northern plains things are brewing that could spell trouble. The residents of some of the farming towns are starting to come under the influence of a strange new religious order, and The Covenant has in fact, apparently brought peace and prosperity with it.

But maybe not all is as it appears on the surface. One resident of the northernmost outpost of the empire has questions; those unacceptable doubts will lead her farther afield than she ever thought to go, and grant her some of her most unexpected dreams… for a price.

At the far end of the Heartland she will find that friends, religion, and politics, are a dangerous combination. As rulers are toppled, nobles vie for power, and unseen forces play a deadly game, observers are left to wonder who is the player, and who is the… Pawn