Candidate Resource: Interview Best Practices

This article outlines how your interview will be structured and assessed, along with helpful tips to improve your chances of success.

To help you prepare, we’ve outlined the structure of your interview and the key areas you’ll be assessed on. If you have any questions about any of this, don’t hesitate to contact us or your recruiter before your interview. 

For tips and recommendations on preparing for your interview, refer to our Karat Technical Interviewing 101.

See the Candidate Dashboard (Prep Environment) under the 'Interview Best Practices' link:

Interview philosophy

We strive to make your interview experience as similar to regular on-the-job programming as possible. This approach provides a better experience for you and allows us to evaluate your skills more effectively. With that said, we understand that your interview will never be perfectly analogous to regular on-the-job programming, as much as we strive for it to be. For example, there are tighter timing constraints than most work projects have, and the situation is higher-pressure than your average work day.

We’ve structured our interviews with both of these ideas in mind: Making it more like a regular programming experience, but also being cognizant of the ways in which it fundamentally differs from a regular programming experience. As a result, our interviews may have some notable differences from other interviews you’ve done.

Interview format

Most of your interview will consist of programming. Depending on the role you’re being interviewing for (check with your recruiter if you’re not sure), your interview will be structured as follows:

• General introduction (10-20 minutes). This may include a project discussion, role-relevant knowledge questions, or a skills test such as a code review.
• Programming (30-45 minutes). We’ll ensure you get the allotted time on programming, regardless of how long the previous sections took.
• Programming problems (time remaining).There are always multiple programming problems available; if you finish a given problem and there is time remaining, we will ask you a new problem.

For each programming problem, you will:

• Be presented with the problem.
• Have an opportunity to ask clarifying questions.
• Be asked to describe an algorithm.
• Choose your language and code up your algorithm in the coding environment.
• Fix any bugs or edge cases.
• Once your solution is fully working, you’ll be asked to describe your solution’s time and space complexity.

Note: If your solution differs from the original algorithm you described, that’s OK. We’ll ask you to explain the time and space complexity of whatever your final solution was.

How the interview is assessed

For the initial, non-programming section, how it is assessed will vary depending on the topic. The Interview Engineer should explain this to you at the beginning of the section, but don’t hesitate to ask your interviewer if you have any questions about how you’re being evaluated.

For the programming section:

• You will primarily be judged on the extent to which you solve each problem. Focus on producing fully functional solutions.
• The optimality of your solution is factored in, but is secondary. When deciding how optimal a solution is, we’ll focus on its Big-O time and space complexity.
• While factors like code quality and testing are recorded for reference, they are not central to your evaluation.
• We’ve chosen these priorities not because we think that things like code quality are unimportant, but because we find that assessing you on a small number of factors and being explicit about what they are creates a better interview experience.
• For example, have you ever had an interview where part of your mental cycles were being spent trying to discern what the Interview Engineer did/didn’t care about? Or where you were being judged on six different factors and weren’t sure which one to prioritize? We strive to help you avoid this as much as possible, so you can focus on thinking about the problems in front of you.
• Your Interview Engineer will help coach you through this if you have questions or they notice you spending extra time on something that won’t meaningfully factor into your assessment.

Programming section details

• The programming problems will not require esoteric data structures; our problems are designed to be solvable with data structures you use regularly and that are available in the standard library for the majority of languages. Examples: Lists, arrays, strings, stacks, queues, hash tables, sets.
• There is no penalty for compiling/running your code. Run it and test it as much as you want! Candidates generally do better if they run their code more, quickly testing each piece of functionality as they build it rather than having to debug all of their code at once at the end.
• You are allowed to look up API references while programming (as you would be on the job), but knowing the most common operations for the most common data structures will save you time, as it does on the job.
• You may speak as much or as little as you want while programming. Your Interview Engineer will offer small tips or ask questions if you’re completely stuck, but they will be watching you code and will be able to follow along whether you’re verbalizing as you code or not.

Tips for performing better

• Practice programming problems if you haven’t recently. You don’t need to spend weeks on this, but most candidates report that spending at least an hour or two brushing up on basic algorithms and data structures and doing a few practice problems on sites like Codewars is helpful.
• Focus on the two key evaluation criteria: your ability to create functional solutions and, to a lesser extent, the optimality of your solution. If you have a working algorithm in mind but aren’t sure if it’s optimal, don’t spend more than a minute or two trying to find a more optimal approach. Your Interview Engineer will help guide you on this decision.
• The problems are designed so that you shouldn’t need to rush, but don’t spend time gold-plating a solution when you could be moving on to the next problem. As with all things time management, your Interview Engineer will help guide you on this; if they feel you are spending extra time on something that won’t meaningfully factor into your evaluation, they will let you know.
• Test your code incrementally as you build it. This approach minimizes complexity and helps identify issues earlier. The extent to which you test won’t be factored into your assessment (not because testing isn’t important, but to minimize the number of things you need to think about prioritizing during your interview), but quickly testing each piece of functionality as you build it can help keep the overall complexity down as you build up your solution.
• Similarly, factoring your code cleanly and using sensible variable names may be helpful to keep things clear in your head. As noted above, though, you won’t be judged on this – just because you write an overly-long function in a time-constrained interview doesn’t mean you’re incapable of factoring your code well on the job.
• If you’re unsure about anything, ask your Interview Engineer. Our problems are designed to not have “gotchas” and to be as unambiguous as possible, but it’s natural that there may still be areas of the question that you’re unclear on or that you’d like clarified. Make a point to ask about these as soon as they occur to you; your interviewer will welcome it!
• When you’ve solved a problem, take 30-60 seconds quickly thinking through whether you have any edge case bugs before saying your solution is complete. There is a slight penalty if an Interview Engineer needs to point out an edge case to you vs. you discovering it yourself. Don’t spend more than a minute on this, though; the penalty is small and it will be better to move on than to spend too much time double-checking your solution. Again, your interviewer will help you navigate this situation: they’ll ask you to double check that you think the problem is fully working and encourage you to move on if it’s in your best interest.

We hope this guide helps you feel confident and well-prepared for your interview. 

Couldn't find your answer? Our candidate support team is more than happy to help with any questions you may have about your interview. Just send a message to [e-mail].