Comment by bilsbie
11 hours ago
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?"
33 replies →
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.
2 replies →
In my case? Two days I think (it was long ago). Two very eye-opening days.
> 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.
1 reply →
Quite a bit based on the number of interviews performed at software companies. Being on either side of the fence gives you experience.
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.
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...
2 replies →
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.
2 replies →
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.
5 replies →
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?
1 reply →
> 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?"
2 replies →
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.
> 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?
1 reply →
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.
> 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.
1 reply →
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?
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.
Apparently some combo of kissing the arse and reading the mind of the interviewer...
"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.
1 reply →
nosql on serverless
distributed virtual abstract factory
1 reply →
> 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.
1 reply →
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.
5 replies →
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 ?
1 reply →
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.
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...
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!
1 reply →
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?
Just to be clear, I'm absolutely not kidding here. E.g., this is the kind of hiring process I favor: https://williampietri.com/writing/2015/slightly-less-awful-h...
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...
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]
> 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.
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".
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
I remember getting a test, in an interview in the 1990s, where I was asked to design a set of gates (ICs) to do some binary maths (Division, multiplication, etc). The input was an 8-bit set of leads, and the output was an 8-bit set of leads.
I looked at the formula, and drew two wires, connecting a couple of the leads from the input, to the output.
I was offered the job, but ended up declining it.
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.
1 reply →
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.
the lesson to learn is - don't let the conversation die off. think of all the weird scenarios that wouldn't make google sheets work.
e.g. no access to internet (or at least VPN access via completely locked down devices) / internal email server / only open source etc.
I had a similar idea once when answering a Stack Overflow question[0].
[0] https://stackoverflow.com/a/1831841/61938
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.
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.
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
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.
I would ask, why are they emailing it? Maybe there's a good reason they can't use sheets.
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'm just not convinced the solution is learning to package simplicity in a more impressive wrapper.
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.
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.
I wouldn’t be surprised and most likely would go for a walk :)
Remember you're interviewing them just as much as they are interviewing you.
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.
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.
1 reply →
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'."
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?
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'm sorry, you're overqualified for this role"
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.
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]