Discussion

Terrible Software

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

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

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

Folcon: I feel like if that's the thought process, that should be stated up frontThere's a ton of incredibly talented neurodivergent people in our ecosystem who would trip up on that question just because of how it's framedBecause 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?

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

BenoitEssiambre: If you're at a place that rewards complexity, you might be able to pitch simplicity as something that to get right, requires deep understanding of complex information theoretic concepts and deep understanding of ontological knowledge about the domain (it helps that this is true https://benoitessiambre.com/simple.html ). You can talk about the Bayesian Occam's Razor ( https://benoitessiambre.com/abstract.html ) and about minimizing the entropy of code ( https://benoitessiambre.com/entropy.html ), of tests ( https://benoitessiambre.com/integration.html ) and even of infrastructure ( https://benoitessiambre.com/pgcentrism.html ).

PKop: 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.)

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

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

tasuki: "The Parable of the Two Programmers" by Neil W. Rickert is pretty much about this, from the year 1985...

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

renegade-otter: 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.

LandR: 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 ?

Niko901ch: AI coding tools are making this problem worse in a subtle way. When an agent can generate a "scalable event-driven architecture" in 5 minutes, the build cost of complexity drops to near zero. But the maintenance cost doesn't.So now you get Engineer B's output even faster, with even more impressive-sounding abstractions, and the promotion packet writes itself in minutes too. Meanwhile the actual cost - debugging, onboarding, incident response at 3am - stays exactly the same or gets worse, because now nobody fully understands what was generated.The real test for simplicity has always been: can the next person who touches this code understand it without asking you? AI-generated complexity fails that test spectacularly.

mattcollins: On the other hand, AI coding tools make it relatively easy to set and apply policies that can help with this sort of thing.I like to have something like the following in AGENTS.md:## Guiding Principles - Optimise for long-term maintainability - KISS - YAGNI

musesum: I wrote something similar in a Claude Code instructions.md: "minimize cyclomatic complexity" What happened next? It generated an 8 line wrapper function called only once from a different file. So, I told it to inline that logic in the caller. The result? One. Line. Of. Code.So, I asked it to modify its instructions.md file to not repeat that mistake. The result was the new line "Avoid single-use wrapper functions; inline logic at the call site unless reused"instruction.md is the new intern.

arealaccount: I'm not sure I agree wit this, if I have work that needs to be done, and have a vague idea how long it should takeThe engineer that consistently quotes 3x my expectation (and ends up taking 4x with bugs) is going to look way worse than the engineer that ships things quickly with no drama.

misja111: This is not entirely true. In an environment driven by business stakeholders, the engineer who ships features quickly, and that break rarely in production, will be greatly appreciated. The engineer who takes weeks to over-engineer a simple feature, which then runs into unexpected side issues in production, much less so.The environment where the over-engineer tends to be promoted is one where the engineering department is (too) far separated from where the end users are. Think of very large organizations with walled departments, or organizations where there simply is not enough to do so engineers start to build stuff to fight non existing issues.

_vertigo: This was my exact thought process reading this. The business side of my company does not care or want to wait for complex solutions that sound cool to engineers. If anything, we have the opposite problem: convincing business stakeholders when complexity is in fact warranted.

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

Gooblebrai: > They made him do it again and he passedI'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?

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

HarHarVeryFunny: I forget who said it, but it seems that AI is basically an amplifier of the talents (or lack of them) of whoever is wielding the tool.In the hands of an experienced developer/designer, AI will help them achieve a good result faster.In the hands of someone inexperienced, out of their depth, AI will just help them create a mess faster, and without the skill to assess what's been generated they may not even know it.

bagacrap: I am the type of engineer who prefers simplicity and I have not found a way to make AI increase the simplicity of code I'm working on. If left to its own devices, Claude absolutely loves adding more member variables, wrapper functions, type conversions, rather than, say, analyzing and eliminating redundancies. So my experience is that AI is more closely aligned with the engineer type for whom the solution is always "add more code", rather than whatever its human manager would do.

Bridged7756: I agree, it just sucks at understanding style and simplicity.It's good at code generation, feature wise, it can scaffold and cobble together shit, but when it comes down to code structure, architecture, you essentially have to argue with it over what is better, and it just doesn't seem to get it, at which point it's better to just take the reins and do it yourself. If there's any code smells in your code already, it will just repeat them. Sometimes it will just output shit that's overtly confusing for no reason.

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

