Consider a question like this:
You need to add two numbers and get a sum. But, importantly, the digits of those numbers are stored in arrays, and they’re backwards.
The return value also needs to be in a backwards array.
In production code, if a problem like this came up, I’d ask “How the hell did we get here?” and try to backtrack and figure out what insanity caused this, because it’s just not right.
But, if this code were truly needed, I’d write code the way I normally would, with clarity in mind first.
And then, if my tools told me it was too inefficient with time or space, I’d figure out a more efficient version.
These questions, then, are able to test what you might come up with when you’re in that position.
The thing is, what I would most want to know is how people write code for the 99% of time when they’re not in that position. That’s not being tested here.
It is true that these sorts of problems don’t reflect the majority of tasks a software engineer faces in their work, and the solutions they expect are even less realistic compared to the average programmer’s workflow. Coincidentally, co-hosts of the Accidental Tech Podcast talked about this very topic in the very recent episode.
Still, it’s good to be prepared; and the problems do sometimes tend to get fun and are well worth the time spent thinking about them.
As a quarantine pastime, I started subscribing to Daily Coding Problem which does what it says on the box. And if there’s any reality replicated in these challenges, it’s that the problems were actually asked by big companies like Apple, Amazon, Google, etc. I solved the problems the first two weeks but now I’m just guilty-marking them as read.
And of course you can’t forget the Perl Weekly Challenge which I’ve been participating in for a while now.
Follow-up: Not mine — his. Again, he’s telling the truth. Anyone who argues is just closing their eyes to reality.