Earlier quoted context omitted.
I had a similar idea once when answering a Stack Overflow question[0]. [0] https://stackoverflow.com/a/1831841/61938
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.
Nobody gets promoted for simplicity
241–250 of 534 posts
Re: Nobody gets promoted for simplicity
#242Re: Nobody gets promoted for simplicity
#243Earlier quoted context omitted.
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…
I feel like if that's the thought process, that should be stated up front There's a ton of incredibly talented neurodivergent people in our ecosystem who would trip up on that question just because of how it's framed Because 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?
Re: Nobody gets promoted for simplicity
#244Re: Nobody gets promoted for simplicity
#245Earlier quoted context omitted.
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…
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.
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.
Re: Nobody gets promoted for simplicity
#246Rarely have I seen an actually straightforward, simple feature that can be done in a day used as the basis to spin up a 3-week mini-project with a complicated new architecure.
What happens is a complicated-sounding feature is requested, and some devs will just take it literally and implement it, maybe along with some amount of "future-proofing" that logically follows because the spec is poorly scoped.
Other devs will spend some time thinking about it, realize that there is a really a simple requirement at the core of the request, and it only sounds complex because it was vaguely specified (or maybe these days an LLM was used to write the spec, and its vomit was copy-pasted verbatim). They just implement the simple thing that is the actual need.
This is one place where the agile/scrum practice of planning poker can help. You get a few smart people in a room, and discuss the story and its requirements. Hopefully someone will throw out a low number of points and say "isn't this simply asking for..."
Over my career, most of the complicated code I have written is no longer running. What is still running after 10 years? Postgres (or more broadly, a relational database). Fad frameworks or architectures come and go pretty quickly, they don't end up working as advertised, and it's on to the next thing. I no longer want to spend time in this hamster wheel churning out complicated code that will only end up as next year's tech debt.
Re: Nobody gets promoted for simplicity
#247Instead 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.
Re: Nobody gets promoted for simplicity
#248I 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…
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.
Re: Nobody gets promoted for simplicity
#249I 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…