Experienced interviewers: Is the key to a successful system design answer knowing when to give a hand wavy response?
Posted by the_collectool@reddit | ExperiencedDevs | View on Reddit | 19 comments
Context:
Currently going through some interview loops, senior to staff level interviews.
I find 1 hour is not enough for me to fully diagram an end to end solution, instead of ending the interview with a full component diagram I end the interview with tons of text that both describe requirements, the work api does and fleshed out entities.
I believe that the reason behind this is because I try to be extremely verbose and check every stone I see (example: I'll list out every single entity I identify and also list out every single property of those entities, while ensuring my interviewer understands and acknowledges what I said), i'm an experienced engineer so you can bet your ass I'm going to identify as much of the required data as possible.
I know 1 hour is not enough time to "design Venmo".
Question:
In order to make most of the given hour, should I quickly mention and not dive deep on every single topic? Instead letting my interviewer ask the questions he wishes to understand or getting to them during the dive deep phase of the interview? Being hand-wavy and only diving deep when asked?
ccb621@reddit
I find it helps to start at a high level and work your way down to increasing levels of detail. Let the interviewer decide if they want to dig deep on DB schema, API, or something else. Your issue seems to be that you’re trying to show everything, and running out of time.
Left_Opportunity9622@reddit
How high level is "high level" enough?
I recently had an system design interview where they asked me to "design WhatsApp". I started by specing out the data model, and the websocket-receptor service needed but then spent too much time figuring out how messages would get transferred between two clients connected on different hosts.
I received a rejection email from the recruiter today. What should I have done differently here? Is it okay to just draw a "box" for the middle service and move on?
ccb621@reddit
Start with asking for requirements and clarification:
It sounds like you jumped to a solution without fully understanding the problem and relevant constraints.
Left_Opportunity9622@reddit
I forgot to mention this in my post, but I did clarify the requirements with them at the beginning. The ask was to build out both one on one and group conversations, and add feature for message deletion.
The scale was 10M DAU. I didn’t ask for average vs peak usage though.
Re SLA, no specific number was provided. I proposed we need near real time latency - they seemed okay with this.
ccb621@reddit
You'll have to ask them for feedback. I wouldn't dwell too much on rejections. You'll go crazy trying to guess what went wrong, and it may not have been anything you did wrong.
titogruul@reddit
When designing stuff for your current job, do you also apply the "uncover every stone" standard? If so, how does that work with a bounded budget?
Or do you first map stuff out, things you know how to do get skipped and focus on the more risky things?
the_collectool@reddit (OP)
I sort of replied to this item here: https://www.reddit.com/r/ExperiencedDevs/comments/1fappkc/comment/llv9l5r/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
Been on a same team for 4 years, the team hasn't had attrition, we know the ins and outs of the systems.
And budget is not that small (big tech)
Also 10 years of not interviewing catches up to you
titogruul@reddit
Thanks for the link, it has helpful context.
Two thoughts:
As a tactical example, whenever I have to design a solution that involves API services, I'd check requirements (is it low load, as in <10qps? Is it relatively small as in ~1Tb?) but if it's your regular API I won't go deeper than definining resources: I've been building API services for 10 years, I can build another one. If the interviewer asks, sure we can go deeper in whatever angle they want, schema, scalability, etc.
the_collectool@reddit (OP)
I appreciate the feedback, however I'm not asking for an analysis on my profile rather what people look for in interviews.
Regarding #1, I've founded and taken a startup from 0 to an acquisition as part of the founding team.
. #2 could be a cop out, it's more of a justification for me to finding problems like "design VENMO" boring as an interview question.
I believe im at a. point in my career where I can understand both points, but i'm taking a bottoms up approach in my system design questions rather than top down .
JUst want to make sure that I stop attempting to achieve completeness in depth and rather aim for completeness in breadth. In my teams, I have taken hand-waviness with a negative connotation but from the comments in this post it seems the industry encourages it in an interview context.
titogruul@reddit
OK. I can stick to just the interview piece, hopefully you'll find it more helpful. :) In my system design interviews, I am mostly evaluating whether the person can navigate ambiguity to figure out a path towards solution. I typically throw an ambiguous problem and see if they can map out a path that I'm confident they will be able to manage it.
I have seen plenty of candidates that decide to rabbit-hole one specific aspect of the problem and ignore validation of the rest. I usually offer a hint and try to pull them out, sometimes it works, sometimes it doesn't. But if they get hired, who will be the one making sure that the rabbit hole they're focused on doesn't get obsoleted by some pivot or risk elsewhere materializing? It might be OK for a senior engineer (if they also show a lot of technical depth in that rabbit hole), but gets dicey fast for staff.
FWIW, I find "Design Venmo" a reasonable question. I wouldn't pick it since I prefer something I'm more familiar with so I can inject realistic context, but it feels both easy to grasp and details I'm sure there are many devils in the details to wrestle with. I usually ask folks to design a migration path for a service to new service with about 85% compatibility. But then I find puzzle coding questions pretty frustrating, so maybe to each their own. :)
MoreRopePlease@reddit
Can I jump in here, since you've had experience as an interviewet?
I'll be interviewing at a staff engineer level with Big Tech. I'm wondering how much am I expected to know about the details of sns, queues, buckets, kubernetes, how consistency and auto scaling works, etc? Is it enough to know that a queue is appropriate here, or that we need a db that is good at eventual consistency, etc?
I'm not an architect, or a db person. I know concepts but not the technical details. I let the back end guys, and devops, figure that stuff out, and I make sure that our solution designs will allow for everything to be connected and talking together, and that nobody is missing any pieces, like hey we need business rule validation, not just schema validation.
I'm trying to figure out exactly what I should be prepping. Do you know of any example YouTube system design stuff for the full stack staff engineer level?
titogruul@reddit
Of course, happy to give you as much rope as you need. :)
The conversation usually does happen at the level of what options are appropriate, but the justification and discussion of trade-offs is usually even more important than the decision itself.
Suppose we're discussing the Venmo example and say you choose your DB that has eventual consistency to keep track of the transfers. I'm coming from low-request background and, as I understand, eventual consistency is a solution towards write throughput, so I'll try to pick your brain about that: what DB are you planning to use (hopefully Spanner, I'm familiar with Spanner)? At what scale do more classical write throughput options (e.g. write partitioning) start to break down and your approach starts to be better; how do you deal with engineers applying transaction-consistent mindset and making bugs?
It might be hard to articulate those trade-offs without first-hand technical experience. But maybe you've led engineers who dealt with details, in which case we can talk more about how you were making sure they don't overengineer, cost of support, etc. Or maybe you don't have any experience at all, but are familiar with the concept and felt like it'd be a good fit; then we can talk about why you chose to take the learning risk for this specific case, how you can manage it, what other experience you had with adoption, etc. As long you're good at articulating the thought process and your approach keeps me confident that you'll be able to execute it, it's all good. Of course, sometimes candidates pull back and just accept whatever approach I seem to advocate, or stonewall the discussion, that makes me a bit less confident that they'll be able to adjust their approach to new things in a real world setting.
For a staff IC, I'd expect them to have first-hand technical experience at a couple of decisions, relying on soft skills for the rest. I can accept more soft skills for a more TLM/manager role.
For interview prep, I'd strongly recommend system design mock-interviews. Unfortunately, I don't learn these things by YouTube and I think this stuff is deep enough that YouTube won't lend itself well. https://gist.github.com/jboner/2841832 is a good thing to be always familiar with. https://staffeng.com/ can offer some inspiration.
rfbp@reddit
Maybe I am missing something, but what signal is the interviewer looking for here? Why not just ask the candidate if/what they think of your alternate approach instead of straight up proposing something and leaving it at that? If the candidate defends their solution, wouldn't the interviewer think they are being rigid? If they can see the pros of the proposed approach, and want to change their decision, would that mean they cannot defend their original approach?
titogruul@reddit
Well, I'm mostly looking for how they integrate my input into their plan. It's not really about which approach is taken in the end, but discovering, considering and articulating the trade offs.
The quote you highlighted is about one of the failure modes I encountered. Continuing on the Venmo from my previous reply, say candidate would lead with a NoSQL approach. I would then ask about why not a more standard SQL approach since you'd be able to use transactions and had candidates switch and go with "yea, that sounds like a good idea" and maybe extoll this newly found insight a bit more. I don't mind them changing their mind, but it can't be over a basic on the surface SQL vs. noSQL tradeoff.
I've used to throw another wrench that would point the other way (maybe write scaling for NoSQL?) and see if they bounce back, but more recently I just switch to something else.
rfbp@reddit
Makes sense, when the interviewer proposes something, start with the tradeoffs and then decide if you will change the design or not. Thank you for sharing!
Rough_Priority_9294@reddit
Faang interviewer here. Try hand waving me and you will get strong No hire.
the_collectool@reddit (OP)
“Faang interviewer” he says it as if that made him special or something 😂😂
Rough_Priority_9294@reddit
It doesn't make me special, but it makes me more experienced into getting into large companies than it makes you ( especially since I've got offers from literally every one of them ). I gave you information you were looking for, feel free to do with it as you please.
the_collectool@reddit (OP)
Who says my quedtion is even targetted at big tech, again… assuming FAang makes anything special is on you.
I just wasted the past decade between thise companies… I don’t want to do anything to do with them for at least the next 5 years of my career