I was going through Alex's DSA course however I don't quite understand a few of the concepts he mentions. For example, Alex mentions that the difference between a yes and a strong yes is that a candidate asks more clarifying questions and edge cases. Aren't these pretty much the same thing? Shouldn't we clarify all of the edge cases in the beginning? Also, shouldn't we discuss alternative solutions before we start coding? Also, time/space complexity as well?
I don't think this is the case however because Alex says not to do the happy flow + edge cases all at once but first to code the happy flow -> account for edge cases (after).
I think what Alex is trying to mention from this course is when given a DSA problem we should do basic edge case clarification and verbalization of our solution to very quickly get a solution out and then try to come up with more edge cases/solutions to see if we missed anything (as this is how software is built in real life. I wanted to confirm this point. Sorry if this is a ramble.
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:
Hopefully this makes sense - Your question definitely isn't a ramble, and if you need more clarification, just respond to this 😊