Daily Coding Problem
There’s at least two things that one might conflate under the “Daily Coding Problem” rubric:
- An email list
- A book
They’re related, as the book is a byproduct of the success of the email list. Both are deficient, but for different reasons
I know what I’m talking about. I subscribed to the email list years ago. I’ve worked at least 26 binary tree problems, 17 linked list problems, and 50-odd less easily categorized problems.
The email list
The email list problems are unevenly and paradoxically rated, and even though they seem to be “for real” problems that people have reported getting in interviews, a lot of them are written badly, have multiple interpretations, or are otherwise flawed. The write-ups never allude to this.
In the context of an in-person interview, maybe even the poorly-written questions work, because the interviewer can see if and how a candidate asks for clarification. The wet garbage questions, the ones that upon inspection don’t have an answer, or have two examples that contradict each other, shouldn’t be included.
The book
The book shouldn’t suffer the same problems as the email list. Proof-reading, editing and additional context should remediate the deficiencies. Nevertheless, the book is little more than a reprinting of a small selection of the email list questions, along with one possible solution per question.
I’d quibble with the inclusion of some of these problems. They’re not the most interesting, or the best to learn from, or have a clever solution, or have a Solution Everyone Should Know. They seem to have been selected because the solution is small, and easy to fit in the book.
The discussions of the coding problems included in the book is limited to non-existent. It never mentions alternative solutions. It includes no context for any problem. The authors never decided what the book should be: a teaching vehicle, a computer science review, or elucidation of clever solutions.
There are two audiences for daily coding problems: developers looking to gain more knowledge (for fun or profit), and those who do interviews, managers or senior engineers. The book only addresses the developer audience. The book misses a large opportunity by completely ignoring what an interviewer might learn from a candidate’s answer to a problem. That’s a problem shared with books like Cracking the Coding Interview, but this book isn’t as in-depth on methods of solution