When trying to get a job, the first goal is to get an interview. It always feels like an uphill climb, with the feeling that if you can just land an interview, you will practically be there, because you can handle it. Then you get that interview, and that confidence fades away, often quickly. Technical interviews can be a real challenge, and you have heard stories about them in addition to what you have experienced.
Just like that, you start dreading the interview. Well, unless you prepare the right way, and with technical interviews, there are two basic things that should guide preparation.
The first is to understand the technical questions you are likely to receive. Any technical interview is sure to have them, although some will have more than others. I have interviewed at companies that had an entire portion devoted to C, ones who asked a series of questions that were language agnostic, and ones who didn’t ask much in the way of technical questions. The technical questions are generally of three flavors:
- Questions about technologies noted on your resume
- Questions about technologies mentioned in the job description
- Being given a problem to solve
The first one is relatively simple to prepare for. A cardinal rule of a resume is that you should never mention anything on your resume that you are not prepared to talk about in more detail. If you put it there, you are basically asking for an inquiry about them. That means you should resist any and all temptation to put a technology down that you know nothing, or next to nothing, about. You might be hoping to get past an applicant tracking system (ATS), but this is a quick way to make the interview go south if you get one, and not just because this is borderline dishonest.
What is likely to happen is that you will be asked what experience you have with the technology, and as soon as you honestly say that you know little more than that it exists, your candidacy will take a big hit, especially if it is a key technology for the position. What you want to happen, of course, is to be asked about technologies you know well and have good experience with, and also a story or two you can tell to demonstrate why you’re a good candidate for it.
The second one is not as simple, but still relatively straightforward. The job description will have requirements and “nice to have” skills noted for the position. Since the hiring manager is looking to fill a position with someone having some combination of these skills, they will try to see if a candidate has them in sufficient supply. As such, when preparing for the interview, your preparation must include time spent thinking about what is in the job description and how your background relates to it, including the specific technologies listed.
One possibility is that you might be quizzed about one of the technologies in some fashion. I have been in interviews where I was presented with some code and had to explain what it does or find the bug in the code, or where I was presented with a setup and had to describe what I think it tells me as a user or developer. One time, I was presented with a file system and asked where I think I would find code for something.
Specialized roles may have common questions that you are basically guaranteed to get at any interview. For example, if you are interviewing for an embedded software role, especially at senior levels, you are sure to be asked some in some way, shape or form about the use of the volatile keyword in C for the case where you may be checking a register constantly over time, as not using the keyword for the variable representing the register could lead to an optimization you don’t want that leads to missing when the register is set to a value at which you want to take a certain action. I am hard-pressed to recall many interviews I have had in the last five years in which I was not asked about this in some form.
Finally, you are likely to be given a problem to solve of some sort, which may or may not involve being asked to write code. Once upon a time, these problems often took the form of brain teasers, and they were a big part of what many would prepare for. While they are still around, the general sense is that very few companies use them, and I haven’t encountered them in a long time. Instead, you are more likely to be asked to solve a problem similar to one that might come up in the course of everyday work at the company should you be hired.
The idea with these is not so much to see a “right” answer, although that would be a nice end result. The most important desire a manager has in using them is to get a feel for how you think and how you would approach a problem. Oftentimes, what are you presented with has a brute-force approach that is easy to figure out, but not very efficient; noting the brute-force method and it not being the best is a good start. You want to then reason about an effective way to solve it, and explain yourself throughout.
The second item to drive your preparation falls outside of the technical questions you might encounter. This applies to any interview, technical or not, and it can be summed up in two words: ask questions. You will invariably be asked, likely when the interviewer is done with questions they have, if you have any questions for them. The worst answer you can possibly give is “No.” You must come prepared with questions that will help you learn about the company, because you want to assess the fit should you receive an offer. You want to ensure, as much as possible, that this is a company you want to work for.
Additionally, you generally should not ask the same question(s) to everyone – indeed, who you are speaking with should make a difference. While there might be a question or two that can sensibly be asked of all, something different should be asked of everyone so that you maximize the information you obtain, especially considering the perspectives. A manager, a would-be colleague and an HR person all experience the company – and what your work would be – quite differently, and they have different experiences for themselves.
When you get that interview, it should not lead to a decline in confidence. Instead, it should be a good sign and one that has you ready to shine and receive the job offer you want. With the right preparation, you can let it be just that and be more likely to get the end result you seek.