A friend told me about his AWS interview experience. It was a case study describing a potential client, their needs, limitations, etc - trying to be “realistic”.
In the end it came down to either pressuring the client to embark on a complex cloud transition in time for a major sports event (that was a make or break event for the customer) or, as my friend recommended, start with a PoC but do the risky transition after the sporting event to minimize the potential for a catastrophic failure if things didn’t go to plan.
He didn’t get the job because even though the technical attributes were all good, he should have pressured the customer.
My takeaway was that interviews are a game with their own rules, and you have to play by those rules - demonstrating some sense of judgement outside the parameters of the game will not be tolerated.
> He didn’t get the job because even though the technical attributes were all good, he should have pressured the customer.
I'd say he didn't get the job because they would have asked him to pressure customers day in day out, he would refuse, never get promoted and be otherwise miserable in an aggressive culture.
IMHO he shouldn't change his answer to please the interviewer, the process is working as intended and I'd assume he found a job that better matched him somewhere else, where his mindset will be better valued.
I have kind of the same personal experience - a couple of days answering questions about the scalability and resilience of a fictional web app and enterprise integrations.
I’m very much a generalist and kept to standards and terms not specific to AWS infra.
They ”passed” me but wanted a follow-up after going through some training packages to make sure I could translate everything to AWS.
At the time I was leaving a bigger software company
, largely because I felt we completely locked down customers in solutions perhaps not in their best interest - so this put me off.
I realized AWS would be just the same, just on a different level.
And of course this makes sense - they want to sell their stuff!
I don’t want to sell stuff, I just want to build things.
If you consider getting hired despite value mismatch winning the interview game, then good judgement would be recognizing that you're expected to push the products aggressively even when it's bad for the client.
Plot twist: the interviewer despises the internal culture and did this as a way to send a signal that the interviewee shouldn't work there regardless of how well the interview went.
Once long ago when I interviewed at Apple I was asked the classic "fork in the road, two guys, one always tells the truth and one always lies" riddle, with complete earnestness as far as I could tell. Possibly the single worst interview question I've ever been asked.
Of course I told the interviewer I'd heard it before and then gave the correct answer. In my case we just ended up chatting about previous experience instead of doing another brainteaser and I ultimately passed the interview, I think. But afterward the recruiter strung me along for weeks telling me they wanted to make an offer but not giving me one, and I ended up going to Microsoft instead.
Not the worst interview experience I've had, though. That would be the time I interviewed for a full time position after an internship and a group of guys who knew me and had worked with me all summer asked me a pointless brainteaser as the only interview question. I crashed and burned for a full 40 minutes in front of them. Humiliating, and pretty much a pointless hazing ritual as they offered me the job anyway. Luckily I got a better offer and was able to turn them down.
Here are some other brainteasers I've been asked in interviews. I actually think these physics based ones are fun (probably because I had no trouble solving them), but they're still terrible interview questions:
You're in a boat on a lake with a bowling ball. After you drop the ball overboard and it sinks to the bottom, is the lake water level higher or lower or the same?
Three balls are on three downward sloping tracks. One track is a straight line down to the end, the second is the same except for a small hill in the middle, and the third is the same except instead of a hill it has a small dip. All tracks start at the same height and end at the same height and cover the same horizontal distance. The balls are released at the same time and roll to the end without leaving their tracks. Which one gets there first?
I suspect you see them as time wasters which is why you end the interview. I see them as ice-breakers and rather enjoy them because they are fun to talk through.
I am on my 50's now, if I have to prove that I am worthwhile being an employee with such teasers instead of what I have done thus far, I rather spend my time elsewhere, unless I am desperate for getting the position.
A dip increases the speed (decreasing travel time), but also the distance to travel (increasing travel time). Which of those effects dominates depends on the shape of the dip.
The hill decreases speed and increases distance, so it's always slower than the straight line.
Most things that can fairly be described as a "small dip" should decrease travel time. When I was presented with the problem it came with illustrations to clarify. Surprisingly hard to make it watertight with text alone.
I find it very easy to solve some of these physics questions by thinking about a degenerate version of it instead, with exaggerated parameters (since these physics phenomenons are described by continuous/monotonic functions).
So for the bowling ball, I replace it with an imaginary marble weighing 1 ton and the answer is now self-evident.
That’s exactly the path I would have gone, ask clarifying question to confuse the interviewers:
- Is my boat actually floating in the lake?
- Is the lake filled with water?
- If yes, what is the temperature gradient of that water from top to bottom?
- How deep is the lake at the spot the ball is dropped?
- What is the current time and phase of the moon, and what are the exact coordinates of the ball drop?
- Are we doing this during some « end of the world gravitational collapse » event?
This would show them three things (which they did were not trying to find out, or maybe):
1. I think these questions are stupid.
2. I know that clear requirements and edge-cases are important
3. I’m an asshole and possibly not fun at parties
You drop a bowling ball off a space boat into a black hole. Has the amount of mass inside the universe increased, decreased, or stayed the same, ignoring the effects of all other changes?
The amount of mass inside the universe has stayed the same, it just moved from the boat into the black hole.
You're really bored at work one day so to entertain yourself you create 1kg of antimatter along with 1kg of matter. Has the mass in the universe increased or stayed the same?
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)`.
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.
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.
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.
> 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.
Well, I've been coding for 15 years (of course walking through data structures, JSON being one of the simplest), hung around HN and did interview puzzles a bunch, and yet have no idea what you mean by DFS nor ever needed to write a topological sorting implementation. No need to explain, I'll look it up for the fomo, but just to show that there's always experienced people who just didn't happen to come across something you say you've needed only on rare occasions ('something you might need')
Edit: oh ok, DFS is just depth-first search. Walking a tree. Okay yeah sure I can do that but it seems (from my security PoV) about as common to write tree parsers and sorting algorithms as designing a new cryptographic protocol, that is: hard avoid, rarely necessary
in my experience, if an interview can't confirm basic knowledge of data structures and algorithms, then some lead ends up having to teach computer science in order to explain why a developers's code with 5 nested loops is probably not a good idea
>The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided.
The problem with these is that their solutions always seem trivial when you are shown them (or spend time solving yourself) and then mull over them for a while.
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.
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.
> 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?
How many devs above 40 do you think still do leetcode to keep themselves entertained, especially if their daily work is doing CRUD stuff between corporate meetings?
> 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
Back when I interviewed at MS as a college senior, I had no clue about these "formats". So when someone asked me how I would make (I think they meant design) a web crawler, I started writing one in Python. They didn’t stop me, and it seemed to be awkward to them that I was doing this, whereas I felt awkward that they were acting that way when I was doing what they asked. It was just stupid all around. These systems deserve to be gamed, and the interviewers can't handle anything else, like in TFA.
> 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.
In the initial state there's 24 (12 * 2) different possibilities: The marble you're looking for is one of 12 and it's either lighter or heavier. By using a balance scale there's 3 possible outcomes (left side is heavier; right side is heavier; same weight). This means that for your last (third) weighing you'll have to have reduced the problem down to 3 (or fewer) different possibilities. If there's 4 or more there's no way to reduce it down to a single possibility. Before the second weighing you should have reduced it down to 9 (3*3) different possibilities.
Once you know this, you can start making educated guesses for the first weighing and quickly eliminate those which makes it impossible to continue. For instance: Splitting the marbles into two. This gives two possible outcomes: Left side is heaver or right side is heavier. For the first outcome it means that either the target marble is lighter and part of the left group (6 marbles) or heavier and part of the right group (6 marbles). That's 12 different possibilities (more than 9) and therefore we know that it's impossible to determine the marble with just two more weighings.
There's still guessing to be done, but at every part of the decision tree you can at the very least quickly avoid exploring paths which are guaranteed to not work.
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 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.
> 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.
Odd that they received a brain teaser at a MS interview in 2015. IIRC that's several years after internal interviewer training was updated to recommend that brain teasers not be used in interviews because they weren't useful.
I interviewed with Microsoft at the end of 2016 as a new grad and was given the same marble question over the phone. I then made it to the on site interview where I failed horribly haha.
There’s a whole book on Microsoft’s hiring brainteasers, appropriately from 2004 right around when the practice was waning and brainteasers started to get a bad reputation: How Would You Move Mount Fuji?: Microsoft's Cult of the Puzzle (https://www.amazon.com/dp/0316778494)
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.
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.
Once I've been to an interview where first they made us solve a problem in a group and then we had 1-1 interviews. After the group task the guy immediately asked me "Don't you have a feeling that you might've been forcing your opinions onto others?" to which I replied "Yes, I have.". Absolute fucking Chad I was.
Interviewer's notes: anal_reactor is stubborn, difficult to work with, has little regard for others' opinions, not a team player. Do not recommend hiring.
Not wrong, especially at the time. I excel when I'm given my own chunk of job to work on with certain degree of freedom. I don't butt uninvited into other people's decisions, I expect others to do the same with me. I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard.
IMO diving people into small groups, sometimes groups of one, with API between them, is the correct way of managing employees. I really dislike the "everyone does everything" paradigm that my current workplace applies because the end result is that there is no design, we just keep stacking features until something gives, and then we have a project "someone please unfuck the application".
And then after being 90% complete with the project having your manager or business liaison change the fundamental requirements at the last second and be mystified as to how that could possibly affect any sort of estimates or deadlines.
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.
In these circumstances I always say "I've seen something similar before". That has the benefits firstly, that the interviewer will probably go ahead with the question anyway while still noting your honesty; and secondly, that it's usually true - it's possible this problem is subtly but importantly different from the one I'm pattern matching against. There are half a dozen versions of this ball problem.
How do you guys view external contractors(the one with email address start with v-xxx)
I was contractor for MS for a while and it was not a very positive experience. i was kind of being forgotten and only be mentioned when convenient. I went by months without any actual real work done.
Speaking as someone who worked offshore for most of their career and is now a full time employee at MS.
Vendors are treated as vendors usually are. They are given the work that nobody wants (work that provides no career growth and usually is uninteresting), they get the least amount of attention and mentoring, they are expected onboard quickly with little help from the team, etc.
I have noticed that I'm more empathetic to vendors than people who have never been the offshore/contractor person.
I definitely experienced that “yellow badges” were viewed by long timers as somewhat of a lower caste. Starting with the first onboarding day where they were given hand-me-down phones and laptops.
(This was a long time ago, during the Ballmer era. Just my personal 2 cents.)
Brain teaser questions are the dumbest thing one can ask in a software engineering position interview. One time I interviewed for Deutsche Bank. There were two interviewers and one guy joined half way through the interview and was completely focusing on something else.
At the end of the interview other interviewer asked from the distracted guy if he has any questions and he came up with the stupidest brain teaser question ever, I don't even remember what it was, but after I answered it, he changed it again and then I asked the answer from him, and was very arrogantly said "I'm sure you know the answer" and I immediately said back, "But I guess you really don't know the answer to your own question right?". He was dumbfounded. I think he didn't expect me, the candidate to call him out.
Afterwards, I immediately sent and email to the recruiter about how bad the interview was and one interviewer was being more than 30 mins late and withdrew from the process and added Deutsche bank to my black list.
Ultimately, the problem is that every person has their own anecdata-driven or follow-the-leader-inspired ideas about how to interview effectively, and large swaths of them are in stark opposition to each other.
And now after decades of research, we're still using magic potions that mostly don't make sense.
The qualities that are needed to grind the algorithms, system design, and what have you have a nice correlation with success later
Perseverance, diligence, sheer will to grok the somewhat boring shit.
Even writing some code in the notepad/whiteboard means you have enough mental RAM/stack/context window to keep the bits in the head.
—
So it ain’t no “magic potion”. Ideally we had a less strenuous thing ( Bloodborne/Dark Souls platinum trophy for the diligence part? :-) ) but you can’t always have what you want.
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 major company 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.
OP here. I didn't want to end the article in a preachy note, but an implicit point is that I'm doing quite well "despite" my policy of being honest. Monetary rewards are a poor substitute for living up to your values!
Besides... many players in the market actually seek people with "moral integrity" (or whatever the fashionable term is nowadays).
"Academic degrees" are, by definition, named something as categories. In your country do they not have the concept of a "bachelors" degree, or "associate" degree or "masters" or "doctorate"? B.A., B.S., A.S.?
Other popular categories could include "fine arts", "PhD", etc.
Anyone putting letters after their name, i.e. postnominals, has graduated and obtained a degree. Sometimes they put the field of study but sometimes you will just see someone on LinkedIn as, "Jane Smith, MA".
Could probably write something like you were in the B.A. track of your field of study. People will write "pursuing graduate degree" or "postdoc" or suchlike. But that is not what GP wrote. GP wrote a field of study; while "Computer Science" describes degree programs, it is undifferentiated, and wouldn't be considered a "degree" by the skeptical reader of CVs.
Eh? Would you? I have two degrees and I never mentioned exactly what they are on my CVs, literally just like above - "2010-2014 Computer Science at University X". I've reviewed countless CVs when I was a hiring manager for a few years too, and I don't really recall if people wrote down what they got, nor was it ever relevant for any position outside of intern ones.
Whatever the reason for not asking that question, it would be a terrible question to ask an interviewee in that situation. "Did you actually graduate from this place?" It would be the equivalent of asking "did you lie on your CV?" If I wrote a CV and they began asking me questions that were answered by my CV, I would read that as skepticism. Conversely, perhaps the interviewers are so good that they only ask questions where they already know the answers, in that regard.
Neither of you have mentioned the qualifications of the jobs you sought. Perhaps those companies did not require or factor-in the degrees of candidates. Perhaps they can open up LinkedIn and see whether or not you graduated. Perhaps they just called their sorority sister at the Registrar for an informal reminiscence about the weather in 2021.
I can understand if you want to put the year-range that you attended college. Perhaps you want to prove you graduated in 4 years, rather than taking 6. There are more people who are unwilling to put any year at all to their education, lest someone figure out that they are over 40.
The bottom line is that if you ask 5 people about résumé building and job interviews, you'll hear 6 opinions on what is right, what is wrong, what is legal, etc. There is plenty of bad advice, and narrow opinions, mine included.
I disagree strongly. Yes, in terms of benefit to yourself honesty may not pay off, but that's not why you should do it. You should be honest (and I try to be honest) because it's shameful to be a deceitful person. Virtue actually matters, it's not all about getting ahead materially.
But what if you know you could make a materially positive impact for the company? Then wouldn’t it be virtuous to play their recruiting game in such a way that you could make that contribution ?
> 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 don't like when people get ahead by lying either, but nobody cares about your internship at the executive level. That one lie helped with the first job, but it doesn't explain all of the person's success.
> There’s no reason to feel guilty about it.
Even if we ignore guilt, there's a subtle problem that happens when you tell a lie to get a job: You have to forever hope that nobody checks it, that no contradictory evidence accidentally shows up, and that it never becomes a point of contention.
I've participated in a lot of interviews where candidates never expected us to check claims they made. It's interesting to see the entire hiring panel's view of a candidate change when someone discovers they lied about something. Everything else comes into question.
This is one of the reasons why I want to exit the workforce and retire ASAP. I just cannot function in an environment where ignoring the elephant in the room is the expected behavior. I am a dead-honest guy and I've surrounded myself with friends who appreciate this trait but they were really hard to find.
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)
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!)
Another AIX different that caughts folks off guard, it uses COFF primarly, and its dynamic library models is closer to Windows, OS/2, Symbian, than classical UNIX with ELF.
Including the existence of import libraries, linker export files, and lazy dynamic loading of symbols.
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.
HR is modern priesthood, and their function is to prevent the "unwashed" from ascending up the higher ranks.
Now there I've made it much worse (or better!) than the actual reality, which is that there's just not enough quality engineering jobs no matter which way you cut it and all of this theatrics result from scarcity.
I have not seen this problem before, but the answer seems blindingly obvious? A balance is trinary, not binary. You just need to explain the decision tree.
I hadn't seen it before either. I solved the branches in my head in a couple minutes, and my initial impulse was instinctively 4-4-4, but until you said trinary I didn't think of it in those terms.
The article only mentioned he asked for a different problem, not that he was quickly explaining the solution and then asked for a different one. So this were exactly my thoughts, it's a bit like getting asked to find the roots of a polynom and replying "oh I already know how to do it, can you ask me something different?"
that seems very risky. it doesn't take much effort for the interviewer to spot a trickster, forfieting the interview. There is also no telling the second problem would be easier. I'd rather take my chances and hope i solve it or try to limp through with a hint.
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 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.
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.
As user I still find it less painful to use than either AWS or GCP, where I had worse experiences in platform complexity (AWS), or talking to bots for support (GCP).
I once had a geography teacher who had the absolutely unhinged habit of asking spontaneous gotcha questions designed to make himself look good. The kind where the question doesn't contain enough information to get to the answer he had in mind. Then when someone answered the question correctly, but didn't use the exact answer he had in mind he went all "gotcha!".
Sometimes he asked the same question again and when someone remembered the answer, he still went "gotcha!" only with a changed answer.
The lesson I learned from that guy, was that sometimes a question says more about the person asking it than about the person answering it — more precisely that men with small egos bend reality to get the outcome they prefer.
The appropriate strategy with him was to ask in a Socratic way while stroking his ego: "But haven't you thought us X is Y? I would like to get it correct!", then he would squirm around and admit that yes, this is also correct.
This type of dynamic can also occur in interviews.
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.
> "I told the interviewer I already knew the riddle, and I asked for another one."
The question wasn't "do you know this riddle", she just wanted the riddle answered. No need to make it more complicated.
There's no lie in withholding information never asked for. It's possible the request for a new riddle was interpreted as a ploy to get an easier riddle.
Questions like this, and things like Leetcode, etc., are a measure of not only your intelligence, but one of the most valuable skills you can have as an employee: the ability to "carry a message to García".
That is, when given an assignment, to faithfully carry it out to the end, without wasting your superior's time with pointless questions or excuses as to why it cannot be done. This, and this alone, is what separates the outstanding employees from "the imbecility of the average man". Tim Bryce has observed that the average programmer is mentally lazy and prone to sloppy thinking; simple tests like this will help to weed these out. The sillier, the better, in fact, as long as the puzzle actually has a solution. OP has failed the test, and justly gotten himself preemptively fired for insubordination.
In the end it came down to either pressuring the client to embark on a complex cloud transition in time for a major sports event (that was a make or break event for the customer) or, as my friend recommended, start with a PoC but do the risky transition after the sporting event to minimize the potential for a catastrophic failure if things didn’t go to plan.
He didn’t get the job because even though the technical attributes were all good, he should have pressured the customer.
My takeaway was that interviews are a game with their own rules, and you have to play by those rules - demonstrating some sense of judgement outside the parameters of the game will not be tolerated.
I'd say he didn't get the job because they would have asked him to pressure customers day in day out, he would refuse, never get promoted and be otherwise miserable in an aggressive culture.
IMHO he shouldn't change his answer to please the interviewer, the process is working as intended and I'd assume he found a job that better matched him somewhere else, where his mindset will be better valued.
The goal when interviewing is not "get the job", it's "am I a good fit for this role".
If the company is some weird dysfunctional hierarchy run by socio-paths, I'll be happier elsewhere.
Or to put things in a much more pretentious manner - If you're too stupid to appreciate my genius, you don't deserve to work with me :)
I’m very much a generalist and kept to standards and terms not specific to AWS infra. They ”passed” me but wanted a follow-up after going through some training packages to make sure I could translate everything to AWS.
At the time I was leaving a bigger software company , largely because I felt we completely locked down customers in solutions perhaps not in their best interest - so this put me off.
I realized AWS would be just the same, just on a different level.
And of course this makes sense - they want to sell their stuff!
I don’t want to sell stuff, I just want to build things.
Of course I told the interviewer I'd heard it before and then gave the correct answer. In my case we just ended up chatting about previous experience instead of doing another brainteaser and I ultimately passed the interview, I think. But afterward the recruiter strung me along for weeks telling me they wanted to make an offer but not giving me one, and I ended up going to Microsoft instead.
Not the worst interview experience I've had, though. That would be the time I interviewed for a full time position after an internship and a group of guys who knew me and had worked with me all summer asked me a pointless brainteaser as the only interview question. I crashed and burned for a full 40 minutes in front of them. Humiliating, and pretty much a pointless hazing ritual as they offered me the job anyway. Luckily I got a better offer and was able to turn them down.
Here are some other brainteasers I've been asked in interviews. I actually think these physics based ones are fun (probably because I had no trouble solving them), but they're still terrible interview questions:
You're in a boat on a lake with a bowling ball. After you drop the ball overboard and it sinks to the bottom, is the lake water level higher or lower or the same?
Three balls are on three downward sloping tracks. One track is a straight line down to the end, the second is the same except for a small hill in the middle, and the third is the same except instead of a hill it has a small dip. All tracks start at the same height and end at the same height and cover the same horizontal distance. The balls are released at the same time and roll to the end without leaving their tracks. Which one gets there first?
- How many golf balls fit into the plane
- How many gas stations exist in country (or alternative version with city)
- How many turns do you have to go on a gum machine until colour comes out?
Naturally they all evaluate properly the skills required for the job, and other professions get asked the same kind of stupid questions.
Unless it is for a position I really, really want, or are unemployed and every opportunity counts, that is usually where the interview ends for me.
I suspect you see them as time wasters which is why you end the interview. I see them as ice-breakers and rather enjoy them because they are fun to talk through.
Boat + bowling ball = level stays the same?
Ball roll = the constant gradient is quickest?
Dip for hill roll is faster
The hill decreases speed and increases distance, so it's always slower than the straight line.
What are the effects of the 10 litres of air displaced from within the boat?
So for the bowling ball, I replace it with an imaginary marble weighing 1 ton and the answer is now self-evident.
This would show them three things (which they did were not trying to find out, or maybe): 1. I think these questions are stupid. 2. I know that clear requirements and edge-cases are important 3. I’m an asshole and possibly not fun at parties
At what point does NVIDIA give you $200bn?
You're really bored at work one day so to entertain yourself you create 1kg of antimatter along with 1kg of matter. Has the mass in the universe increased or stayed the same?
Steep then flat one because it gets up to speed fastest.
It's a classic "annoy people who've forgotten that newtonian physics is all integrals" problem. Graph the velocity. Look at area under graph.
They received a crash course in the power of Haskell ADT and `deriving (Show, Read)`.
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.
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.
Well, I've been coding for 15 years (of course walking through data structures, JSON being one of the simplest), hung around HN and did interview puzzles a bunch, and yet have no idea what you mean by DFS nor ever needed to write a topological sorting implementation. No need to explain, I'll look it up for the fomo, but just to show that there's always experienced people who just didn't happen to come across something you say you've needed only on rare occasions ('something you might need')
Edit: oh ok, DFS is just depth-first search. Walking a tree. Okay yeah sure I can do that but it seems (from my security PoV) about as common to write tree parsers and sorting algorithms as designing a new cryptographic protocol, that is: hard avoid, rarely necessary
The problem with these is that their solutions always seem trivial when you are shown them (or spend time solving yourself) and then mull over them for a while.
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.
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.
"Just solve it and I'll note down an A+" is sometimes better than "candidate was honest, but didn't finish the alternative riddle."
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
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?
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
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.
How would you approach it from an information theoretic sense?
Once you know this, you can start making educated guesses for the first weighing and quickly eliminate those which makes it impossible to continue. For instance: Splitting the marbles into two. This gives two possible outcomes: Left side is heaver or right side is heavier. For the first outcome it means that either the target marble is lighter and part of the left group (6 marbles) or heavier and part of the right group (6 marbles). That's 12 different possibilities (more than 9) and therefore we know that it's impossible to determine the marble with just two more weighings.
There's still guessing to be done, but at every part of the decision tree you can at the very least quickly avoid exploring paths which are guaranteed to not work.
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.
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.
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...
Lol, I'm increasingly wary of whatever SV / startup circles prefer nowadays... The shitload of BS is ever forthcoming.
I've never interviewed there, or been asked that question, but I think it would be a lot of fun to answer.
Wait 1s.
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.
IMO diving people into small groups, sometimes groups of one, with API between them, is the correct way of managing employees. I really dislike the "everyone does everything" paradigm that my current workplace applies because the end result is that there is no design, we just keep stacking features until something gives, and then we have a project "someone please unfuck the application".
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.
How do you guys view external contractors(the one with email address start with v-xxx)
I was contractor for MS for a while and it was not a very positive experience. i was kind of being forgotten and only be mentioned when convenient. I went by months without any actual real work done.
Vendors are treated as vendors usually are. They are given the work that nobody wants (work that provides no career growth and usually is uninteresting), they get the least amount of attention and mentoring, they are expected onboard quickly with little help from the team, etc.
I have noticed that I'm more empathetic to vendors than people who have never been the offshore/contractor person.
(This was a long time ago, during the Ballmer era. Just my personal 2 cents.)
At the end of the interview other interviewer asked from the distracted guy if he has any questions and he came up with the stupidest brain teaser question ever, I don't even remember what it was, but after I answered it, he changed it again and then I asked the answer from him, and was very arrogantly said "I'm sure you know the answer" and I immediately said back, "But I guess you really don't know the answer to your own question right?". He was dumbfounded. I think he didn't expect me, the candidate to call him out.
Afterwards, I immediately sent and email to the recruiter about how bad the interview was and one interviewer was being more than 30 mins late and withdrew from the process and added Deutsche bank to my black list.
And now after decades of research, we're still using magic potions that mostly don't make sense.
The qualities that are needed to grind the algorithms, system design, and what have you have a nice correlation with success later
Perseverance, diligence, sheer will to grok the somewhat boring shit.
Even writing some code in the notepad/whiteboard means you have enough mental RAM/stack/context window to keep the bits in the head.
—
So it ain’t no “magic potion”. Ideally we had a less strenuous thing ( Bloodborne/Dark Souls platinum trophy for the diligence part? :-) ) but you can’t always have what you want.
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.
Besides... many players in the market actually seek people with "moral integrity" (or whatever the fashionable term is nowadays).
“2015 - 2020 / University X, Computer Science”
on your resume, nobody asks if you actually graduated.
Other popular categories could include "fine arts", "PhD", etc.
https://en.wikipedia.org/wiki/Academic_degree
Anyone putting letters after their name, i.e. postnominals, has graduated and obtained a degree. Sometimes they put the field of study but sometimes you will just see someone on LinkedIn as, "Jane Smith, MA".
Could probably write something like you were in the B.A. track of your field of study. People will write "pursuing graduate degree" or "postdoc" or suchlike. But that is not what GP wrote. GP wrote a field of study; while "Computer Science" describes degree programs, it is undifferentiated, and wouldn't be considered a "degree" by the skeptical reader of CVs.
Neither of you have mentioned the qualifications of the jobs you sought. Perhaps those companies did not require or factor-in the degrees of candidates. Perhaps they can open up LinkedIn and see whether or not you graduated. Perhaps they just called their sorority sister at the Registrar for an informal reminiscence about the weather in 2021.
I can understand if you want to put the year-range that you attended college. Perhaps you want to prove you graduated in 4 years, rather than taking 6. There are more people who are unwilling to put any year at all to their education, lest someone figure out that they are over 40.
The bottom line is that if you ask 5 people about résumé building and job interviews, you'll hear 6 opinions on what is right, what is wrong, what is legal, etc. There is plenty of bad advice, and narrow opinions, mine included.
I don't like when people get ahead by lying either, but nobody cares about your internship at the executive level. That one lie helped with the first job, but it doesn't explain all of the person's success.
> There’s no reason to feel guilty about it.
Even if we ignore guilt, there's a subtle problem that happens when you tell a lie to get a job: You have to forever hope that nobody checks it, that no contradictory evidence accidentally shows up, and that it never becomes a point of contention.
I've participated in a lot of interviews where candidates never expected us to check claims they made. It's interesting to see the entire hiring panel's view of a candidate change when someone discovers they lied about something. Everything else comes into question.
(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)
In an industry that loves calling itself "engineering", it seems nothing further of value can be established?
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.
Now you have my attention. I'd love to read about some of these trivia.
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.
Including the existence of import libraries, linker export files, and lazy dynamic loading of symbols.
^^^ THAT is how an Interview Question should work around this factoid.
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.
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.
Now there I've made it much worse (or better!) than the actual reality, which is that there's just not enough quality engineering jobs no matter which way you cut it and all of this theatrics result from scarcity.
It's more plausible that the issue is this being a lemon market
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.
What a great way to filter out talented people. Great times. Very character building.
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.
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.
See, this is why you weren't selected for the team: https://imgur.com/a/xnHgjjH
Sometimes he asked the same question again and when someone remembered the answer, he still went "gotcha!" only with a changed answer.
The lesson I learned from that guy, was that sometimes a question says more about the person asking it than about the person answering it — more precisely that men with small egos bend reality to get the outcome they prefer.
The appropriate strategy with him was to ask in a Socratic way while stroking his ego: "But haven't you thought us X is Y? I would like to get it correct!", then he would squirm around and admit that yes, this is also correct.
This type of dynamic can also occur in interviews.
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.
The question wasn't "do you know this riddle", she just wanted the riddle answered. No need to make it more complicated.
There's no lie in withholding information never asked for. It's possible the request for a new riddle was interpreted as a ploy to get an easier riddle.
The rejection was so generic and there's so much random bs that goes on it could be anything that lead to that result.
https://en.wikipedia.org/wiki/A_Message_to_Garcia
That is, when given an assignment, to faithfully carry it out to the end, without wasting your superior's time with pointless questions or excuses as to why it cannot be done. This, and this alone, is what separates the outstanding employees from "the imbecility of the average man". Tim Bryce has observed that the average programmer is mentally lazy and prone to sloppy thinking; simple tests like this will help to weed these out. The sillier, the better, in fact, as long as the puzzle actually has a solution. OP has failed the test, and justly gotten himself preemptively fired for insubordination.