So my cofounder was talking to Stripe about an acquihire (this was after I’d left.) As part of it, he had to do a systems design interview.
He got the prompt, asked questions about throughput requirements (etc.), and said, “okay, I’d put it all in Postgres.” He was correct! Postgres could more than handle the load.
He gets a call from Patrick Collison saying that he failed the interview and asking what happened. He explained himself, to which Patrick said, okay, well yes you might be right but you also understand what the point of the interview is.
If the point of the interview was to test if the candidate can design something that can handle google-scale problems then maybe the interviewer shouldn't state throughput and availability requirements that can be satisfied by postgres
Maybe 10 years ago I interviewed both for Netflix and Facebook.
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.
Postgres might have been a perfect answer, but the candidate needs to explain why and how.
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.
100% interviews are about communication and demonstrating thought process; after going through some rounds of interviewing candidates myself, any candidate who can adequately explain what they're thinking and how they arrive at their conclusions will be able to demonstrate their skills much more thoroughly than 'just use Postgres'.
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.
Fully agreed on the point that interviewers should prompt and push 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.
I went to law school and a few of us students were engineers. For our first set of essay exams, the professors all instructed us to "just answer the legal question" and not include extra analysis. After the exam, many of the engineers didn't do well because the professors *actually* wanted you to weave the whole sylabus into your answer (i.e., discuss hypotheticals that were not actually part of the question asked), not just answer the question. After that, we were fine.
This is also what I learned the hard way. In many situations the customer doesn’t say what they really want. There are a lot of reasons why. I usually have to write down a lot of hypotheticals. If X is the primary concern, we should do Y. If U is the issue, we should do V.
I wouldn't expect customers to say what they really want. They are looking for faster horses after all. But law professors? Among all professors, law professors should be the ones saying what they really want.
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.
I feel like if that's the thought process, that should be stated up front
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?
I dont even think you need to be neurodivergent or anything to answer this question like the parent’s cofounder did.
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.
We also aren't mind readers and interviews are a crapshoot. Some companies do in fact want you leveraging tools and API's in your solutions. Some want to probe your foundational technical knowledge. Ideally they will poke you towards the answer they want, but not always. But few will let you know ahead of time for some reason.
Or just add a couple zeros to all the requirements until postgres is a worse solution than whatever the interviewer envisions. Isn't that the point of stating throughput requirements?
Right? I'll often structure interview questions like this. I give a basic problem, hoping for a basic answer. Then I add complexity, seeing how they respond.
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.
> neurodivergent people in our ecosystem who would trip up on that question just because of how it's framed
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.
It's probably more about your mindset, than about being neurodivergent vs. neurotypical. If you care more about maintainability and operations, there's a whole host of solutions you'd never built.
if your brain short-circuits at ambiguity, or you're completely incapable of understanding intent and you take everything literally, that is a negative hiring signal.
> He got the prompt, asked questions about throughput requirements (etc.), and said, “okay, I’d put it all in Postgres.” He was correct! Postgres could more than handle the load.
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.
To be fair, the simple answer is not so simple within Google.
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?"
If you're interviewing at Google, the expected answer to the interview question can't be to use Google's internal tools. "Use Postgres" is the standardized, understandable answer for anyone outside Google who needs to solve Postgres-shaped and Postgres-sized problems.
FWIW, that was the second time I interviewed at Google. The first time, which resulted in strong yes across the board at L7, the first system design was to design Youtube Video Upload. The second was a more practical problem about replacing a high-volume logging component where correctness was critical but environment was space-constrained (i.e. no ability to run old + new in parallel).
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.
This is just an indication that it's a poor interviewing technique. If you ask a question expecting the answer to be predictable then you had better cover all possible ambiguity in leading the candidate to the answer you want to hear. But then you're no longer asking the candidate to be creative, are you? As an interviewer I might be more inclined to allow such an answer and then follow up with questions of my own to test the limits of the candidate's knowledge of and confidence in Postgres as a technical choice for serving all the different constraints of the problem space. This way either I discover how well-reasoned the answer is or else (for a good candidate) it prompts them to adjust the design to better fit the problem. In no case would I expect they need to fit their answer into some key and then scold them for not playing along with my imaginary game.
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?
If they don’t want to hear the correct answer, let them modify the question to exclude postgres answers. Interviews are a 2 way street, you will miss out on great candidates by being this stupid.
On the one hand, interviewers can suck. They can be uninterested in understanding and embrace instead the role of a trigger-happy interrogator looking not for a good response - something that may very well require effort and considering new ideas on the part of the interviewer - but an excuse to cross you off the list. The interview begins to look like a game of "Guess what I'm thinking". Interviews should simulate a colleague asking you for help.
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.
No, it was a perfectly fine question IMHO. it is a broken incentive - it is expected that you design complex systems regardless whether they are useful or not. Try to interview for the role you have to fill, nor for a role you a dreaming you would love to have whenever you're Google2.
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.
Great example, and a lost opportunity in the interview---they should have asked "What are the requirements that would invalidate this answer? and what would you design if the requirements were changed in this way?". Maybe even "how long is the runway for your Progress solution if we consider future scaling up of the requirements"
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.
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.
The question was bad if using Postgres would really be a better solution than designing and implementing a bespoke system, under the stated constraints. Either they should provide a better problem statement, or at least immediately follow up with “okay, suppose you can’t make use of an existing system like Postgres for $reasons”.
Eh, it's a good answer and shows good instincts, but they still want to know how he would design a system if one was necessary. There's no need to be ridiculous about any of this from either perspective, which is why it should never have been a "fail" without the original interviewer simply saying "That's a solid answer now tell me what you would do if you had to build something new". I mean look how much time he wasted for everyone including his own CEO by being stubborn about it.
If the numbers can be satisfied by a Postgres then thats the correct answer. The interviewers fucked up, because they sized the problem wrongly.
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
And people weeded out by this kind of questions are probably rightfully so. I for one could not ever work with someone that says "my answer is correct, period.". Part of the answer and the discussions made by mature individuals must ask for feedback, incorporate it in your design, be open to compromises sometimes but also to die on a hill when it makes sense. And in an interview context, you ought to show the hiring manager all these faces.
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.
The point is the interviewers are sometimes obtuse.
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.
In an interview you need to explain your thought process and demonstrate that you’re making an informed decision with supporting evidence.
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.
I always find it funny that "engineers" straight out of school who barely know how to create a PR are expected to "ace" planet scale design questions. It's. Just. So. Dumb.
The best way to get promoted at stripe is just self-marketing and social manipulation. Good engineers are leaving meanwhile tecnical leadership is being replaced with designers and marketers. Internal performance metrics are heavily manipulated as well. Patrick has completely surrounded himself with extreme sycophants at this point - he has no idea what is actually going on in his company beyond curated metrics produced by manipulative sociopaths.
Patrick Collison sounds like a lovely, trusting, scientifically-minded man who needs to learn the constructive power of destruction. The power of rage and contempt for bad solutions and bad communication (regardless of intent).
With a smiley face front-end, of course. Wouldn't want to seem not-nice!
Agreed, I really like Patrick - he is smart, humble, hardworking and trusting. But his kind and trusting nature is being aggressively exploited by some truly despicable people.
Completely idiotic on the part of the interviewer. Failing somebody for a correct answer - what a waste of everybody's time. If you want the candidate to pursue a particular technical path, tell them to do so while they're there in the office.
I realized that my manager really confuses complexity with robustness. Case in point: we have a very complicated script that runs at deployment time to determine the address of the database. It's been the source of a few incidents - database wasn't discovered because it was restarting and the script passed an empty string instead of stopping the deployment, script failed because of python update and empty configuration was passed, shit like that. I've been arguing "bro why can't we make terraform create a config file with all the addresses that is directly passed to the app at deployment, or better yet, just copy-paste the database addresses into a file in the repo because we change something there once a year at maximum" but my manager took it as a sign of incompetence and my inability to understand complex systems.
I feel like lots of people just follow the happy path and don't understand that complexity incurs real cost.
It's crazy the original interviewer allowed it to come to this which sounds like a waste of time for everyone involved, instead of simply saying; "Very good that is a legitimate solution to the problem. Now let's pretend you have to build something new, what would you do?"
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.)
“There’s no right answer we just want to see how you think” is gaslighting if there is a right answer and wrong answer.
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
> yes you might be right but you also understand what the point of the interview is
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...
In the US, the FDA has a Compassionate Use exemption to clinical trials for exactly this circumstance!
There must be informed consent, no reasonable alternatives (which, in cases we deem terminal, is often the case), and some evidence pointing to the treatment possibly being helpful. It's an excellent ethical program that gives patients a choice and advances science.
In my experience most legitimate biotech companies working on promising drugs and therapies don’t want to touch the exemption with a 30 foot pole. Since they raise most of their money from the public to fund clinical trials, a single bad reaction could generate enough bad PR to derail fundraising and kill the drug. Sticking to clinical trials allows them to control that blast radius so even though the FDA approves >95% of applications, in practice very few drugs are available that way.
The biggest exception is oncology. Since everyone knows that chemotherapy is hell, cancer drugs tend to get a pass and pre-approval companies are (slightly) more willing to work with compassionate use exemptions.
1st comment: 2 day old account, "is the real story here", summary -> comment -> question, general punchiness of style without saying that much. These llms feel like someone said "be an informal hacker news commenter" so they often end with "Curious how" instead of "I'm curious how" or "Worth building" instead of "It's worth building". Not that humans don't do any of this but all of it together in their comment history, you just get a general vibe.
author reply: not as obvious, but for one thing yes literally em dash, their post has 10 em dashes in 748 words, this comment has 2 em dashes in 115 words. Not that em dash = ai, but in the context of a post about AI it seems more likely. And finally, https://github.com/mksglu/claude-context-mode/blob/main/cont... the file the author linked in their own repo does not exist!
Thanks for making me aware of another federal agency :)
Seems to me prosecuting or regulating this sort of activity is futile, and pretty much serve only the interests of the mob. These markets make additional data open source, which otherwise might exclusively belong only to mob, so that's pretty cool. We democratized buying airstrikes.
It You may know how bad things really are, but if you don't, the lawboys are pretty much just playing pretend at this point, and have been for a while.
Mob wants me to add: if you try to buy an airstrike with our very based and functional cryptocurrency systems, you will probably just find mob. We have mob priced in, anybody with a significant amount of cryptocurrency knows this too.
It's not as simple as "buy an airstrike" comrade (we are referencing the person writing this post)
If you see prediction markets as how they were originally pitched (price ~approximating likelihood), then insider trading is good. It provides discovery.
If you look at what prediction markets are today (gambling, especially on sports, especially in states that have banned it), then insider trading is bad. Particularly when the people trading can influence the outcome (e.g. a pitcher purposefully throwing into the dirt.)
> Isn't insider trading on a prediction market only wrong to the extent the insider is violating some duty of secrecy to the company?
Yes.
Prediction markets, for corruption reasons, are regulated by the CFTC. In commodities markets, actors are assumed to be making trades based on propriety information. Hedging is the whole purpose!
> …like it's a stock market where there is some society-level interest in giving participants protection from having less information than insiders.
Ah, no!
Insider trading in the stock market is (usually) only illegal in your first case: when the person trading is violating confidentiality.
It is not about fairness.
Fairness is a poor proxy for whether specific trading is illegal.
For example:
If a company accidentally leaves a press release for a merger publicly available, I happen to guess the URL, and then I trade on it: Unfair (I have access to insider information that other market participants do not) but legal!
If I work at the company, am sent the press release to copy edit, and then trade on it: Illegal. I have a duty to the company not to trade on it.
Okay, then imagine you overhear at a bar. Yes “anyone could have” theoretically, but not actually. In either case, you have material non-public information that your counterparty in the market does not.
you got that piece of non public information was not because you are an insider. As long as the bar is not exclusive to insider, i don't see any difference
Isn't it exclusive to people who live in the area of the bar?
What if the bar has a cover charge, so only those who pay get in?
What if the cover charge is $10,000 and the bar is advertised as "the place where public company execs love to come talk to each other about private deals"?
Your comment seems to imply that trading based on material non-public information in prediction markets is always okay, which is not the case. The CFTC just made a press release detailing some instances of invalid use of nonpublic information on prediction markets: https://www.cftc.gov/PressRoom/PressReleases/9185-26
Interestingly, the CFTC objects to a political candidate trading on their own candidacy on the grounds that it is fraudulent. So it looks like they could attempt to regulate self-trading quite strictly, at least if that theory holds up after a court challenge.
>> If a company accidentally leaves a press release for a merger publicly available, I happen to guess the URL, and then I trade on it: Unfair (I have access to insider information that other market participants do not) but legal!
Not necessarily. Just because you accidentally left your S3 bucket open and I brute force my way to the link by guessing doesn’t make it legal. It can still be insider information. Insider information is not limited to people who have a duty to the company. If I break into the companies office and steal information and trade on it then it can be insider trading.
Supply chain risk is not meant for this. The government isn't banning Anthropic because using it harms national security. They are banning it in retribution for Anthropic taking a stand.
It's the same as Trump claiming emergency powers to apply tariffs, when the "emergency" he claimed was basically "global trade exists."
Yes, the government can choose to purchase or not. No, supply chain risk is absolutely not correct here.
> The government isn't banning Anthropic because using it harms national security. They are banning it in retribution for Anthropic taking a stand.
You might be completely right about their real motivations, but try to steelman the other side.
What they might argue in court: Suppose DoD wants to buy an autonomous missile system from some contractor. That contractor writes a generic visual object tracking library, which they use in both military applications for the DoD and in their commercial offerings. Let’s say it’s Boeing in this case.
Anthropic engaged in a process where they take a model that is perfectly capable of writing that object tracking code, and they try to install a sense of restraint on it through RLHF. Suppose Opus 6.7 comes out and it has internalized some of these principles, to the point where it adds a backdoor to the library that prevents it from operating correctly in military applications.
Is this a bit far fetched? Sure. But the point is that Anthropic is intentionally changing their product to make it less effective for military use. And per the statute, it’s entirely reasonable for the DoD to mark them as a supply chain risk if they’re introducing defects intentionally that make it unfit for military use. It’s entirely consistent for them to say, Boeing, you categorically can’t use Claude. That’s exactly the kind of "subversion of design integrity" the statute contemplates. The fact that the subversion was introduced by the vendor intentionally rather than by a foreign adversary covertly doesn’t change the operational impact.
But there will always be deficiencies in testing, and regardless, the point is that Anthropic is intentionally introducing behavior into their models which increases the chance of a deficiency being introduced specifically as it pertains to defense.
The DoD has a right to avoid such models, and to demand that their subcontractors do as well.
It’s like saying “well I’d hope Boeing would test the airplane before flying it” in response to learning that Boeing’s engineering team intentionally weakened the wing spar because they think planes shouldn’t fly too fast. Yeah, testing might catch the specific failure mode. But the fact that your vendor is deliberately working against your requirements is a supply chain problem regardless of how good your test coverage is.
The rule in question is exactly meant for “this”, where “this” equals ”a complete ban on use of the product in any part of the government supply chain”. That’s why it has the name that it has. The rule itself has not been misconstrued.
You’re really trying to complain that the use of the rule is inappropriate here, which may be true, but is far more a matter of opinion than anything else.
You keep trying to say this all over these comments but this isn’t how the law works, at all.
I fully understand that they are using it to ban things from the supply chain. The law, however, is not “first find the effect you want, then find a law that results in that, then accuse them of that.”
You can’t say someone murdered someone just because you want to put them in jail. You can’t use a law for banning supply chain risks just because you want to ban them from the supply chain.
Not sure what you think “the law” is, but no, this kind of thing happens all the time. Both political teams do it, regularly. Biden, Obama, Bush, Clinton…all have routinely found an existing law or rule that allowed them to do what they want to do without legislation.
> The law, however, is not “first find the effect you want, then find a law that results in that, then accuse them of that.”
In this case, no, there’s no such restriction. The administration has pretty broad discretion. And again, this happens all the time.
Sorry, it sucks, but if you don’t like it, encourage politicians to stop delegating such broad authority to the executive branch.
It doesn't harm national security, but only so long as it's not in the supply-chain. They can't have Lockheed putting Anthropic's products into a fighter jet when Anthropic has already said their products will be able to refuse to carry out certain orders by their own autonomous judgement.
The government can refuse to buy a fighter jet that runs software they don't want.
Is it really reasonable to refuse to buy a fighter jet because somebody at Lockheed who works on a completely unrelated project uses claude to write emails?
I’m not sure if you deliberately choose to not understand the problem. It’s not just that Lockheed can’t put Anthropic AI in a fighter jet cockpit, it’s that a random software engineer working at Lockheed on their internal accounting system is no longer allowed to use Claude Code, for no reason at all.
A supply chain risk is using Huawei network equipment for military communications. This is just spiteful retaliation because a company refuses to throw its values overboard when the government says so.
This isn’t the case, sadly. Some people, like Ben Horowitz sadly, have gone completely off the deep end.
Some are culture warriors who feel they have been wronged, some are opportunists. But the thing with opportunism is that this is who they are and what they believe in. Having a president who is corrupt is exactly what they want because they know exactly how to work with him: quid pro quo.
There is no distance between them being pro-Trump and opportunistic. He’s the perfect embodiment of those values.
This is patently silly. The US does not have a democratically elected dictatorship.
People and companies are free to do whatever the fuck they want that’s not illegal. They can resist any government priorities for any reason, including finding them destructive or anti-democratic or corrupt.
The government is able to change the laws within the current system to back its will—regardless of whether it’s in the interest of the people who voted for them, let alone the entire population.
He got the prompt, asked questions about throughput requirements (etc.), and said, “okay, I’d put it all in Postgres.” He was correct! Postgres could more than handle the load.
He gets a call from Patrick Collison saying that he failed the interview and asking what happened. He explained himself, to which Patrick said, okay, well yes you might be right but you also understand what the point of the interview is.
They made him do it again and he passed.
reply