That time when I failed the Microsoft interview
ochagavia.nl
ochagavia.nl
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 made the mistake of letting that company bring me back for a second "less technical" round of interviews, but I shouldn't have.
About 45 minutes into doing this I decided that any company that screened candidate like this was not somewhere I wanted to work so I told the interviewer that I didn't think this was the right fit and I appreciated them taking the time to consider me for the role but I wouldn't be continuing on.
I'll never forget he was like, "But you're doing great!" ... like yes, I know. I'm not stopping because I'm failing, I'm stopping because you are.
Which is why I never lie in interviews. If I don't make your cut, I might be dodging a bullet.
For me personally, quality of life is important, so is vibing with my coworkers, and management that respects work-life balance. I have this at my current job. My salary is good, not amazing but comfortable. Would I trade double the salary for an environment where I'm stressed, expected to work 50 hour weeks, and answer calls on my own time? Nah. No way.
But how do you differentiate between if it is just this one interviewer or if it is the team or the whole company? I had interviewed at places that my friend referred me to, and after the fact, my friend told me it is just this one interviewer with their weird preference that screwed the whole process…
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.
While this resonates with me and probably the majority of the HN readership, I also want to be paid (handsomely) to build things. But in every case where someone pays me to build things, they want to sell it to someone (if they haven’t already sold it before I built it).
I think the important difference is whether you believe the thing you’re building is good for the people that are buying it. Never have I ever seen vendor lock-in become a net benefit for those who have found themselves in its grasp.
Certainly not every enterprise setting is like this, but they do exist, or the setting can even be created if just enough people of the right stuff end up together.
1) Is this word for word what they told him?
2) If so, why did he believe them?
1) I rarely get any feedback, particularly not feedback as detailed as this, with a single reason for failure 2) Employers habitually bend the truth around interviews: interviewing for jobs that don't exist, that are already filled, reneging offers 3) Not being hired after an interview doesn't mean you failed it. They're more like dates than exams.
> They're more like dates than exams
It's much better to look at your own performance critically than to trust the feedback you get. Because the feedback you get (if you get any at all) is unlikely to be that useful or that trustworthy.
/edit: now that i think about it, they may prefer a sales mindset in all roles which i can also understand
But you don't get to know the rules.
Back in the 90s, looking for a job wasn't so bad. Now it's a nightmare.
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.
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.
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.
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?
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?
If it was a floating bowling ball, the lake water level would stay the same when you toss it from a boat. If it were a sinking one, it would decrease.
Wouldn't that mean the water level will raise a bit because: displaced weight > displaced volume?
So for the bowling ball, I replace it with an imaginary marble weighing 1 ton and the answer is now self-evident.
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?
At what point does NVIDIA give you $200bn?
PS: Assuming the boat isn't falling too (it's still in orbit), dropping the ball does nothing. You need to decelerate it (reduce it's orbital speed) for it to fall into the black hole.
(I actually don't know the answer to this)
The more pressing thing is that every thing around the lake is irradiated by the evaporation of the microscopic black hole, which supposedly emits quite a lot of energy, as it falls through the bottom.
Why do you care whether I do or not?
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
I got this vibe at AWS, interviewing in 2020. They asked me to design a stock price tracking webapp. I started asking questions and sketching things out and at each question (fairly basic ones, too, like, how many users are we supporting, how frequently do they request updates, and how timely does the data need to be). Seemed reasonable to me but I think my line of questions annoyed them because they said, "just design the app!" Maybe they thought I was stalling? Hmm, ok, but it'll fall over on day 2. I turned down the offer.
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.
1) Imagine pushing the boat down into the lake, displacing water. The level would go up.
2) Imagine the ball instead of being in the boat, is attached under the boat by a rope. Same thing. (Imagine it magically moving through the bottom of the boat - it has no impact on the boat or water level).
3) Imagine you cut the rope. The ball will fall, and the boat will bob up. Water level goes down.
Here's one of my old blog posts where I do the derivation:
- 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.
Ironically the same companies are more than willing to get the same seniors as highly paid external contractors for exactly the same tasks, and without these kind of time wasting interviews.
There are other ways to assess those skills, sure. But questions like that aren’t bad ways.
> 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
This person is close minded and is filtering themselves out of the process. This is ideal.
Are you saying you’re against all open-ended questions in the interview process?
Since we are it, lets make Jeopardy for getting a job.
Or maybe the job is about actually carrying golf balls into planes.
Notes:
0 - https://www.amazon.com/dp/0316778494
1 - https://en.wikipedia.org/wiki/Fermi_problem And not the question Where are they? https://en.wikipedia.org/wiki/Fermi_paradox Same guy. At the same Los Alamos.
2 - You know, the guy who got a Nobel Prize for inventing transistors. https://en.wikipedia.org/wiki/William_Shockley
Just like not every cook wants to be a Michelin star with molecular cuisine, a tiny food drop in the middle of a gigantic plate.
I walk in, and the CEO's secretary hands me an IQ test and says I have one hour. I do the test, then I meet the CEO and we chat about general topics while she grades the test nearby. Then she announces my IQ, and the CEO says "hmm, yes, that's above the minimum I'd consider for a developer." Then for the last few minutes he goes through the 2-3 questions I got wrong and asks me to explain why I gave the answer I did.
That was the first and only interview, and about six weeks later they call me back in and the CEO made an offer. I reply that I'll need a few days to consider. CEO: "What? Why??"
Not even brain teasers or IQ. Just: can applicant FizzBuzz? Verboten!
This is how, in a mass job application world, enterprises end up with >80% of coders, all making 6 figures, that can't FizzBuzz.
A hack to get the enterprise to assess is find the third party SWE test providers to big brand logos the board recognize, brands under the same risk governance / regulatory regimes, and ask "what do we know they don't?" First, the board know and respect those brands. Second, the question makes the board consider what they think about those in charge of the failing capabilities internally. This is something now both easy for the board to discuss, and obviously done by good references. Ok, let's try empirical evals.
Countless such broken record warranting beliefs clanging around 100k employee enterprises. McKinsey, BCG, PWC, KPMG -- all they need to do to justify 8 figure bill for the year is undo any one of them.
"This is literally a Title VII violation."
Griggs v. Duke Power Co. held that "The [Civil Rights] Act [of 1964] does not preclude the use of testing or measuring procedures, but it does proscribe giving them controlling force unless they are demonstrably a reasonable measure of job performance."
Why do you believe that prior documentation is required, and that the absence of such documentation would make the testing illegal?
Check his blog and find out. I particularly enjoyed the part where the best way to improve public transport is to keep poor people out, not to increase frequency.
His suggestions for improving public transport are not relevant to this discussion.
EDIT: Hang on, I decided to just test the idea with the usual suspects and I don't see how you could design this in a way that works. You'd need some kind of non-contaminated testable outcome - lines of code etc. don't work - that is considered job performance which is scientifically validated in order to be able to survive the litigation that would follow the test.
I suppose the part that was wrong was that I claimed you can't run an IQ test. That's not true. You can. It just legally exposes you to a paperwork burden involving proof that it is required for job functionality - proof which you'll almost certainly fail because software engineer productivity isn't mechanically solved yet.
Is that the distinction? Listen, I've read your stuff and generally trust you and in any case I'm open to having my mind changed on this subject, but it seems like the actual thing is "Possible, but if you do it, you're going to find yourself in a massive paperwork and legal headache".
But I'm not aware of any evidence showing that is true.
And, even if it were true in the past, it seems that the DOJ believes that was based on a misinterpretation of the law. So it is less likely be true since June 2026: https://www.justice.gov/olc/media/1444871/dl
(The CEO doing the testing wasn't Japanese though - maybe Russian at a guess.)
The reason more companies don't do this is that the tests don't work well for this purpose.
and the provider is https://www.shl.com/
I took the practice test to completion that PWC recommends and just to give people an idea of these cognitive tests. It was a series of questions that went:
> Which statement describes you best?
> 1. I usually make decisions only after I have collected all relevant information.
> 2. I usually think of all factors when I am trying to understand a business issue.
> 3. I change my interaction style based on the personality of whom I am speaking to.
With a warning when you "go too fast". The test is supposed to take 16 minutes but finishes quite fast. I must imagine that these cannot be the only category. It also wasn't even clear how someone takes one of these to practice since it's impossible to get 'better' on them. There is no evaluation provided at the end. So one must conclude that 'practice' involves 'gaining familiarity with the testing system'.
Presumably the psychometric tests are wordsum, shape rotation, something numeric, but I couldn't find one for free to look at without applying so I'm content to just accept that it exists and move on with my life.
A. You answer it from memory. B. Have to actually solve it, which from my experience requires a bit of time.
It just seems awkward to have somebody look at you while they wait for you to solve some riddle.
To which I always reply "I just start beating the crap out of one at random - the reaction of the both victim and witness will tell me which is which."
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.
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.
[1]: https://leetcode.com/problems/stone-game/
[2]: return True
The answer seems pretty clear when you think about it enough, even the proof seems like it makes sense. The problem is marked Easy on Leetcode. But coming up with the algorithm and proving its correctness is a two-name algorithm with its own Wikipedia article. In your example, the challenge isn't even really to "design" that algorithm, it's to prove that it's true.
1: https://leetcode.com/problems/majority-element
2: https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_majority_v...
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
However, in my experience, if an interviewer can't confirm basic knowledge of data structures and algorithms, then some lead ends up having to teach computer science to explain to a developer why their code with 5 nested loops is probably not a good idea.
Having been that lead who has had to stay up all night trying to debug some difficult to reproduce deadlock or race condition ... I would prefer that companies spend resources on training rather than spending $5k to interview a candidate
agreed. However, as I read the parent's post, they did not immediately see that DFS was an acronym for a basic algorithm. Given their implied background in computer security, a field littered with thousands of abbreviations (very few of which are basic algorithms) it is understandable that they needed a minute to see what DFS meant.
I could alternately ask a number of python developers if they were familiar with Javascript object notation, and cause a panic because they aren't familiar with javascript. Interviews are stressful. If your field always call it 'json' or 'a dict', you might not immediately make the connection.
Funny anecdote about that:
I had written code with (in a nutshell) more than five nested loops because that's how password cracking works: try all the options. Someone in the presentation audience came from compsci education and asked if that isn't bad for performance. I really struggled to explain this basic logic of... like, yeah, it takes a while but what magic do you think exists to not do the password cracking algorithm (that indeed takes an indeterminate amount of time) yet get the password back from the hash (which was the objective of our research project)!
We got a good grade but I'm not sure if I was able to clear up this compsci student's confusion :p. They learned a theory but didn't know where to apply it
> However, in my experience, if an interviewer can't confirm basic knowledge of data structures and algorithms, then some lead ends up having to teach computer science [...]
Instead of making interviews a repeat of the exams that their diploma certifies, I'd suggest asking after the knowledge that you need/prefer them to have. E.g. we had a vacancy related to large-volume log data processing, so we gave people a challenge to answer simple questions about a large dataset which doesn't fit in RAM (e.g. "which city in the dataset had the most events"). The candidates, all in the last year or having finished compsci university, solved it in O(n) memory at best (some solutions were worse) instead of the O(1) solution¹ that seems obvious to me. They would, instead, split the dataset in a biased way and provide answers for the first slice only, often (not always) acknowledging it's a partial or biased solution and needs to be repeated for each slice, but not making the logical connection that if one can add up the results for the parts then maybe they could also just structure the code that way and process in a streaming manner for each record that comes in
I found it very insightful about candidates' ability to work with real-world data; that their algorithms class' theoretical knowledge doesn't translate if they haven't taught themselves that
Programming is commonly self-taught. I basically dropped out of high school to do a vocational school instead since I had already learned the basics, and there I'm not sure we covered algorithms for dealing with tree structures, I just know about that from the internet. In projects I've done for fun or for other jobs, it quickly becomes obvious which solutions perform and which ones don't. Looking up an existing algorithm to use is a lot quicker than knowing math theories and needing to learn programming from scratch still, so long as you know that performance in hot loops or UI threads is a thing to be aware of
¹ for(event in events){cities[event.city]++;} asort(cities);, excluding some wrapper code to e.g. associate event coordinates with a list of cities that we provided
To be fair, knowing the acronym "DFS" itself is not necessary - it reflects badly on the industry itself (not necessarily the candidate) that we're so bad at even agreeing what our shared jargon is.
The interview was literally nothing but back-to-back brainteasers and leetcode-challenges for 3 hours straight.
I didn't get the job even though I only failed to solve one problem, and looking back I think that the problem was in fact unsolvable and they wanted me to come to that conclusion rather than admit that I couldn't solve it in my head.
(Though personally I don’t think giving a truly unsolvable problem in an interview without warning that this may be unsolvable is a reasonable test of anything, but a cruel experiment)
Google, just like all other FAANG companies, uses a lot of Leetcode-style questions and there's no tendency for this to change so far. The thing that Google does is that they ban interview questions which were exposed on Leetcode, so they could've meant that you won't be given a question that is known to Leetcode crowds.
> looking back I think that the problem was in fact unsolvable
As for the unsolvable problem, this is weird, but when the company has tens of thousands of active interviewers, chances are that one of them will surely ask some bullshit question, and there is a very low chance that someone will ever let that interviewer know that they're not doing a good job. The lottery aspect always exists here.
I remember an MS interview I failed in 2015 or thereabouts:
As part of the interview, they asked "how would you find the kth element from the end of a singly-linked list in the shortest time", and they strongly implied that size() followed by counting forward was not what they were looking for, and that they were expecting constant space.
I didn't know the answer, and failed. I don't know if I failed because of it, but anyway.
So I went home and looked up the intended solution, which is the dual iterator, advance one k times then repeatedly advance both one step. After a bit of thought I realized that the time complexity is the exact same as the naive size() + count.
With size(), you do n traversals to get the number of elements, then you do n-k to get your iterator to the desired position. With dual iterators, you advance one n times and the other n-k times. Same deal, total number of steps is 2n-k no matter what, and linked lists usually aren't sequential in memory, so there are no cache benefits favoring one over the other.
There are other advantages to dual iterator-like algorithms (e.g. if it's a stream, you cache the k last seen values and pass only once at the cost of O(k) space; or if it's paging from very slow storage, it pages less due to locality). But they didn't say anything to indicate they were doing a stream. They were, essentially, just reading a puzzle from a book and expecting a particular solution.
Those are usually the first hints I give; mostly because I'm concerned about "everything else" in the coding question.
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.
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt
> It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical
One would expect folks coming from an elite CS program, and able to master Google's hiring processes, to be a bit more skilful.
Ironically all those four languages that get mentioned have quite advanced type systems, versus the one for "simple" minds.
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.
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?
Also: when we think about whether we've seen a problem or not before (in order to be honest during an interview), presumably this includes all problems we have a significant memory of, not just problems we've seen recently.
Love to know how many do build bridges, repair cars,..., on their spare time for job interviews.
You can study for the interviews you'd like to have, or the ones you'll actually have.
He applied for Microsoft.
They received a crash course in the power of Haskell ADT and `deriving (Show, Read)`.
[1] https://aphyr.com/posts/341-hexing-the-technical-interview
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.
No one uses binary trees or some manual form of serialization.
They use "superlib.search(arr)" or (seriliazer.parse(thingy)" and that's about it. No one cares about what it does. They just know it does it faster than something they could write. The only places that care about it are at the utmost peak of scale.
Heck, I run an API that gets tens of millions of reqs a day and I'm an idiot that couldn't computer science their way of of a paper bag.
I feel like people bend themselves out of shape trying to avoid these so-called "complex" or "esoteric" "only theoretical Computer Science" topics. You don't need a general purpose tree or graph manipulation library. Trying to make one ends up creating something far more complex than necessary and all you succeed in doing is making the calling code maybe two lines shorter but also not easily portable between projects, and also at a huge maintenance cost. It would be like trying to make your own, bespoke "Collection handling class" because you think trying to keep track of arrays and lists and dictionaries and sets and queues and stacks is too "complex, esoteric." No, you end up creating something complex and esoteric in the attempt to try to handle the erroneously identified "complexity."
In general, I don't think you can argue definitively on the uselessness of a piece of knowledge from a standpoint of ignorance of that knowledge.
I agree, I think those things are definitely worthwhile learning. But I don't think that it follows we should test for them in interviews.
It sounds like you've done some pretty impressive work around graph algorithms, but if a job doesn't need you to do this, testing for it is a little silly. (If it's a criteria you're explicitly hiring for, I think that's clearly different)
Got the job offer too, though I didn’t take it
(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 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.
Their goal is to find a "good fit", not to find a good engineer. That's why their software is so incredibly disfunctional: it's just a reflection of their workplace culture.
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...
That's interesting, the complaints I hear most often are about bloat and lag. I'm on Mac as a daily driver but whenever I use Windows I don't find much lacking, just maybe it's more optimized for different workflows. Do you mean in terms of features, or polish, or capability?
I think Windows has been getting more featureful lately, like the ability to link your phone, the ability to share files by short distance radio, and of course, some experiences entirely unique to Windows, such as Thunderbolt Share. A lot of the things you can do with macOS have some sort of Windows equivalent, even if it's more of an alternative workflow rather than a direct replacement. I never really felt like it was impossible to do things on Windows that I would have done on Mac, but I felt the difference everywhere.
Here's an example. macOS has had Spotlight for a pretty long time now. It can access any of my applications, or even any of my files simply by hearing the name, and nowadays (in the macOS 27 betas) it even has Siri. Maybe this counts as features. Windows does not have such a thing. Windows does have file search, but Explorer has to scan the directory tree each time, and the Start menu often doesn't find things well. (I recently heard they're looking to fix that, though?) There are third-party tools, like WizFile, Everything, PowerToys, now Raycast, etc. and I could perhaps look into those, but they just didn't seem to fit right.
I ended up organizing all the files I needed into a folder structure I could fully memorize, so that I could just recall the location of a file. That, to me, was faster than relying on search. In my opinion, that is somewhere Windows failed me. On Mac, I don't have to do that -- my files can be anywhere, organized however they were first created. It was such a relief to let go of all that folder structure once I moved back.
I will give Windows credit for allowing me to just start typing after hitting the Windows key -- that is almost entirely what allowed me to avoid the need for external tooling. That sort of thing is rare, though.
I will also note that the lack of QuickLook was annoying, but only until I picked up a piece of software from GitHub that scratched the itch well enough, and then I never really had to think about it again.
On to polish... I feel like Windows has terrible polish. I can feel every missed frame, every input delay, every animation glitch. The worst part is, it feels like every part of the OS is its own bespoke pile of hacks. The Start menu is not the Taskbar is not the modern Settings app is not Explorer is not the Notification Center is not Widgets is not the Win+Tab or ... like, fuck, dude. Then there's the administrative tools like Event Viewer, Task Scheduler, Microsoft Management Console, Group Policy Editor -- as you progressively peel back the modern abstractions, you reach a progressively more and more primitive base system with increasingly limited functionality, but of course, a lot of enterprise and business stuff.
This old tooling often doesn't work well on modern HiDPI displays either. Split views in those old apps are much more difficult to target because the dividers are sized in physical pixels. Lots of old software suffers from these problems, and the high-DPI scaling settings can be confusing (also, the filtering algorithm Windows uses to upscale pixelated bitmaps when you have it set to "System (Enhanced)" looks terrible to me).
To be fair, Windows has never treated high-DPI particularly well, because there are so many old low-level APIs and the way that software is rendered is simply the way that it is and it's just. Everything is so simple and straightforward, and that's the problem! Everything is so direct, so low-level, there's no room for the operating system to do the work for you. That's why there are all of these extra abstraction layers on top, that's why Microsoft keeps building more and more and more, but they're never quite happy with it and I'm not either. :/
I tried making a WinUI 3 app a few years ago. It was awful! Absolutely terrible. I was supposed to make the layout in this awful XAML format, and it took me forever to figure out how to do basic things like combine a tab bar into the title bar... and it was really difficult to understand how I was supposed to render dynamic content and. It just sucks :(
I also looked at the WinUI 3 library's XAML, did you know the text field widget's appearance is fully entirely implemented in that declarative garbage including the insertion caret and everything? It doesn't use the native OS facilities practically at all.
Contrast this to Mac where you can just pull in the same system frameworks that the system itself uses, hook up some objects and delegates and such and you have a fully functional user interface that supports all system-level actions and accessibility features. And because everything is object-oriented, you don't have to constantly reimplement it all from scratch to do anything special!!
Oh, also, I hate rebooting Windows because it suuuucks at reopening my programs. Windows has a much fuzzier model of applications than macOS does, so you don't even necessarily know which processes to restart and how, and also none of the applications are necessarily going to restore their state properly because they weren't necessarily designed for it, etc. On Mac, I'm not afraid of reboots! I just close down the stuff I don't need to stay open, then just tell it to reopen my windows after the reboot. It's so much better.
As for capability... Windows is capable of a lot, especially since it's typically the one platform for developers to support (first/ever), and it can even do some things Macs can't yet (like Thunderbolt Share!), but I'm more often frustrated to find something available only on Windows, than I am grateful for practically anything Windows has ever done for me.
Windows absolutely has some good parts, and I know at least a few people who absolutely love the idea of the NT kernel, but the way the overall system is just seems really, stupid!! for lack of a better word. It feels dumb, maybe designed for dumb users, but... dumb nonetheless. I want to say braindead, it doesn't feel quite that bad, but Microsoft has been screwing up a lot more lately and that certainly feels kind of braindead.
People really like to make fun of Apple for "dumbing things down" and "treating their users like idiots" but I honestly feel like Windows is worse with that? At least I feel like an idiot when I use Windows because I don't understand how the people that made it even thought any of it up. After being exposed to the low-level primitives of Apple operating systems (I used to tweak iOS back when that was possible, before I ever had a Mac) even after growing up with the primitives of Windows, Apple just made so much more sense to me, and felt so agreeable and so much better compared to Windows that I have just never been able to understand where Windows even comes from. It literally feels so alien in the dumb way.
The worst part is a large part of the Internet will literally just gaslight me and say I'm an Apple sheep for agreeing so much with their software, but I just have nothing else!! Apple feels like one of my last hopes in this world for secure hardware and software that I own, and they've really been struggling to stay that way lately but I really hope they pull through, especially with the new CEO.
Lol, I'm increasingly wary of whatever SV / startup circles prefer nowadays... The shitload of BS is ever forthcoming.
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".
Those are the worst. No, I don’t feel like I need to let Bob feel heard. Bob wants to create a nightmarish stack involving ElasticSearch and Kafka for a problem that grep and a flat text file could realistically handle. I have already explained to Bob that his solution is unnecessarily complex.
Look mate, software is business and business is marketing. If your solution really is better, you need to market it as such, even to the Bobs of the world. Especially to the Bobs of the world. If you couldn't present it in a way such that it's obvious to Bob and everybody else that your solution is better, that's a failure on your part, not Bob's, the other participants', or the meeting organizers.
A real anecdote: I once had to explain to other software engineers, during a retro, that the aggregate bandwidth their queries demanded for the result set was far in excess than that of the DB’s capabilities.
“This would’ve required 230 Gbps, assuming the DB could’ve fulfilled it.”
…
“That’s more than a typical top-of-rack switch.”
…
“It’d be like filling 69 Blu-Ray discs every minute.”
“Ohhhhh.”
The switch analogy may have gone over their heads, admittedly, but the fact that 230 Gbps on its face didn’t sink in is distressing. Entirely too many devs don’t understand any fundamentals, and as such they can’t do basic back-of-the-envelope calculations, and we wind up with Bobs.
I invite you to go to any Arab country and tell them to legalize gay marriage.
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.
I feel like after presenting a great solution to the stupid, cryptic, arbitrary interviewer games where you have to guess the rules on your only attempt at playing the game, you've added one at the last minute. What if one of the values is attention to detail?
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.
(This was a long time ago, during the Ballmer era. Just my personal 2 cents.)
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.
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
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 went in totally unprepared for logical tests, and flubbed the perfect answer partially, but it was funny because I asked the guy if I was "doing an interview to be an electrician or a software developer?".
Since then I've been just fine, and to this day, I've never had to answer that question nor use that type of logic on any job... I reverse engineer & migrate major software apps all the time as a Solutions Architect & Development Director.
I've always found interviews that involve behavioral and cognitive tests to never be good for me as long-term jobs... Now I interview & hire people regularly without asking those types of questions at all because the questions can too easily be studied & rehearsed prior to interviews.
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.
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.
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.
I've never interviewed there, or been asked that question, but I think it would be a lot of fun to answer.
Wait 1s.
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.
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.
Most of the pushback is from dull corporate programmers (no shame in that, so am I) who want to claim that they are hackers for the clout but aren't. Ironic that a site named Hacker News is almost entirely devoid of true hackers.
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.
Those are broadly interesting behavioral signals but very subjective, and possibly less relevant than ‘do they enjoy figuring out puzzles that they don’t really understand the significance or relevance of?’
In an industry that loves calling itself "engineering", it seems nothing further of value can be established?
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.
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.
“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.
Besides... many players in the market actually seek people with "moral integrity" (or whatever the fashionable term is nowadays).
I know a guy who worked for a prestigious accounting firm and was the dead-honest type. Everyone was inflating their billable hours to clients, except for him. He was 100% truthful on his hours and made sure not to waste any client money, but still got just as much work done as his colleagues who were inflating their hours. Guess who was the first target during layoffs?
If you don't want to play the game that's totally fine, but I wouldn't be surprised if giving yourself a disadvantage didn't hurt in the long run.
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.
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
Source: as an interviewer, I had to sit in that meeting.
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.
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.
Nowadays, with x64 and AArch64, the first several arguments will be passed in integer or floating-point registers.
The rejection was so generic and there's so much random bs that goes on it could be anything that lead to that result.
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 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
What a great way to filter out talented people. Great times. Very character building.
I have had an interview or two where I got a programming challenge, and I was able to solve it with intuition. I don't know exactly if I didn't explain my reasoning well enough, or if my code was just too messy even though the tests passed, but I didn't get the job.
Sometimes they want some insight into how you think, and they might not get it even if you solve it.
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.
I think someone without an "aha moment" can use a question like this to nail an interview:
Candidate: thank for your the questions. I don't immediately see how we can solve this by using the scale only 3 times. What I would normally do in situations like this is explore a simpler problem to get an understanding of the space and some solution that works and then try to improve it. Can I try that?
Interviwer: absolutely. Makes a note: candidate able to propose an approach when answer not obvious. Able to nareare their thinking.
Candidate: let me think about a naive solution first. We just weigh the balls in pairs. If two balls weigh the same then neither is the answer. If the pair doesn't weigh the same then one is the answer but we don't know which one. So we need to compare one of them against any of the other balls: if the scale is unbalanced then that one is the answer, otherwise the other one. I think this tells us which ball is the answer but obviously we use the scale too many times. In this case at best we use the scale twice and at worse seven times.
Interviwer: great - I agree this works but uses the scale too much. How can we improve it? Makes a note: candidate able to design a simple algorithm that gets the answer.and evaluate its performance.
Candidate: the fact that we have to do the final weighting even after we know which pair has the imbalance and the fact that I can compare against any other ball seems interesting. Let me think about that for a second.
...
Hmm hmm hmm
...
Hmm hmm hmm
(Fails to have the aha moment)
Interviwer: ok that's a good insight. What if you could place more than one ball on each side of the scale at a time? (Gentle hint that can put the candidate on track without giving away the answer)
Candidate: oh interesting! I wasn't visualizing it that way.
...
Ok! So we have the pattern of "figure out which pair has the imbalance and then which one in the pair is the weird one" so now we can generalize it
Let's try this: I weigh 3 vs 3. If balanced, it takes me 2 weighings to figure out which set of 3 contains the answer. And from there another 1 or 2 to figure out which of those 3 balls is the answer. So now our "worst case" has gone from 7 to 4. That's better but still falls short of our goal of course ...
Interviwer: Makes a note: candidate is open-minded to feedback and made good use of a subtle hint to improve their solution while still realizing the goal is not met.
OK! this is a good improvemen. There was something interesting you said: that it could take 1 or 2 weighings to figure out which ball of the 3 is the answer. I am curious about the case when you can do it with 1. What's that about?
Candidate: well if we weigh two balls and they are the same - that tells us something about the one we didn't weigh. OH! Ok I see why you are drawing my attention to that.
What if we took the same approach to the initial step of the problem. Let's try: split the 12 into 3 sets of 4...
(Etc etc)
Interviwer: this was fun! Thanks for working through this problem with me
Makes a note: candidate is a solid problem silver, able to define and analyze a solution and look for improvements. Did not give up. Listened carefully and made good use of hints provided. Able to show transpancy into their thinking and collaborative. Would not hesitate to bring them on the team, leaning hire.
Better than "this is a bad question, I hate puzzles" huh.