Given how great Java/C#/JS debuggers are, one could hope that every new language will ship with a working debugger, that it would be table stakes.

But there’s a whole generation of working programmers that started their careers in Go and were told debuggers are lame all along, so it’s hard to blame them for not using one.

It’s not that I enjoy stepping through code line by line, I rely on a debugger to verify if my assumptions about “starting conditions” of a certain piece of code are correct and, if so, at which point my understanding of how things should be no longer reflect reality.

This can all be done with printf, if you knew ahead of time what you want to print. But most of the time I don’t, the whole point is that I do interactive exploration of the program state (“evaluate expression” is the main feature of a good debugger). When I find a problem I dig deeper, which is a lot faster within a debugger session than any recompilation loop I’ve ever seen (even in Go).

In similar spirit I play with SQL queries when given a data set that I need to extract something from.

[1] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/run-catc...

[1] https://arxiv.org/abs/1902.05178

I think this is the biggest gap in the Haskell ecosystem right now. Every time I try to write something in Haskell, I remember I cannot "talk to my program" easily and just give up.

From my own experience - people that do well in such interviews are good generalists. On their own they will start discussing performance improvements and ways to parallelize the solution, it's a pleasure to have such an interview.

It's about enjoying problem solving and willing to keep your brain fit. It has nothing to do with memorizing solutions to some existing set of problems.