fennecfoxy: Yep people get promoted for bullshit throwaway projects that are built in the fastest & dirtiest way possible so that management can dance & clap about how brilliant everyone is about every 2-4 weeks.

Steve16384: It's rare to have two engineers working separately but on exactly the same problem so their results can be directly compared.

mrweasel: [delayed]

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

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

slfnflctd: > now nobody fully understands what was generatedTo be fair, a lot of the on call people being pulled in at 3am before LLMs existed didn't understand the systems they were supporting very well, either. This will definitely make it worse, though.I think part of charting a safe career path now involves evaluating how strong any given org's culture of understanding the code and stack is. I definitely do not ever want to be in a position again where no one in the whole place knows how something works while the higher-ups are having a meltdown because something critical broke.

bandrami: This. I've been a sysadmin for a quarter of a century and have professionally written next to no software. I've debugged every system I've had to support at some point though. It's a very different skill set.

ziml77: [delayed]

austin-cheney: The name of the game is framing. You don't talk about simplicity, because most people don't really understand what simplicity is. They falsely equate it to easy.Instead you talk about how you complete all your tasks and have so much bandwidth remaining compared to all your peers, the beneficial results of simplicity. Being severely under used while demonstrating the ability to do 2x-10x more work than everybody else is what gets you promoted.In this vein simplicity is like hard work. Nobody gives a shit about hard work either. Actually, if all you have to show is how hard you work you are a liability. Instead its all about how little you work provided and that you accomplish the same, or more, than everybody else.

marcosdumay: Well, yes, doing the interview again is the right choice.

badosu: Sorry, I didn't get it. What was the 'right' answer?

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

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

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

wongarsu: 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

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

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

an0malous: Agree but I wouldn't say it's subtle, the slop builds up quickly

mrkeen: One more opinion piece uselessly recommending "simplicity" with no code samples or concrete takeaways.> It also shows up in design reviews. An engineer proposes a clean, simple approach and gets hit with “shouldn’t we future-proof this?” So they go back and add layers they don’t need yet, abstractions for problems that might never materialize, flexibility for requirements nobody has asked for. Not because the problem demanded it, but because the room expected it.$100 says the "clean, simple" approach is the one which directly couples the frontend to the backend to the database. Dependencies follow the control flow exactly, so that if you want to test the frontend, you must have the backend running. If you want to test the backend, you must have the database running.The "abstractions for problems that might never materialize" are your harnesses for running real business logic under unit-test conditions, that is, instantly and deterministically.If you do the "simple" thing now, and push away pesky "future-proofing" like architecting for testing, then "I will test this" becomes "I will test this later" becomes "You can't test this" becomes "You shouldn't test this."

codingdave: Sure they do. You just need to spell it out in business terms, not tech terms:"Reduced incidents by 80%", "Decreased costs by 40%", "Increased performance by 33% while decreasing server footprint by 25%"Simplicity for its own sake is not valued. The results of simplicity are highly valued.

vjvjvjvjghv: [delayed]

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

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

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

LPisGood: What kinds of system design questions got destroyed?

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

getnormality: 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!

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

rawgabbit: [delayed]

mrweasel: There's also the operational cost of running whatever is churned out. I wouldn't exactly blame that on AIs, but a large contingency of developers optimize for popular tech-stacks and not ease of operations. I don't think that will change just because they start using AI. In my experience the AI won't tell you that you're massively overbuilding something or that if we did this in C and used Postgresql we'd be able to run this on an old Pentium III with 4GB of RAM. If you want Kubernetes and ElasticSearch, you'll get exactly that.

yieldcrv: The “There’s no right answer we just want to see what you think” gaslighting should go straight to the DOL, EEOC, FTC as some form of abusive practice that excises it from the employment process under threat of economic sanctions

dude250711: It's a bad time to be an altruistic perfectionist, tell you what.Avoid hands-on tech/team lead positions like hell.

whattheheckheck: Thats the kind of thinking that got us into this mess... scab

mathgladiator: There is a balancing point.At core, complexity is derived from discovery of demand within those pesky complex humans.Simplicity is the mechanism of finding common pathways within the mess of complexity of a product.the tragedy is that simplicity is very expensive and beyond most organizations ability to support (especially since it can slow down demand discovery), and this is one of the allures of big tech for me. I was greatly rewarded and promoted for achieving simplicity within infrastructure.

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

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

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

