And what story should you tell when someone comes at you with whiteboard coding challenge?
I have a colleague who, every coding challenge, immediately started by writing a bunch of tests and asking questions around the edge cases so that he could clarify the exact specs of the task he was being asked to perform. Any interviewer who didn't roll with that was a sign to him that there probably wasn't an engineering maturity culture fit and helped eliminate a lot of companies.
The story he was trying to tell was that he was an engineer that considered understanding the problem to be a much more important task than understanding the solution and he managed to tell it via the way he approached whiteboard coding.
Different problems test for different skills. Perhaps that colleague just misunderstood what he was being tested on.
Linus Torvalds had this to say: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Not every coding challenge is about software design skills. A large number is about the programmer's potential to code to DS & A. It's assumed that design, philosophy and other moot software skills can be picked up, or that internal coding standards and code reviews somewhat mitigate a lack in that area.
But I can very well see a mature engineer being annoyed by someone incessantly asking to confirm small details on a problem where they could make their own decision about terminal and exceptional conditions. Even if they have to explain them later. After you probe your interviewer once or twice on edge cases, you're usually told to assume the simplest situation. This should nudge you to what you're actually being tested on. No need to beat around the bushes, just solve the problem.
Also, to gain insight into the culture of an organization, don't just assume or infer things, like that colleague did. Ask proper questions. Express that working in an organization with a mature engineering culture is a concern of yours. Ask about code review, software development philosophy, etc. You've shown yours, ask them to show theirs.
It makes the point that while those kind of coding challenges could be a useful filter or signal, it also stresses that I'm looking for a senior developer role and that perhaps time would be better spent assessing that part of my skill-set.
I also had an interview where I joked, "You're not going to ask me to define SOLID are you?".
The interviewer sheepishly replied that they only ask that if the person puts it on their CV, before scrambling for a different question to ask.
I would thank you for that and I would ask you to kindly do the code challenge.
Anyway, aside from a few bad faith individuals who try to make them seem smarter than you, the interviewers aren't going to fail you for small mistakes. They are more interested in your thought process, how you approach the problem and how fast. They even might give you some hints or guide you slightly if you are in trouble.
Talking through what the expectations are, what you're thinking and what you're doing help cover points where you may make a mistake and vitally where there's a disconnect with your understanding and theirs.
I've had paper problems to do that to solve the literal problem in front of me would be to write some very short code. But the problem looks like a shrunken version of a bigger system, and so explaining this shows I'm not just over engineering this toy problem I'm showing I understand (this was an early position) classes and inheritance and how to manage that.
Are you asking how I'd build systems to do this kind of thing? Are you asking what I'd do if the boss comes over and says they need this one off thing done asap?
You want to be seen as someone they could actually work with on something.