Hiring for a technology you know nothing about

Kate Yoak
LeanStreet
Published in
5 min readJan 31, 2019

I have been running technical interviews since shortly after I was legally allowed to drink. The basic idea is straight-forward. Introductions. A few jokes to put the candidate at ease. I talk about culture, emphasizing the creative focused work — making the technical interview an obvious first step to ensure such a great workplace continues to exist. This gives me the right to spend the next hour (if they are any good) diving deep into technology.

Now we can get to the whiteboard and solve some problems. I watch them think. I ask questions. I nit-pick. Do they get defensive? Are they able to perform under some amount of pressure? What happens when they get completely stuck? Are they able to receive help and recover?

The interview continues until I have either answered the above questions or aborted on clear incompetence. By the time I have ended the interview, I know more than the person’s technical ability and the knowledge of the topic — I know what it would be like to work with this person, manage him, and introduce him into the team.

All of this is predicated on knowing more about the subject than the minimum qualifications for the candidate. Yet, as a technical manager, CEO, or founder, I run into an occasional obscure tech I’ve never heard of, am bad at, or even job functions I have nothing more than a few google searches worth of knowledge about. I have developed a process for a reliable interview approach for those times when I have no clue. After practicing it for a while, I found that this is my favorite interview type.

Interview Outline

  1. Ask the candidate to explain what the Thing is all about.
    The best part is, by the time you talk to the third guy you start making sense of it! More importantly, if you are managing a specialist in an area where you are blind, you might as well convince yourself that you’ll be able to ask questions and get clear answers.
  2. Ask clarifying questions until you can connect the information to something you already know — or a metaphor that seems to fit. Explain the connection, “Ah! So React.js sort of invents its own HTML tags that are defined elsewhere?” or “Is this like a browser plugin, only for Outlook?” Now you can have a discussion about how you are right or wrong. You should expect the candidate is not going to find your analogy spot-on, but correct some details. The conversation may get so interesting, you’ll be looking to share a cigar with your future teammate.
  3. Ask for challenges and best practices and get to examples of where developers (or whatever expert type you are talking to) would typically fail. Now you are ready for the whiteboard. “Can you show me a sample code that implements the bad practice you just mentioned, and how you would correct it?” I have found that this question separates those who repeat things they have heard without truly understanding or experiencing them. Expect your weaker candidates to freeze up and stutter. Don’t laugh. Just say, “OK, maybe it’s a bad example. See if you can come up with a best practice that can be isolated more easily.” If they are coming up blank, it’s probably time to wrap up.
  4. Ask the developer to pick three very simple feature that can be implemented within 5 minutes on a whiteboard. Pick one at random. Imagine you are learning to do the task. Ask questions to clarify the syntax. Assume you will be quizzed at the end. Feel free to be a total nerd about it. Your candidate will be more relaxed if they watch you engage. If you are interviewing a coder and you’ve never seen a line of code in your life… you are at a disadvantage — but don’t be shy — ask him to explain the whole thing to you, a-z. Your next interview will go that much better.
  5. Now pick a real feature you need to have built. Tell your guy — or gal — to imagine it’s their first day on the job — and this is the task. Let’s figure out how we are going to build it! Work with them as hard as you would on that day. Think through edge cases. Ask them to consider details that are relevant to your actual application. If you have existing infrastructure (such as AWS, Continuous Integration environment, etc) ask questions around how deployment would work, what they need to know in order to get the job done. Then trust your gut. Do you believe, you and this new partner will be able to build the thing? Can you think alongside each other and trade knowledge? Will he take into account what you have missed? Will you be helpful to her mode of thinking? If you feel lost today, move along. Find the person you can depend on.

Wrapping up

If you have no idea what you are talking about, you will need a pretty senior person that does. If you had to abort the session, don’t end the relationship. First of all, you might find your senior guru — and a couple of months later, you might need to add to the team. Standards are now lower. The new team member no longer needs to advise you — he just needs to work with your guru. You might come up empty and decide to have another round with your top 2–3 choices, and see if you can do a test project to train your intuition and see what you might have missed the first time around.

Tell them how much you enjoyed. Recap some of the things you found interesting about the tech, and the stuff you talked about. Tell them how much you appreciate it — and add them to your contacts, to say thanks a few months later, after the project launched, and though they didn’t get to be part of it — you enjoyed getting to know them — and perhaps now is a great time to expand the team. (Of course, don’t do any of that if you truly disliked the candidate!)

If you liked them, tell them you would love the opportunity to work with them! That there are a couple more candidates in the queue, but you can’t imagine having a better connection.

If you’ve been through the queue already, and you want the rest of the team to meet them, tell them they are your choice, and you are excited to have them on board — though you have to allow your team to raise flags.

Why state these so strongly? Because interviewing is hard. You are judging the persons' professional worth. They have made themselves vulnerable to you and your judgment. Appreciate it. They will be eager to reciprocate, accept an offer with less haggling — and be a loyal employee going forward.

Plus, although both statements are strong, they are true. If you made a connection, can you imagine making a better one with two random strangers with resumes still outstanding? If you liked the guy, why are you having him talk to your team, except on the off chance they will raise flags?

Treat your candidates like your future partners, and they will surprise you by living up to your treatment… Good luck!

--

--