I’ve been through quite a few developer interviews in my career. Some were great, some … not so great. I still remember one in particular, back when I was a young junior developer. I went in to an interview and was absolutely grilled by a couple developers in a conference room. I can still remember to this day walking out of that building feeling so embarrassed. My tail tucked firmly between my legs and a strong disdain for the company and almost my entire profession.

It’s a feeling I still carry around with me to this day. A feeling that helps me empathize with developers I work with as well as developers I interview. And I don’t ever want to make anyone feel the way that I felt that day.

There are a lot of different techniques when it comes to hiring developers nowadays. On one side of the spectrum there are the “we don’t believe in asking detailed technical questions, doing coding puzzles, coding tests, or take home tests.” And on the other end you have, “we expect you to be able to talk about Big O notation, white board sorting algorithms, answer all the esoteric questions about your language of choice, code our 8 hour take home test, and/or know as many of the technical details to the printed out list of interview questions we ask.”

As with most things in life, I believe, the answer lies somewhere in between. And it’s a thin line to walk. I honestly don’t think anyone expects a company to hire a developer just because they put “Developer” in their resume and just tells the company they know Javascript. And I completely understand that developers don’t want to go in to an interview and discuss computer science sorting algorithms, white board how to optimize a b-tree, write a coding assignment in front of three other developers they’ve never met, or discuss topics that have almost zero basis for modern business software.

So what are we to do? Where is the middle ground? How are companies supposed to find qualified developers to work with? And how are developers supposed to find companies that don’t have silly interviewing processes?

It’s tough. Plain and simple. And, obviously, there is no silver bullet. Personally, I don’t see the problem with asking some technical questions during an interview. For me as an interviewer, it helps me steer the conversation. For me as an interviewee, it helps me show my personality and flex some of my technical muscles.

But most importantly for both sides, it’s a good way to just size up each others personalities. Most of the time, I’m less interested in whether or not they get the answer right … and more interested in how they interact with me. Do they speak with confidence? Over confidence? Are they speaking in absolutes? Or vagaries? If they don’t know the answer, do they flat out say so? Or do they just talk in circles in an attempt to confuse you? Do they control the conversation? Or is it an interactive back and forth? These are the intricate personality details that I am interested in fishing out during an interview process.

Of course, if they know the answers to the questions, then that’s great too! But you can also get a feel for how “hungry” a developer is to learn by asking these interview questions.

Personally, I don’t find it particularly efficient or relevant to dig in to computer science topics like big O notation and data structures. They’re just not topics that really pertain to a vast majority of the code that is written in business software. I also don’t tend to ask questions about esoteric parts of a language that just aren’t relevant to any of the code that we write on a day to day basis.

Overall, I tend to lean more towards the spectrum that is less focused on computer science topics. And more focused on the real world application of developer skills. Show me your code and that’s great! Talk to me about what you know and what you don’t know. Let’s see how well we can have a conversation about software, regardless of what we know or don’t know.