The Art of Technical Interviews

There is a particular art to interviewing for software development positions. I’ve interviewed for many different jobs over the years, from burger joints, lifeguarding, IT support, and of course, MANY software development interviews. I should note that this article will not help you with any technical questions since there are many way better resources for that out there. If you’re looking to sharpen your knowledge of data structures and algorithms, I suggest using Leet Code. It’s a great place with loads of practice questions you might see in a technical interview. This article is more focused on HOW you interview and what you should expect going into a technical interview. I think people who are new to the field or are interested in getting into software development should give this article a once-over.

What can I expect?

Going into a technical interview can be somewhat intimidating, even for seasoned pros. In 2021 it’s more than likely you will be interviewing over Zoom or some other digital medium. If you’re wondering what in-person interviews will be like, don’t worry, I’ll cover those too!

The Virtual Interview

With the pandemic still going strong, and even as companies open back up, don’t be surprised if you’re slotted for a Zoom interview. Essentially what is going to happen is either an HR person or a recruiter will be your first point of contact to set up the interview. They will be the middle person between you and the technical interviewer. They will give you some time slots, and you will choose the best one that suits you. Once your time slot is confirmed, you will get a calendar invite with a link to join the meeting. Make sure you keep an eye on it so that you’re fully ready when it comes around. My suggestion is to pick a slot that works best for you and is most convenient for you.

Once you’re in the meeting, make sure to put your camera on. If you can’t for some reason, just let your interviewers know! The only other difference here will be the technical screening. Usually, you do a whiteboard screening (which I’m not a fan of); however, there are a couple of other techniques in a virtual meeting. Most of the introductions and small talk will be the same if you’re virtual or in-person, so I’ll cover that in the in-person section.

The first is a Q&A-style interview. Your interviewer might start with this kind of interview first and build to a coding challenge. This interview is to get a baseline of your knowledge of a particular topic. For example, if you’re interviewing for a position where they need you to know C#, they may ask you some questions about the language itself or if you’ve ever used a specific framework that the language is known for.

The coding challenge is where things get interesting. There are a few ways that companies do these, and I think the most common is the screen share. They will send you a link to a question on a site like JSFiddle, dotnetfiddle, etc., that they have saved to that site. Then they will ask you to share your screen so they can watch you while you write the code. Often these sites are not collaborative, so in order for your interviewer to see your code, you’ll need to share your screen. There is another way, and the only way I know of is called CoderPad. This is probably my favorite tool, but it makes it, so you don’t have to do any screen sharing. The coding environment is fully interactive, and the interviewer will be able to see you type on their screen. If you’ve never seen it before, you can sign up for a free trial (no credit card needed!) at https://coderpad.io if you know you’ll be doing a coderpad interview. This will help you get familiar with the online IDE and save you some precious minutes beforehand. The same goes for any of the fiddle sites. You can ask your point of contact how the technical interview will be, and they should be able to give you an answer. These are just a few different ways I’ve seen interviews and done interviews. If you can figure out the tech they’re using beforehand and brush up on it, that should give you a significant advantage.

Some companies also give you a timed online assessment before you even interview. Basically, you get a link, log into a portal, and you’ll be met with some instructions, and you’ll have like an hour or so to answer a question and submit it. Then someone will look over the recording of you answering the question. This usually happens as a pre-interview question to see if they even want to interview you. This is generally reserved for larger tech companies.

Expect something to go wrong doing an online interview. Internet could go out, bad connections, something isn’t working as expected, goodness forbid the call drop. These are all things that can go wrong. Don’t stress out about it too much, but you do need to be aware and think on your feet or at least have a general plan if something happens.

The In-Person Interview

This will be a little bit different since you’re going to be in person. This will also be a lot less error-prone since you do not have to rely 100% on technology to collaborate. Make sure you arrive AT LEAST 10–15 minutes early. This gives you enough time to find parking if you drove, figure out where you’re supposed to go and take the edge off a little bit. Interviewing can be nerve-wracking, and being early and prepared puts you in a much better headspace than if you’re rushing around last minute.

When you get there, expect to meet your point of contact or one of their colleagues. The interviewers will introduce themselves and ask you a few questions about yourself and make general small talk. Before the interview starts, they will generally give you a quick rundown of the company, the teams, the products you’ll be working on, stuff like that. Pay attention to this part because it could ultimately determine if you want to work there or not. Remember, HR people and recruiters write job descriptions. You don’t need 10+ years of Angular experience. This is the ONLY time before you get hired you’ll hear from an actual developer what the products and tools they use.

Sometimes interviewers will give you time beforehand or afterward to ask questions of them; I highly encourage you to come with some questions prepared. If you don’t know what questions to ask, don’t stress out, I’ll give you a couple of examples.

