Live data from Hacker News

Nobody gets promoted for simplicity

terriblesoftware.org

391–400 of 534 posts

Re: Nobody gets promoted for simplicity

#391

I'd add one point to this, as someone who voraciously fights against complexity at 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 so…

To add to this, sometimes leadership will assume (or even imply) that there's some laziness involved in not wanting to jump immediately on-board with the complex proposal. I often end up saying, "I can build this, and I will build this if product insists on it, but first let me suggest an alternative ordering of deliverables that starts with a simple implementation and moves towards this one." In almost every case, t…

Lead time for "how long until we can start using it" is one that is hard for a lot of folks to really take into consideration. There are terms for this, "earned value" and such. I have rarely seen them used in such a way that the planning actually worked out, long term.

Re: Nobody gets promoted for simplicity

#392

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

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.

That's unusual. Maybe that's a US thing? In Europe anywhere I've had to interview people I've received at least a couple of hours of training and then usually sat in as the shadow on at least one interview.

Quality varies, but I think it's only the super small outfits where I've been expected to just wing it.

Re: Nobody gets promoted for simplicity

#393
post #91
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…

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

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"

Re: Nobody gets promoted for simplicity

#394

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

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

Re: Nobody gets promoted for simplicity

#395
post #53

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.

Won't that show up in roi numbers?

Re: Nobody gets promoted for simplicity

#396

Earlier quoted context omitted.

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.

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

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

Re: Nobody gets promoted for simplicity

#397

Earlier quoted context omitted.

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.

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

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.

Re: Nobody gets promoted for simplicity

#398
post #388

Earlier quoted context omitted.

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

"That does sound like something nice to have. However, recreating Google Sheets is a substantial undertaking. First, we need to evaluate the business case for duplicating something that already exists to ensure that there is a net benefit in doing so. Second, we need to determine if the business has sufficient capital to see the project through."

There is a difference between being smart and acting smart.

Re: Nobody gets promoted for simplicity

#399
Extends to the extreme levels of SaaS-ification of fairly basic app functionality as well.

It's often simpler to build something you know than to integrate a 3rd party service, but it's highly frowned upon by a lot of devs and management.

Auth and analytics are things I'm thinking of - we have good tools to build these in-house. Also just running a database - never seen so many people afraid of installing postgres and a cronjob to back it up.

Re: Nobody gets promoted for simplicity

#400
post #333

Earlier quoted context omitted.

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

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.
Post reply on HN