This is how I figure out if one of my students is ready for their interview.
Gauging how prepared someone is for a big-tech interview is a tricky thing to do. Interviewers have almost complete control of what question they ask, meaning you can get something random that has never been asked before, making preparation seem impossible.
The good news is that most interviewers behave within a certain bounds. This means you can prepare and have a 90%+ chance of being ready for it. So while nothing is 100%, I ask these specific questions to the Hackpack community to see if they are 90%+ ready for their big tech interviews.
Questions to ask yourself
- From 1-10, how confident are you on the different DSA topics?
- For any above an 8, have you tried teaching this concept to anyone else? How confident were you in your class?
- Have you conducted Mock interviews? How many? Do you find yourself getting nervous? Have you been tracking your results?
- What topics give you extra trouble?
- Do you have a structure to how you approach interviews?
- Have you done a mock behavioral interview with someone? From 1-10, How confident are you when it comes to speaking about your experience?
- How many days a week are you solving a programming interview problem?
- (Mid Level and above) From 1-10, How confident are you in System Design?
- (Mid-level and above) From 1-10, Would you consider yourself an expert in the language you plan to interview in?
- How long do you have before your interview?
Questions I do NOT ask
- How many leetcode problems have you solved?
- How many languages do you know?
When you answer these questions, it becomes clear where your weak points are and where you should spend your time to improve your odds during the interview. If your answers to all of these questions are very positive, then you are more prepared than the vast majority of people that show up to these interviews. If you are very confident in your progress so far, I encourage you to teach others to help you cement your own understanding.
Next I’ll breakdown why I ask each of the above questions.
From 1-10, how confident are you on the different DSA topics?
Fill out the spreadsheet on your own(Data structures and Algorithms) and see where you land with different topics.
Rating your own confidence from 1-10 follows predictable patterns and as a result is the best way I’ve found to measure someone’s readiness. The goal should be to get everything to a 9 or a 10.
An outline of how it usually goes
- Normally, people start at a 0 for topics they’ve never heard of.
- After reading some basic materials, they jump their rating to a 4 or 5.
- After getting a few leetcode style questions correct, they bump themselves up to a 7, 8 or 9.
At this point, you have a solid grasp of the concept, you can solve some medium difficulty problems and you are feeling pretty good. It’s important to challenge yourself at this point to make sure you really understand the fundamentals of a topic. The fastest way to do this is to teach others that concept.
When you can confidently teach others how to handle a difficult problem in a specific topic, you can truly put yourself at a 9 or 10. At this point, I would then mark a specific topic as Ready and move on to the next topic.
For any above an 8, have you tried teaching this concept to anyone else? How confident were you in your class?
The best way to confirm you are rock solid in a topic is to teach someone else how to handle a difficult problem in that topic area. I’ll write another article soon diving into how to effectively teach a class to others.
After teaching your first class, your confidence level will tend to drop a bit, because you realize there were little things you didn’t fully understand. This happens because teaching someone else will force you to identify all of the things you normally skipped over in your head. While teaching your class, you should write down anything where you aren’t confident, and address them promptly afterwards. This has the added benefit of helping you learn how to think out loud and bring others along with your thinking.
Have you conducted Mock interviews? How many? Do you find yourself getting nervous? Have you been tracking your results?
I’ve summed up my thoughts on the topic here. As a recap, getting comfortable with the nerves introduced during a mock interview is very important. I’ve know people who clearly knew the material, but had trouble thinking on the fly and articulating their ideas as a result of their nerves.
In addition, leetcode doesn’t give you interview problems in the same format you will receive them during the actual interview. Often interviewers intentionally leave key information out, to see if you will ask. They also tend to not give you examples or bounds on the problem. You need to get used to this ambiguity.
Handling different interviewer types is important as well. Interviewers have different personalities and learning how to handle someone who is clearly having a bad day is a skill in itself.
What topics give you extra trouble?
This list should be empty by the time of your interview. If Dynamic Programming is giving you trouble, you need to identify why it’s giving you trouble. Consider this list a roadmap of what you need to spend extra time on preparing. You aren’t ready until this list is empty.
Do you have a structure to how you approach interviews?
You should have a structure to how you approach your interviews. Here is how I broke down my interviews, I encourage you to adopt it. This is important so that you can reduce the amount of variables, buy yourself time to come up with an intelligent solution, and make sure you are hitting all of the points the interviewer is grading you on.
Have you done a mock behavioral interview with someone? How confident are you when it comes to speaking about your experience?
Most people never practice doing a behavioral mock interview. It is such an easy thing to do, one competent mock behavioral interview is really all you need to give you a strong basis for the interview.
You should be very confident speaking about your experiences in a way that can help you shine.
How many days a week are you solving a programming interview problem?
While Leetcode isn’t the only thing you should be using, there is no substitute for solving problems. Here is a simple technique to better use leetcode. You should be doing at least one problem every day. Quality over quantity, its better to spend 4 hours dissecting a problem and fully understanding it over “solving” 5 problems and just quickly reading their solutions.
(Mid Level and above) How confident are you in System Design? 1-10?
You should be at a 9 or 10 here. I’ll write an article soon on advice for system design prep! Stay tuned.
(Mid-level and above) Would you consider yourself an expert in the language you plan to interview in? (1-10)
For mid-level+ you should be very well versed in how your language works. There is an increased chance that you’ll be asked about some advanced language functionality, especially around concurrency. If you have the time, I encourage you to learn one new fact about your language every day and record them in a running list, this way it’s never overwhelming. After a month of learning a new fact everyday you’ll be surprised how far you’ll progress.
How long do you have before your interview?
This is important because depending on how much time you have, I’ll recommend different ways to prepare. It’s all about maximizing your odds, and the advice varies based on how much time you have. There is a lot to add on this topic so I’ll write another article on it soon.
Questions I never ask
How many leetcode problems have you solved?
I’ve known people who have “solved” 800+ leetcode problems who still fail the interview. Why? Because just grinding leetcode isn’t a comprehensive interview prep study plan. You need to nail the fundamentals, study the techniques, learn to articulate your thoughts and handle the nerves in addition to practicing problems.
Leetcode is important, but it isn’t a substitute for the other aspects.
How many languages do you know?
The only language that matters is the language you plan to interview in. Focus all of your efforts becoming an expert in it and stop spreading yourself thin. No one cares that you took an intro course in Ruby