Moving From Easy to Medium Code Problems
Technical Preparation for the Busy Interviewee
How to Make Leetcode Your Best Friend
I spent the last months doing 'the tech interview grind', solving dozens of questions, and studying for those big tech interviews, ending with some great offers - my 5 sprints plan for the job hunt is here.
I present a handful of tips to maximize the knowledge and experience gained while minimizing the time spent.
While I talk about Leetcode, you can implement these concepts into every study platform there is. And now - let's start!
Where to start?
Start with the classic CTCI book, Youtube videos, or Leetcodes Study lists. They cover some basic info and the common questions that utilize these data structures and dive into subjects only if you need to study them again.
Start with relevant questions
After getting some background, I enjoyed working on "Top Interview Question — Easy Collection". It has a few easy problems on each subject and is an excellent introduction to coding questions.
The best part is that you start working on recurring questions right away, and you don't waste time finding them. As you can see in the pic below, I did 90% of this collection, and by the time I finished, I had the confidence to move to medium-level questions.
Keep solving only relevant questions
Leetcode premium provides frequently asked questions for big companies. While I was interviewed, I got some very similar ones — it happened at my interview at Dropbox and again at Amazon.
Leetcode has more questions than you can solve in a lifetime, the questions in the top frequent collections are similar to the real interview questions and will give you the best preparation value.
Maximize the gain of your time investment
Instead of memorizing solutions, learn concepts
If you take only one tip, this should be the one: learn the repeating kinds of problem and their solutions — I call them patterns, you can find some here, and the top 10 common concepts are in this video.
The basic 'must know' are - BFS, DFS, binary search, and using hash as cache.
Limit the time spent on a single question
When I just started, I wouldn't let go of questions - I spent 2 hours trying to develop the algorithms myself.
The interviews don't test you on inventing brand new algorithms but utilizing familiar concepts, so learning and implementing ideas is the best value of your time.
To conclude, if you have no clue what to do next - move on to the solution.
I limited the solving time to 20 minutes for easy, 40 minutes for medium questions, unlocking hints (if they existed) every 10 minutes.
The following 20 minutes are for extra learning the solution.
Extra learning for questions I didn't solve
In the next 20 minutes, I would go over the comment section or official solution, look for hints and explanations before peeking at the code, and implement the new idea myself.
Sometimes I found it difficult to rewrite the solution I just saw, this made me realize I didn't truly understand the details, and I struggled to figure them out again.
After writing down a piece of code and debugging all the edge cases to make it run - you will understand it much better and remember and know how to use it.
Extra learning even if you did solve the question
Go over the solutions and compare your code to theirs - can you learn new syntax? Write it cleaner? Do you have over-complex code related to edge cases that you can simplify?
You may find out there are a few ways to solve a question, some optimize run time, and some space, so you are likely to learn something new from the solution.
Another tip here is to dive into similar questions — they may be more challenging or use completely different techniques. Solving a series of related questions will allow you to learn the slight hints where two similar subjects may differ very much in solution.
Have a weekly plan
In a single session of problems, practice questions around the same concept, algorithm, or data structures, to master this subject.
During a week, practice different topics and levels, and spend at least some time solving "random" questions.
Knowing the difficulty, tags, or subjects gives you clues to solve the question. Practice without this helps to simulate an actual interview.
I kept a list of questions to return to, unfamiliar concepts and bits of code I did not understand, and every week I went back to them, I found myself knowing the material better and writing better code.
Don't dwell on hard questions
If the question is hard with low acceptance rates or if the official solution has lots of code or too many thinking steps, it's unlikely to figure it out within the 45 minutes interview - these are the time consumers you want to avoid. So instead, go briefly over the solution and keep practicing questions that allow you to improve your thinking instead of discouraging you.
Programming Language tips
In big companies' interviews, you may write using a basic IDE, allowing some syntax highlighting but not autocomplete, and sometimes you won't be allowed to compile/run the code.
Consider languages you are familiar with and those with a simpler syntax. For example, there is a clear advantage to Python over C.
A pro tip for quickly improving your writing is to disable the Autocomplete feature and get used to the actual interview environment. You can do this in the IDE window near the language tab.
How and why write pretty code?
Your interview code will be read by testers offline after the interview is done. They haven't met you in person, and your code is the only impression you can make on them. On top of producing the correct outputs, Interviewers evaluate your coding ability, so it should be clean and easy to read.
Look for the "Discussion" section, where somebody has already uploaded a solution in every programming language.
It was my primary source of learning interview syntax and getting my writing tied and clean.
My last tip about programming languages is that some syntaxes are standard in interviews, and you will look like a pro if you know them well.
You can search for "advanced python topic "or "interviewing in C++" and put time into this material.
I also encountered good tips in the discussion section about python packages used in interviews, such as Collections and bisect.
How to keep yourself motivated?
- Do some questions that you enjoy solving.
- Take on leetcode daily challenge, where many others will engage in discussions.
- Go back to that list you keep of unsolvable questions and witness yourself getting better over time.
- Share the experience - in every given moment, others are studying the same material, joining social networks, and sharing their thoughts.
- I enjoyed following Leetcodes Study plans, where you solve questions daily. The sense of progression motivated me.
What is not covered by Leetcode?
Leetcode only cares about correct outputs to given inputs, but the interviewer also tests you on technical communication, your thought process, code quality, and debugging your code.
Answer structure
I hope you are familiar with this great sheet that describes the answer structure you should follow.
At first, keep it in sight and follow the steps while solving questions step by step, until it becomes second nature until you are stuck and your next thought is 'let's look for Bottleneck in the brute force solution, and maybe brainstorm some data structures".
Technical Communication
Try doing mocks, live interviews using platforms like Pramp, or even vocalize your thought process while leetcoding, but get used to speaking while solving the questions and vocalizing your thought because the interviewer will require it.
Big O notation
Sometimes the question has a test case that will fail an O(n^2) solution and pass an O(log(n)), but more often than not — leetcode doesn't consider runtime aspects. The interview requires analyzing your code and explaining the time and space complexity. Sometimes there is a focus on trade-offs between time and space you can make or why there can't be a more efficient solution.
To practice this, you can check the discussion section, sometimes there are discussions over code efficiency with detailed thoughts, or do some Youtube exercises on big O.
Testing
Leetcodes suggest default examples and inputs, sparing you the trouble of coming up with simple or interesting edge cases yourself. In the interview, you will need to come up with those, and in the typical case, your code isn't perfect - debug it and run an example to find your bug. I suggest avoiding the temptation of just submitting "looks good" answers and practicing these aspects before submitting a final version.
Conclusion and a bonus tip
Have you stayed this long? Thank you!
This bonus tip kept me away from migraines, as leetcode doesn't have a built-in dark mode yet. However, HERE is a great cross-browser extension that worked very well with leetcode.
I hope I have offered some insights, and I wish you good luck in your journey.
Relevant posts - Intro to System Design Interviews and Sprint Plan for the Busy Interviewee.
Source: https://towardsdatascience.com/technical-preparation-for-the-busy-interviewee-9082830550e5
0 Response to "Moving From Easy to Medium Code Problems"
Post a Comment