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

451–460 of 534 posts

Re: Nobody gets promoted for simplicity

#451

Post by dilyevsky »

giancarlostoro wrote: post #439
dilyevsky wrote: post #406

Earlier quoted context omitted.

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

Thats fair, it definitely sucks for those seeking employment to have a really awful interview. How do you turn it around without looking like an a-hole…

At google where i started interviewing it worked pretty well at least initially when recruiters assembled panels such that you only get 1-2 inexperienced interviewers out of 6. They also didn’t let you do screens as fresh interviewer where it’s much harder to get signal. Every other place i worked it was basically a crapshoot

Re: Nobody gets promoted for simplicity

#452

Post by godelski »

This is so weird to read given the quote at the top. The kind of simplicity Dijkstra is talking about is a form of abstraction. He's talking about elegance. While the author is talking about a different type of abstraction, more like the image or a Jackson Pollock painting. Look at how Dijkstra talks here [0].

When a scientist says "simplicity" they mean "elegance". This is very different from "easy to understand". There's a reason that quote says simplicity is difficult to achieve. This doesn't seem in line with the author's examples. But it's easy to see what Dijkstra was talking about. Have you ever derived an equation in math or physics? You start one place, do a whole lot of work, and then you get out this "simple" thing. You could write pages of math to come up with an equation that uses only a few symbols. E=mc^2 is simple but getting there was very hard and took a lot of time, thinking, and abstraction.

The author conflates simplicity with speed, not with what the end result is and how well it solves the problem.

Why are CS people against abstraction? All we do is abstraction? We act like all abstraction is the same, and it's evil.

We have to be more nuanced. I could see the entire blog post written in the exact other way where engineer A gets promoted because they complete more tickets and engineer B doesn't because they take too long. But the reality is that from such a high level we can't determine which solution is right. Sometimes A's method is the best and sometimes B's is the best. But we don't know the impact. B's solution could create more problems, like the author suggests, but also it could solve many problems that don't end up appearing. Same for A's solution!

I don't like this over simplification and the author's conclusion is naïve. If we make everything understandable to everybody then it's a race to the bottom Who does it need to be understandable to? The senior? An experienced developer? A junior? A manager?

Don't get me wrong, there's tons of unnecessary complexity out there and that's bad too. But for that I'll reference Knuth's famous and misunderstood quote where he says "get a fucking profiler before optimizing things". He too is talking about elegance, but a balance of how we should prioritize things.

[0] Concern for Correctness as a Guiding Principle for Program Composition https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...

Re: Nobody gets promoted for simplicity

#453

Post by john_strinlai »

theli0nheart wrote: post #408
maccard wrote: post #356

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.

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.

remember that we already did the "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?" part.

the "good answer" was already acknowledged, the "real-world scenario" answer was accepted.

the second part ("what if we wanted to build it in-house") is purely hypothetical to gauge how the interviewee would approach the specific technical challenge (shedding some of the "real-world" constraints so that the focus is technical).

if they again say "well that is dumb i would just use sheets", that is absolutely an interviewee problem.

Re: Nobody gets promoted for simplicity

#454

Post by BurningFrog »

jb3689 wrote: post #309
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.…

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?

The obvious way is to put the spreadsheet file on some shared network location.

You still need some "locking" mechanism so two people don't try editing at the same time.

Which again probably means Google Sheets is the best answer!

Re: Nobody gets promoted for simplicity

#455

Post by throwaway292939 »

aarestad wrote: post #389

The example he gave where each dev gets a single feature done seems to skip over the opportunity that Dev A has - after she spends only "a couple days" on that feature to ship a simple solution, she now has the rest of that week to do another feature, and another... in fact, she could probably get 6 features done in the time that Mr. Complexity took to do his one feature (3 weeks in the straw-man example). Then the p…

I think sometimes flip side is that the engineer looks like they just shipped a bunch of "small features" A, B, C... because the solutions were so simple

Re: Nobody gets promoted for simplicity

#456

Post by BurningFrog »

9rx wrote: post #388
EthanHeilman wrote: post #343

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

That's a good real world answer, but a terrible SWE interview answer.

Re: Nobody gets promoted for simplicity

#457

Post by ChrisMarshallNY »

Yup.

As a manager, I preferred engineers that delivered simpler code, but I also ran a team of experienced, high-functioning coders. I suspect teams with many less-experienced people get The Parable of The Toaster[0].

[0] https://www.danielsen.com/jokes/objecttoaster.txt

Re: Nobody gets promoted for simplicity

#458

Post by ChrisMarshallNY »

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…

I remember getting a test, in an interview in the 1990s, where I was asked to design a set of gates (ICs) to do some binary maths (Division, multiplication, etc). The input was an 8-bit set of leads, and the output was an 8-bit set of leads.

I looked at the formula, and drew two wires, connecting a couple of the leads from the input, to the output.

I was offered the job, but ended up declining it.

Re: Nobody gets promoted for simplicity

#459

Post by narmiouh »

I feel like the article is conflating simplicity with minimalism. Just doing the minimum of whats asked isn’t in itself enough to differentiate great vs ok.

Simplicity is worth recognizing only when the person started with a complex problem and ended up with a relatively simpler solution.

For a straightforward ask you will have people who will just build a hut and another will build a campus, who is right really depends on many factors and time.

Re: Nobody gets promoted for simplicity

#460

Post by JDye »

voxl wrote: post #385
JDye wrote: post #272

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

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

It's more "just put it in A database". If someone said MongoDB I'd be just as happy.
Post reply on HN