As I have grown older, I have realized dead-honesty is a false ideal to live by, especially when it comes to being rewarded in the capitalistic world. I know someone who reached executive level position in a big startup and all of his career progress can be traced back to lying on his resume about a NASA internship he never got, which he conveniently purged later from everywhere.
I wouldn’t go that far, but I think it’s perfectly fine to reverse-engineer the interview game and reap the rewards. There’s no reason to feel guilty 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.
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.
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.
> 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
> 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.
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.
A classically terrible interview question. Solving riddles in realtime is almost never a real job skill. _Maybe_ in an incident, but you’d be relying on tooling and experience, not an intern.
Same with leetcode at startups. It makes no sense. You’re almost certainly not going to do algorithms work. It’s only relevant if you’re looking for people willing to grind bullshit, which is certainly some jobs, but, again, you’re almost never doing this under arbitrary time pressure with someone watching over your shoulder judging and not helping.
My advice: if you encounter this, don’t work there. If a company doesn’t value testing relevant skills for candidates, don’t expect leadership to be strong critical thinkers once you get there.
The speed with which I can remember some obscure AIX partitioning-related fact during an incident, for example, is orders of magnitude faster than the speed with which I would figure out which of 12 marbles is slightly heavier than the others.
Not the GP, but I have one non-partioning AIX trivia I discovered by accident. Turns out that malloc(0) returns NULL on AIX, but non-null on Linux, SunOS, and Irix. (I was surprised multiple ways on that one!)
Now that you know, can you conceptualize reasons why each pattern might be a correct preference? Among those reasons, which would you prefer as a system?
^^^ THAT is how an Interview Question should work around this factoid.
This was an internship interview over a decade ago. Nothing wrong with a brain teaser interview question under those circumstances. What would you rather ask an internship candidate? They don’t have work experience or real world skills.
I’d be unsurprised if an interviewer who thinks that trivia isn’t a goofy waste of time also believes that young people don’t have real world skills. But a good interviewer would probably spend time getting to know the candidate’s character.
Something I’ve learned from years of mentoring teens and raising kids is that there are qualities you cannot teach, and they’re enormously more valuable than any technical skills. I’m confident I can teach just about anyone any of the skills Microsoft employees find themselves milling away at. But I can’t teach that fire a 10th grader has where they go home and spend their entire weekend figuring out how to make their idea work in Java, even though they barely understand programming, and then swarm you at the door next week to proudly show it.
That’s the kind of quality you seek to find in an interview. All the other stuff can be taught to anyone.
I was interviewing interns before this, starting in 2013 or so. There are plenty of more useful questions you can ask.
Tell me about a project you’ve worked on, then many follow ups, for example. Asking about group project dynamics or something they’re passionate about and involved with. Ask why they’re applying for this role, ask about difficult conversations or things they’re proud of. Ask about decisions they would do differently if they could go back and why.
There are tons of ways to glean actually relevant information in an interview.
I hate such interview questions. They have nothing to do with think one really needs to do in practice. It seems for me to be just a way for interviewers to show their intellectual superiority.
I interviewed for an internship in 2006 and didn't get any brainteasers, but I got some pretty interesting questions that were somewhat computer science-related:
1. Suppose you have a binary tree (NOT a binary search tree) where each node with pointers to its parent and children. Given pointers to two arbitrary nodes in the tree, find their lowest common ancestor.
2. My favorite: given a uniform random number generator mod 5, create a uniform random number generator mod 7
3. Forgot the exact question, but something along the lines of: suppose you want to keep track of function arguments as you call them. How do you do that?
I got (1) and (2) and utterly failed (3). (3) is entirely trivial and basically a stated fact if you know how anything about how operating systems work, but I was a freshman in college and didn't know that function arguments got pushed on a stack in memory, so I was totally lost.
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)
It's interesting to see how interviews often test more than technical skills. I probably would've made the same choice and asked for another question too man. Really enjoyed reading this.
I’m guessing they didn’t care whether or not the OP knew the answer, they just wanted to see how they solved the problem and cramming for the test is the anti-pattern because that’s what the try-hards do and you generally don’t want try-hards around except where you need people to grind out things.
I’ve been through the Microsoft loop(s) several times over the years, and (to borrow from Tolstoy) each was unhappy in its own way. There were great people who would have been a pleasure to work with but always at least one joker in the deck. One just had to laugh because it was so obvious it wasn’t me.
I remember speeding through the loop for something closely analogous to my job at the time, only to be suddenly told by the hiring manager (who up to that time was a strong supporter) in a final interview that I wasn’t qualified. Not wanting to invest any more energy, I formally withdrew, only to get a call from him protesting why I’d do such a thing. Or being told to leave at the end of the day only to be called to drive back 20 miles immediately during dinner, and finding out later that was a mistake. Or being literally screamed at (spittle in my face!) that HPC was only MPI and nothing but MPI. Or being yelled at that Windows Server was exactly the same as an enterprise storage system like EMC/HP/Hitachi. The hits go on.
As I have grown older, I have realized dead-honesty is a false ideal to live by, especially when it comes to being rewarded in the capitalistic world. I know someone who reached executive level position in a big startup and all of his career progress can be traced back to lying on his resume about a NASA internship he never got, which he conveniently purged later from everywhere.
I wouldn’t go that far, but I think it’s perfectly fine to reverse-engineer the interview game and reap the rewards. There’s no reason to feel guilty about it.
The candidate may have had more success if he saved the honesty for after he solved the riddle he claimed he already knew how to solve.
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.
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.
Well, maybe you can use this to trick the interviewer into giving you a new problem if you don't know the first one they give you.
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.
> 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
> 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.
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.
[delayed]
Please no. No and home quizzes
A classically terrible interview question. Solving riddles in realtime is almost never a real job skill. _Maybe_ in an incident, but you’d be relying on tooling and experience, not an intern.
Same with leetcode at startups. It makes no sense. You’re almost certainly not going to do algorithms work. It’s only relevant if you’re looking for people willing to grind bullshit, which is certainly some jobs, but, again, you’re almost never doing this under arbitrary time pressure with someone watching over your shoulder judging and not helping.
My advice: if you encounter this, don’t work there. If a company doesn’t value testing relevant skills for candidates, don’t expect leadership to be strong critical thinkers once you get there.
The speed with which I can remember some obscure AIX partitioning-related fact during an incident, for example, is orders of magnitude faster than the speed with which I would figure out which of 12 marbles is slightly heavier than the others.
> I can remember some obscure AIX partitioning-related fact
Now you have my attention. I'd love to read about some of these trivia.
Not the GP, but I have one non-partioning AIX trivia I discovered by accident. Turns out that malloc(0) returns NULL on AIX, but non-null on Linux, SunOS, and Irix. (I was surprised multiple ways on that one!)
Sometimes I think "it's a UNIX system, I know this" but I've been caught by subtle differences before too.
killall is very different between Linux and Solaris, for example. I would rather have not found this out on a client machine for the first time.
Now that you know, can you conceptualize reasons why each pattern might be a correct preference? Among those reasons, which would you prefer as a system?
^^^ THAT is how an Interview Question should work around this factoid.
That one has bitten me more than once
This was an internship interview over a decade ago. Nothing wrong with a brain teaser interview question under those circumstances. What would you rather ask an internship candidate? They don’t have work experience or real world skills.
I’d be unsurprised if an interviewer who thinks that trivia isn’t a goofy waste of time also believes that young people don’t have real world skills. But a good interviewer would probably spend time getting to know the candidate’s character.
Something I’ve learned from years of mentoring teens and raising kids is that there are qualities you cannot teach, and they’re enormously more valuable than any technical skills. I’m confident I can teach just about anyone any of the skills Microsoft employees find themselves milling away at. But I can’t teach that fire a 10th grader has where they go home and spend their entire weekend figuring out how to make their idea work in Java, even though they barely understand programming, and then swarm you at the door next week to proudly show it.
That’s the kind of quality you seek to find in an interview. All the other stuff can be taught to anyone.
I was interviewing interns before this, starting in 2013 or so. There are plenty of more useful questions you can ask.
Tell me about a project you’ve worked on, then many follow ups, for example. Asking about group project dynamics or something they’re passionate about and involved with. Ask why they’re applying for this role, ask about difficult conversations or things they’re proud of. Ask about decisions they would do differently if they could go back and why.
There are tons of ways to glean actually relevant information in an interview.
Classical algorithms kind of thinking is similar to ML research.
> You have 12 marbles and a balance scale.
I hate such interview questions. They have nothing to do with think one really needs to do in practice. It seems for me to be just a way for interviewers to show their intellectual superiority.
I interviewed for an internship in 2006 and didn't get any brainteasers, but I got some pretty interesting questions that were somewhat computer science-related:
1. Suppose you have a binary tree (NOT a binary search tree) where each node with pointers to its parent and children. Given pointers to two arbitrary nodes in the tree, find their lowest common ancestor.
2. My favorite: given a uniform random number generator mod 5, create a uniform random number generator mod 7
3. Forgot the exact question, but something along the lines of: suppose you want to keep track of function arguments as you call them. How do you do that?
I got (1) and (2) and utterly failed (3). (3) is entirely trivial and basically a stated fact if you know how anything about how operating systems work, but I was a freshman in college and didn't know that function arguments got pushed on a stack in memory, so I was totally lost.
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)
This was the real riddle all along.
It's interesting to see how interviews often test more than technical skills. I probably would've made the same choice and asked for another question too man. Really enjoyed reading this.
What was the lesson learned?
I’m guessing they didn’t care whether or not the OP knew the answer, they just wanted to see how they solved the problem and cramming for the test is the anti-pattern because that’s what the try-hards do and you generally don’t want try-hards around except where you need people to grind out things.
I’ve been through the Microsoft loop(s) several times over the years, and (to borrow from Tolstoy) each was unhappy in its own way. There were great people who would have been a pleasure to work with but always at least one joker in the deck. One just had to laugh because it was so obvious it wasn’t me.
I remember speeding through the loop for something closely analogous to my job at the time, only to be suddenly told by the hiring manager (who up to that time was a strong supporter) in a final interview that I wasn’t qualified. Not wanting to invest any more energy, I formally withdrew, only to get a call from him protesting why I’d do such a thing. Or being told to leave at the end of the day only to be called to drive back 20 miles immediately during dinner, and finding out later that was a mistake. Or being literally screamed at (spittle in my face!) that HPC was only MPI and nothing but MPI. Or being yelled at that Windows Server was exactly the same as an enterprise storage system like EMC/HP/Hitachi. The hits go on.
Theres a Sphinx working at Microsoft and you proved that you aren't capable of adapting to the team culture.
Microsoft is a dumpster fire. You probably dodged a bullet. Source: I work in the dumpster fire
I agree. Source: I used to work at the dumpster fire
I agree. Source: I am an Azure user.
My condolences. I read that other hacker news post (was it a couple months back) from the (ex?) engineer...