The Pocket Guide To Hiring Geeks

In The Pocket Guide to Hiring Geeks, Bill and George tackle the complex topics involved when hiring technical resources effortlessly, humorously and informatively. This books makes for a very clear and easily understood reading experience that can impact your next round of interviewing in a tremendously positive way. It can help move your department, and company, to the next level — today!

read more

Tip 5: How to Hire Someone Who Has More Technical Knowledge than You

Key Points

  • Let them explain the technology to you.
  • Don't try and fake it.
  • Ask them how difficult it was to acquire/learn this technology.
  • If it was easily done, that might be a good sign the person can learn new things.
  • If it was difficult to do, it might be a sign the person does not yet fully grasp the technology.


Let them explain the technology to you.

  • If they have mastery of a subject, they should be able to describe it, or better yet, teach it. Its OK to ask questions for the candidate to back up and fill in some background before proceeding.
  • Get them up at a white board to draw pictures; they really are often worth thousands of words and you have limited time to interview.
  • As a side benefit, you’ll get to see their presentation style. Can they communicate clearly? Are they pitching to the right level for the audience?

Don't try and fake it.

  • Today's technologies are complex and someone trying to fake it is often easily uncovered.
  • You should be prepared enough to know a little about the person and the technologies they are highlighting on their resume before the interview. This preparation can lead to good questions to use during the interview.

Ask them how difficult it was to acquire/learn this technology.

  • Ask them how they picked up the skills. Were they sent to a training class, or did they find a whisper of a hint of an idea and track it down themselves?
  • Before the discussion is over, relate the technology or skill to their present job. How did learning that skill help the company? How would they measure the ROI of the time spent to learning the technology?

If learning this technology was easily done...

  • ...that might be a good sign the person can learn new things.

If they say learning this technology was difficult to do...

  • might be a sign the person does not yet fully grasp the technology.

Real World Story

As a young manager, I had to hire someone to continue development on the code generation portion of our product. This wasn’t generating source code to be complied later, but generating the machine instructions dynamically in memory; basically a compiler inside of a product that generated code for the more static portions of the product to invoke on the fly.

We had someone who had worked on this section for years, and he had decided to move on and leave the industry entirely. It was a huge hole to fill in the software development department and an enormous hole in the company. If not filled correctly, it would severely impact the ability of the company to deliver product. It was a bad situation and it was made worse by the fact that there was no way I could dial a recruiter and say, “Give me 10 resumes with this skill set.” To further complicate things, I had tangential experience myself with the work, but I hadn’t directly worked on the code and it was always a black box to the rest of the development staff.

So here I was hunting for candidates, in a skill that I had scant knowledge, and trying to screen the applicants. The easy part was that there were maybe five candidates who could even attempt to meet the requirements for the job.

One candidate was very appealing right from the resume, as he had done the type of work we needed in the past and was local. It was just dumb luck that I found someone in the same city, and the stars must have aligned because he worked in the building next door! I did the phone interview one morning, and when I found out he was next door, I offered to meet in the park between the buildings in a few minutes. He agreed, and our first meeting was in that park.

We shook hands, and I knew instantly the guy was twice my age. With his experience, he could have easily snowed me. But I had an ace in the hole in the situation: the leading question. I knew enough about the problem space to phrase the question and keep the conversation going—and I also knew to shut up. I was the hiring manager, and regardless of his experience, he needed me to make a job offer. We discussed the company, and a little about the product and what skills I was looking for and then I set up a leading question and let him talk.

He explained similar work he had done in the past and what the application was as I listened and nodded at the right times, and then the spark happened: he started asking me questions. Not general questions about the 401(k) benefits, but detailed stuff like a common problem, the possible solutions, and which approach did we take. Since my experience developing the product was using the output of the generator, we could start talking about the interface between the selections of code, what the stack looked like, what was the order of parameters, and so forth. I may not have known every intricate detail of the work that he would do, but I knew how to use the output and how to interface with the code he would continue to enhance and create.

The secret here wasn’t that I knew every detail, but working it to the interface points where we both were comfortable. I shut up to let him talk, only asking more leading questions and putting his responses through the B.S. filter in my head as fast as he was talking. The filter never lit up, and I ended up making him an offer (after interviewing a few more candidates).

  • IT Manager, 32