dismalaf: All this is game theory top to bottom. The only way to really quantify productivity is to look at "how much" of a thing has been created. In this case, lines of code, features, files, etc... So of course people who want to maximize their own income through promotions will also be incentivized to maximize the only quantifiable thing that they're judged on.

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

jcmontx: Sad but true. I'm very strict with my developers and extremely cautious of introducing new "moving parts" to existing systems. I try to keep a single deployment-unit if possible. I like monoliths.

robertlagrant: I had a similar idea once when answering a Stack Overflow question[0].[0] https://stackoverflow.com/a/1831841/61938

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

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

ngow25: You can though. You can build a simple system that's easy to operate, and just sail it in.

sovietswag: 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

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

jsiepkes: I have a story about this; People had an HSM (in USB key form) which needed to be shared. The question came to create some elaborate piece of software for lending to prevent people from accidentally leaving it in their pockets and accidentally going home with it (which had happened a couple of times).Instead I went to the hardware store across the street and bought the biggest (and cheapest) screwdriver I could find and attached it with some cord to the HSM. They never lost it afterwards.

erelong: "Code footprint is 80% more efficient / less"(when there is a simpler design over more complex "big ball of mud abomination" in contrast)

ajspig1: 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'm just not convinced the solution is learning to package simplicity in a more impressive wrapper.

01284a7e: 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.

callamdelaney: Sqlite, the one trick interviewers hate!

tracker1: I'd add one point to this, as someone who voraciously fights against complexity t every turn, more and more as I get older. I've experienced times where leadership/management will assume that you're fighting against the complex solution simply because you don't grasp or understand it. It's irritating at best.The longest lived projects and solutions I've worked on have always been the simplest, easiest to replace solutions. Often derived from simple tests scenarios or solutions that just work and get shifted over without much re-work.What's somewhat funny, with this is that AI code assistants have actually helped a lot with continuing this approach for me... I can create a stand alone solution to work on a library or component, work through the problems, then copy the component/library into the actual work project it was for. I'm in a really locked down internalized environment, so using AI for component dev is on my own hardware... but the resulting work is a piece that can be brought in as-is. No exposure of internal data/resources.I don't think I'll have a level of trust to "one-shot" or vibe code solutions from AI, but leveraging the ability to spin up a project as a sample to test a component/library is pretty great to say the least.

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

oceanplexian: Ironically, this article is "over simplifying" the problem.In the FAANGs I've worked at, engineers who come from scrappy companies and implement hacks (Like the example of emailing spreadsheets around) undermine the business and will cost the productivity of thousands of people.However, at the startups I've worked at, the folks from big companies that try to implement a super complex thing (e.g. exotic databases, overly ambitious infrastructure) The results are equally catastrophic for a company attempting to bootstrap when the complexity is so far removed from their core business.What makes an experienced engineer is recognizing both states, understanding what works where and making the right trade-offs, usually from experience you can't fake your way through. I've seen a lot of projects that took 10-20 engineers 18 months to so we could sell something that landed a $100M contract with a customer. You see that enough times and you won't bias as hard against complexity. But of course it's situation dependent, like anything.

spelunker: This is definitely a "known problem". At my company we call it "promotion-driven development". The promotion guidelines call out that knowing when _not_ to build something is important, but how do you put that in a body of work? "Decided not to build A". Nobody cares.

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

Cthulhu_: Exactly, simplicity is a subjective term; some think of it as in Clean Code where codebases end up as oneliner functions or overly formal lasagna code with many clean-feeling layers, but they can't see the resulting complexity in the overarching architeture.

musesum: I wrote something similar in a Claude Code instructions.md: "minimize cyclomatic complexity" What happened next? It generated an 8 line wrapper function called only once from a different file. So, I told it to inline that logic in the caller. The result? One. Line. Of. Code.So, I asked it to modify its instructions.md file to not repeat that mistake. The result was the new line "Avoid single-use wrapper functions; inline logic at the call site unless reused"instructions.md is the new intern.

reedlaw: Maybe a better way to handle "minimize cyclomatic complexity" would be to set an agent in a loop of code metrics, refactor, test and repeat.

musesum: Good idea. Am still a bit shy around token budget spend.

