I had an interview question. What would you do if two different people were emailing a spreadsheet back and forth to track something?
I said I’d move them to google sheets. There was about five minutes of awkwardness after that as I was interviewing for software developer. I was supposed to talk about what kind of tool I’d build.
I found it kind of eye opening but I’m still not sure what the right lesson to learn was.
Having been both the interviewer and the candidate in this kind of situation, this is really a big interviewer training failure.
The general way to handle this as an interviewer is really simple: acknowledge that the interviewee gave a good answer, but ask that for the purposes of evaluating their technical design skills that you'd like for them to design a new system/code a new implementation to solve this problem.
If the candidate isn't willing to suspend disbelief for the exercise, then you can consider that alongside all of the other signals your interviewer team gets about the candidate. I generally take it as a negative signal, not because I need conformance, but because I need someone who can work through honest technical disagreements.
As a candidate, what's worked for me before was to ask the interviewer if they'd prefer that I pretend ____ doesn't exist and come up with a new design, but it makes me question whether I want to join that team. IMO it's the systems design equivalent of the interviewer arguing with you about your valid algorithm because it's not the one the interviewer expects.
A good interviewer won’t be looking for a single solution to the problem. I’d expect them to entertain the Google Sheets answer - it’s good signal that the candidate will consider what already exists in the world. I’d rather extend the problem: the team is spending considerable time iterating with manual entry, what would you do?
Complete agreement. "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?"
"That does sound like something nice to have. However, recreating Google Sheets is a substantial undertaking. First, we need to evaluate the business case for duplicating something that already exists to ensure that there is a net benefit in doing so. Second, we need to determine if the business has sufficient capital to see the project through."
That's a good real world answer, but a terrible SWE interview answer.
There is a difference between being smart and acting smart.
I suspect a lot of businesses are going to make this mistake in the "SaaS is dead" era as companies try to eliminate $50k/mo subscriptions for boring business software, and they figure it's easier to burn AI tokens creating an internal solution they didn't plan on maintaining in the far future.
Funny times we're in right now.
> "now what if we wanted to build it in-house?"
"Well I would probably go home and work on my resume because that's a fool's errand."
I hate going to work and reinventing wheels all day because the company I work for thinks it's so special that every business function needs a 100% tailored solution to solved problems. I much prefer working somewhere that's able to tailor business processes to conform to existing standards.
But maybe that's just me.
I’ve interviewed a few hundred people. Probably approaching a thousand, if not already. An interview is a scenario, and if you aren’t willing to engage in the scenario that we all agreed to partake in, that’s a huge warning sign that you’re going to be difficult later down the line. The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I'd call it an interviewer failure, not an interviewee failure.
I absolutely want people I hire to be "difficult" when the moment calls for it. If the scenario is one where the right business/user choice is "let them keep using Google Sheets", then the answer I want is "Google Sheets seems fine to me", no matter what people with more power start out wanting. Too many developers have been encouraged to be minions, not professionals.
Ditto for ones who act like everything is a nail for their coding hammer. A developer who can save a company a couple hundred thousand dollars by not turning something simple into a big coding project is a rare and precious commodity. Or should be, at least.
The thing to do isn't to give demerits for "being difficult". The thing to do is to then add something to the scenario where they get into the thing you want them to get to. "For this, we need better access control than Google Sheets allows us." Or, "We need this to be more closely integrated with our accounting system."
Unless, of course, what you're hiring for is the willingness to roll over for unreasonable requests from people with more power. Which, honestly, a lot of places are.
but also maybe its a green flag in that this employee might see the wood for the trees and save the company a lot of money later down the line. In my experience, a lot of engineers can waste a lot of time dicking around re-inventing wheels and whatnot.
While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate [0].
For reference, I think both answers are fine and both perspectives (its a positive or a negative) are equally valid. Its just that I don't think we can confidently state either way.
> While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate
Yes, I did. More than once. I always regretted it. Sure it could be a cognitive bias, but the entire interview process is essentially trying to figure out “can I work with this person”.
> I think both answers are fine and both perspectives are equally valid
I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
if you answer ""Well I would probably go home and work on my resume because that's a fool's errand." You probably are missing the wood and the trees.
and if you hire only based on solely on employee compliance then you are also probably missing the wood for the trees. I've worked in such orgs and they're extremely vulnerable to cargo culting.
I’m not hiring on compliance. I’ve accepted that his answer is correct but asked for the purposes of the exercise if he can put that to a side so we can talk about it. I’ve worked with and hired people like this and they tend to turn every molehill into a mountain, which is just killer on a small team.
I think you missed the point in GP's post. Not all organizations optimize for problem solving. Some organizations prefer subordinates who follow orders (or better, is able to read the mind of the boss to decipher what order he is actually making) than those who breaks out of the box and says ”just use gsuite, boss."
sure but if its not a privately held business then using gsuite is better for the shareholders. Ultimately its the bosses choice, but for the board to fire them its worth knowing they were aware of being able to use gsuite instead of pissing away resource on a needless project.
The question isn’t should we use gsuite, it’s can we talk about a tech problem. If you don’t understand that you’ve failed the interview.
Most real-world scenarios aren't so arbitrary, and hardly any have a "right answer". If I had a candidate that broke out of the box of our interview to give a good answer, and that's not the answer I "want", I'd be more likely to believe the interview question is the problem, not the candidate.
remember that we already did the "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?" part.
the "good answer" was already acknowledged, the "real-world scenario" answer was accepted.
the second part ("what if we wanted to build it in-house") is purely hypothetical to gauge how the interviewee would approach the specific technical challenge. if they again say "well that is dumb i would just use sheets", that is absolutely an interviewee problem.
> The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I think a lot of people miss this point.
Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.
Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.
In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).
I think the contrived scenarios you come up with need to not have a trivial solution. Everything about my brain is optimized for KISS, it breaks everything to turn down simple solutions to reach for something more complex.
Think of it this way: they're paying you lots of money to build something boring that has a lot of prior art/research available to you for free. This could be the easiest money maker in your life.
It's not your problem they're hellbent on building a new wheel. They're willing to pay you!
Chances are, you've thought of your own pain points in whatever they've asked you to build and you've now got an opportunity to shine by solving them and demonstrate your expertise.
There is a tool invented lately, that's very good for solving problems, that are well-researched and had been solved multiple times already. This tool is actually why there is a RAM shortage in the world right now.
Some even say, this tool will replace a lot of workers soon(sic!).
Setup Etherpad
The obvious way is to put the spreadsheet file on some shared network location.
You still need some "locking" mechanism so two people don't try editing at the same time.
Which again probably means Google Sheets is the best answer!
While I agree, how much training does anyone get as an interviewer? I spent 10+ years doing interviews at all sorts of orgs (including Fortune 500s, government, etc.) without a single hour of interviewer training.
Now that I think about it, none of those organizations ever trained me at anything at all. Huh.
> none of those organizations ever trained me at anything at all
They trained us repeatedly not to bribe foreign government officials, even though I had zero access to anybody like that. There was also some mandatory training against harassing coworkers. I.e. "protect the company from lawsuits" training, not "here are some ideas for how to do your job more effectively" training. They were megacorps, too.
> "protect the company from lawsuits
Yeah that's proven by the fact they get degree educated level engineers and force feed them videos designed for people working entry level positions. Its a crying shame because there's actually a lot of interesting discussions around nuance that are just sidelined by these videos creating basic bitch absurdities:
> During the lunch break, Jim has dipped his penis into Samantha's yoghurt
> is this:
> a) entirely acceptable, its just his culture
> b) a borderline issue
> c) something that someone should report to HR
Instead of:
Jane is developing feelings for someone that reports to her, they meet up outside of work and have a one-night stand. What should Jane do next?
> It's just his culture.
Wrong. Her yogurt, her culture.
That's unusual. Maybe that's a US thing? In Europe anywhere I've had to interview people I've received at least a couple of hours of training and then usually sat in as the shadow on at least one interview.
Quality varies, but I think it's only the super small outfits where I've been expected to just wing it.
> While I agree, how much training does anyone get as an interviewer?
TL;DR: not enough training.
As a hiring manager, whenever we start a hiring period I have a conversation with my interviewer team about what qualities we're looking for and review the questions they plan to ask in order to normalize the process. Stuff like "what does a good answer look like, and why? what does a bad answer look like? is this something easy for a candidate to engage with or will you spend half the interview just explaining the background? is this coding question unreasonably hard?" and so on.
I also look at the evaluations that interviewers give relative to other interviewers. Almost every hiring cycle I've done I've had to deal with some interviewer (all over the seniority spectrum) asking unreasonably hard questions.
Yeah, I had no training on being an interviewer before I started doing interviews. My manager gave me some tips, and I came up with two security bug-hunt exercises (was hiring AppSec engineers), but that was it.
Now, I wonder if I had rejected earlier candidates that I would have passed if I was a better interviewer.
The best advice I've had on interviewing is: Find an actual problem that your team is actually working through and ask the candidate how they would approach it.
Then to jazz it up: simplify the proble. To get to the root stuff that needs to be covered (e.g. ignore creating Jira tickets and focus on connecting to a database with cross-refion replication). You also want it to be simple enough that it can be solved in <30 minutes
Quite a bit based on the number of interviews performed at software companies. Being on either side of the fence gives you experience.
Same here. I receive a training budget at some places but it goes unspent. Everything is self directed learning in my own time.
Seriously? I worked at startups and research institutions. We trained people on interviews. I know Google used to invest quite a bit on interview training.
Sounds common to have training in big tech but I never received any training either. Sometimes we’d discuss changes we wanted to make to the interview process, which suppose could be considered adjacent to training.
I prefer pushing the constraints to motivate a different solution instead of asking them to do an unmotivated exercise.
“Google Sheets is a great solution for two people, but let’s say the department expands and now it’s ten people. How does this change your answer?”
It’s easy to break Google Sheets as a workflow by increasing the number of users, adding complex business logic, etc.
It’s interesting to see what candidates come up with and how they think. Sometimes the solutions are genuinely interesting. Mostly they’re not, which is okay. If you don’t give yourself the opportunity to learn as an interviewer, you’re missing out.
> this is really a big interviewer training failure.
Vast majority of interviews are pretty bad. I can only remember one or two interviews that did not colossally suck in some way.
It takes a lot of practice to become good interviewer and majority of ICs especially at small shops never get the required mileage. I don't think i really knew what i was doing until like 100 sessions in...
Thats fair, it definitely sucks for those seeking employment to have a really awful interview. How do you turn it around without looking like an a-hole…
At google where i started interviewing it worked pretty well at least initially when recruiters assembled panels such that you only get 1-2 inexperienced interviewers out of 6. They also didn’t let you do screens as fresh interviewer where it’s much harder to get signal. Every other place i worked it was basically a crapshoot
If I would be the interviewer in this kind of situation, I would just follow up with something like this: "that might be a good option, but let's assume you need to build a tool to replace those excel sheets, ..."
Surprisingly often you do get an interviewee who just won't accept the premise of the hypothetical. I've had people get hung up on the equivalent of 'but I'd just use excel' even with prompting/nudging/explanation that this is an exercise.
“Yeah okay forget sense, show me how good you are at budget protecting overdesign”
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.
They made him do it again and he passed.
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.
It's both.
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.
> and give them another shot
Isn't this rather giving yourself another shot.
Of course, but the point is you don't fail a candidate for this. Some people do, including some of the examples to which I was replying
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.
The point is that you’re supposed to kiss clown’s ring and do the dance.
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.
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.
sigh I miss in-person interviews.
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.
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.
> They made him do it again and he passed
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?
That was what I felt too. Why even need an interview for an acquihire when you have a direct link with the founder/CEO?
To maintain the illusion of meritocracy
> 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?
> you also understand what the point of the interview is
Exactly, it's also a test of ability to conform. Especially useful to weed out rogue behavior picked up in startups.
No, the point was to demonstrate how you’d design a complex system.
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.
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"
Let me guess: the point of the interview was to see if he was a "team player".
This is the part I would say thank you, and pass on the opportunity.
And yes, I have done this on a second Google interview about 15 years ago.
Sorry, I didn't get it. What was the 'right' answer?
Apparently some combo of kissing the arse and reading the mind of the interviewer...
It depends on the situation.
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.
"Postgres, because..."
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.
- [deleted]
nosql on serverless
distributed virtual abstract factory
You need the StrategyFactory in case you need further variances to the Factories you're making.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
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.
That is why they say, as a candidate, you are also interviewing the company you would be working for...
> They made him do it again and he passed.
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.
My read of the story is that the decision to hire was already made, the interviewer goofed but was then set on the right track by his boss.
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.
What kinds of system design questions got destroyed?
The correct answer is “Postgres would handle it, but if it needed to scale even higher, I’d…”
The point of a system design interview is to have a discussion that examines possibilities and tradeoffs.
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.
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.
Well, yes, doing the interview again is the right choice.
> okay, well yes you might be right but you also understand what the point of the interview is.
So the point is? I honestly dont understand.
The point isnt to give a simple answer, even if it's a correct answer. The point is show how much you know and how smart you are.
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 ?
> The point is show how much you know and how smart you are.
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.
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.
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.
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
Ha! I just had a debate about this with my friend. A certain ferry company uses a big Google Sheet to track where all of its vessels are currently docked in their home port, as well as which employee is assigned to which vessel for the day, etc (it's very information dense with color coding, and employees check it daily to get their vessel assignment). My friend thought this was completely unacceptable for a big company, and that they should build a bespoke software for this purpose. I think that it was a brilliant idea to use Google Sheets, it already solves all of the difficult problems and obviates the need to have an inhouse software development team or an expensive contract. I buried my hubris deep underground
As a teenager I worked at a company that rented rafts for a short trip down a river. We’d take the rafts from the customers at the end and truck them back up to the start. As they became bigger and busier, it became more important to keep track of the status of rafts and know when they were going to be getting back to the top.
They paid tens of thousands to have software made for this purpose. It sucked and was totally unable to handle the simultaneous realtime access and modification that was required.
They knew I was good with computers, so asked me if I had any ideas. In about an hour I made them a Google Sheet that worked great for the next several years until I left.
I've just spent a few weeks making a tool in our software to replace a complicated google sheet, and it was surprisingly hard. I think the most important thing was that our designer really figured out what the tool should do. If we've just replicated what they have and made a columnar editor of sorts, we would've just made a less flexible tool for them. But in the end, we made something not even resembling what they had, but which actually solved the core issue, and I think that's important.
And when you take away their sheet, you better be ready to support them. If they need to track new data, they could just add a new column in their sheet. Now they have to talk with tech. If tech blocks operations, they're quickly back to their sheets. The tool made by tech should be an enabler, not something to force compliance or whatever.
Sheets are so, so flexible. This can be really hard to replace. At the same time, they're also brittle with little system support. Like the example above, what if you assign someone not working that day to a boat? Or accidentally put two boats in the same location? Lots of small issues that proper tooling could handle, especially when backed with more data inside the system.
What made the operators happy to use my tool in the end was that they didn't have to punch so many numbers. They would copy paste numbers from various systems into their sheet every hour to keep track. The tooling pulls it in real-time.
So we replaced this one sheet, because it would help them a lot. But their other sheets we're leaving untouched for now. Nothing to gain by moving them. So judge each sheet individually.
My startup used Google Sheets as a CRM until we discovered there’s a 3 million row limit (by running into it) and had to build something else. Sheets is amazing. Don’t forget to lock that first header row, though.
I'm there with you... maybe, maybe using the sheets API to create a simpler front end for very specific use cases, like an individual seeing their assignment for the day, or maybe texting everyone that info.
As much as people will rely on databse (rdbms/sql) backed applicatons, in the end a lot of the business world runs on spreadsheets... Not only that, but excel, and I'm assuming plenty of others have integration points for pulling data from other resources... Spreadsheet masters can do very impressive things with what appears to be a simple tool.
I've seen suppliers using google sheets for a list of tens of thousands of items. Also color coded and filterable and what not. It worked. I could access it programmatically, I had no complaints. (Especially with an experience of some of these suppliers having shitty hosts and shitty platforms and their massive XMLs taking forever to load.) Then again I'm sure I would speak differently if someone just decided to rename a column randomly :D
We have no idea if its a good solution or not. It depends upon, among other things: how long it takes to update it, the error rate, and how acceptable those errors are.
All fun and games until an Intern deletes the original sheet or fatfingers critical information.
[dead]
[dead]
I think the correct answer would be to ask "why are they doing that and not using Google Sheets?".
There are a lot of good reasons for not using Google Sheets. Maybe the spreadsheet is using features that Google Sheet doesn't support, maybe one of the parties is in China, where Google services are blocked, maybe it is against company policy to use Google Docs, maybe they have limited connectivity.
It is good to acknowledge the obvious, off the shelf solutions, but if you are given a job, that's either because the customer did their homework and found out that no, it is indeed not appropriate, or, for some reason, they have money burning their pockets and they want a custom solution, just because. In both cases that's how you are getting paid. So, I don't consider "use Google Sheets, you idiot" to be an appropriate answer. Understand the customer specific needs, that's your job, even more so in the age of AI.
And maybe the interviewer will be honest and say "just assume you can't, this is just an exercise in software architecture".
> What would you do if two different people were emailing a spreadsheet back and forth to track something?
I realize this is part of an interview game, but perhaps the best response is still to ask why this is a problem in the first place before you launch into a technical masterpiece. Force the counterparty to provide specific (contrived) reasons that this practice is not working for the business. Then, go about it like you otherwise would have.
I actually really prefer your answer. I would likely counter with, “what potential issues could you see with doing things this way?” But a) you’ve shown me that you don’t charge into solutions without first attempting to define the problems, b) your follow-up answer reveals to me what kind of things you think are important, and c) I’d probably quickly ask something like,”let’s assume that in the past, we’ve had issues with missing changes when emailing this back and forth,” and encourage some more dialogue.
I do dislike interviews where a candidate can fail simply by not giving a specific, pre-canned answer. It suggests a work culture that is very top-down and one that isn’t particularly interested in actually getting to the truth.
To give you the inverse perspective, an OG blogger named Steve Yegge made a list of five essential phone screen questions:
https://sites.google.com/site/steveyegge2/five-essential-pho...
Question three is this:
Last year my team had to remove all the phone numbers from 50,000 Amazon web page templates, since many of the numbers were no longer in service, and we also wanted to route all customer contacts through a single page.
Let's say you're on my team, and we have to identify the pages having probable U.S. phone numbers in them. To simplify the problem slightly, assume we have 50,000 HTML files in a Unix directory tree, under a directory called "/website". We have 2 days to get a list of file paths to the editorial staff. You need to give me a list of the .html files in this directory tree that appear to contain phone numbers in the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.
How would you solve this problem? Keep in mind our team is on a short (2-day) timeline.
In Yegge's case, he explicitly does NOT want a hand-written program, he wants the candidate to suggest a CLI tool, e.g.
grep -l -R --perl-regexp "\b(\(\d{3}\)\s|\d{3}-)\d{3}-\d{4}\b" > output.txt
———
So...
These questions aren't good or bad unto themselves, but when the person asking is engaging in "Guess the answer I'm thinking of," don't beat yourself up if you guessed wrong. Your answer might be prized by someone else with an enormous amount of experience hiring engineers.
At AWS, a team asked for help maintaining a bespoke internal Java service that diff'd json for manual reviews.. replaced it with a jq one-liner
A former coworker was evaluating the cleanliness and structure of some non-free GeoIP data that took the form of several large CSV files. He was writing nested loops in Go that parsed the CSV and evaluated the predicates that interested him, and it was arduous and not going as quickly as he would like.
I told him to slurp it all into a sqlite database and to express his data integrity questions as SQL queries.
It was still a pain in the ass for him, but leveraging that tool made things go a lot better.
The followup questions usually help, like: "What are they tracking?" and "What are the problems caused by using a spreadsheet?" That usually gives you a clue of the answer they're looking for. The answer might be bullshit, but you pass an interview by playing their game, not yours.
This! It’s better to assume that you don’t know some context than go with what appears to be the most pragmatic answer. Even in the real world.
Way back when I was in IT Admin, I used to have this problem all the time. Some non-tech person emails a spreadsheet, another non-tech person edits it, and saves it. The original person complains that they can't see the changes. Yeah, because it's saved in some MS Windows Profile location that no sane human would ever visit. My solution was to ONLY email links to shared files on a shared resource. The LAST thing I'd ever think of is writing software to solve this problem!
These days if I were interviewing someone and they said, "I'd use the simple solution that is fairly ubiquitous", I'd say, "yes! you've now saved yourself tons of engineering hours - and you've saved the company eng money".
I attach a copy of the file and then provide a network location for where it is located. Makes it easy for people to just open up a simple copy to look at it and they know where to go to access the original.
I've stopped playing the game of 'guess what the right answer is'
I would have said the exact same thing and pushed the interview to consider 'why are we creating a tool when something off the shelf solves our business needs? What kind of runway and resources do I have to meet this goal? What is good enough for our problem here? Do we want to expand our scope to enable external data integration and downstream data consumption"
You will find better employment outside the circus, possibly even selling to the circus
This is one of my favourite interview questions too. I ask a design question that technically could be solved using the specialist skillset I interview for but it would be insane to actually do that in the real world. It's a good opener to see how practical and open minded they really are.
Is it? I have long thought that most things business people are using a spreadsheet for belongs someplace else. They are easy ways to run quick what-ifs or make lists, but generally the right answer is update the system so they don't need a spreadsheet. If the data is financials - why can't your accounting system give everyone the view they need from the shared system? Othertimes what they really need are a database to track this. But a spreadsheet is easy and so they ignore all the problems it creates because it needs a real engineer (and often more money than they can spend) to create the right solution.
> it needs a real engineer (and often more money than they can spend) to create the right solution.
Then it's the wrong solution. Period.
There are plenty of annoyances with spreadsheets, but part of what makes them so robust and powerful is that they don't take a ton of specialized knowledge, and they remain incredibly flexible.
An expensive, complicated, static, "right" solution for a small business is folly (honestly - this stays true up to medium/large business). It's a ton of time and energy focused on the absolute wrong thing. When a spreadsheet can reach the same result in a fraction of the time.
Especially given the result may not actually be that important, and they pivot to something else entirely in the very near future.
I've worked at several startups. I'd caution even software startups from assuming that custom solutions are the right approach. They usually aren't. They're a waste of time and effort that ends up saddling you with a brittle, expensive solution designed to solve problems from last year.
You are missing something: how much is spent because the spreadsheet isn't the right solution - nobody measures this (or even knows how). How much are you risking because spreadsheets are not robust - when will a mistake catch up, and what will be the cost? There is a reason accountants use double entry bookkeeping, and spreadsheets don't have that.
Nobody has the money to spend doing things right unless they have been burned. That doesn't mean the money shouldn't be spent first.
Spreadsheets are powerful I will grant. However they are not robust. A robust system works very different and includes features (like tests) that your spreadsheet doesn't have (I don't if it could have them, but it is safe to guess they don't)
I didn't quite mean it that way. My question is basically asking "Does this hammer know that not every problem is a nail". To give a specific answer to your question, my accounting system is excel, and "everyone" is me. There are definitely plenty of places where a database makes sense. But it's also important for database engineers to understand where databases don't make sense. It's kind of like that old problem we had where people would keep on saying "We can do X with blockchain" and the typical answer is "ok but that's worse".
Well, you've long thought wrong.
Argh gawd I hate this!
There are plenty of reasons that a department within a company will prefer spreadsheets. Software is not the answer to everything and also this is the same problem you get when Microsoft introduces those pesky 'Power App' developers etc or previously the Sharepoint 'web parts' etc....essentially someone who kind of feels they are the 'owner' of some information then decides to formalise the process in their own little way.
Now you have a person wasting a bit of time making their little tool but you've also got people complaining that someone's now essentially taken control of it etc. At a former employer our procurement team used spreadsheets to track basically everything but importantly everything on our PCBs - every single component and their suppliers and prices etc (various factories around China usually). This would have been a horrible thing to try and formalise in a web app just because of how often they were all changing their own conventions etc (often suppliers changing what information they gave to them, too). It would have been a wild goose chase to formalise it and more than the trouble it would be worth.
I had a similar idea once when answering a Stack Overflow question[0].
Quoting your comment: "You definitely don't want to hire the person who thinks - bizarrely - that using library functions is a sign of weakness."
So true...I've failed interviews, because the interviewee did see using library functions as a sign of weakness.
I just wish that in those cases the interviewee gives feedback and allows you to rewrite instead of just failing you. I mean in practice nobody writes library functions themselves unless absolutely necessary, but I get that for some positions you have to demonstrate that you can write lower-level code if you have to.
I think that it was probably a poorly designed question, but surely you could throw the interviewer a bone by giving a custom answer after they reject the library.
I love how your answer was straight, to the point and leverages existing standards, then scrolled up to the question and had to go through someone else's thorough, multipage response. Full marks to both answers!
I do absolutely love the other answer!
The lesson to learn is that in-house development groups are often incentivized to “sell” custom software solutions to their organizations, as their existence (budget) relies on it.
As an interviewee it’s important to try and identify whether the group you’re interviewing with operates this way, literally: How will they get the money to pay for your salary? That way you avoid giving nom-starter answers to interview questions.
I wouldn’t be surprised and most likely would go for a walk :)
Not an engineer but reminds me of a similar situation I've seen interviewing
Sometimes we'll ask market sizing questions. We will say it's a case question, it's to see their thought process, they're supposed to ask questions, state assumptions, etc.
Occasionally we'd get a candidate that just doesn't get it. They respond "oh I'd Google that". And I'll coach them back but they just can't get past that. It's about seeing how you approach problems when you can't just Google the answer, and we use general topics that are easily accessible to do so. But the downside is yes, you can google the answer.
Honestly, if I'd have heard that, I'd hire you in a heartbeat, you solved the problem without increasing total cost of ownership to the company and meant we could move forwards
I'd actually trust you to take on harder problems
Doesn't really matter what the situation is, there's much more that can be achieved in my book with that kind of mindset :)
I'm also of the opinion that in an increasingly LLM software written world, being able to have this kind of mindset will actually be really valuable
I would ask, why are they emailing it? Maybe there's a good reason they can't use sheets.
I'm just not convinced the solution is learning to package simplicity in a more impressive wrapper.I get that "communicate your thought process" or "play along with the exercise" gets offered as the fix here. But that framing bothers me too. Why should simplicity require more justification than complexity? Google Sheets is the design. The fact that it doesn't sound like engineering is the whole point.depends on what metric it is that _you_ want to optimize. i would have given the same answer, then aikidoed their confusion into some quick lecture on efficiency of software solutions in a business context and finally a segway into a project i worked on (or made up on a whim) of related relevance that i assume would be more interesting to talk about instead. but given my rather unimpressive career i'd suggest to not listen to me.
Maybe you were supposed to identify what business need they were trying to solve and see if there was anything better than a spreadsheet?
Spreadsheets are a tricky one some people like the power and automomy they have with spreadsheets.
But more often spreadsheets are the only way to transfer data between solos and it wastes a lot of time and is error-prone.
It really depends on how much time is spent filling out the spreadsheet.
If they are collectively spending 1hr/mo on the spreadsheet then it’s not worth an SWE’s time to optimize it. If they are spending 4hr/day on the spreadsheet then it’s a prime candidate for automation.
It depends sometimes it's currently 1hr/month but more frequently and a dashboard would add value to the enterprise.
The annoying thing about corporate hiring practices is – speaking from experience – some of us would have loved your answer. But then it goes to committee and someone's like, "this iOS engineer doesn't know any javascript, and I'm an expert in javascript, so I'm a 'no'."
The awkwardness after your answered was the interview telling you something important. A team that penalizes picking the right tool over an impressive one is a team where you'll spend years creating complexity nobody needs. The lesson isn't "next time pretend Google Sheets doesn't exist." It's that you found out early what they actually reward.
I feel like you could start waxing poetic about engineering value of meeting people where they are, not reinventing the wheel, etc.
Then after a brief discussion of that you could actually ask if the purpose of the question was for you to design a system to handle that situation and jump into the design.
In our agency that would be a plus, because we focus on customising existing products instead of building everything from scratch.
Exactly because that means less costs for software development when deliverying solutions.
Remember you're interviewing them just as much as they are interviewing you.
It's a culture fit question. When the culture is 'make everything ourselves' you're not a great culture fit. When the culture is 'just solve the problem', you fit in perfectly well.
Probably that you didn't want the job?
At least from the point of view of the interviewer, this was the point where they should give you a polite "hey, play along" nudge.
> At least from the point of view of the interviewer, this was the point where they should give you a polite "hey, play along" nudge.
That may be the game, but we all know it's bullshit, and we shouldn't be playing along.
If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software
> If a member of my team actually proposed building a bespoke system for something that can be straightforwardly done in a spreadsheet, we'd be having some conversations about ongoing maintenance costs of software
All interviews are contrived / artificial situations: The point is to understand the candidate's thought processes. Furthermore, we're getting Bilsbie's (op) take on the situation, there may be context that the interviewer forgot to mention or otherwise Bilsbie didn't understand / remember.
Specifically, if (the hypothetical situation) is a critical business process that they need an audit log of; or that they want to scale, this becomes an exercise in demonstrating that the candidate knows how to collect requirements and turn a manual process into a business application.
The interviewer could also be trying to probe knowledge of event processing, ect, ect, and maybe came up with a bad question. We just don't know.
Given that Bilsbie can't read their interviewer's mind, there's no way to know if that's what the interviewer wanted, or if the interviewer themselves was bad at interviewing candidates.
> The point is to understand the candidate's thought processes
The problem is that this is a 2-way street. The candidate is forced to guess the interviewer's thought process, because otherwise they may be pitching over the interviewers head.
We have to spend a ton of time calibrating hiring loops for this, because otherwise you get staff level candidates being failed by mid-career interviewers who don't understand the full context of the question they are asking (and hence don't understand why a staff eng solves it differently than they would).
I think you could start saying that there are multiple options. The simpler is sharing the sheets in Google (or Microsoft) Sheets. After this, Then, I would have asked if there are any security and/or compliance issue to doing so to analyze other alternatives.
I would have said "Move them to Google Sheets, but I gather from the nature of the question this is about finding a solution to build from an engineering standpoint..." and then go into ideas for how to collect user research, and apply those findings to a new tool build.
"I'm sorry, you're overqualified for this role"
- [deleted]
Yours was a clever answer to a stupid question. Tech interviewers need to leave college behind and start treating candidates as professionals. Puzzles, white boarding and riddles are unique to software engineering roles, you would never see a lawyer, an accountant, a doctor, or engineers in other disciplines going through any of this nonsense. These methods are proven to be a poor predictor of job performance. In my last role as lead engineer we would chat with the candidate over lunch about random topics. We first wanted to see if they would fit our team. Then in the afternoon let them work in a little project that was actually part of active development. This way we discovered that most candidates who went through the screening process could actually be pretty good team members. Our issue was having to decide who to give the offer to, while other companies keep rejecting candidates over bubble sort. Our attrition was also pretty low. So it happens that software engineers will surprise you when you treat them as grown ass adults. Who would have guessed?
Honest question: did you really not read the room there? I mean, if I were on the interviewer side, asking that question, and getting an initial answer "Well, to be honest I would tell them to use GSheets because given the current situation is the highest benefits/costs solution, but for the sake of a system design interview I would also think about designing a bespoke internal solution that would use blah blah blah". You would get a "strong hire" evaluation and you would still be able to turn down the offer if you wanted because that question might have been a red flag to you.
Did you get the job?
The lesson was that sometimes the interviewee can be more competent than the interviewer and they should run.
So nobody can ever hire someone better at particular skills than they are? Oh boy.
Run or email their seniors and ask them if they're hiring for higher-up positions.
But this is connected to another thread on HN about engineer/manager titles and how they basically have no value if you try to compare them between employers.
Or maybe this: https://news.ycombinator.com/item?id=47247719
I mean you gave the right answer imho. Software engineers are just business people whose main tool is coding. You know you're good if you don't reach for the hammer when you don't have a nail.
[dead]
I mean that's not really a good answer because you need to ask why they are sending a spreadsheet back and forth. Like yeah using a shared spreadsheet saves them having to email back and forth, but it doesn't help formalize the process, include validations, or make the data available to other systems. And maybe it would turn out that none of that is actually helpful in this case, but if you don't make an effort to ask and understand what's going on then you won't know if there's some bigger problem that needs addressing.
[dead]