1. Do you enjoy working here? If the answer is ever not really or giving a kind of “meh” answer, run.
2. What does a typical day look like? If you get hired and decide to work at that place, this person will be your colleague. Their day will look a lot like your day, and you’re going to spend a decent amount of time at work, so it helps to know what you’re getting into.
3. Is there a decent budget/allotted time for R&D? This may not be important to you, but I like this question because it tells me if a company wants to stay up to date and how much they value modernizing. Some companies, especially enterprises, are usually quite old and slow, and if that’s not what you want, this could help weed out a company you wouldn’t want to work at.
4. What is the typical team size? Team sizes are important; how important they are is up to you.
5. Ask about company events. If you want to know about company events, ask about it if you like holiday parties and whatnot (who knows if they’re happening this year, but it might interest you). Sometimes companies do online events like virtual happy hours. If this is something that you like to do or is important to you, it’s something you can ask about.
6. Do you issue laptops/equipment? Most companies want you working on a company issues device. They will also issue other equipment like connectors, monitors, keyboards, etc. Think about if that’s an important aspect of working at a company for you.

These are just a few examples, but my general advice is to think of things that are important to you and ask about those things. You can also ask about your performance during the interview. Usually, an interviewer will be honest with you and say how you did in general, and that can be excellent feedback for future interviews if that one didn’t go so well.

The Technical Questions

I mentioned technical questions a bit earlier, but what are they? These are baseline questions that you should know if you’re interviewing for the position. So if you’re interviewing for a position that uses C#, you should know the data types that C# uses. These questions can go from basic to pretty advanced. If you’re being asked these questions, it’s really important that you don’t bullshit your interviewer. We know when you’re bullshitting, and we don’t like that. If you don’t know something, say that you don’t know. If you’re not sure, let us know that you’re unsure but we will give an answer a try. Another thing you should never do is Google the questions while we’re asking them. It’s really obvious when a textbook answer follows a good 15–30 seconds of silence. It’s really important that you’re honest with your interviewer; they aren’t there to trick you. They want to assess your knowledge and if that level of knowledge will be a good fit for the position.

The Big Bad Coding Challenge

You’re going to have to do some kind of coding challenge at almost every interview. They can vary from super hard questions to not-so-hard questions; it really depends on where you’re interviewing. If you’re going for an interview at Google, expect some really classic questions like inverting a binary tree. These are the times when you would want to brush up using something like Leet Code that I mentioned earlier.

Most people are really scared of the coding interview and with good reason. It’s been made out to be this big bad scary thing but let’s demystify it a little bit. You should have good knowledge of the basics of writing code and the basics of the language you’re interviewing in. The coding questions are really designed to see how you solve a problem. The interviewer wants to see your thought process as you solve a problem, and they will also be able to assess your knowledge of the given language you will be expected to work with. The coding questions should be a collaborative effort but ultimately one-sided. The interviewer is usually there to help you along but not hold your hand.

When the coding challenge starts, your interviewer will give you the requirements and then give you some time to ask questions about it. Asking questions is a good thing, but if you genuinely don’t have any questions at the start, it’s ok to jump right into it. During the coding interview, it’s really important to vocalize your thoughts. I would not recommend you jump right into just coding. I would suggest doing some pseudo-code and telling your interviewer what you’re thinking and why you think it will work. If you do have questions at any time, ask them. Collaborate with your interviewer; remember, you are a potential colleague, and they’re going to want someone they can work with. A part of this interview is how well you work with others. Most companies don’t want a lone wolf developer.

Watch out for the Red Flags

I’ve been giving you advice for genuinely benevolent interviewers. However, sometimes you’ll get a bad interviewer. Whether they seem disinterested or they’re just plain rude during the interview, these are some things to watch out for. Other things to watch out for are interviewers technical or otherwise asking questions they shouldn’t be asking.

What questions should they not be asking? These are somewhat dependent on where you live and what’s legally allowed. In most places, they shouldn’t be asking any questions about these things:

• age
• race
• sex
• religion
• disability
• finances
• criminal history
• political views
• previous salary

If you’re in an interview and they ask about any of these things it’s a major red flag. I’ll talk a little bit about that last one, the previous salary. When you’re trying to negotiate salary your previous salary is something your potential employer should not be concerned with. This isn’t an article about negotiating salaries but I will say revealing your previous salary is completely up to you and whether you think it will help or hurt your negotiation.

If your interviewer makes you feel uncomfortable in any way that’s also a big red flag. Sometimes you can’t put it into words, but there are certain things that just make you feel uncomfortable. You should definitely trust that instinct because it’s something that we’ve developed over tens of thousands of years.

When you’re doing technical screenings watch out for your interviewer trying to trick you. This is a really fine line between asking a hard question and asking a trick question. For example, if they ask you something like “How does React’s direct DOM manipulation work?” and they’re expecting you to say something like “React uses the virtual DOM” that’s a really bad trick question. The question should have been more direct to ask you about the virtual DOM and how that works at a high level. I mentioned that your interviewer won’t be trying to trick you, but if you find they are that’s a major red flag.

These are just a few red flags to watch out for, but there are certainly more. Take your time, ask good questions, and see how you feel at the end of the interview. If an interview is bad enough, you can absolutely walk out. However, I’d reserve the walkout for the most egregiously bad interviews. I’ve had TONS of interviews and have yet to walk out on one.

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!