Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Sadly I've seen this kind of interviewing from lots of places; maybe it's a technique they teach in college or something.

    Interview questions like this are useless as they are not an accurate approximation of a real work scenario. I've frozen up at a whiteboard in an interview before, and then figured it out on the drive home.

    The best approach I've found is to do a send home quiz, and then ask them questions about the quiz to test understanding. The test also shows coding habits, which tells you a lot right there.

    Bonus: put some typos in the quiz that don't matter. Red flag for the people that get hung up on that.

  • Please no. No and home quizzes
  • I always give people a ton of leeway in an interview because nobody is at their best in that situation. I once got asked how to use window functions in SQL, with like 10 years of SQL experience using window functions and froze.

    I much prefer a pair programming interview or something where you can really see how they work through a problem they don’t necessarily have to finish or do perfectly.

  • > Bonus: put some typos in the quiz that don't matter. Red flag for the people that get hung up on that.

    I feel like after presenting a great solution to the stupid, cryptic, arbitrary interviewer games where you have to guess the rules on your only attempt at playing the game, you've added one at the last minute. What if one of the values is attention to detail?

  • An accurate approximation of a real work scenario would be sitting in a conference room for two hours while trying not to fidget or visibly look bored as co-workers make a mountain out of a molehill.
  • > Microsoft, of all places, might sound like a weird company to target in 2026.

    Heh, Microsoft might actually have been weird to target in 2015, especially in SV / startup circles, given that pg had declared it dead in 2007 (https://paulgraham.com/microsoft.html) I guess the Netherlands didn't get that particular memo.

    In 2026 Microsoft might actually be interesting again, given it's up there in the Mag 7 jockeying for position in the AI race. I know it's gonna be impossible to get an accurate vibe-check on HN, but I wonder what younger folks think of it today...

  • Not super young but I've felt like Microsoft has been really sloppy. Not like, AI sloppy, but like, not good at their jobs. They've always just seemed stupid to me. Windows feels so basic and primitive compared to other operating systems.
  • 2015 was one year after Satya Nadella became a CEO, and Microsoft looked pretty OK to me back then. Much better than a few years before that.
  • > especially in SV / startup circles

    Lol, I'm increasingly wary of whatever SV / startup circles prefer nowadays... The shitload of BS is ever forthcoming.

    by wofo
  • I really loved to work there. I knew alot of friends, toured the campus, and even worked with prior employees that had good experiences. Every product before 2015 was beautiful (i still miss my Zune).

    Then they broke me. I tried to give feedback on the products, interviewed, and really tried to reach out to them. Mostly ignored (except Outlook team, thanks ). The heavy marketing and tech debt within Windows is what did it for me. Rant over.... the interview felt like some trick questions at that time.

  • Halfway through my career, being on both sides of the table (interviewer and interviewee,) I've observed that a common interviewer mistake is to expect candidates to regurgitate facts; or be able to provide a memorized answer.

    In this case, the goal is to hire great engineers; and great engineers do not memorize solutions to every problem, nor can they come up intuitively with great solutions in a matter of minutes.

  • The problem is much bigger than that.

    Their goal is to find a "good fit", not to find a good engineer. That's why their software is so incredibly disfunctional: it's just a reflection of their workplace culture.

  • Life lesson learned for OP, when it comes to tech interviewing:

    (1) the riddles you already know you answer after some staged deliberation to pretend you are working it out from first principles using your genius brain (bonus points if you can work "first principles" into the conversation).

    (2) The riddles you don't know the answer to are the ones you say you already read in a book or online and repeat this until you get back to a (1)

  • I've seen candidates breeze through the basic version of a question they claim to never have seen when asked and then choke hard when the requirements are modified slightly. Honesty is the best policy, kids.
  • This was the real riddle all along.
  • My favourite interview question that I received was when I was asked to write code that would serialize/deserialize a binary tree and was told it was fine to use "any programming language".

    They received a crash course in the power of Haskell ADT and `deriving (Show, Read)`.

  • Well, did they hire you? Don’t leave us hanging!
  • Those kind of abstract CS interview questions never feel that helpful to me, but in all honesty, your story sounds like a job of the interview working.

    You were able to demonstrate that you were enthusiastic and knowledge about programming as a whole, which is probably more helpful than what they were originally trying to test for.

  • I'm so glad most of my technical interviews weren't about trying to remember things I once learned in college (15-20 years ago now) and never had to use in practice. It's been either practical "build a simplified webshop" tasks, or just an interview talking about my previous experiences. There was one where I had to do a fizzbuzz on a whiteboard but that was about it.
  • Counterpoint to many responses here - when I have interviewed people, it’s a really positive signal if the candidate says they have already seen a problem- the we can move onto something more interesting! Not solving does not mean failure either. As a candidate myself I always mention if I have seen similar problems, such as finding primes - real example, and I was hired on that loop at Microsoft!

    On the other hand, if I heard that a candidate had not mentioned they had the same question twice, or later let it be known they already knew the answer, I would lose a lot of trust in them.

    Be honest; it’s more likely you will be hired by honest people.

  • > As a candidate myself I always mention if I have seen similar problems, such as finding primes - real example, and I was hired on that loop at Microsoft!

    Normally I'm completely in favour of being honest about this (and would almost certainly do it myself), but in the case of something as common as "finding primes" I'd think it's OK to just do it. Does any interviewer really expect that the majority of candidates haven't look at basic prime finding and primality checking algorithms?

  • > Be honest; it’s more likely you will be hired by honest people.

    He applied for Microsoft.

  • I'd preface the solution and the key point before mentioning that I'd seen this problem before and then further ask if they still want me to code up the solution. This eliminates the case that I, the interviewee might be bluffing. Also they might just be interested to know if you can think on your feet by then adding a twist later. who knows not my call.

    It would be dumb if the next one they throw at me is one i've also seen or is ridiculously hard for an interview. Then i'd question the value of my honesty.

  • IMO the key thing is that interviews have a heavy component of randomness.

    The question your interviewer selects (both topic and difficulty), how the interview performs as far as presenting the question/giving hints, how the interviewer is feeling, any biases the interviewer might have, and so on.

    You can of course 'increase your surface area for luck' by studying the questions/topics a company tends to ask, being an interviewee who comes off as well qualified.

    But, if you get an interviewer who is in a bad mood, if your interview isn't competent or paying attention, etc. then you're just screwed.

    ---

    I say this because the OP was honest and failed; you were honest and were hired. There's no 'secret' to getting in. It is a combination of:

    1. Being a competent engineer (or student)

    2. Putting in the time to study, leetcode, practice, etc.

    3. Luck

  • > You have 12 marbles and a balance scale. One of the 12 marbles is inconsistent with the others, meaning it could be heavier or lighter than its peers of normal weight. You are allowed to use the balance scale exactly 3 times to identify which of the 12 marbles is irregular AND determine whether it is heavier or lighter than normal.

    I also got this riddle, in 2015. I couldn't solve it. Tbh, I think it's a terrible question. There isn't really a step-by-step problem solving process, but you just need to have a "leap" to realize you can weight the marbles in groups of 3. I also got rejected. It's crazy to get rejected from a one-question riddle like this

  • > Tbh, I think it's a terrible question.

    I think it's a terrible _interview_ question, partly due to it's "IQ test" nature, but mostly because it's a pretty hard problem and I really wouldn't expect someone to be able to just spew out a solution the first time they hear it.

    Of course, the process would be more about the interviewer observing your thought process, seeing how you develop a notation for solving this thing which you almost certainly don't have any pre-existing notation for, etc. I just really wouldn't expect much progress in the space of 5 to 10 minutes, although I am basing this on the "13 marbles" version of the problem.

  • > I also got this riddle, in 2015. I couldn't solve it. Tbh, I think it's a terrible question. There isn't really a step-by-step problem solving process, but you just need to have a "leap" to realize you can weight the marbles in groups of 3.

    It’s an information theory question similar to the “how far can you drop the egg before it breaks” puzzle. You don’t need a leap of intuition, just remember the right theorems and formulae from college.

    I probably would’ve failed the interview. At best I could write an algorithm that empirically arrives at the answer, which may or may not impress the interviewer enough to pass.

    Stuff like this is why I dropped out of coding competitions some time in high school. You can always brute force the easy version, then the next tiers drop numbers that cannot be solved unless you know (or can invent) that one weird maths trick.

  • Probably explains why Microsoft hasn't made a good product in...as long as I can remember. It's all shibboleths and gate-keeping.
  • Just don't ask brain teasers when you conduct an interview; I believe they give no valid signal at all, and I also believe Microsoft does not ask them anymore.

    The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided.

    When I conducted interviews for FAANG, I asked somewhat simpler coding questions, something around DFS and/or topological sorting (without calling it by name, of course), because those are thing which you might actually need to implement at work: people sometimes traverse JSONs, and people sometimes resolve dependencies. No one has ever told me "oh, I know this problem, it's DFS", because surely I know they know it. Just show me that you can write the code.