Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody gets promoted for simplicity

terriblesoftware.org

Post reply on HN
Print view View original

401–410 of 534 posts

Re: Nobody gets promoted for simplicity

#401

Post by sam_bristow »

praptak wrote: post #53
codingdave wrote: post #2

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.

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

One of my the papers I share around a lot is "Nobody ever gets credit for fixing problems that never happened (2002)"[1]. I like it because it's not purely about software so the examples resonate better with some exec level people in other teams I work with.

[1]https://ieeexplore.ieee.org/document/1167285

Re: Nobody gets promoted for simplicity

#402

Post by a4isms »

bilsbie wrote: post #73

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…

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.

Re: Nobody gets promoted for simplicity

#403

Post by bigfishrunning »

gondo wrote: post #329
slfnflctd wrote: post #129

Earlier quoted context omitted.

> now nobody fully understands what was generated To 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…

People on call will use AI as well. As long as the first AI left enough documentation and implemented traceability, the diagnosing AI should have an easier time proposing a fix. Ideally, AI would prepare the PR or rollback plan. In a utopia, AI would execute it and recover the system until a human wakes up. Or at least there is something to chat with about the issue at 3am.

> In a utopia, AI would execute it and recover the system until a human wakes up.

in that utopia, the on-call guy doesn't have a job

Re: Nobody gets promoted for simplicity

#404

Post by fatnoah »

dmurray wrote: post #400
btilly wrote: post #333

Earlier quoted context omitted.

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 laye…

If you're interviewing at Google, the expected answer to the interview question can't be to use Google's internal tools. "Use Postgres" is the standardized, understandable answer for anyone outside Google who needs to solve Postgres-shaped and Postgres-sized problems.

FWIW, that was the second time I interviewed at Google. The first time, which resulted in strong yes across the board at L7, the first system design was to design Youtube Video Upload. The second was a more practical problem about replacing a high-volume logging component where correctness was critical but environment was space-constrained (i.e. no ability to run old + new in parallel).

Those were my favorite system design rounds ever, thanks to the problems being interesting and the interviewers also being very dynamic. It was also pre-Covid, so it was just awesome whiteboard design sessions.

sigh I miss in-person interviews.

Re: Nobody gets promoted for simplicity

#405

Post by giancarlostoro »

munchbunny wrote: post #248
bilsbie wrote: post #73

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

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

Re: Nobody gets promoted for simplicity

#406

Post by dilyevsky »

giancarlostoro wrote: post #405
munchbunny wrote: post #248

Earlier quoted context omitted.

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

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

Re: Nobody gets promoted for simplicity

#407

Post by myroon5 »

a4isms wrote: post #402
bilsbie wrote: post #73

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…

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 sin…

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

Re: Nobody gets promoted for simplicity

#408

Post by theli0nheart »

maccard wrote: post #356
SteveNuts wrote: post #352

Earlier quoted context omitted.

> "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 stan…

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.

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.

Re: Nobody gets promoted for simplicity

#409

Post by fluidcruft »

bitmasher9 wrote: post #206
fluidcruft wrote: post #198

Earlier quoted context omitted.

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.

Re: Nobody gets promoted for simplicity

#410

Post by johnfn »

Niko901ch wrote: post #21

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, onb…

Was this comment written by an LLM? It has a lot of the tell-tale signals, and pangram gives it a 100% chance of being written by AI.
Post reply on HN