Interviewing is probably one of the most important and stressful processes to follow.

However, it's a process that can be learned, practice, and approached with a strategy.

Take a deep breathe. If you have the time and resolution, you'll be able to attain the job or internship you want. Follow this guide to learn how.

Author's note: This article was written in mind for software engineers applying for generalist roles. Other technical roles like front-end developers or DevOps engineers are assessed differently.

Table of contents

• Which programming language should I choose?
• What is the entire software engineering interview process?
• What should I expect from a coding interview?
• Why do coding interviews even follow this structure?
• How am I evaluated?
• How do I prepare for a coding interview?
• What do I do during the actual coding interview?

Which programming language should I choose?

Choose Python.

It's easy to read, pick up, and remember, which is especially advantageous for interviewing.

During the actual interview, you get stressed, you forget to include a bracket or curly brace, you lose precious time trying to remember the correct obscure syntax with no documentation or example to follow. You'll start to sweat and regret.

With Python, you can write less code for the same functionality so you save time and effort. And because it's easier to pick up and remember how to use, you can also avoid asking your interviewer if you can Google how to do something.

The only reasons you should choose a different language is if you're seriously limited with time or feel only confident using a certain language.

What is the entire software engineering interview process?

The interview process varies by companies and roles. Generally, an entire interview process will follow this format:

• Take home assessment (optional): Companies start by giving you a take home assessment, usually done on third-party platforms like HackerRank or CodeSignal where you're expected to complete 2-3 coding questions or debugging tasks on your own time.

• Talk to a recruiter (optional): A recruiter will schedule a 10-15 minute phone call with you to assess whether your qualifications and skills fit the role their company's looking for.

• Technical phone screens: Your recruiter will help you schedule one or two technical phone screens. If you're applying for an internship, sometimes you're only expected to complete a technical and/or behavioral phone screen. You'll likely be coding in a real-time collaborative editor like HackerRank or CoderPad.

• Onsite technical interview: Typically, this round is more rigorous for candidates looking for full-time roles but may apply for interns as well, especially at startups. Prior to the pandemic, companies would fly out candidates to their office to attend 4-5 interviews with a lunch break in between. Sometimes, the lunch break is used as an assessment on culture-fit. Because this is onsite, the company may expect you to code on a whiteboard. However, it's more often now that onsite interviews are virtual. There will be several technical interviews, a behavioral interview, and possibly a system design interview for more senior candidates.

• Followup interviews (optional): If your interview feedback is mixed between two ratings, your recruiter may schedule you for followup interviews to assess whether they want to move you to the next stage or determine what engineering level to place you at.

• Team matching (optional): If you've gotten this far, you received positive interview feedback. Some job applications are for a specific team or organization, in which case, you've likely already talked to the hiring manager. Otherwise, the recruiter will be inviting you to talk to teams that may fit you (and vice versa) at this stage.

• Negotiations: This part of the interview process will likely give you the most return on investment, as a simple conversation can increase your compensation by tens of thousands of dollars or secure you additional benefits. You'll get the most leverage for negotiating if you have competing offers (so prepare sufficiently for every interview!).

The interview process is usually shorter for smaller companies, and longer for larger companies, so it may be advantageous to apply to larger companies before smaller companies.

What should I expect from a coding interview?

The format will typically follow this:

• Brief introduction (2-5 minutes): The interviewer will introduce themselves and likely will ask you to introduce yourself. Have a 1-2 sentence in mind and keep it as brief as possible, so you can maximize the time you can get for coding.

• Coding problem (35 minutes): If you're applying for an internship, you can expect an easy or medium level question. If you're applying for a full time role, you can expect a medium or multipart questions.

• Questions (5 minutes): The interviewer will give you time to ask any questions about the company. Have one or two questions ready to show your genuine interest in the company.

Some companies have longer interviews, potentially up to an hour.

Again, the format does vary as some companies follow more "real-world" tasks like debugging a file.

Why do coding interviews even follow this structure?

• It's a contained way to assess the candidate's problem-solving skills

• It makes objectively comparing each candidate's performance against other candidates easier

• It's applicable to most programming jobs (can the candidate assess the situation, create a plan, communicate well, work with the interviewer, and adapt if the problem changes?)

It's not a good way to assess how well someone can actually perform for a specific project, however it's a decent indicator for how someone logically approaches solving problems and whether they can communicate their approach well.

How am I evaluated?

Every company will have ta specific rubric for the interviewers to follow. These are the general aspects on how you're evaluated:

• How are the candidate's comprehension skills? (Did they understand the problem? Were they able to adapt if you tweaked the problem?)

• Is this candidate technically capable for this role? (Did they finish the question? Did they complete follow-up questions? Did they need hints, or did they struggle to implement a solution?)

• Can the candidate communicate well? (Was the candidate able to explain their approach?)

• Would you want to work with the candidate? (How did the candidate react when given suggestions? Were they open to feedback? Would the candidate be enjoyable or easy to work with?)

How do I prepare for a coding interview?

If you really care about getting that role, you need to follow all of these rules. Not just one, not just two. Don't just read it and then forget about it. Digest it, make a plan, and put your plan into action.

1. Give yourself at least 3-6 months to prepare.

   This is the most obvious rule yet so many people still dismiss it. Give yourself time to prepare.

   I get that you have a whole life to tend to, however, getting a job offer is one of the main things that can impact the trajectory of your career. Don't put it off. You will cannot expect yourself to be able to wing an interview with less than a week of studying.

   Create a study schedule that fits your timeline and day-to-day schedule. Break down your goals, so they are achievable in the timespan of a week.

   For example, at the start of every week on Monday, give yourself a subset of questions you want to practice with. Set a goal for yourself to complete those tasks by the end of the week on Sunday. Your goal could be completing an entire section by the end of the week, or to complete 3 questions and revisit 2 already solved questions. Adjust your goals depending on your overall progress and timeline.

