The post is a short retrospective on a failed Microsoft interview. The author had prepared for the company’s old puzzle-heavy style, got a well-known balance-scale marble riddle, said he had seen it before, asked for a different problem, and was later rejected with a generic form letter. The piece is really about a common candidate dilemma: do you answer the question in front of you, even if it is artificial, or do you try to be maximally honest and risk violating some unspoken interview norm.
Most people reading it took the rejection as another example of how badly software interviews drift from real work. Brainteasers, whiteboard puzzles, and coding questions that hinge on one hidden trick were treated as weak signals for day-to-day engineering. Several people who had interviewed at Microsoft, Google, Apple,
AWS, IBM, Facebook, and elsewhere said the same pattern keeps showing up under different branding. The complaint was not just that these questions are unpleasant. It was that they reward rehearsal, favor candidates who have seen the trick before, and collapse too much of the decision onto interviewer taste and luck.
The sharper point was that the process often tests obedience to a game, not engineering judgment. People kept coming back to the fact that candidates rarely know the real rules. They do not know whether honesty is valued, whether clarifying questions are welcome, whether a practical answer will be rewarded, or whether the interviewer just wants the canonical trick. Even at companies that supposedly banned brainteasers years ago, commenters said individual interviewers still use them, which makes the experience feel like a lottery run through local customs rather than a consistent hiring system.
There was still some nuance. A few people argued that the interview may have been working as intended. If a company wants someone who will play along with contrived tasks, sell aggressively, or operate comfortably inside a rigid culture, then rejecting someone who pushes back is a form of filtering. Others defended certain open-ended or estimation questions when they map to real work, especially large-scale capacity planning or basic graph traversal. The best version of that view was not "puzzles are good". It was that a strong interviewer can use an imperfect question to see how a candidate structures a problem, accepts hints, and communicates under pressure.
Where the comments landed was less about Microsoft specifically and more about interview design. Simple coding exercises tied to actual work, pair programming, deep discussion of past projects, and clearly scoped system design came off as far more credible than riddles or gotchas. The consensus was blunt: interview difficulty and job difficulty are barely related, and a sloppy loop can tell you as much about a company’s culture as about a candidate’s skills.
ochagavia.nl
How Would You Move Mount Fuji?: Microsoft's Cult of the Puzzle