Brute-forcing my algorithmic ignorance

I am quite passionate about algos, do lots of katas on codewars for fun, and done plenty of leetcodes.

Then I had a technical interview when I was asked to implement a simple algo for the tris game (aka tic tac toe) and my mind was completely blurry.

I was tired, i'm in eu and this was for a San Francisco startup interviewing me at their lunch time, very late in Italy.

And generally don't like to be interviewed/tasked.

Of course the solution is beyond simple, but I struggled even at brute forcing it.

I can easily do these kind of exercises (and much harder ones obviously) for fun, but not when interviewed.

I struggled with the same thing in University. I graduated with 104/110 even though I was consistently among the most prepared, and I learned to learn, not to pass exams (plenty of stellar performers didn't remember anything few weeks after exams).

Once I asked a professor why did he grade me 27/30 even though I spent one hour answering with details on everything, including the hardest questions.

"Because you never appear convinced when you answer".

I get nervous, I don't like to prove my knowledge this way. I rethink constantly what I'm saying, or even how I sound.

I forget how to type braces or back ticks.

I did not have any issues when not interviewed, or in written exams, or during my research period when I published 3 papers that have been highly cited.

But I am just not a fan of these types of interviews they tell absolutely nothing about the candidate.

You interview me and you'll have the very wrong impression if you ask me to live code or white board.

Meanwhile I've seen leetcode black belts spend most of their time logged on Tekken 7 on discord, consistently creating work and providing negative value while somehow always selling their high skills.

I have found much more value in seeing personal projects, and OSS contributions.

Never asked a single of these bs questions and never failed at hiring anyone. Not once.

I have never seen correlation.

The most important thing about a candidate is whether he's gonna be professional and hard working.

Technical interviews tell me nothing about it.

Of course I can see large companies that have a high number of candidates relative to positions needing such methods, they can afford false negatives.

But outside those cases personal projects and OSS contributions say much more.

I'm always interested in write-ups when folks try new attacks on self-study.

I will also admit that this part hurt my heart to read (vicarious embarrassment):

> the recruiter mentioned I needed to pay more attention to code debuggability (whatever this means - I assume that under the corpo-language, they mean that I wrote invalid code)

You have to build a house but dont use concrete mixers you must mix by hand to really see if you know the physics of concrete

I completely understand why that line caused vicarious embarrassment. Looking back, I realize my brain was(is) operating on a completely different definition of that word based on my daily constraints. I plan to write more about this in Part Two, but at that point in time, I wasn't even aware of this alternative understanding of the term.

In telco, when a remote node crashes at a client's site, I often only have access to a heavily restricted subset of logs, and the debugging communication loop via email can take days to understand "what happens". Because of that, I write defensive, strictly encapsulated code, and I think in terms of domain-specific states and objects that can be explicitly tracked from an external PoV.

Similarly, during game jams, "debuggable and maintainable" means to me that the code is modular enough that I can completely rip out and rewrite a core mechanic in the final 3 hours just because the game design suddenly changed.

My habit of writing code optimized for remote logs and sudden architectural shifts actually became my biggest enemy under the algorthimic interview (or 45-minute LeetCode) constraint. It makes the core algorithmic state less clear and hides algorithmic mistakes under layers of defensive "if" statements (where I would normally drop a debug log).

I am simply used to not trusting the inputs, whereas in algorithmic problems, the whole point is to exploit constraints that you need to be absolutely sure about.

So the "if" statements that usually increase "debuggability" in telco or during game jams are the exact opposite of the "debuggability" term used in algorithmic thinking.

Thanks for naming this issue so clearly - it is a very valid reality check.