Clarifications on DSA course (clarifying questions vs edge cases vs alternative approaches))

Great questions!

...that a candidate asks more clarifying questions and edge cases. Aren't these pretty much the same thing?

They are deeply connected, but not the same thing. Clarifying questions tee up your ability to find edge cases. For example, take this clarifying question:

What is the type of the input parameters? Int or Float?

You need to ask this question as it will literally affect your code, and the answer will help you come up with edge cases after the solution is written. However, I don't think you would ask all the specific follow-up questions afterwards of whether ints can be huge (INT_MAX), you can get a bunch of duplicates, etc. If you do that, you would be directly and fully merging the clarifying questions and the edge cases together, and you would spend like 10-15 minutes just asking questions before coding (i.e. way too long). Something else to keep in mind is you need to be careful on the follow-up; the failure mode is that you spend 5-10 minutes discussing a single tricky edge case instead of actually writing code.

Another example of a good clarifying question to ask for the k-closest points example I worked through is the tie-break one. If the interviewer wants some strange algorithm, that will directly affect your implementation in a major way, so you need to catch it ASAP. Looking back at the course, I do think I could have phrased the clarifying questions section better as a lot of the questions are sort of sub-questions that can be merged together into 1 grand question. For example, with the tiebreak question, you can quickly iterate through the options to show how forward thinking you are but still ask it in 1 big question.

In a nutshell, you want to ask the main questions that will affect the core implementation engine of your code. Anything that can be handled with an if-statement (e.g. null input) isn't that important.

The overall process should be:

1. Ask sharp clarifying questions to mold the code and set up the foundation to dig deep into edge cases later
2. Write clean code that handles the happy flow very well. If you can account for edge cases proactively by writing good code, do it. Otherwise, don't it (i.e. you need to write some super narrow if-statement)
3. Talk about the solution, which will include edge cases if the interviewer is pushing you hard as many FAANG interviewers do. If they force you to account for an edge case in code, do it

Hopefully this makes sense - Your question definitely isn't a ramble, and if you need more clarification, just respond to this 😊