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.

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.

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

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.

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.

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 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.

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.

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'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.

I had a similar idea once when answering a Stack Overflow question[0].

[0] https://stackoverflow.com/a/1831841/61938

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.

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.

  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.

I wouldn’t be surprised and most likely would go for a walk :)

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.

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.

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.

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.

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'."

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.

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.

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?

"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.

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.

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.

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]