When have you solved a problem that didn’t involve coding?

Web Development
#1

Getting stuck in a coding interview is not game-over.

I repeat. If you find yourself seemingly unable to move forward on a coding problem, you have way more options at your disposal than you probably think.

You see, there’s lots of reasons engineers get stuck. Some are technical and some are psychological. Some are obvious and some are sneaky. And it’s so tempting to throw your hands in the air, assume the problem is beyond your skill-level, and panic. Don’t.

Here’s what you should do instead — so you might find yourself passing even when all hope seems lost.
Rewrite the question in your own language
There have been times when I’ve read an interview question repeatedly and remained completely baffled as to what it was asking. It’s as though the words just didn’t compute at all, and I sat there thinking I must be stupid.

Turns out, what really happened was a misalignment of expectations, which can manifest in a few different ways.

For example, if you’re a front-end developer, you might expect to see problems that look something like those you’d see in actual front-end work. But instead, you get something like this:

Write a function that, given n, returns the nth Fibonacci number.
If you have a strong math background, this might seem like child’s play. But if you just graduated from a mobile bootcamp, you might not even remember what a Fibonacci number is. And if you don’t remember (or don’t really get math speak) the question itself doesn’t even really make all that much sense.

If there’s something in it you don’t understand, ask your interviewer. It’s ok to ask “to be refreshed” about the “precise definition” of a Fibonacci number. It’s ok to ask the interviewer to rephrase the question a different way to help you understand what it’s asking. Sure, some interviewers might be judgmental, but that’s not something you can control. And even if they are, it’s better to get clarity quick and make progress on the problem rather than burn time and make little to know progress.

Likewise, you might run into problems that seem totally and utterly pointless in real life, which might make you question whether what’s being asked is seriously being asked. Once, I was asked to implement a word processor in a terminal. As someone who does a lot of iOS front-end work, I was pretty baffled by this question. My first thought was that it was way more complex than what was actually being asked because I could never imagine a word processor anyone would ever want to use being implemented in a terminal. My disbelief actually prevented me from accepting the problem for what it was.

The point is, when you encounter a problem that baffles you to this degree, try as best as you can to accept it for face value. If you’re unclear about what’s being asked, start a discussion with your interviewer and don’t be afraid to confirm the details and ask probing questions. Interview questions are frequently contrived, because they’re designed for interviews. It’s not that the questions are inherently bad, they’re just unnaturally small in scope and definitionally not practical in the way real problems are. Talking with your interviewer about the details will help you build a picture of what they intend for you to do much faster than staring at it on your own trying to guess.