Meta Interview Prep
Preparing for an upcoming meta interview.
I'm going to use this post for resources and other useful things I want to remember for my upcoming interview.
7 steps to success in your coding interview:
- Do not jump straight into coding, take a few mins to understand the problem and ask any clarifying questions (but not too long!).
- Describe your solution to your interviewer and get their thoughts on your solution.
- Think about your algorithm(s) including the complexity and runtime. Ask the interviewer if it’s ok or if you should think about something more optimized. Then figure out your data structure and implement.
- Run through your code verbally with your interviewer. This is really important at this point. Does it really do what you think it does? Make sure to read what is there, not what you think is there.
- Test your code, put in an input to see what happens. We’re looking for you to find the bugs yourself and fix anything that comes up
- Restate the complexity. Is it the same, or different to your initial thinking based on what you have actually coded up? Make sure you’re thinking about both space and time
- Optimize. Proactively suggest ways to optimize to the interviewer and get their feedback to ensure what you’re trying to do is not overly complex and is correct then code it up.
Neetcode
I found this roadmap through a youtube video about doing Leetcode problems in a structured and better way. I'm using it to guide my study for the next few weeks.
03/11/2024 Update
I've been working through the roadmap and I've had two breakthroughs so far:
- I'm coming to terms with these sorts of problems as a sort of puzzle. I enjoy metal puzzles and those too have a certain trick that, once discovered, makes the puzzle trivial. Finding that trick is difficult, but becomes easier the more you do.
- I'm more confident in just brute-force solving the problem first. Originally, I'd get caught up thinking that the solution was obvious from the description, and I just needed to find that first. But these are designed to be difficult and I can't imagine the sort of person you would have to be to intuit the solution easily. People work on these algorithms for a long time in Universities and such. Expecting to intuit the most ideal solution is crazy.
My second breakthrough came when I saw this problem on Leetcode: 3Sum. I still got frustrated at it being such a strange and contrived problem, but I got over that fairly quickly and decided to just brute-force it right away. Below is that:
Now I couldn't think of a better way to ensure uniqueness than just to sort the 3 item array, Stringify it with JSON, put it in a Set, and then rebuild a solutions Array from the set. But it worked! And I did it in reasonable time. It didn't pass all tests in the alloted time, but it was a working solution. I allowed myself to peak at the solutions, and then implemented the better one:
Turns out, the twoSum problem from before was a good and time-efficient way to find all the possibilities needed. That helps me to understand how and why to break the problem into smaller parts. I hope this "sharpens that tool" for me going forward in to the harder problems.
03/12/2024 Update
Did a hard problem in about an hour and a half, though I thought through a brute force solution in maybe 20-25 minutes and could at least articulate it even if I didn't get the code going for the next hour or so. I tried to write my thoughts down as I was thinking in comments.
My first intuition was to go by each row and find the space water could sit in, then track that height and offset future calculations. I realized about halfway through the solution I'd be doing it in something like O(logN) time, but I persevered and got it working.
Since I got a working solution, I let myself look at the "right" solution from that neetcode guy. And ya know what? I feel like I wasn't far off from that one. I had seen "rows" in my head and so I went that way, but it was better to think in "columns." I like to believe that if I saw the "columns" first, I would have arrived at the more optimal solution.
Overall, I had an idea that I could articulate within the time window of the interview—and for a hard problem. That's some good progress for me.
03/13/2024 Update
Oh man I have to write about this one it was exactly like those metal puzzles. I was scratching my head for a while on it. I was hoping I could just keep a min
variable that I could update as I go with the smallest, but what about when the stack gets popped?? If the value that gets popped is the smallest value, then now I have to go back through everything to find the smallest one again.
Well I have to admit I cheated and checked the solutions. It was obvious though once I saw it, you just keep an array of the current minimum at the index (level?) of the stack alongside it, and you pop then both when you pop. Then, you just get the "top" of the min stack to get the current minimum. It reminded me of the one about finding the product of all numbers except the current index one, without dividing. Basically, you make another helper array (or two) that help you track of something.
03/15/2024 Update
Doing Binary Search now and just want to record the implementation I made. I never actually wrote one before so I will continue to write them each time I need it in the problems, but I wanna keep this for reference.
03/26/2024 Final Update
I had my interview and I was super nervous. I didn't perform very well and they said they wouldn't continue with me. I didn't have working code for my algorithms. I think I focused too much on explaining my solution and I got lost coding it up. I should probably practice doing both at once.. The second one I was totally lost it was some ordering of a tree. I'm sure it would've obvious if I had more experience working with trees.
So I will continue my practice until it's all second nature. They may not be very useful to my everyday coding, but they're good tools to have in my tool belt.