Cthulhu_: I think this is at the moment the practical limitation to using AI for everything (and what the coding agents themselves also optimize for to some degree, or it's the slider they can play with for price vs quality, the "thinking" models being the exact same, but just burning more tokens).

musesum: Am waiting for the next Mac Studio to come out to experiment with the "AI for everything" approach. Most likely, the open source distilled models will lower quality. So, another "price vs quality" tradeoff. Still, will be fun to code like I'm at a foundation lab.

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

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

portly: Maybe I am naive but I still believe that simplicity leads to personal wins in the long run. Having simpler system designs lead to velocity and eventually you become known as the "team that can deliver".

Steve16384: Or, the team that everyone takes for granted and/or the pointy-haired bosses assume their project must be pretty basic and anyone can do it.

portly: But it frees up time to build more products, which could give you leverage for negotiating better pay.

notepad0x90: You can sell simple solutions as complex by focusing on what they solve. No one has to know your solution is simple unless they're looking under the hood.And complexity doesn't always sell better. A lot of times it might look like the whole thing is messy, or too hard to maintain, tech burden nightmare. Things that are simple might look complex and vice versa too, I think anyone who had to implement requirements from people who don't understand the implementation complexities will know this very well.

1024core: Except when one of the criteria for promos is "demonstrates complexity". Then you results do matter, but you don't have the "complexity" box checked.

praptak: You can't measure the impact of not creating a steaming pile of complexity.

e-topy: You can. GitHub is about to hit zero nines of uptime[0]. But feedback like that is far too late to be useful. Maybe (principal or senior) engineers should be the ones to judge, and be trusted by management that their foresight is worth pushing the deadline?[0]: https://mrshu.github.io/github-statuses/

EchoReflection: I imagine Steve Jobs would not have agreed with the statement "Nobody gets promoted for simplicity".

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

1024core: FAANGs are notorious for promoting complexity, and the results are there for all to see.One thing engineers can do to fight this, and I think it's mentioned in the article, is to write extensive documentation. Bosses in these companies are too lazy to dig into solutions and figure out for themselves; so they resort to proxies like the number of lines of code, number of pages in the design doc, etc.Unfortunately, some of us who aim for simplicity are also averse to writing long docs; but with the advent of LLMs, there is some relief in sight.My career has suffered a lot in terms of promos, etc. because I hate complexity.

blobbers: Haha. This title: Nobody Gets Promoted for SimplicityThis was the model at my last job. The "director" of software had strong opinions about the most random topics and talked about them like they would be revolutionary. His team was so far from the product teams they would just build random crap that was unhelpful but technically demo'ed well. Never put into practice. Promoted for 4 years, then fired.

GuB-42: 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 they homework and found 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".

sampo: > and give them another shotIsn't this rather giving yourself another shot.

erelong: Relatedly, I'm periodically thinking about the issue of people who prevent problems not being rewarded as much as those who become "heroes" for resolving avoidable situationsI guess it may be important to underscore the value that simplicity provides over needless complexity or to sell people on the value of problems prevented rather than preventable catastrophes that were dealt withMaybe we could encourage a culture of patting people on the back for maintaining reliable "boring" systemsSome people also crave "drama" so there might be a way to frame "boring reliability" as some kind of "epic daily maintenance struggle that was successfully navigated"

stahorn: The difference between the fire fighter and the fire safety inspector. The former puts out fires and saves lives and is of course a hero. The latter complains about things that never happen, wastes everybody's time and money and is generally annoying.

strix_varius: It seems like the safety inspector might be closer to a SOX compliance auditor or something... in this metaphor, the engineer who doesn't build something that "catches fire" is just the one who uses sensible materials, includes smoke alarms in the design, and chooses to use passive insulation in the walls instead of electric space heaters on a high-pile rug.

jghn: 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

andresquez: I think it's simpler than that, you get noticed and then maybe promoted based on what you deliver. The ability of delivering what you were asked to, on time, or even before that.Adding extra things can always help, specially like in the UI side of things, since higher ups will probably just notice that part.

noisy_boy: The only solution that I've found to work, somewhat, is to plan with it to design the APIs exactly how you want it, atleast the public facing ones. It still does all kinds of mess in the functions but those are easier to cleanup on the next iteration cycle. If you let it design everything, it'll definitely go overboard.

andix: 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, ..."

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

btilly: 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?"

jppope: The article's point is sound, but its missing a key component. People who build simpler systems are capable of getting more done - the build takes less, the maintenance takes less, etc. So when the engineer choosing simplicity is looking to get promoted they might have 3 or 4 bullet points to their name instead of 1.Of course, over-simplification is the wrong decision some times, the same as abstraction and complexity is the wrong decision some times...Your shortcut for promotion is generally building value for the company, but people need to remember that promotions support the business and they aren't free to the company.

jb3689: 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?

EthanHeilman: Complete agreement. "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?"

amelius: Simplicity is a driver for better abstractions. But now with AI, will we even develop new abstractions?

MarcelOlsz: I was in charge of cleaning up a slop codebase by someone who has barely even heard of 'coding' before. Let's just say, it was abstract.

Cthulhu_: tbh codebases like that predate AI code generators. I had one job where my predecessor was not a very good developer by modern standards, but he was productive... a dangerous combination.

MarcelOlsz: I also kind of respect it, it bothers me endlessly when everything isn't perfect and this guy just threw caution to the wind. Jokes on me as I'm working for him now. But it's not like anything that predates AI, I couldn't write this type of slop if I tried lol. Zero formatting, linting, or anything. Just straight goulash.

pretzellogician: Except you spend extra time making your code simple, rather than slapping together something that requires extra maintenance from the eventual owners.Ideally we need metrics saying, "my projects require 30% less support or 50% less brainpower than comparable projects". Things like "average cyclomatic complexity", etc.

austin-cheney: Simplicity is like any form of automation in that there is always an expensive upfront cost. The automation pays for itself by reducing time per interval, so its only a matter of when break even occurs as derived by the savings per interval multiplied by intervals in a given frequency.

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

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

reedlaw: This seems like a perfect use case for a local model. But I've found in practice that the system requirements for agents are much higher than for models that can handle simple refactoring tasks. Once tool use context is factored in, there is very little room for models that perform decently.

musesum: What I hope to do with refactoring is to distill namespace and common patterns into a DSL. I am very curious about what tradeoffs you found.

reedlaw: Whatever agent I tried would include thousands of tokens in tool-use instruction. That would use up most available context unless running very low-spec models. I've concluded it's best to use the big 3 for most tasks and qwen on runpod for more private data.

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

astrobe_: The problem simplicity is facing is mentioned in TFA with the keyword "future-proof", which is the typical instance of FUD in software. It is extremely difficult to fight against it, as, just like fake news, it would take 10 times more effort to debunk it than to make it. Yes, you spell out the cost of the additional layer, but it is invariably answered with "that's not so expensive", and risk aversion does the rest.

gmuslera: Not just simplicity, we are wired towards additive solutions, not substractive ones, on a problem we try to add more elements instead of taking out existing ones. And are those additions what counts, what are seen, not the invisible, missing ones.

tumetab1: True.By chance, recently in an architecture discussion document I added that one of aspects to consider is how easy is to remove (the whole thing) if it's not wanted anymore.It was an obvious case because it was an AI capability, which can be become deprecated/useless/too-risky very fast.

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

aljgz: In my team, I've been working to help everyone do a task that's necessary, but because it was too difficult, people bypassed it. Over time, I made it simpler, others are joining to make it even simpler, but in the process, I'm not doing as many "feature tasks" as I could. I joke that people are mad at me every day, but grateful every week and month.I had to stop trying to prove myself to the company. I have already done that when y'all interviewed me. Now I do what's best for everyone, and I want the company to prove to me that it deserves people who do the right thing despite the processes not valuing it. If it does not, I have enough resources to spend some time on the projects I cared about most.This mentality gave me peace of mind and helped many people in partner teams go faster and with higher quality.Management still does not openly appreciate it, but it shows in how they interact with me. Like when you learn to talk to your parents as equals. It's unexpected for them, but they quickly embrace the new interaction and they love it much more than the one before.Oh, and this is happening in a BIG company, and is not easy, the "failure to do what you're tasked with is failure to be acceptable" voice in the head is too strong and does not like to give up easily.

Quarrelsome: 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.[0] https://www.youtube.com/watch?v=rZ3ETK7-ZM8

e40: I hate clickbait titles like this. Of course, some organizations appreciate and reward simplicity. Mine does.

sztanko: Did you get the job?

Tepix: Setup Etherpad

EmilySmith23: This is true, but since the article mentions interviews. They're a game in itself.

david-gpu: > none of those organizations ever trained me at anything at allThey 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.

Quarrelsome: > "protect the company from lawsuitsYeah 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 HRInstead 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?

RobRivera: 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

phito: I keep reading this online but never encounter it in real life. People I work with and for like simple solutions that don't add complexity. It saves them time and money. I really wonder how is it that some people seem to encounter this toxic mentality so much that they assume it is universal. Is it a FAANG/US culture thing where everyone acts based on corrupted incentives?

mrkeen: It's the definition of simple that's the problem. For any definition of simplicity you might have, someone has an equal and opposite definition.Take these two alternatives: class UserService { PostgresDatabase db; } class UserService { IDatabase db; } There are some coworkers who will veto the first example for being too complex, because it brings Postgres (and its state and connections and exceptions and mappings) into the scope of what otherwise could have been a service concerning Users.There are some coworkers who will veto the second example for being too complex, because Postgres is all you use for now, and if you really need to use a second database, you can change the code then (YAGNI). Also the Interface gives you a pointless indirection that breaks IntelliSense so you can't just 'click-through' to follow the code flow.

tumetab1: I agree with your comment, but I disagree a both the example opinions... complex is the discussion :DI heard something that helps better framing those discussions, use "familiar" instead of "simple".An highly abstract way to access a database table, with ORM for example, can be simple because everyone is expecting it and knows how to do all tasks (changing schema, troubleshooting, managing transactions, etc.).Doing userService.pgSql("select ....") in the same way can be simple.

flashybaby: This is playing out in real time with AI. Someone uses ChatGPT to compress weeks of work into hours, and the organizational response isn't "great, let's scale this" -- it's panic about what it means for headcount and hierarchy.There's a short film making the rounds that captures this perfectly -- an employee uses AI to generate the quarterly results his whole department was working on, and instead of being promoted, he gets fired: https://youtu.be/O5FFkHUdKyEThe simplicity penalty is even worse when the simplification comes from AI. It's not just "you made us look bad" -- it's "you made our entire team look unnecessary."

easton: What's going on here? There's a AI generated song in a youtube video, but it was posted yesterday and this bot is here today. Did someone have future sight of what today's HN post was going to be?

elictronic: Quite a bit based on the number of interviews performed at software companies. Being on either side of the fence gives you experience.

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

swiftcoder: > 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

gwbas1c: > 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 softwareAll 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.

swiftcoder: > The point is to understand the candidate's thought processesThe 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).

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

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

JDye: We've had an interesting experience on the interviewing side of this. Asking a system design question and getting answers involving multiple layers of caching, pub/sub, event-driven whatever/etc.. when the real answer is to just use postgres. It handles the scale we're asking about. We know it, as that's what we use internally.I've only worked at my startup so I can't comment on scale elsewhere, but if our simple architecture can handle 30k requests per second, I think it can handle most other companies scale too.

voxl: If your interview questions answer is a particular technology then you're asking a really bad question.

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

jpollock: Won't that show up in roi numbers?

jpollock: There are definite discontinuities in there. What works for a team of 5 is different to 50 is different to 500.Even just taking fault incidence rates, assuming constant injection per dev hour...

h3lp: 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"

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

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

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

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

munchbunny: > 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).

