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've too many wacky interview stories to list here, but the first time I came to this same conclusion was when I had an interviewer interrupt me mid-answer to correct my pronunciation of "idempotent" (because I said it in what is apparently a more British fashion). I asked him to repeat himself to see if he'd apologize or brush it off as a tic and he repeated himself with an elevated level of contempt. I declined the offer, that company got bought by McKinsey a year later, and everybody lived happily ever after.
A long time ago, maybe 2016, I interviewed at Paperless Post. The interviewer asked me explain the concept of a promise in javascript, then asked me to implement it from scratch, then asked me to extend it with different features like promise.all.
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.
I had an interviewer once interrupt me and say that there was no way I could remember the techincal details of a 10 year old project I was the architect for, thus any details I did offer would likely be lies. Needless to say, I didn't get an offer nor would I have accepted it.
I had an interviewer once interrupt me and say there was no way I would have studied gray codes in college. I still don't know if that was some bias that I went to a "provincial school" in their mind or that they hadn't noticed my Master's degree or that my degree program also involved a lot of hardware and electronics work or just that they didn't study it in college and were secretly telling me how useless their fancy "West Coast Ivy" degree program was for them.
I made the mistake of letting that company bring me back for a second "less technical" round of interviews, but I shouldn't have.
The only goal of an interview for the interviewee is to get as much money as possible. If they're offering really good money, you need to pass whatever obstacles they have. If they're not, why are you there?
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.
> 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.
And when you break the rules, you get absolutely no feedback. You don't even know if you break the rules, or you were just beat by a candidate the interviewers preferred. I had to go through the process last year and hated almost every microsecond of it, except my interview with the place that actually hired me.
Back in the 90s, looking for a job wasn't so bad. Now it's a nightmare.
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.
> 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.
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
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.
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.
I actually don't think it's good to ask for feedback. Mainly for the reason you said here:
> 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.
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.
You avoid people problems by interviewing soft skills as soft skills, not building elaborate mazes of "technical interviews" that are really soft skill interviews testing how pedantic you want to be or how much you want candidates to sweat in soft skill-dominant conditions that don't resemble your job that you are hiring for.
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?
This reminds me of the weirdest interview I ever had (boutique software agency, maybe 30 devs).
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??"
I interviewed at IBM back in the mid-90s right out of college for "Internet consultant". I was given an aptitude test and the hiring manager said that I scored one of the highest he had ever seen. He then proceeded to not give me the job because I didn't have enough experience, which is something they already knew before making me jump through hoops. It was so dumb, but it pretty much exemplifies IBM-thinking.
This can't have been recent. Or perhaps it was and they violated the law. A standard IQ test is probably quite good at assessing if you'll be good at a programming job but it is also quite illegal unless it has passed through a battery of compliance paperwork - which it actually cannot pass because it would require the output of IQ tests to be race-equal and they cannot be both an IQ test and race-equal. This is literally a Title VII violation.
"illegal unless it has passed through a battery of compliance paperwork"
"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.
You might alternatively prefer the ones about how health insurance never denies care, Luigi Mangione was a bad guy, or Democrats have made it profitable to be a victim.
Wow, I am entirely wrong here, huh? I thought that "demonstrably a reasonable measure of job performance" was held to the standard that it had to be proven fair (and consequently documented to have proven job impact).
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".
Your last statement is closer to the real situation, but you make it sound like it's certain that you will be called upon to defend the legality of your actions.
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
Several (not many relative to the total industry, but several) large household-name companies publicly do general cognitive testing for white collar roles, and the companies that administer these tests have logo crawls just like any SAAS company of their clients. These companies have enormously deep pockets and would be juicy targets for employment law practices. But nothing happens, because this is mostly not a real thing.
The reason more companies don't do this is that the tests don't work well for this purpose.
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.
I'm a broken record about this, but no, it's not illegal to administer IQ tests in white-collar employment, and it doesn't take a battery of compliance paperwork to do so. This is an Internet myth.
Oh yeah the estimation problems are terrible. The probability ones are at least notionally trying to test your math skills. But still pretty far from being relevant in almost all cases.
Having had to estimate peak user traffic patterns, bandwidth usage, etc. for continent-scale services, Fermi estimation questions (https://en.wikipedia.org/wiki/Fermi_problem) are excellent questions for people working at the largest scales. Even if the guessed inputs or formula for the estimate are imperfect, being able to bang out an approximate formula that can brought out for discussion with peers and refined into something that can be agreed upon as a target is extremely valuable. It's not a useful skill for everyone but for those aspiring to be more than a mere coder, it's worth knowing.
Years ago, I read a book titled How Would You Move Mount Fuji? [0] about the cult of Fermi Questions [1]. These are questions where you're looking for an order of magnitude. The cult of Fermi Questions in Silicon Valley started with William Shockley [2] using them in interviews. Several of his smart dudes quit to start companies you may have heard of like Intel, AMD & Fairchild [3].
Things that open-ended are ripe for abuse, which is to say when you have a team of white techbros, guess which candidates get high marks on these ad-hoc questions?
Companies are groups of people behaving a certain way, and jobs are behaving that way. As an outsider, you don't know what the job is. If the interview is a bunch of questions you think is stupid, then the job is probably doing a bunch of stuff you think is stupid. If you want the money and prestige anyway, then learn to do the stupid stuff.
You understand that this is a job interview working as intended? You may be awesome at the work but your values do not align with the company’s and it’s best if you don’t work there.
So if somebody tried to solve the brainteaser with an impossibly high likelihood of being completely wrong. You get the signal that their values match yours, they are open minded and that they are good at writing great programs?
Again, I’m not saying that job related questions are bad. I’m saying that these types of questions can be good. You can ask more than 1 type of question!
Mostly of the same basket and equally bad, on my experience, because usually it is some dude or gal, that rather be coding than doing interviews that gets dragged to question this guy that just dropped on reception for the interview.
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.
Honestly that may be just the reaction the company was hoping for which is both valuable for you and them. You save time not going through an interview for a place you might dislike and they get to move on quickly.
Seniors are not welcomed by most companies, because we already seen all movies management pulls up employees to trick them "doing more with less".
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.
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
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.
This is starting to sound like the old joke about a coconut laden swallow from (the film) The Holy Grail. I would pay to see the interviewer sweat as you ask the follow-up questions! You sound like fun at a party!
The intake rate of a microscopic black hole is too small to measurably absorb much matter before it falls through to the bottom of the lake until it reaches the center of the planet and oscillates there.
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.
According to wikipedia, microscopic is considered up to 1 micron. [1] According to the Schwartzchild formula [2] r=(2Gm)/(c^2) so if I take the largest black hole the definition would allow, the mass would be about 10% of the moon. You'd feel 1G at about 60km distance because of it. But indeed, it would fall and take about 20 minutes to reach the core of the planet, while displacing a whooping 1gram of matter. Kind of funny how wierd this whole thing is.
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?
I'm not sure what other effects I should ignore, but the mass would increase. The ball gains relativistic mass as it accelerates towards the black hole.
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.
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.
First one depends on the bowling ball. Most alleys have balls ranging from 7lb to 16lb, all the same volume, and the crossover point where they’d sink is 11.6lb.
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.
I think you're counting the overall sphere as the volume, but water would leak in through the finger holes so only their actual material counts. I suspect different weight bowling balls generally have different volumes.
That's what they meant by "in boat displaces its weight in water". While it's in the boat, the amount of water it displaces weighs as much as the bowling ball. While it's in the water, it displaces the volume of the bowling ball, and its weight doesn't matter. The ball is denser than water (since it sinks), so the amount of water it displaces based on its weight is bigger than the amount of water it based on its volume.
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.
"I was asked the classic "fork in the road, two guys, one always tells the truth and one always lies" 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."
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.
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.
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
I understand where you're coming from and can empathize because I've been asked some absurd computer science questions in interviews.
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
> an interviewer can't confirm basic knowledge of data structures and algorithms
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.
Dunno, there are very few universal knowledge checks that would work across the entire industry, but my two absolute baseline standards for anyone who would be coding are 1) knows how to version control, and 2) can comfortably traverse a graph.
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.
Several times I have implemented topological sorts and parsers as part of routine work in very ordinary tech jobs. I think it is absolutely incorrect to say that these tasks are tantamount to implementing your own crypto. They are not things you do every day, but they are basic informatics and to be honest if a developer told me that they could never conceive of implementing them in their job I would be inclined to regard them as someone who was working without a full toolbox, so to speak.
That might just be my world in which the acronym DFS has a single well defined meaning; but of course the interview question never says "implement DFS", it will be a kind-of-real-life coding exercise that can be solved by a graph traversal, like checking if some nested structure has a loop.
I had an interview with Google about 10 years ago. Everyone said "Google doesn't ask brainteasers or leetcode-challenges any more".
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.
> Everyone said "Google doesn't ask brainteasers or leetcode-challenges any more"
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.
Haven't encountered "marbles in an airplane"-style brainteasers, but leetcode challenges are definitely still the norm at Google and other big tech. Not sure who was claiming otherwise.
(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)
> The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided.
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.
The interviewer probably learned the trick with two pointers and wanted to see you implement it, for no real reason. This question, just like it's well-known sibling question "check if the linked list has a loop", has absolutely no practical applicability; no one will ever want to find k-th element from the end of the linked list, it's just not the right data structure for this kind of task: it's better to use an array or a double linked list if you need to do this operation often.
In my corner of the Faang world it's been 20 years since that sort of brain teaser was asked. We switched to coding problems that require dynamic programming!
>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.
I've been doing "daily leetcode" for fun, just to remember how to write code manually without agents, and a few days ago they gave a brain teaser kind of task [1], for which the solution was just [2] (spoiler alert). It took me quite some time to come to that solution, and I'm not really sure I would've found it with all the stress of being on a real interview.
Yeah one of the worst offenders of this are the leetcode problems that have a clever but extremely elegantly simple greedy algorithm (such as "return True" lol). Great example is Majority Element [1]
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.
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.
I think it's because most of us don't do CS once we graduate. We build APIs and websites which don't involve CS at all. It barely involves engineering. lol.
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'm not some Google/Microsoft/whatever engineer who's been working on highly scalable, highly available systems. I've mostly worked in consulting on small projects. I have never not had problems with the defaults on any of those sorts of libraries. I've almost always had to roll my own graph manipulation and heavily customize any serialization system I've used. And when I do so, because I've gotten good at doing it (in particular, I don't think of the graph stuff as being hard at all), it makes tons of other stuff inside around the project a lot easier.
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.
> 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.
Google was more elitist than most in its early years. As I recall, candidates had to have graduated from an elite CS program with and provide a transcript when applying showing top grades.
> 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 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.
Now that you spell it out, I guess this just binary search. You need O(log n) weighings because each weighing splits the search space in half. So I was wrong it’s not an information theory question, it’s just comp sci algorithms. I got my college classes mixed up (it’s been 14years)
Exactly. Same kind of thinking gives you bounds on what can be done. For example, can you do 13 marbles in 3 weighings? 213 < 3^3, so maybe (though I think not). Can you do 14 marbles? 214 > 3^3, so definitely no.
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.
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.
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.
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.
> 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?
We're specifically talking about people who are interviewing for jobs - I'd expect a lot of them to have done leetcode before the interviews.
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.
Really, do you expect folks to dust off their algorithms and data structures from 30 years ago, instead of what they have been doing the last decade on the job?
Love to know how many do build bridges, repair cars,..., on their spare time for job interviews.
Yeah, it's weird (to me and you at least) why people bother quizzing industry veterans. After 10 years in the workforce you should be able to talk shop about various experiences you had at work (NDA permitting) and drop down to technical details where appropriate. Yet some companies or interviewers insist on techniques that could be replaced with asking the potential hire to eat boogers on camera for a stronger signal of what they're actually looking for.
> 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...
Right, that was the Ballmer era, and when pg pronounced them dead. But I do think that perspective didn't appreciate the coporate Game of Thrones (https://substackcdn.com/image/fetch/$s_!Vk-D!,f_auto,q_auto:...) Ballmer had to play to pave the way for Satya to remake Microsoft from a Windows + Office company to an Azure + Windows + Office company.
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.
> Windows feels so basic and primitive compared to other operating systems.
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 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.
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:
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`"
At one point earlier in my career (during the early 2000s), they flew me to Chicago, picked me up in a limo and gave me a tour of the office... I knew I didn't want to relocate (from the East Coast) and remote work wasn't an option back then, so I had nothing to lose... They asked me the question of "4 lightbulbs in a room down the hallway, with 3 light switches in the room I'm in" to tell which switch belonged to which bulb...
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.
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".
> I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard.
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.
But is your solution scalable? Resilient against injection attacks? What about o11y? Is literally anyone besides you going to be running these searches? If so, you're going to want to put a UI around it and that means thinking about scalability, data sanitization, and o11y. Maybe Bob knows something about the scope of the problem that you don't?
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.
It is not my responsibility to teach critical thinking and a CS degree to Bob, nor is that in my job description. If Bob can successfully convince our boss and finance team that his solution is necessary, then so be it; I will continue banging my head into the wall.
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.
> 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.
I invite you to go to any Arab country and tell them to legalize gay marriage.
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.
> Bonus: put some typos in the quiz that don't matter. Red flag for the people that get hung up on that.
I feel like after presenting a great solution to the stupid, cryptic, arbitrary interviewer games where you have to guess the rules on your only attempt at playing the game, you've added one at the last minute. What if one of the values is attention to detail?
Attention to details that matter and knowing what to pass on, is what's important. If they did poorly on the important stuff but then point out the typo, clearly they were putting their efforts in the wrong places
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.
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.
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.
Coming from another experienced dev who was frustrated (early) - one tip. Don't over think it. I was tripping up in two system design interviews that ultimately boiled down to them wanting laughably basic answers (one pagination, the other a db transaction). Don't be afraid to deal in basics and then directly ask if they'd like something more detailed, or not. Many places, especially non-elite ones, treat system design as a _very_ basic test of knowing how pieces fit together.
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.)
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.
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)
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.
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.
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.
Gah, I can't remember what the specific trivia was now (ironically), just that some disk wasn't mounting and something in the fstab stuck out to me that I then looked up in the manpages and confirmed was wrong. (I wasn't even the AIX guy, I was just the sysadmin of an app that ran on AIX.)
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.
It does; the old school hackers, the people who built the computer and software industry, loved logic puzzles / brainteasers and elegant, high performance solutions to coding challenges.
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.
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.
The answers to this questions will tell you whether the candidate is a good storyteller, whether they have been lucky or unlucky in group project assignments, and whether they can spin experiences as self promotion.
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?’
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.
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.
Totally agreed. Capitalism is just a game of competition, and if you want to win the game you should take all advantages that you have. Pretty much everyone else you're competing against will be doing the same.
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.
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 ?
Depends on your school of ethical thought. If you're a consequentialist, sure. But I'm very much not a consequentialist, so I don't think that it's morally correct to do a bad thing in order to achieve good ends.
> 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)
I've seen candidates breeze through the basic version of a question they claim to never have seen when asked and then choke hard when the requirements are modified slightly. Honesty is the best policy, kids.
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.
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.
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.
FWIW, in most architectures the first few function arguments get passed in registers. But so many of today’s programmers grew up with 32-bit x86, which has a paucity of registers, that they mentally shortcut to “every argument gets passed on the stack”.
Nowadays, with x64 and AArch64, the first several arguments will be passed in integer or floating-point registers.
Wow, I got the same question, wonder if we interviewed with the same dude.
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.
I’ve been through the Microsoft loop(s) several times over the years, and (to borrow from Tolstoy) each was unhappy in its own way. There were great people who would have been a pleasure to work with but always at least one joker in the deck. One just had to laugh because it was so obvious it wasn’t me.
I remember speeding through the loop for something closely analogous to my job at the time, only to be suddenly told by the hiring manager (who up to that time was a strong supporter) in a final interview that I wasn’t qualified. Not wanting to invest any more energy, I formally withdrew, only to get a call from him protesting why I’d do such a thing. Or being told to leave at the end of the day only to be called to drive back 20 miles immediately during dinner, and finding out later that was a mistake. Or being literally screamed at (spittle in my face!) that HPC was only MPI and nothing but MPI. Or being yelled at that Windows Server was exactly the same as an enterprise storage system like EMC/HP/Hitachi. The hits go on.
As 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 hate such interview questions. They have nothing to do with think one really needs to do in practice. It seems for me to be just a way for interviewers to show their intellectual superiority.
> "I 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.
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.
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.
so funny to read the reactions here. "Puzzles are stupid and hiring is broken" without thinking about how to navigate a question like that.
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.
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've too many wacky interview stories to list here, but the first time I came to this same conclusion was when I had an interviewer interrupt me mid-answer to correct my pronunciation of "idempotent" (because I said it in what is apparently a more British fashion). I asked him to repeat himself to see if he'd apologize or brush it off as a tic and he repeated himself with an elevated level of contempt. I declined the offer, that company got bought by McKinsey a year later, and everybody lived happily ever after.
A long time ago, maybe 2016, I interviewed at Paperless Post. The interviewer asked me explain the concept of a promise in javascript, then asked me to implement it from scratch, then asked me to extend it with different features like promise.all.
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.
I had an interviewer once interrupt me and say that there was no way I could remember the techincal details of a 10 year old project I was the architect for, thus any details I did offer would likely be lies. Needless to say, I didn't get an offer nor would I have accepted it.
I had an interviewer once interrupt me and say there was no way I would have studied gray codes in college. I still don't know if that was some bias that I went to a "provincial school" in their mind or that they hadn't noticed my Master's degree or that my degree program also involved a lot of hardware and electronics work or just that they didn't study it in college and were secretly telling me how useless their fancy "West Coast Ivy" degree program was for them.
I made the mistake of letting that company bring me back for a second "less technical" round of interviews, but I shouldn't have.
> IMHO he shouldn't change his answer to please the interviewer
Which is why I never lie in interviews. If I don't make your cut, I might be dodging a bullet.
Yes, strongly agree with this.
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 :)
Unfortunately most people have a problem with starvation and homelessness, you'd almost swear they're allergic to those things.
The only goal of an interview for the interviewee is to get as much money as possible. If they're offering really good money, you need to pass whatever obstacles they have. If they're not, why are you there?
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.
> 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.
> 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.
And when you break the rules, you get absolutely no feedback. You don't even know if you break the rules, or you were just beat by a candidate the interviewers preferred. I had to go through the process last year and hated almost every microsecond of it, except my interview with the place that actually hired me.
Back in the 90s, looking for a job wasn't so bad. Now it's a nightmare.
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.
> 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.
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
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.
> 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?
These are good questions to ask.
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.
I actually don't think it's good to ask for feedback. Mainly for the reason you said here:
> 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.
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.
You avoid people problems by interviewing soft skills as soft skills, not building elaborate mazes of "technical interviews" that are really soft skill interviews testing how pedantic you want to be or how much you want candidates to sweat in soft skill-dominant conditions that don't resemble your job that you are hiring for.
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?
This reminds me of the weirdest interview I ever had (boutique software agency, maybe 30 devs).
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??"
I interviewed at IBM back in the mid-90s right out of college for "Internet consultant". I was given an aptitude test and the hiring manager said that I scored one of the highest he had ever seen. He then proceeded to not give me the job because I didn't have enough experience, which is something they already knew before making me jump through hoops. It was so dumb, but it pretty much exemplifies IBM-thinking.
Thats a particular type of insane that might have been fun to take the offer
At least he didnt came out with a measuring tape and tried to measure your skull.
That's silly! Everybody knows it's the shape that shows the intelligence, not the circumference!
This can't have been recent. Or perhaps it was and they violated the law. A standard IQ test is probably quite good at assessing if you'll be good at a programming job but it is also quite illegal unless it has passed through a battery of compliance paperwork - which it actually cannot pass because it would require the output of IQ tests to be race-equal and they cannot be both an IQ test and race-equal. This is literally a Title VII violation.
"illegal unless it has passed through a battery of compliance paperwork"
"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?
> Why do you believe that ...
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.
Is there a specific page on his blog that answers my question?
His suggestions for improving public transport are not relevant to this discussion.
You might alternatively prefer the ones about how health insurance never denies care, Luigi Mangione was a bad guy, or Democrats have made it profitable to be a victim.
From your descriptions they don't seem relevant to this discussion.
It identifies a certain type of person.
Wow, I am entirely wrong here, huh? I thought that "demonstrably a reasonable measure of job performance" was held to the standard that it had to be proven fair (and consequently documented to have proven job impact).
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".
Your last statement is closer to the real situation, but you make it sound like it's certain that you will be called upon to defend the legality of your actions.
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
Got it, thanks. That's helpful.
Several (not many relative to the total industry, but several) large household-name companies publicly do general cognitive testing for white collar roles, and the companies that administer these tests have logo crawls just like any SAAS company of their clients. These companies have enormously deep pockets and would be juicy targets for employment law practices. But nothing happens, because this is mostly not a real thing.
The reason more companies don't do this is that the tests don't work well for this purpose.
It seems to be quite accurate that many of these tests are publicly referenced. e.g. (PDF warning) https://www.pwc.com/m1/en/careers/documents/assessment-proce...
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.
I'm a broken record about this, but no, it's not illegal to administer IQ tests in white-collar employment, and it doesn't take a battery of compliance paperwork to do so. This is an Internet myth.
Well, you and rahimnathwani up there have convinced me. Now I have to go around and deprogram everyone I said this to...
It's a really widespread myth, hard to fault anybody for believing it. There's even a kernel of truth to it (Griggs).
Would you mind helping me understand what degree the truth is? More here about my confusion: https://news.ycombinator.com/item?id=49171999
I've always wondered about these brainteasers: do interviewers really expect people to solve them? The truth/lie one is pretty well known so either:
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.
Here a few additional teasers,
- 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.
See how you fare with these:
https://subway-kann.exe.xyz/
Oh yeah the estimation problems are terrible. The probability ones are at least notionally trying to test your math skills. But still pretty far from being relevant in almost all cases.
Having had to estimate peak user traffic patterns, bandwidth usage, etc. for continent-scale services, Fermi estimation questions (https://en.wikipedia.org/wiki/Fermi_problem) are excellent questions for people working at the largest scales. Even if the guessed inputs or formula for the estimate are imperfect, being able to bang out an approximate formula that can brought out for discussion with peers and refined into something that can be agreed upon as a target is extremely valuable. It's not a useful skill for everyone but for those aspiring to be more than a mere coder, it's worth knowing.
Years ago, I read a book titled How Would You Move Mount Fuji? [0] about the cult of Fermi Questions [1]. These are questions where you're looking for an order of magnitude. The cult of Fermi Questions in Silicon Valley started with William Shockley [2] using them in interviews. Several of his smart dudes quit to start companies you may have heard of like Intel, AMD & Fairchild [3].
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
3 - https://en.wikipedia.org/wiki/Traitorous_eight
Not everyone dreams to found the next unicorn, real life for most of us isn't the Silicon Valley TV series.
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 think those questions are good ways to assess open mindedness, estimation, and verbal communication skills.
There are other ways to assess those skills, sure. But questions like that aren’t bad ways.
Things that open-ended are ripe for abuse, which is to say when you have a team of white techbros, guess which candidates get high marks on these ad-hoc questions?
Hot Asian milfs?
From the comment I was replying to:
> 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?
Ideal would be if the questions are actually job related, how many other professions do you think get these kind of stupid questions?
Since we are it, lets make Jeopardy for getting a job.
Companies are groups of people behaving a certain way, and jobs are behaving that way. As an outsider, you don't know what the job is. If the interview is a bunch of questions you think is stupid, then the job is probably doing a bunch of stuff you think is stupid. If you want the money and prestige anyway, then learn to do the stupid stuff.
Which is why, as mentioned, unless I am desperate for a job, I walk out.
Or maybe the job is about actually carrying golf balls into planes.
I bet it is about solving the daily brain teaser of working with unmaintainable code!
I thought we had Fable for that now.
You understand that this is a job interview working as intended? You may be awesome at the work but your values do not align with the company’s and it’s best if you don’t work there.
I do understand that these are stupid ways to achieve that goal.
So if somebody tried to solve the brainteaser with an impossibly high likelihood of being completely wrong. You get the signal that their values match yours, they are open minded and that they are good at writing great programs?
Again, I’m not saying that job related questions are bad. I’m saying that these types of questions can be good. You can ask more than 1 type of question!
Mostly of the same basket and equally bad, on my experience, because usually it is some dude or gal, that rather be coding than doing interviews that gets dragged to question this guy that just dropped on reception for the interview.
Its funny how some people react to these?
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.
Honestly that may be just the reaction the company was hoping for which is both valuable for you and them. You save time not going through an interview for a place you might dislike and they get to move on quickly.
Yeah I can see people using these as proxies for age discrimination
Seniors are not welcomed by most companies, because we already seen all movies management pulls up employees to trick them "doing more with less".
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.
I have no idea and want the answers:
Boat + bowling ball = level stays the same?
Ball roll = the constant gradient is quickest?
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
> 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.
This is starting to sound like the old joke about a coconut laden swallow from (the film) The Holy Grail. I would pay to see the interviewer sweat as you ask the follow-up questions! You sound like fun at a party!
You drop a microscopic black hole off a boat into the lake. Does the water level increase or decrease?
The water level decreases, along with the shore and anything with it falling within the event horizon. Any other apocalyptic brain teasers?
The intake rate of a microscopic black hole is too small to measurably absorb much matter before it falls through to the bottom of the lake until it reaches the center of the planet and oscillates there.
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.
According to wikipedia, microscopic is considered up to 1 micron. [1] According to the Schwartzchild formula [2] r=(2Gm)/(c^2) so if I take the largest black hole the definition would allow, the mass would be about 10% of the moon. You'd feel 1G at about 60km distance because of it. But indeed, it would fall and take about 20 minutes to reach the core of the planet, while displacing a whooping 1gram of matter. Kind of funny how wierd this whole thing is.
[1] https://en.wikipedia.org/wiki/Microscopic_scale
[2] https://en.wikipedia.org/wiki/Schwarzschild_radius
I think a microscopic black hole would evaporate very quickly from Hawking radiation, so the result might be more bang than suck.
Sure, but the mass is not specified so I just assumed the closest one to cosmic horror.
You invert the phase of the Higgs field within a basketball. What happens?
I believe this would nucleate a cosmic string (and annihilate everything in its vicinity obviously)
The universe becomes suddenly VERY different, while a ghostly rendition of the Harlem Globetrotters theme whistles eerily in the background?
(I actually don't know the answer to this)
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?
The mass of the observable universe has probably changed a lot by the time the bowling ball hits the bottom.
I'm not sure what other effects I should ignore, but the mass would increase. The ball gains relativistic mass as it accelerates towards the black hole.
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.
You drop a black hole the size of a bowling ball into a frontier AI startup.
At what point does NVIDIA give you $200bn?
At the point nvidia's office becomes part of the accretion disk.
Will a one ton marble embed into the lake bed?
Why does it matter?
First one water is lower. Ball is more dense than water, in boat displaces its weight in water, in water displaces it's volume
Dip for hill roll is faster
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.
First one depends on the bowling ball. Most alleys have balls ranging from 7lb to 16lb, all the same volume, and the crossover point where they’d sink is 11.6lb.
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.
I think you're counting the overall sphere as the volume, but water would leak in through the finger holes so only their actual material counts. I suspect different weight bowling balls generally have different volumes.
Bowling balls aren't hollow, they're solid spheres with finger holes drilled in. The varying weights comes from having weighted cores inside.
Oh OK thanks, I didn't realise. I just had some fun looking at bowling ball cross sections.
Also if the lake is a mile deep it would pressure the ball more than the air do.
That's why the problem statement specifies that the bowling ball sinks.
> Ball is more dense than water
Wouldn't that mean the water level will raise a bit because: displaced weight > displaced volume?
Next bail 10 litres of water from the lake into the open-topped boat.
What are the effects of the 10 litres of air displaced from within the boat?
Unless there was a butterfly in that part of the air .. not much.
Lake level stays the same.
But won't your boat displace more water by lowering a bit if you've got additional mass on board?
That's what they meant by "in boat displaces its weight in water". While it's in the boat, the amount of water it displaces weighs as much as the bowling ball. While it's in the water, it displaces the volume of the bowling ball, and its weight doesn't matter. The ball is denser than water (since it sinks), so the amount of water it displaces based on its weight is bigger than the amount of water it based on its volume.
Ah, that makes sense, thanks.
Boat + bowling ball => level drops.
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.
The fastest path involves a small dip, though deriving that fact is non-trivial!
Here's one of my old blog posts where I do the derivation:
https://jasmcole.com/2020/04/13/briechistochrone
>Ball roll = the constant gradient is quickest?
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.
Maybe they were judging your perseverance and conduct, not whether you actually finished the work.
"I was asked the classic "fork in the road, two guys, one always tells the truth and one always lies" 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."
Uhh, strong reject
Halfway through my career, being on both sides of the table (interviewer and interviewee,) I've observed that a common interviewer mistake is to expect candidates to regurgitate facts; or be able to provide a memorized answer.
In this case, the goal is to hire great engineers; and great engineers do not memorize solutions to every problem, nor can they come up intuitively with great solutions in a matter of minutes.
The problem is much bigger than that.
Their goal is to find a "good fit", not to find a good engineer. That's why their software is so incredibly disfunctional: it's just a reflection of their workplace culture.
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
I understand where you're coming from and can empathize because I've been asked some absurd computer science questions in interviews.
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
> an interviewer can't confirm basic knowledge of data structures and algorithms
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.
Dunno, there are very few universal knowledge checks that would work across the entire industry, but my two absolute baseline standards for anyone who would be coding are 1) knows how to version control, and 2) can comfortably traverse a graph.
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.
Several times I have implemented topological sorts and parsers as part of routine work in very ordinary tech jobs. I think it is absolutely incorrect to say that these tasks are tantamount to implementing your own crypto. They are not things you do every day, but they are basic informatics and to be honest if a developer told me that they could never conceive of implementing them in their job I would be inclined to regard them as someone who was working without a full toolbox, so to speak.
That might just be my world in which the acronym DFS has a single well defined meaning; but of course the interview question never says "implement DFS", it will be a kind-of-real-life coding exercise that can be solved by a graph traversal, like checking if some nested structure has a loop.
I had an interview with Google about 10 years ago. Everyone said "Google doesn't ask brainteasers or leetcode-challenges any more".
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.
> Everyone said "Google doesn't ask brainteasers or leetcode-challenges any more"
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.
Haven't encountered "marbles in an airplane"-style brainteasers, but leetcode challenges are definitely still the norm at Google and other big tech. Not sure who was claiming otherwise.
The Kobayashi Maru
(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)
> The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided.
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.
The interviewer probably learned the trick with two pointers and wanted to see you implement it, for no real reason. This question, just like it's well-known sibling question "check if the linked list has a loop", has absolutely no practical applicability; no one will ever want to find k-th element from the end of the linked list, it's just not the right data structure for this kind of task: it's better to use an array or a double linked list if you need to do this operation often.
> The coding questions that require an "aha!" moment are very similar to brain teasers, and should also be avoided.
Those are usually the first hints I give; mostly because I'm concerned about "everything else" in the coding question.
In my corner of the Faang world it's been 20 years since that sort of brain teaser was asked. We switched to coding problems that require dynamic programming!
>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.
I've been doing "daily leetcode" for fun, just to remember how to write code manually without agents, and a few days ago they gave a brain teaser kind of task [1], for which the solution was just [2] (spoiler alert). It took me quite some time to come to that solution, and I'm not really sure I would've found it with all the stress of being on a real interview.
[1]: https://leetcode.com/problems/stone-game/
[2]: return True
Yeah one of the worst offenders of this are the leetcode problems that have a clever but extremely elegantly simple greedy algorithm (such as "return True" lol). Great example is Majority Element [1]
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...
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.
The one time an interviewer started describing fizzbuzz as a problem for me to solve, I said “oh FizzBuzz?” And he said “oh never mind then” haha.
Got the job offer too, though I didn’t take 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.
What is "abstract CS" about binary trees and serialization?
I think it's because most of us don't do CS once we graduate. We build APIs and websites which don't involve CS at all. It barely involves engineering. lol.
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'm not some Google/Microsoft/whatever engineer who's been working on highly scalable, highly available systems. I've mostly worked in consulting on small projects. I have never not had problems with the defaults on any of those sorts of libraries. I've almost always had to roll my own graph manipulation and heavily customize any serialization system I've used. And when I do so, because I've gotten good at doing it (in particular, I don't think of the graph stuff as being hard at all), it makes tons of other stuff inside around the project a lot easier.
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.
https://aphyr.com/posts/340-reversing-the-technical-intervie...
I like the next blog post even more: "Hexing the technical interview" [1]
[1] https://aphyr.com/posts/341-hexing-the-technical-interview
Well, did they hire you? Don’t leave us hanging!
> 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
Probably explains why Microsoft hasn't made a good product in...as long as I can remember. It's all shibboleths and gate-keeping.
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.
A lot of people rave about VS Code. Also, TypeScript. Also, open source re-write of C# (Project Roslyn?). All excellent products.
They are not the only ones, Google is famous for this kind of stuff, and then you look into Android code quality.
Google was more elitist than most in its early years. As I recall, candidates had to have graduated from an elite CS program with and provide a transcript when applying showing top grades.
This same Google,
> 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.
A lot of people at Google (and some other companies mentioned here) understood their hiring process didn't function as well as desired.
> 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.
>It’s an information theory question similar
How would you approach it from an information theoretic sense?
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.
Now that you spell it out, I guess this just binary search. You need O(log n) weighings because each weighing splits the search space in half. So I was wrong it’s not an information theory question, it’s just comp sci algorithms. I got my college classes mixed up (it’s been 14years)
Not binary. Each weighing can give you left, equal, right. So a ternary tree, if you want.
Exactly. Same kind of thinking gives you bounds on what can be done. For example, can you do 13 marbles in 3 weighings? 213 < 3^3, so maybe (though I think not). Can you do 14 marbles? 214 > 3^3, so definitely no.
> Tbh, I think it's a terrible question.
I think it's a terrible _interview_ question, partly due to it's "IQ test" nature, but mostly because it's a pretty hard problem and I really wouldn't expect someone to be able to just spew out a solution the first time they hear it.
Of course, the process would be more about the interviewer observing your thought process, seeing how you develop a notation for solving this thing which you almost certainly don't have any pre-existing notation for, etc. I just really wouldn't expect much progress in the space of 5 to 10 minutes, although I am basing this on the "13 marbles" version of the problem.
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.
IMO the key thing is that interviews have a heavy component of randomness.
The question your interviewer selects (both topic and difficulty), how the interview performs as far as presenting the question/giving hints, how the interviewer is feeling, any biases the interviewer might have, and so on.
You can of course 'increase your surface area for luck' by studying the questions/topics a company tends to ask, being an interviewee who comes off as well qualified.
But, if you get an interviewer who is in a bad mood, if your interview isn't competent or paying attention, etc. then you're just screwed.
---
I say this because the OP was honest and failed; you were honest and were hired. There's no 'secret' to getting in. It is a combination of:
1. Being a competent engineer (or student)
2. Putting in the time to study, leetcode, practice, etc.
3. Luck
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.
The interviewer might also just be a cog in the machine and know how it works.
"Just solve it and I'll note down an A+" is sometimes better than "candidate was honest, but didn't finish the alternative riddle."
> 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?
We're specifically talking about people who are interviewing for jobs - I'd expect a lot of them to have done leetcode before the interviews.
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.
Really, do you expect folks to dust off their algorithms and data structures from 30 years ago, instead of what they have been doing the last decade on the job?
Love to know how many do build bridges, repair cars,..., on their spare time for job interviews.
If you expect Leetcode-style problems in the interview and are actually interested in doing your best there, why wouldn't you prepare for that?
That is the thing, I don't expect them, other than for newly graduates without anything else to show their value for.
Yeah, it's weird (to me and you at least) why people bother quizzing industry veterans. After 10 years in the workforce you should be able to talk shop about various experiences you had at work (NDA permitting) and drop down to technical details where appropriate. Yet some companies or interviewers insist on techniques that could be replaced with asking the potential hire to eat boogers on camera for a stronger signal of what they're actually looking for.
Even if that's the way it should be, it's not reality.
You can study for the interviews you'd like to have, or the ones you'll actually have.
> Be honest; it’s more likely you will be hired by honest people.
He applied for Microsoft.
The experience I was referencing was actually Microsoft!
> 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...
> especially in SV / startup circles
Lol, I'm increasingly wary of whatever SV / startup circles prefer nowadays... The shitload of BS is ever forthcoming.
2015 was one year after Satya Nadella became a CEO, and Microsoft looked pretty OK to me back then. Much better than a few years before that.
Right, that was the Ballmer era, and when pg pronounced them dead. But I do think that perspective didn't appreciate the coporate Game of Thrones (https://substackcdn.com/image/fetch/$s_!Vk-D!,f_auto,q_auto:...) Ballmer had to play to pave the way for Satya to remake Microsoft from a Windows + Office company to an Azure + Windows + Office company.
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.
> Windows feels so basic and primitive compared to other operating systems.
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 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.
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:
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!
At one point earlier in my career (during the early 2000s), they flew me to Chicago, picked me up in a limo and gave me a tour of the office... I knew I didn't want to relocate (from the East Coast) and remote work wasn't an option back then, so I had nothing to lose... They asked me the question of "4 lightbulbs in a room down the hallway, with 3 light switches in the room I'm in" to tell which switch belonged to which bulb...
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.
A common interviewer mistake is looking for exact answers, assuming that a candidate just needs to regurgitate facts.
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".
> I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard.
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.
But is your solution scalable? Resilient against injection attacks? What about o11y? Is literally anyone besides you going to be running these searches? If so, you're going to want to put a UI around it and that means thinking about scalability, data sanitization, and o11y. Maybe Bob knows something about the scope of the problem that you don't?
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.
It is not my responsibility to teach critical thinking and a CS degree to Bob, nor is that in my job description. If Bob can successfully convince our boss and finance team that his solution is necessary, then so be it; I will continue banging my head into the wall.
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.
> 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.
I invite you to go to any Arab country and tell them to legalize gay marriage.
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.
> Bonus: put some typos in the quiz that don't matter. Red flag for the people that get hung up on that.
I feel like after presenting a great solution to the stupid, cryptic, arbitrary interviewer games where you have to guess the rules on your only attempt at playing the game, you've added one at the last minute. What if one of the values is attention to detail?
Attention to details that matter and knowing what to pass on, is what's important. If they did poorly on the important stuff but then point out the typo, clearly they were putting their efforts in the wrong places
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.
Please no. No and home quizzes
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.
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.
Coming from another experienced dev who was frustrated (early) - one tip. Don't over think it. I was tripping up in two system design interviews that ultimately boiled down to them wanting laughably basic answers (one pagination, the other a db transaction). Don't be afraid to deal in basics and then directly ask if they'd like something more detailed, or not. Many places, especially non-elite ones, treat system design as a _very_ basic test of knowing how pieces fit together.
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.
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.
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.)
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.
Yes, the best way to land yourself a good gig is to have a friend in the company already and will put a good word.
It makes sense alright.
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.
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.
We do it every several years. It just takes a lot of paperwork. https://en.wikipedia.org/wiki/World_Geodetic_System
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)
> "If you had to move Mt Fuji, how would you do it?"
Wait 1s.
"I wouldn't even try it because I don't want to be deported from Japan."
"One mouthfull at a time"
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.
You are not required to be honest with corporations, corporations are not honest with their consumers or employees.
Jeez, the text in the rejection letter is the same today as it was back in 2015!
You can not improve on perfection!
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.
A classically terrible interview question. Solving riddles in realtime is almost never a real job skill. _Maybe_ in an incident, but you’d be relying on tooling and experience, not an intern.
Same with leetcode at startups. It makes no sense. You’re almost certainly not going to do algorithms work. It’s only relevant if you’re looking for people willing to grind bullshit, which is certainly some jobs, but, again, you’re almost never doing this under arbitrary time pressure with someone watching over your shoulder judging and not helping.
My advice: if you encounter this, don’t work there. If a company doesn’t value testing relevant skills for candidates, don’t expect leadership to be strong critical thinkers once you get there.
The speed with which I can remember some obscure AIX partitioning-related fact during an incident, for example, is orders of magnitude faster than the speed with which I would figure out which of 12 marbles is slightly heavier than the others.
> I can remember some obscure AIX partitioning-related fact
Now you have my attention. I'd love to read about some of these trivia.
Gah, I can't remember what the specific trivia was now (ironically), just that some disk wasn't mounting and something in the fstab stuck out to me that I then looked up in the manpages and confirmed was wrong. (I wasn't even the AIX guy, I was just the sysadmin of an app that ran on AIX.)
Not the GP, but I have one non-partioning AIX trivia I discovered by accident. Turns out that malloc(0) returns NULL on AIX, but non-null on Linux, SunOS, and Irix. (I was surprised multiple ways on that one!)
Sometimes I think "it's a UNIX system, I know this" but I've been caught by subtle differences before too.
killall is very different between Linux and Solaris, for example. I would rather have not found this out on a client machine for the first time.
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.
That one has bitten me more than once
This was an internship interview over a decade ago. Nothing wrong with a brain teaser interview question under those circumstances. What would you rather ask an internship candidate? They don’t have work experience or real world skills.
I’d be unsurprised if an interviewer who thinks that trivia isn’t a goofy waste of time also believes that young people don’t have real world skills. But a good interviewer would probably spend time getting to know the candidate’s character.
Something I’ve learned from years of mentoring teens and raising kids is that there are qualities you cannot teach, and they’re enormously more valuable than any technical skills. I’m confident I can teach just about anyone any of the skills Microsoft employees find themselves milling away at. But I can’t teach that fire a 10th grader has where they go home and spend their entire weekend figuring out how to make their idea work in Java, even though they barely understand programming, and then swarm you at the door next week to proudly show it.
That’s the kind of quality you seek to find in an interview. All the other stuff can be taught to anyone.
Doesn’t “enthusiasm to try and tackle somewhat abstract puzzling questions” act as a reasonable proxy for some of those attributes?
It does; the old school hackers, the people who built the computer and software industry, loved logic puzzles / brainteasers and elegant, high performance solutions to coding challenges.
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.
“true hackers” Yikes. I’m not sure a rebuttal is even needed for a comment that’s just so lost in its own limited view of things.
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.
The answers to this questions will tell you whether the candidate is a good storyteller, whether they have been lucky or unlucky in group project assignments, and whether they can spin experiences as self promotion.
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?’
Classical algorithms kind of thinking is similar to ML research.
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.
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?
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).
The candidate may have had more success if he saved the honesty for after he solved the riddle he claimed he already knew how to solve.
I learned that if you put
“2015 - 2020 / University X, Computer Science”
on your resume, nobody asks if you actually graduated.
Because they know that if you had graduated, you would have, at every turn, mentioned the name and date of your degree, instead!
In my country “Computer Science” would be your degree. Your graduation date also isn’t mentioned, just the year.
"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.
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.
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.
"Did you get a bachelors or masters degree from university X, your CV doesn't say?"
Totally agreed. Capitalism is just a game of competition, and if you want to win the game you should take all advantages that you have. Pretty much everyone else you're competing against will be doing the same.
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.
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 ?
Depends on your school of ethical thought. If you're a consequentialist, sure. But I'm very much not a consequentialist, so I don't think that it's morally correct to do a bad thing in order to achieve good ends.
> 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.
"if you never lie, you don't have to remember what you said"
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)
I've seen candidates breeze through the basic version of a question they claim to never have seen when asked and then choke hard when the requirements are modified slightly. Honesty is the best policy, kids.
This was the real riddle all along.
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.
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.
We have a perfectly good mechanism for dealing with scarcity, it's called scarcity.
It's more plausible that the issue is this being a lemon market
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.
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.
That is exactly what the interviewer did. And yes solving the problem you know how to solve is the right move.
It's interesting to see how interviews often test more than technical skills. I probably would've made the same choice and asked for another question too man. Really enjoyed reading this.
What was the lesson learned?
I’m guessing they didn’t care whether or not the OP knew the answer, they just wanted to see how they solved the problem and cramming for the test is the anti-pattern because that’s what the try-hards do and you generally don’t want try-hards around except where you need people to grind out things.
I 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.
FWIW, in most architectures the first few function arguments get passed in registers. But so many of today’s programmers grew up with 32-bit x86, which has a paucity of registers, that they mentally shortcut to “every argument gets passed on the stack”.
Nowadays, with x64 and AArch64, the first several arguments will be passed in integer or floating-point registers.
I would assign (3) to language runtimes and calling conventions rather than operating systems.
Wow, I got the same question, wonder if we interviewed with the same dude.
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.
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.
Now I understand why Microsoft, Apple, and other tech giants are slowly falling behind: they put strong candidates through a series of puzzles.
What a great way to filter out talented people. Great times. Very character building.
Companies that use riddles get the employees they deserve.
Microsoft is a dumpster fire. You probably dodged a bullet. Source: I work in the dumpster fire
I agree. Source: I used to work at the dumpster fire
I agree. Source: I am an Azure user.
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).
My condolences. I read that other hacker news post (was it a couple months back) from the (ex?) engineer...
I'm so sorry
> You have 12 marbles and a balance scale.
I hate such interview questions. They have nothing to do with think one really needs to do in practice. It seems for me to be just a way for interviewers to show their intellectual superiority.
> They have nothing to do with think one really needs to do in practice.
See, this is why you weren't selected for the team: https://imgur.com/a/xnHgjjH
> "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.
What? They were still asking these Mt Fuji ass questions in 2016??
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’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.
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".
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.
ummm..!
so funny to read the reactions here. "Puzzles are stupid and hiring is broken" without thinking about how to navigate a question like that.
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.