What I Learned Giving Technical Interviews

For some background, I’ve been writing code since I was pretty young. I’ve always had a passion for writing code and solving problems and I’ve been in the field professionally going on for 6 years now. One part of the job I had never really gotten into was being an interviewer.

That all changed early on in 2020 when I started giving technical interviews. When I started out I had some ideas of what I wanted to do and how I wanted to be as an interviewer. I drew most of what I wanted to do from experiences I had when I was a candidate. I’ve interviewed at small startups and large tech giants alike. I have some serious issues with the way that interviews are generally done at large tech companies like Google, Amazon, and Facebook. My chief concern is that they seem to try and drill into knowledge you generally haven’t used since college (think Binary Trees). I also had issues with smaller companies as well, mainly the fact that their interviews are almost too easy or just not relevant. For example, I took an online assessment for one company (I won’t name names) that asked me about doing IT-related things that generally wouldn’t come across my desk as a developer. Of course, the questions weren’t hard but are you really going to weed out bad developers with easy generalized IT questions?

I knew I needed to strike a balance between the two worlds and give a technical interview that was challenging, represented a realistic(ish) problem, gave me some insight into how the candidate thinks about solving a problem, and how proficient they are with the programming language or programming in general. That being said, I also knew that there were developers of different skill levels, and some needed to be challenged more than others.

Picking a Candidate

I want to talk really briefly about how I go about reviewing resumes and what I look for in a resume. Generally, I interview candidates across a wide array of skill levels and your resume is going to tell me how hard I’m going to be on you. If you look like you’re a rockstar developer I’m going to expect more of you than I would someone who looks like a very junior developer.

I generally look for candidates who have experience in the technologies and languages that we use on our projects. I’ve interviewed people with 1–2 years of experience to people who have 5+ years of experience. There’s a lot of nonsense around how long your resume should be. Personally, I don’t care how long your resume is, as long as it’s all you.

Pro tip: don’t lie on your resume. I’ve seen resumes of people with like 1–2 years of experience and they put things like “Lead Developer” or “Senior Developer” on their resume. I’ve even seen people put that for internships they had while in college. No company is hiring a lead developer who is also an intern with 2 years of college education under their belt. Stop it. If I see stuff like that I’m likely not going to want to interview you. If I don’t happen to catch your lie on your resume, I absolutely will when it comes time for the interview.

One thing I wanted to say is that resumes generally go through recruiters before they get to me. So in order for me to see your resume, it would have had to been picked by a recruiter. I also wanted to mention that I don’t get a lot of say in the job description, that’s also up to the recruiter and other folks. Personally, I’d rather write the job descriptions myself because I don’t know what these guys are putting on there (anyone got 50 years of JavaScript experience and a Ph.D. here?)

The Position and Process

So I am responsible for interviewing front-end developers, specifically with React experience as that’s what the company uses (my personal feelings about React aside). I designed the interview process in 2 parts:

1. Asking the candidate some React questions starting with some basics and then drilling down into their React knowledge
2. A coding question

Part 1: The Questioning

So let’s talk about the first part: The Questions. As I said, these range from some SUPER basic things like “What are some advantages React offers over other libraries/frameworks?” I like this question because you can have a super basic answer like “There is a thriving community behind React and lots of detailed documentation” or you could talk about the Virtual DOM, etc. You can go in a lot of different directions with this question and it’s interesting to see how many people answer it. Then I go a little deeper into it like asking them things like what props are and how are they used? When we start to get deeper into their React knowledge I can really see how much they know and how in-depth they can get with their answers.

My main goal is to see how much they know and figure out what they don’t. Before I start asking questions I always tell the candidate that it’s ok if they don’t know something. I don’t expect you to be a walking React encyclopedia, I just need to know that you know what you’re talking about.

Pro tip: if you don’t know something just say that you don’t know. I can’t stand it when people try to pull some crap out of their ass or try and quickly Google the answer. I always know when either scenario is happening and likely your interviewer will as well.

Part 2: The Dreaded Coding Question

Some people HATE having to do a coding question. I think part of the anxiety comes from situations where you have to spend a year studying, reading books, doing mock interview questions, just to see if you’re good enough to get in the door. Personally, I feel like this is overkill for any software development interview process. No one should have to read 100 books and do 10 hours of practice questions a week just to get a job somewhere. You can disagree with me, but like I said that’s my personal opinion.

Onto the actual question itself, let’s have a look at a question that I USED to use (emphasis on the past tense which is why I’m sharing it here). This question has been modified to exclude some of the testing suites I used to test the results, I just wanted to use this as a basic example of a set of requirements I would give a candidate.

https://gist.github.com/shadow1349/50b985a38dcc2ca3cc598a436736bdc5

Basically, I want the candidate to write a function to check to see if a given input is a palindrome. I’m not going to answer this question here since that’s a little out of scope for the topic of this article, but I am going to tell you why I like this question.

The first reason I like this question is that the answer can use many facets of the basic JavaScript principles. It shows me that a candidate knows the built-in array methods, string methods, etc. The second reason I like this question is that it shows me how well a candidate can think about a problem. There are many answers to this question and all of them will achieve the same result, but are some solutions better than others? I’ve had people answer this with like 3 or 4 nested loops, I’ve had others give me 5 lines of clean concise JavaScript code, others look for the most optimal solution in terms of runtime performance, and some just couldn’t figure out how to even start the question.

Some more pro tips: Think out loud, I want to know what your thought process is as you’re starting and as you’re going along. Read the requirements fully and ask questions if you have them. I can’t tell you how many times people gloss over the fact that the input can be a string or a number and that we want to ignore special characters even when I emphasize those things. If you’re stuck say you’re stuck and ask for help don’t just freeze. If you just don’t know where to begin, start small and build from there.

Is this question perfect? No. I’m not sure exactly when you would need a function like this while you’re working on my team. However, the fact that it’s a problem that requires you to know and use many built-in functions of the JavaScript library that you absolutely will use every day I feel ok overlooking that fact.

Wrapping It Up

I’ve done a ton of interviewing since I started early in 2020 and I’ve actually enjoyed it so far. Specifically, I have enjoyed designing and tweaking the process over time as well as training other developers to use my process and getting their feedback. I think the marking of a good interview process is one that changes over time. I don’t think you have to make sweeping changes all the time but tweaking small things here and there I generally see as a good thing.

If you’re someone who doesn’t typically perform well in interviews, I get it. Depending on the company you’re interviewing at the process can be daunting. The best advice I can give you is to not stress out too much over it (a little stress can be good), breathe, talk through your interview, ask questions, and work with your interviewer. Ultimately, the interviewer is there to help guide you through the interview and assess how you did. When you get on a job site you’re going to be expected to collaborate with people and interviews love to see that collaborative attitude during the interview.

If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!

If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!