"Funny that you ask me about this problem! One time, my brother, who is now out of state, had a similar problem and came to me. He said: "I have these numbers, and every time theyre a multiple of 3 or 5..."

The story of the problem being solved.

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.

Exactly! Coding challenges are not about miraculously finding the right solution, which is boring (and extremely suspect). They are about describing a path from the problem to the solution, and dangers and pits along the way.

Given that some companies now have candidates do them on fully automated web pages, it's pretty clear they are often just about getting the right solution, and nothing else.

In that case they are simply trying to filter out the pool of candidates. But there will be a step downstream that involves storytelling.

All job interview steps are "simply trying to filter out the pool of candidates". If it is the filter that removes the most people, that actually makes it the most important part of the interview process.

I tell them "Hey, I've used this question before when I'm interviewing developers" (often not true, but what's a little white lie), then explain what I'm looking for in a developer when asking those kind of questions.

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 tell them "Hey, I've used this question before when I'm interviewing developers" (often not true, but what's a little white lie), then explain what I'm looking for in a developer when asking those kind of questions.

I would thank you for that and I would ask you to kindly do the code challenge.

Story telling is not about code challenges. When it comes to code challenges, you can either do it or refuse the job.

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.

People on both sides of the table have the common misconception that coding challenges are about solving the problem. They're not, coding challenges are there for me to gain an insight into how you think through problems and the questions you ask are 100x more important to me than the code you write.

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.

Tell that to my Google interviewer.

> 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.

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.

Ye. Story telling is important for the non-technical part of interviews (although some technical interview do benefit from some story telling). It won't save you from having to cram leetcode for days.

"Long ago, on Svalbard, when you were a young witch of forty-three, your mother took your unscarred wrists in her hands, and spok:[...]"

https://aphyr.com/posts/341-hexing-the-technical-interview