Counting Black Holes with Quadtree Binary Search

Feedback about Distinguished Dromedary (the interviewee)

Advance this person to the next round?

Yes

Strengths and what went well: - Communication: - At all time I could understand your thought process. You did very well in explaining the different approaches for a solution as well as pros and cons. You did a god job in writing your thinking on the IDE for the interviewer to see as well as going over the examples, edge cases, etc... - You received my feedback candidly and applied it right away, as well as asking clarifying questions. This signal is very important, since the interviewer is looking for a signal that will indicate if they would like to work with the candidate in a collaborative environment. - Problem Solving - You did an excellent progression from proposing a brute force solution to an optimized binary search. - Great job in figuring out the particular quad-binary search variant as well as the formula for dividing the coordinates in squares - You proactively identified the base cases of the recursive solution and how to go about counting the black holes - Coding - Code was syntactically correct, extensible and well formatted. - You dry runned the solution with example inputs to demonstrate it works and has no bugs Areas of Improvement: - Communication: Write down the approach of every proposed solution in a concise way, so it stays as a record of what you've done so far and you can easily go back to. For example you could have written down in pseudocode the structure of the recursive solution to provide the interviewer one more option of visualizing your proposal - Problem solving: - Time complexity was correct but you struggled a bit with space. Like I mentioned, you can "time box" figuring this out and write down your thoughts. Then mention to interviewer if it is ok to move on to another thing and look at it later. I recommend you review problems that have this complex recursive branching and their time and space complexity - Very important: If you have clarifying questions, take a second to go back to the problem!! We are assuming that candidates are thorough and go over docs. Some of the questions you had where in the problem statement (output as coordinates vs count) - Coding: - Don't wait for interviewer to ask you to dry run and verify. You have to proactively mention it: "Ok, I am done coding. Should we go ahead and dry run it to verify it works?". - Like I mentioned, I recommend adding a validation step to discard bad inputs (you could raise exception or return a null value, just make sure to justify your choice) - Add some minimal comments to the code. Advise for Future interviews (some of this we covered): You can find many examples and patterns in a lot of books and online practice platforms. Candidates typically practice hundreds of problems during interview prep. They work on a lot of topics and increasing levels of difficulty. Inteviewing.io has some excellent guides and blogposts. - Track practice on a spreadsheet and identify what you need to get better at. Always go beyond your comfort zone. - Work on timing as part of your practice. Set some milestones and take note of the timestamp for reaching each one. Then keep a record for each problem worked on so you can gauge which part you need to work on more. Companies will allocate a different amount of time, where some will allow 30-45 mins for a med/hard problem while other ones will expect 2 easy / med problems in 40 mins (18-20 mins each!) - Suggested milestones: 3 mins intro 10 - 15 minutes problem solving and arrive at an optimal algorithm 5 - 10 minutes code 5 minutes dry run and debug 5-7 minutes implement working code with test cases if required that can be run on ide - Be pro-active in asking clarifying questions about variables, edge cases, expected outcomes, etc... Be proactive with explaining time complexity and dry running after coding. - Ensure that explanation of time and space complexity are always there and fully fleshed out. If there are 2 portions that do O(n) then don't just put O(n) but rather T = O(n) + O(n) ~= O(n) . Same with space. - For certain problems consider explaining Brute force approach (which you did) and going down an optimization ladder (example approach 1 O(n^2) approach 2 O(nLogn) etc...) so you show a signal of weighing different approached for the same problem - If you are stuck, find some good wording to get a hint from the interviewer. Don't just say "I am stuck, give me a hint". But rather something like "I am thinking of doing this approach where a b and c go this way. But I am having trouble with x, y z. How do you think we could go about this? " . It shows a strong signal for collaboration. - Be proactive with dry running the code (do it always!) . Start with small cases, edge cases and growing to more complex ones. Go line by line, demonstrating that your code works as expected. I guarantee you are going to find bugs. Showing interviewer you identify problems with your solution and you correct them shows a very strong signal for ownership. This is what interviewers are expecting. - Practice producing working solutions with test cases that can be run in the code environment and produce the expected output. Some companies will be expecting that. Keep practicing and good luck with everything! Thank you.

Feedback about Ferocious Lightning (the interviewer)

Would you want to work with this person?

Yes

Interviewer was really helpful in delivering feedback and making sure I got the most value I could from the interview. Very helpful in jumping in when I needed spend more time but also letting me work through the problem when I was on the right track.