At Netflix, I used a state machine library to handle the project they gave me. Got rejected because I didn't show I knew raw JavaScript enough.
At Facebook, I wrote a calendar dropdown from scratch. Got rejected because I should have used a library.
Interviews sometimes is just a lottery...
Yes I know both companies should have set the expectation, but you can set the expectation for EVERYTHING, otherwise you give candidates all the answers you're expecting. There's always going to be some chaos due to the huge number of variables.
As a hiring manager I've had situations like this arise because there was a gap in my plan and I didn't realize it. When those come up, we thank them for their cleverness, apologize to the candidate, reframe the situation, and give them another shot.
But also sometimes I leave intentional ambiguity in the plan. Part of the goal is to see if they have a degree of common sense commensurate to their level. If they're interviewing for a high level position, I'd expect them to be able to spot silly flaws and push back that perhaps the whole problem needs rethinking. And of course, I also expect them to know the brute force solution as well. Do they only know one? Both? Let's fine out.
Isn't this rather giving yourself another shot.
The purpose of the interview is for the candidate to demonstrate their thought process and ability to communicate it. “Just use Postgres” doesn’t do that.
This would be more obvious if it was a LeetCode problem and the candidate just regurgitated an algorithm from memory without explaining anything about it. Yeah it’s technically the right answer but the interviewer can’t tell if you actually understand what you’re talking about or if you just happened to memorize and answer that works.
Interviews are about communication and demonstrating thought process.
That being said, it's also on the ones giving the interviews to push the candidates and ensure that they really are receiving the applicants best. The interviewers don't want to miss potentially great candidates (interviews are hard and nerve-wracking, and engineers aren't known for their social performance), and thus sometimes need to help nudge the candidates in the right direction.
The best thing someone can do to learn how to perform well in interviews is to sit on the other side where you’re interviewing candidates. Some candidates will get stuck on arguing some irrelevant point or trying to fight against the interview question for too long in an interview. Once you see how much it hurts the interview process you learn to never do it yourself.
There's a ton of incredibly talented neurodivergent people in our ecosystem who would trip up on that question just because of how it's framed
Because how is the interviewee to know if you're testing for the technically sophisticated answer no one in their right mind would ever write or the pragmatic one?
From one side, we call ourselves problem solvers, on the other hand we are not satisfied with simple solutions to these problems. If im interviewing for a job, i should be expected to behave and solve hypothetical problems the way id do it on the job. If that screws up your script, you probably suck at hiring and communicating your expectations.
In my experience, it's much easier to train somebody on how to scale a basic system up in response to need than it is to get somebody who favors complexity to cut it back.
If anything, it's neurodivergent interviewers. If I insisted on a different design I'd either ask a question that's not solved by "just use postgres" or follow up with "ok, that would work, but what if <something that would prevent postgres from working>". Just failing a candidate for a correct answer is a prime example of why interviewing is so bad.
I had this happen in a Google interview. I did back of the envelope math on data size and request volume and everything (4 million daily events, spread across a similar number of buckets) and very little was required beyond that to meet performance, reliability, and time/space complexity requirements. Most of the interview was the interviewer asking "what about" questions, me explaining how the simple design handled that, and the interviewer agreeing. I passed, but with "leans" vs. "strong" feedback.
The issue is that Google achieves reliability by insisting on n+2/n+1. Globally your service is in at least 2 more data centers than is required for full load. In each region in at least 1 more data center than is required for full load.
If you're using the Google toolchain, all of the scalability and fallover problems are automatically handled by the layers that you're relying on. Which everyone expects you to use, because they are already integrated into the environment.
But if you go to use Postgres as a data storage layer, then you also need to take care of replication, failover, backup, and make sure that this is integrated with the automated systems that Google already has to detect when this is needed. Even after you've done that, people from outside of your team will need to be convinced that you've done that. Simply because you're doing things differently, you'll get extra scrutiny.
As a result, even if Postgres would have worked perfectly well, it is usually not the optimal answer for someone who is working within Google's environment. Don't think of it in terms of, "Does this do the job?" Think about it in terms of, "Can those in the broader organization easily certify that this does the job?" That certification is easier when you use standardized parts that are themselves already certified within the organization.
My guess is that your interviewer was aware of this. And was left with, "What about that question that I didn't think to ask you about?"
Those were my favorite system design rounds ever, thanks to the problems being interesting and the interviewers also being very dynamic. It was also pre-Covid, so it was just awesome whiteboard design sessions.
sigh I miss in-person interviews.
I'd assume that if he got a call from Patrick himself and a second opportunity to get interviewed, that's already a cue for interviewers to pass him regardless of what he says?
On the other hand, interviewees can give poor answers with no explanation. The interviewer should press for an explanation in those cases, of course, but perhaps some are trying to see if the interviewee instinctively provides at least some basic rationale behind the answer without having to be prodded each time, in which case it is a matter of communication habits and skills. Communication is essential, and it is under-emphasized and under-taught in so-called 'STEM' curricula.
Exactly, it's also a test of ability to conform. Especially useful to weed out rogue behavior picked up in startups.
If a valid answer was “just use Postgres” then it just wasn’t a very good interview question.
In real life, the answer almost certainly would be “just use Postgres” and everyone would be happy.
If the interview wants you to think about stuff that never happens in your role, I think it is a sign that in your role, you're expected to solve the problems like in the interview.
And yes, I have done this on a second Google interview about 15 years ago.
Sometimes you just have a bad interviewer who is looking for something specific from you but isn't telling you. If you're experienced in these interviews, you catch the signs and adapt by asking questions to suss out which direction the interviewer wants to take it.
Sometimes your answer is plausible but the interviewer wants to see you justify it. Sometimes your answer is wrong but the interviewer wants to see if you can reason your way through it, and maybe come up with an alternative.
If you're junior/inexperienced, it's often hard to tell and it'll feel arbitrary/unfair, and unfortunately that's just how it goes. As a more senior/experienced candidate, you can often figure out which situation you're in by asking questions to feel out the interviewer and then try to pivot during the interview, though it still takes valuable minutes out of the interview that you could have otherwise spent showing your competence.
They want a conversation to see how you think, not an actual answer.
Which is stupid, because they asked a question that the person didn't need to think to answer. So they didn't get to see them think.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
I would hire the "just use postgres" dude in a heartbeat without re-testing, if the numbers made sense, and perhaps give a stern talking-to to the interviewers. But then again I'm not a unicorn founder, so what do I know.
This is the same issue that was prevalent when the industry switched from HDD to SSD: some system design questions suddenly became trivial, because the IOPS went up by magnitudes. This is not a failure of the interviewees, who correctly went with the times, but a failure of the interviewers.
Obviously. But they don't care about that answer, they care about the design of a new system so I'm saying the interviewer is dumb for not just asking directly for the solution he wants to see (while also giving credit for the original right answer).
The interviewee is dumb (if he wants the job) to not know this is what they want to hear, so he can just say "I really do think Postgres would satisfy the requirements here, but as an alternative a custom solution would look like.."
What is the point of not demonstrating your own well rounded knowledge when given the opportunity? Is it not obvious what they want to hear? Then why not tell them, again given that he did want the job
The point of a system design interview is to have a discussion that examines possibilities and tradeoffs.
Then, there are hiring managers that suck and you might be discarded because you didn't follow the script. Sure, but that's a bullet you dodged.
So the point is? I honestly dont understand.
The question is framed to you as a way for you to show you know x, y and z and talk about x, y and z.
Even if a valid solution is just do a, that's great. But the interviewer has no idea if you actually know about x ,y and z do they ?
I like that this sentence can be read both as a productive, well-meaning view on interviews, as well as a highly cynical one.
Also makes me wonder if the person will keep showing how much they know and how smart they are after they are hired, and if that is a good thing.
Sometimes the point of the interview is to see if the candidate knows an existing solution and "just use postgres" is the good answer. Sometimes it's to test the technical chops and pretending postgres doesn't exist is the point.
The candidate shouldn't be expected to always guess right, unless the position says "a psychic". The interviewer should notice if the candidate is solving the wrong kind of problem and nudge them in the right direction instead of punishing the candidate for the wrong guess.
Saying “just use Postgres” and then providing no explanation for why you believe Postgres is sufficient for the job, a general explanation of what type of hardware and architecture you’d use, and other details is not answering the question.
With a smiley face front-end, of course. Wouldn't want to seem not-nice!
I feel like lots of people just follow the happy path and don't understand that complexity incurs real cost.
Why on Earth did the company have to be so willingly obtuse and stupid about it including what sounds like the CEO (well at least he gave him another shot, but there doesn't need to be implicit assumptions about the "point of the interview", just come out and address it head on explicitly.)
This should go straight to the DOL, EEOC, FTC and other bodies as some form of abusive labor practice that excises it from the employment process under threat of economic sanctions
To make the interviewer feel smart and powerful? To hire people who will do the thing the boss wants whether or not it makes sense? To find people who will overdesign things to maximize resume impact and the ability of their bosses to talk about what sophisticated systems they're running and for which they therefore need a much bigger budget?
To rethink hiring, you have to spend some time understanding why most hiring is terrible both in terms of candidate experience and actual result. In my view so much of both hiring and general business operations is about managerial status and ego. https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...