5 ms·
I know this isn't really what you asked, but I've administered hundreds of software engineer interviews, and there are two very common mistakes I see when it co
by _moof 4y ago
I know this isn't really what you asked, but I've administered hundreds of software engineer interviews, and there are two very common mistakes I see when it comes to system design:
1. Not clarifying the problem. The very first thing out of your mouth should be a series of questions that helps you define the requirements more clearly. Identify use cases. Try to understand the scale; questions that start with "how many" are good ones.
2. Not being concrete. For example, I had a design problem I'd give people that usually wound up with them sending lots and lots of messages in real-time from one system to another. But when pressed, very few people were able to describe the contents of those messages in any detail.
Just thought I'd pass that along in case it's helpful to you. And I'll second what a lot of other folks here are saying: the best way to learn this is to get experience.
- Fiahil 4y agoAnd I would add : 3. Not being specific about any technologies. Instead of using a "SQL Database" and a "cache", just say "PostgreSQL" and "Redis". It's an interview, if you're not specific, I will start thinking you don't have any experience with Redis or Postgres. If you really don't have any, I will find out anyway.
- Aeolun 4y agoI would think it doesn’t matter? Whether we use redis, memcached or anything else is irrelevant to the point, which is that you want ‘something’ to function as a cache.
- maddynator 4y agoI would advise against it. Two reasons: - if the person interviewing you know the specific tech you picked, you give them an opening to control the interview. They can go anywhere they want and you would likely fall short unless you know the stack in&out - when you pick specific technology, you also have to defend why this one specifically. For ex, why redis and not memcache or why only postgres and not redshift.. If you keep it at sql and no-sql, you can easily defend the answer and control the interview
- patrulek 4y agoI would also advise against it. At this level i would expect the more abstractive way of thinking. I don't see a reason to go so much in detail right now. Model > tools.
- bluesnowmonkey 4y agoAs an interviewer I ding people who don’t understand the underlying capabilities. They often matter! Like if the design depends on modifying two keys atomically, a transaction is required. Some KV stores have that ability, some don’t. Do you need the keys to be in the same shard now? What kind of persistence is required here? Redis and Memcache are quite different where the rubber meets the road. Gotta know what you’re talking about, don’t handwave over the details.
- manimino 4y agoGreat point. It's also hazardous if your interviewer does NOT know the specific tech you suggest. They may reject it with "Sounds suspicious, if that's any good why haven't I heard of it?"
- nly 4y agoI interviewed someone who put an Amazon AWS product in every box on their design and was unable to explain how each would solve a particular problem except "Amazon product X solves this for us". No abstract thinking. Strong no.
- nolevels 4y agoAll these differing opinions on this tells me interviews are a crapshoot subject to the interviewer's whims. If I got you for an interviewer I would need to be specific, for others who replied to this, I'd need to be generic. Hopefully the interviewer is helpful in this regards and indicates his preference, maybe by asking what cache would you use and why instead of silently docking me points.
- manimino 4y agoFrom the inside, it can feel like there are actually too many rules. The interviewer is likely running a fairly narrow script. The interviewer probably believes they are being fair or generous when allowing minor deviations from their structure. From the outside, it all feels random: unless you know the rules the interview is playing by, you can easily make a mistake. Each place has a different interview script and priorities.
- _moof 4y agoI loathe secret requirements in interviews and am up-front and explicit about what I'm looking for. Even with that guardrail though, lots of folks don't answer the questions I'm asking. So I guess a more general piece of advice would be: listen to the interviewer, listen to the question, and answer the question that was asked. (This is the same advice I give people when I'm coaching them for FAA oral exams, incidentally. People really have a hard time listening to a question and answering the actual question.)
- Aeolun 4y ago> But when pressed, very few people were able to describe the contents of those messages in any detail. Can you explain why this matters? It’s an architecture interview right? Not an API/Worker/Queue design exercise. It’s not like I don’t expect someone to be eventually able to figure out the contents of the payload, I’d just not expect it to be at the forefront of their mind.
- 28304283409234 4y agoEmails with attachments vs plain text messages. Binary content. Compressed content. Size matters, especially at scale.
- Aeolun 4y agoAh, gotcha. We're still talking about 'what kind' of messages. Not, 'which fields', which is what I understood.