Technical interviews can be very overwhelming. Where do you start when you are given 45 minutes to solve a coding problem? How do you organize a plan when you don’t even know what the question is asking? But, whether over Zoom, on a whiteboard, or through an online portal, if you follow these six steps on each practice problem you do, you will be set up for success in the real interview.

First thing’s first. Getting the correct solution is not the most important thing in a technical interview. Let that sink in. Obviously, it’s never a bad thing to answer the question correctly; however, it’s more important to demonstrate that you are a capable and smart coder who thinks ahead. In technical interviews, interviewers are looking to understand your thought process. They want to hire someone who can work with others, not a robot who has memorized how to solve a DFS problem.

Before we start, I want to make one thing clear. You will make mistakes in your technical interviews. That is fine. I cannot stress this point enough. Mistakes are inevitable. What’s important is to stay calm. Freaking out about a mistake will only prevent your ability to think logically. Just acknowledge the issue and move forward.

1) Clarify the Problem

Once you are presented with the problem, verbally repeat it back to the interviewer in your own words. If you have any questions, ask! You don’t want to waste any time or brain power thinking about how to solve the wrong problem. Even if you are confident you understand the question, clarify it. Companies are looking to hire engineers who fully understand what they’re coding before they start typing.

2) Write the Function Signature

Depending on what language you pick, the function signature will include parameters and possibly the return type. Not only will writing the function signature keep you focused once you actually begin coding, but it also demonstrates that you are thinking ahead about what inputs and outputs are necessary.

3) Write Small Test Cases

Physically type out small test cases above your function signature. Write more than you think you need to. As you write, you can ask clarifying questions about allowed inputs. These test cases should be smaller than example test cases you may see. Make each one small enough such that you can easily run through it with pen and paper.

Problems in technical interviews are purposefully under-constrained. Do not assume that all test inputs will be in the form you expect them to be. What if you are passed an int rather than an array? Having thorough test cases already written out will help ensure that you include checks for corner cases in your code before you submit your final answer. But beyond that, it also illustrates to your interviewer that you can write shippable code. 

Here’s an example. Say you are writing a function to find the smallest element in an array. You’ve already asked your interviewer and learned that the function will only be passed arrays. Your list of test cases should include: [], [0], [2], [-3], [1,5,2], [5,1,2], [5,2,1], [1,5,1], [1,-3, 3], [-1, -2, -3], [-1, 0, 2]. Note that I included an empty array, arrays with all positive values, arrays with all negative values, arrays with both positive and negative values, and arrays with repeat values. Think critically as you create your test cases. If your function is attempting to sort an array, what happens if you pass it an array that is already sorted?

4) Pseudocode

Next, both type out and verbally explain to your interviewer some pseudocode. In order to do well in a technical interview, you and your interviewer must be on the same page about your intended plan. If you silently code out the answer without explaining your logic, the interviewer will have no actual sense of your coding abilities. You also might save yourself some time by finding flaws in your logic before you’ve taken the time to get the syntax right.

You don’t need to go into too much detail with your pseudocode. Just jot down some notes and speak aloud about how you plan to organize your code. 

5) Code

Now it’s time to actually implement the code! Although it may feel unnatural at first, continue to speak aloud each step that you type. It’s imperative that the interviewer understands what you’re thinking as you code. 

Offer time and space complexity as you think of it. It’s okay if you don’t implement the fastest solution. But make it clear to the interviewer that you are aware that there are more efficient solutions. Verbalize that, for example, the for loop you wrote takes O(n^2) time, but if you had had more time, you would have looked into using a hash-map or a graph as a more efficient solution. 

6) Test

Once you finish coding, be sure to check your code against each and every test case you brainstormed earlier. Companies want to hire employees who search for bugs in their own code before its shipped.

Importantly, test the code you actually wrote, not the code you think you wrote.

Following these six steps with each practice problem you do will build the confidence and develop the clarity in communication you need to succeed in a technical interview.

Comments

topicTopics
academics study skills MCAT medical school admissions SAT expository writing college admissions English MD/PhD admissions GRE GMAT LSAT chemistry strategy writing math physics ACT biology language learning test anxiety graduate admissions law school admissions MBA admissions interview prep homework help creative writing AP exams MD academic advice career advice study schedules summer activities history personal statements premed philosophy secondary applications Common Application computer science test prep organic chemistry supplements PSAT admissions coaching economics grammar ESL law statistics & probability psychology SSAT covid-19 legal studies reading comprehension 1L CARS logic games Spanish USMLE calculus dental admissions engineering parents research Latin mathematics verbal reasoning DAT excel political science French Linguistics Tutoring Approaches chinese DO MBA coursework Social Advocacy academic integrity biochemistry case coaching classics diversity statement genetics geometry kinematics medical school mental health quantitative reasoning skills IB exams ISEE MD/PhD programs PhD admissions algebra astrophysics athletics business business skills careers data science internships letters of recommendation mentorship social sciences software engineering tech industry trigonometry work and activities 2L 3L AMCAS Academic Interest Anki EMT English literature FlexMed Fourier Series Greek Italian MD vs PhD Montessori Pythagorean Theorem STEM Sentence Correction TMDSAS Zoom admissions advice algorithms amino acids analysis essay architecture argumentative writing art history artificial intelligence cantonese capacitors capital markets cell biology central limit theorem chemical engineering chromatography class participation climate change clinical experience cold emails community service constitutional law cover letters curriculum dental school distance learning enrichment european history executive function finance first generation student fun facts functions gap year harmonics health policy history of medicine history of science hybrid vehicles information sessions institutional actions integrated reasoning intern international students investing investment banking logic mandarin chinese mba mechanical engineering meiosis mitosis music music theory neurology operating systems pedagogy phrase structure rules plagiarism poetry pre-dental presentations proofs pseudocode quantum mechanics resume school selection science simple linear regression sociology software study abroad synthesis teaching technical interviews time management transfer typology units virtual interviews writing circles