morning-coffee: In my engineering job of over 30 years, I've noticed that the heroes that get rewarded for fixing the problems are usually the same ones who created the problems in the first place.I've only been a paid-on-call firefighter for 10 years, but I have yet to work with any who are also arsonists. ;)

dalmo3: Long rant, but the author never defines what he means by "simple". He heavily hints at smaller changeset == simpler.Too often the smallest changeset is, yes, simple, but totally unaware of the surrounding context, breaks expectations and conventions, causes race conditions, etc.The good bit in tfa is near the end:> when someone asks “shouldn’t we future-proof this?”, don’t just cave and go add layers. Try: “Here’s what it would take to add that later if we need it, and here’s what it costs us to add it now. I think we wait.” You’re not pushing back, but showing you’ve done your homework. You considered the complexity and chose not to take it on.

tetha: I agree. I generally don't ask "Do we need to future proof this?", I rather ask: "Do we paint ourself into a corner?"For example, if you implement a job framework of things calling a REST API to do stuff async, a sufficient first implementation is a simple monolith doing the stuff and some retries or periodic calls. Because, if it does not scale, we can start thinking about replacing that with something to put things into queues and scaling stuff-doers horizontally and such. But often enough, these simple things scale quite the distance.On the other hand, if you start introducing in-memory caches into a singular instance to taper around database performance... that's a huge issue. That always leads to pain.Additionally though, I"ve started to keep notes about people doing simple, efficient things without fanfare. This way, if my boss asks me what Bob did over the year, I can tell them that Bob made these problems disappear and how Bob is starting to handle this area of topics more and more. Suddenly Bob is growing responsible for this area, and if my boss asks Bob about these topics they did well in an annual review, Bob can shine. Hope they learn though.

