YaGIP: Yet another Guide to Interview Preparation

nafSadh // notes // YaGIP / Preface / Reading Log / Resources

This article talks about what are the things to focus on and how to prepare for software engineering job interviews.

Table of Contents


I am using following abbreviations in this document:


Mindset and approach

Having a right mindset is helpful. What is right for you may be different from someone else. But, invariably do these:


I am a software engineer, and this note is about interviewing for software engineering roles. Titles vary; but usually:

Often shortened as SE, SWE, SDE etc. For more info visit level.fyi. There would be a lot of qualifiers; e.g.: Senior SE/SDE/SWE, Staff ~. Manager roles may be titled as: Software Engineering Manager, Engineering Manager, Director of Engineering etc.

Things to focus on

As a software engineer you need to focus on the following things:

Your Profile

Resume is important for job search. But, today, LinkedIn is the most important form of profile. You have more room to list all of your achievements, voluntary works and what not. So, try to polish your LinkedIn profile. Do not exaggerate or lie. Remove stale info. Proudly showcase what you have done. For each role, describe what you worked on, list your projects so on so forth. It is nice to have recommendations and endorsements, but these or of subjective value.

Resumes should be strictly one page, should have your contact info and list your relevant jobs and education. Read CSCQ FAQ on resume and utilize their threads on resume review.

Your Story

[Notice how the storytelling changes with time length and format]

Be excited about what you are doing. Be excited about yourself. Exude confidence and passion. To prepare for this, take some time to reflect on your life and career. Go through your good old memories, and, if you can, through your past projects (their documentations, demos, videos, presentations, source code – whatever you have). If you are currently working, please, make sure you have an understanding of the bigger picture and architecture of your current project(s).

Also, reflect on any decisions (technical or otherwise) you have made at work or for yourself. Do some introspection. Was that a right decision? Why did you make those decisions etc.

Know thyself.

Data Structures and Algorithms


Understanding most used data structures and algorithms is a must. Depending on how fresh is your knowledge, you may benefit from reading on them. Make sure that you understand most of the following:

DS&A Topics

Data Structures

Algorithm concepts

🔬 Basics:

[Note that, you’d probably never be asked directly about these topics. However, a solid understanding of the aforementioned topics is the foundation on which you’ll build your skills.]

🔬 Intermediate:

✨ Somewhat Advanced:

🌪 Advanced (can skip):

Related concepts

DS&A Reading Materials

Everyone has their own style of studying. So, adopt accordingly.

These are some books that I have found to be useful in the past:

However, I used following resources to brush up my understanding of algorithms,

Here is a log of what I have read during my preparation.

The Coding Interview

Hacking the Coding Interview

Coding interview can feel like playing Russian roulette. You are expected to solve some problem, come up with an algorithm and code it within some time constraint. This can feel challenging. But, with practice, you can get better at it.

Preparing for coding interview is often colloquially known as leetcoding. This is because LeetCode is the ubiquitous resource that almost everyone uses for preparations.

Types of coding interview

Let us talk about types of coding interviews. The goal of coding interview is to test your ability to produce useful code. That is what you are primarily being hired for. So it makes total sense to test this skill. There some common formats of coding interviews

Screening rounds

Most companies screen their candidates before inviting them to on-site. Screening can be done using an online assessment (1-2hr) or a phone/video interview session (~1hr).
Some companies may want you to do longer online assessments or take home tests. Anything that involves more than 90 minutes of your time and zero minutes of their time is a big no.

Online assessments then will have some LC style easy to medium problems to solve. You are generally given a clear problem statement and an online coding editor where you can write, run and test codes. Often they will provide 2-3 explained test cases and more than a few hidden test cases. Often you can run your code and know if all hidden cases passed. These will be done using platforms like HackerRank, AmCat etc.

