back
312 comments
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.

> My takeaway was that interviews are a game with their own rules, and you have to play by those rules

But you don't get to know the rules.

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.
I can see both sides but it depends on the position. Was he interviewing for something like a Sales Engineer role or strictly a technical role? If you're doing Sales Engineering or going for a Solution Architect on a PS team then sales is part of the role. If it's strictly a technical role that is not a part of the selling process then it doesn't make much sense to me.

/edit: now that i think about it, they may prefer a sales mindset in all roles which i can also understand

> He didn’t get the job because even though the technical attributes were all good, he should have pressured the customer.

This is hearsay, and smells like bullshit to me. I've given dozens of interviews during my tenure at AWS (in which I had a sales-adjacent role) and we never made a decision based on that. Plus, we'd never give that kind of feedback to a candidate.

Interviews at Amazon are highly structured and there's a Bar Raiser assigned to oversee every one of them to make sure they follow the rules during the debrief. The BR, who is usually not even on the same team or organization that's hiring, would not have allowed this to be the cause for rejection. It's far more likely the candidate was reported weak on one or more of the Leadership Principles evaluation sessions.

> He didn’t get the job because even though the technical attributes were all good, he should have pressured the customer.

1) Is this word for word what they told him?

2) If so, why did he believe them?

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.
One thing I've taken away in my career, interviewing every 3-5 years is that difficulty of interview & difficulty of job are uncorrelated. Often they are inversely correlated.

Possible reasons.. Sometimes a team is growing so fast / or turnover is so high / everyone is so busy / etc that they cannot really stand up a proper interview process .. and/or they just need to get people into seats, and are happy to fire fast later.

Sometimes a job is so boring and team leads have so much time on their hands that they can construct immaculate interview processes and spend hours grilling candidates.

> difficulty of interview & difficulty of job

Define "difficulty of job"

I'm going to assume you mean "people problems;" because the best way a team avoids people problems is by interviewing very, very carefully.

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?

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.

> 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

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.

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)`.

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)

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.

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...

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.

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 have question for MS people.

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.

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.
My experience like this was for a data scientist position at Facebook in 2022.

So the question was something like, here is a table of predicted probabilities for credit card transactions (hypothetical table, I do not remember the exact quantities), but it looked something like this:

    Amount, Probability, ActualFraud
       $5 ,    0.2     ,  0
     $100 ,    0.5     ,  0
       $3 ,    0.7     ,  1
       $1 ,    0.9     ,  1
And then the question was "what was the threshold used to maximize (precision|recall)?" (I cannot remember which metric they were asking for).

My response was that a proper decision model should take the dollar amount of the transaction into consideration, so the decision should more like be `$*p > threshold`, where this threshold meets your precision and recall for preventing dollars lost instead of the binary yes/no.

The interviewers English was not great, so after all that I was just like "well to answer your exact question, it could be anywhere between `0.5 < p <= 0.7`"

Did not make the second round!

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.

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.

My current stumbling block is the "design" interview. I get what they're going for and what I have to practice, but as someone with 25 years of experience I just can't help but have my experience creep into my thoughts.

Chief among those thoughts is that we can't design a clearinghouse for a banking system that already has 11 components and the request is just two simple sentences asking for a design. I apparently have an hour to complete this design task. An hour is so laughably small a time to get onto the design phase.

Again, I understand what they are going (I'm just not practicing it) for but it all feels like they're hiring for tennis but interviewing for ping pong.

My favorite (probably apocryphal) Microsoft brain teaser question I've heard is, "If you had to move Mt Fuji, how would you do it?"

I've never interviewed there, or been asked that question, but I think it would be a lot of fun to answer.

> "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.

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.

My most interesting interview experience, but as interviewer not interviewee, was when we interviewed someone by phone and could hear a friend of the candidate whispering answers to him. He was not offered a job. We should have offered it to the mystery voice person.
Sadly interviews are really aptitude and personality tests, perhaps knowledge of leetcode, tools, frameworks and languages.

In an industry that loves calling itself "engineering", it seems nothing further of value can be established?

Jeez, the text in the rejection letter is the same today as it was back in 2015!
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.

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.

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.
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.
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.

You are not required to be honest with corporations, corporations are not honest with their consumers or employees.
Most interesting is that interviewers were still asking such questions some fifteen years after Microsoft interviewers were told by HR to quit asking such questions (because the answer might rely on cultural knowledge, etc.)

Source: as an interviewer, I had to sit in that meeting.

Google analysis of their own hiring data shows these questions provide no predictive value for job performance. Gets you a bunch of puzzle experts. Probably bad idea since they will enjoy wasting time playing sodoku on the job instead of focusing on their work.
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.
Companies that use riddles get the employees they deserve.
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’m afraid I’ll never know!

The rejection was so generic and there's so much random bs that goes on it could be anything that lead to that result.

Theres a Sphinx working at Microsoft and you proved that you aren't capable of adapting to the team culture.
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.

Microsoft is a dumpster fire. You probably dodged a bullet. Source: I work in the dumpster fire