[_moof]

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.

[Aeolun]

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

Emails with attachments vs plain text messages. Binary content. Compressed content. Size matters, especially at scale.

[Aeolun]

Ah, gotcha. We're still talking about 'what kind' of messages. Not, 'which fields', which is what I understood.

[Fiahil]

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

[maddynator]

I 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

[bluesnowmonkey]

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

[patrulek]

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

[nly]

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

[manimino]

Great 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?"

[nolevels]

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

[_moof]

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

[manimino]

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

[Aeolun]

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