2. Have a good understanding of programming fundamentals

   You should know the basics initiating variables, writing if/else statements, for/while loop, how to calculate time/space complexity of an algorithm, what object-oriented programming is.

3. Have a good understanding of a list, dictionary, and set

   You should know the time complexity of getting and setting values in each of these data structures and the differences between them.

4. Learn the pattern first

   Follow a tool like InterviewCrunch that focuses on teaching you the pattern of how to solve problems.

   Many people make the mistake of practicing problems based on data structures. This not useful because candidates end up using data structures that don't make sense for the problem. Do they know why they're choosing to use a dictionary over a set, or are they throwing a dictionary into the solution just because?

   Another pitfall is you might be well-versed with using a data structure, but you may not know how to use it to solve the problem.

5. Practice at least 5 questions using the pattern

   Start with a couple easy problems, then move onto medium difficulty problems.

   Continue practicing until you can identify when to use that pattern, and can solve a medium level question without help.

   InterviewCrunch already provides the questions and a certain order to practice the questions with.

6. Revisit problems you struggle with

   For any problems you struggle with, mark it and revisit it after 2 weeks.

   InterviewCrunch allows you to keep track of flagged questions in its interface.

7. Learn advanced data structures as you learn the patterns that require knowledge of them

   Do not dive into 10 lectures about data structures before you study for interviews. You already know the basic data structures needed to solve most problems (lists, dictionaries, sets).

   To save time and reduce context switching, learn the advanced data structures as you learn patterns that require them. For example, learn about linked lists when you start learning about linked list manipulation. Learn about trees and graphs (adjacency lists, adjacency matrices) when you start learning about breadth first search or depth first search.

   You won't be able to understand linked list manipulation patterns without understanding linked lists first, and you also won't need to know about linked lists unless you're doing linked list manipulation problems.

8. Keep practicing until you can solve 15 out of 20 questions

   Practice various questions. Mark the ones you struggled with, and practice similar problems that use that pattern.

   Eventually you'll get better at recognizing and implementing the pattern. When you have a success rate of about 75%, then you're in a pretty good spot to interview.

9. Take mock interviews

   Do mock interviews with your friends, and try to schedule your interviews so you take interviews for your least favorite company first.

What do I do during the actual coding interview?

• Show up early: Physically show up to the interview early before it starts, or already be waiting in the virtual meeting room several minutes before your interview is scheduled to begin. Give yourself as much time as possible, even if it's only 1 or 2 extra minutes.

• Introductions (2 - 3 minutes): Listen to interviewer's introduction. Give your own 1-2 sentence introduction. Keep it brief so you get more time to code.

• Understand the question (5 minutes): Let the interviewer explain to you the question. Ask about edge cases. Then give an input and output of a test case you make up and verify with the interviewer if it's correct.

  This is all so that you fully understand the question before you start coding, and to also let the interviewer know that you're able to define the scope of the problem before you begin to solve it.

• Explain to the interviewer your general approach (2 - 5 minutes): Start with the brute force solution and then try to think of an optimized solution.

  Explain your approach like you're talking to a child. Make the explanation easy to understand for both you and the interviewer. This helps the interviewer stop you if they find any potential mistakes, and this helps you solidify more clearly what you'll do. At the end of your explanation, ask the interviewer what they think of your approach.

  If the interviewer questions your approach at any point from here, be very aware that they may be giving you a hint on how your plan can go wrong. Make sure you give the interviewer space to explain themselves and try not to interrupt them. It's ok to ask "What do you mean by that?" if you don't see the issue.

  If you're stuck on thinking of a solution, you can try to prod the interviewer by making a suggestion and hearing their input. For example, you can say something like "I'm thinking we'll need to track the seen numbers with a set..." and watch if they nod or agree.

• Begin coding for a happy case while talking out loud (15 - 20 minutes): Ask the interviewer if they want you to write the brute force solution or to skip to the more optimal solution. Sometimes the brute force solution is so trivial that the interviewer is OK with skipping it. If you can't think of the more optimal solution, then you can ask if you can write the brute force solution first.

  Prioritize two things:

  1. Write a complete solution down, even if this means you need to write a brute force solution. Don't bother optimizing your code for edge cases until you know it works for a happy case (a normal case). This is essential because having some working solution is better than an incomplete one.

  2. Explaining your thought process as you write. Do NOT keep silent. The more you talk, the more the interviewer can follow what your intention with a piece of code is, which allows them to stop you or point out any mistakes they might see.

  Again, interviewers are there to also help guide you. If they offer help then accept it wholeheartedly.

• Run through the code with a test case (5 minutes): Walk through your code with a test case. Or depending on the interview platform, you can run your code and see which test cases fail. Walk through your code with a test case that fails.

  Having bugs is expected. What the interviewer is evaluating is whether you can find your own mistakes and know how to correct them.

• Answer follow-up question (5 minutes): It's a good sign if the interviewer is asking follow-up questions. Talk through your answers again. If you're out of time, you and your interviewer may need to just talk about the solution without implementing it.

• Ask questions about the company (5 minutes): Regardless of your performance so far, this is a good opportunity to talk to the interviewer and show your genuine interest in their company. Keep several go-to questions in mind, be present, and listen to their answers. If you're short on time, mention to them "I'm aware we're almost at the end of the interview and want to be respectful of your time." which shows the interviewer your consideration toward them. Finally, thank them for the interview before signing off.

  At this point, you do want to kill them with kindness just a bit so they leave the interview with a good impression of you. Even if you failed the coding portion, at least they know you would have been a nice person to work with.