shafyy: Not sure if you're kidding or not, but to write great maintable code, you need a lot of understanding that a LLM just doesn't have, like history, business context, company culture etc. Also, I doubt that in it's training data it has a lot of good examples of great maintainable code to pull from.

yudhiyudhi: Neither do most humans writing such code, i have seen llms generate better code than 90% of coders I have seen in the last 20 years

Thanemate: Awesome! However, the corporate is excited with using AI, making the coder the one who's at risk at getting fired for writing the exact same lousy (for the sake of the argument) code.Or worse: for not relying as much as possible to the AI who apparently can write just as bad code but faster!A subtle detail: you speak of coders, not software engineers. A SWE's value is not his code churning speed.

Jtsummers: > Picture two engineers on the same team. Engineer A gets assigned a feature. She looks at the problem, considers a few options, and picks the simplest. A straightforward implementation, maybe 50 lines of code. Easy to read, easy to test, easy for the next person to pick up. It works. She ships it in a couple of days and moves on.> Engineer B gets a similar feature. He also looks at the problem, but he sees an opportunity to build something more “robust.” He introduces a new abstraction layer, creates a pub/sub system for communication between components, adds a configuration framework so the feature is “extensible” for future use cases. It takes three weeks. There are multiple PRs. Lots of excited emojis when he shares the document explaining all of this.So in this scenario two solutions are produced: Fast to develop but probably brittle (it is not described as robust, but it is described as easy to change), slow to develop but not brittle (but perhaps too complex and likely hard to change).Both fucked up. Engineer A stopped too soon, and Engineer B built too much up before any value was realized.You want Engineer C: Makes the fast solution that gives you feedback (is the feature worth pushing further? do users want/need it?), and continues to produce a more robust solution that won't crap the bed.Engineer A is a potential chaos agent, tossing out and abandoning work too soon. Engineer B is a bottleneck who will waste weeks or months producing invalid solutions.Go for the middle path.