Phone interview is just a single session of on-site interview – but is conducted via a phone call or video conferencing. Generally they’d ask one-two LC style easy to medium questions, but some dark soul may also ask a hard problem. (It is not difficult to solve a hard problem, just that the remote nature of the interview often cause technical issues and communication difficulties which may eat up time necessary for a hard problem.) Some companies may conduct a remote pair programming session. Nothing to worry about these interviews either. Note that, even though this round in colloquially known as phone interview (because originally it was conducted via telephone) it can utilize any remote communication tool, including but not limited to telephone calls, Hangout/Skype etc. or other video conferencing (BlueJeans, Zoom) or online coding interview platforms (e.g. HackerRank, CoderPad etc.).

Preparing for the coding interview

a.k.a. grinding LeetCode

Preparing for a coding interview is like taking any standardized test; only that such interviews are by no means standardized. Fear not, most large companies and big names try to evaluate all of their candidates with one common yardstick. So, it is not very difficult to prepare.

Most common approach is to solve problems on LeetCode.com. However, there are about a thousand problems on LC and there are problems outside of LeetCode.com. Moreover, if you try to cram solutions, that is not going to work. You are not going to see an exact LC problem but some refinement, variation or extension of LC problems. It is also likely that you’d see a problem which cannot be related to some LC problem. Remember, there are engineers who device their won problems and there are engineers who just recycle from someone else’s. Regardless, the goal of these kind of interview is to test your ability to use known algorithms and data structures to solve some toy problems. They often mimic real life problems or are often simplified versions of them.

How to “grind” LeetCode?


(if you can solve LC easy under ten, then you can skip this step) First step is to build your base skills. Make sure you have basic understanding of some of the most used data structures and algorithms:

Once you are confident about these, try solving LC easy problems. Your goal is to solve LC easy under ten minutes.


I found following approaches to be useful:

Most common interview problems

There is a small collection of problems that covers a wider variety of common challenges that you may face in an interview. It is a good idea to solve and understand all problems listed here.

Gauging your problem solving ability

Given enough time and tools, you can solve most medium problems. However, if you need more than 60-70 minutes for a medium problem, that means you are struggling with the problem. So, try to solve a problem first. If you can do it within an hour or so, go to discussion, read the article (if there is one) about the problem. Look at different approaches to solve the problems and pros and cons of each solutions (runtime, space complexity etc.) If you encounter a new data structure or a new algorithm read up more about it. If you could not arrive to a solution within an hour, mark the problem and revisit it after one or two weeks.


Your goal is to be able to solve any LC medium problem under half an hour. Usually, a good benchmark would be, being able to solve average LC medium in fifteen to twenty minute.

Other platforms for practice
Study to learn

When athletes build their physique, they eat and practice. Same goes for building problem solving skills. Just practicing is not enough, you need to nourish your brain by providing proper reading materials. Seek to learn both actively and passively:


Engineers work through collaboration. So, naturally, preparing for interviews get better with collaboration.

Often doing these can be difficult for working engineers. To help with that, there are online platforms that can pair you up with random strangers. Pramp.com is one such platform. Besides practicing with friends, it can be beneficial to conduct mock interviews on Pramp with strangers. Besides, interviewing.io is good too.

Preparing for pair programming interviews

From my experience, being good at your work combined with being good at LC style problem solving helps you do good at pair programming interviews.

Even though this is called pair programming, it is still an interview where you are being judged. So, you are expected to come up with solutions and you are expected to do all of the coding.

Problems in pair programming interviews are generally of medium difficulty. Your pair may start with asking you to define a model or a class for some toy problem (often representing a real scenario). They will gradually add more scenarios. For each part of this session, you may keep adding more function definitions and come up with algorithms for those sub-problems. There are generally 3-4 parts and often a fifth bonus question.

Since, these problems are not hard, you are expected to code fluently, come up with solutions quickly and also be able to come up with test cases, edge cases and run tests.

Think of these 45-60 minute pair programming sessions as rapid prototyping sessions.

Preparing for screening rounds

Since these rounds are similar to on-site coding interviews, preparing for it is all the same. Just note that, if you found passing phone screening difficult, it is advisable to take way more preparation before going to on-sites.

2019 © nafSadh
Maintained on GitHub by nafSadh.
Please report issues and add suggestions here.