nyeah: Really you can. You look at the engineers who create steaming piles, and you look at the ones who don't. Over a year or two, the difference is easy to spot. For people who care to spot it.If there's no competent front-line technical management who can successfully make this simple comparison, then, sure, in that case the team may be fucked.

cloverich: It's easy to gloss over this assessment but ultimately this needs to be a key decision point for where you choose to work. No matter how well you manage complexity as an IC or a lower tier leader, if your upper tier of leaders don't value it, it won't last. Simplicity IME is not a "tail that wags the dog" concept. It's too easy to stomp out if nobody in power cares.

quaunaut: Except it's not something you can really accurately assess before you start working somewhere.

Paracompact: > It's just his culture.Wrong. Her yogurt, her culture.

thallavajhula: >I think there’s something quietly screwing up a lot of engineering teams. In interviews, in promotion packets, in design reviews: the engineer who overbuilds gets a compelling narrative, but the one who ships the simplest thing that works gets… nothing.I got emotional reading this. This is way too real.

alansaber: "I'm sorry, you're overqualified for this role"

alansaber: The only way to learn this lesson is the hard way

alansaber: Being able to project manage yourself is indeed a very difficult skill

9rx: "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."

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

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

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

pavlus: 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!).

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

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

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

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

geoduck14: 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

maccard: > 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 candidateYes, 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 validI 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.

bhk: Let me guess: the point of the interview was to see if he was a "team player".

bhk: Ah, but it's worse than this. The truly ambitious ladder climber creates not just unnecessarily complicated abstractions, but organizations. Processes for people to follow. Infrastructure for people to maintain. Committees to vet changes. Standing meetings.