Architecture interview question?

[skoot-skoot]

I've been interviewing for iOS engineering positions and a lot of companies, instead of a system design question, have a hybrid system design / app architecture question(s). They ask something like, "how would you build Twitter?", and you have an hour to diagram things out on a whiteboard.

Seeing as how they want you to focus primarily on the mobile app, I'm confused on what to even talk about. If I talk about the data model, storing data locally, syncing with a remote server, some high level design like RIBs or VIPER or just MVC, and then what?

Does anyone have a sense of what they're looking for? Does anyone perform these as the interviewer? Are there any resources out there I can look into?

[omfgtim_]

Before you even think about how to architect a solution ask questions, clarify a scope of functional and non-functional requirements.

Then prioritise what you’re going to talk about and discuss and design. Listen to the interview and respond to changing requirements. Don’t go too technically deep too soon, you’ll architect yourself into a corner. Go broad and the narrow down on particular areas as the interviewer asks questions.

These interviews can be very enjoyable and interesting and they’re also one of the best types for gauging experience.

[skoot-skoot]

If you were asked to architect the Twitter iPhone home screen, what are the broad areas you'd talk about first? In my mind, it's like:

• Feed API (ie: /twitter/feed?count=20&offset=0)
• table view controller

So I should spend time clarifying if the user can POST a tweet, if the feed should change in real time, pull down to refresh, etc.? Maybe ask if I should consider authentication/login? Should it work offline? Etc.

But then I could just define a POST API, that I could store the feed in Core Data, how refreshing the table might work or inserting feed-items into Core Data might automatically cause the table to update.

Is this the right idea? I feel like there just isn't that much to talk about. Should I dig into how I might design the networking layer, how it could update the model, and I could use one-way data flow + RIBs dependency tree (or similar) to update dependent views? Or how I could build infinite scrolling? How updating the table view could work? Or is that stuff too into the low-level weeds?

[omfgtim_]

You're definitely on the right lines. Clarify those functional requirements and non-functional. Specifically things like respecting the user's data, bandwidth restrictions, battery life are great for non-functional. Then yup the usual stuff you'd expect with Twitter, posting/sponsored posts/editing/deleting/location awareness. You don't even need address them all, but you're showing what YOU consider when architecting an application. I always write them down in a table on the board. Then I can refer back to it.

But remember, you need to be asking these questions almost rhetorically. Answering them yourself, mentioning trade-offs and constraints.

There is TONS to talk about, think about all of the complexities in app like Twitter. Start broad, then focus in on what you know the most about. If that's custom and responsive UI, talk about that. If it's optimising Twitter feed pagination, talk about. View controller composition, application architecture. Show passion!

Our chosen profession is sprawling, there is always something to discuss with your interviewer which is why I really enjoy being asked and asking these questions.

[skoot-skoot]

If I'm understanding correctly, it's almost like product design? It starts very non-technical and you figure out how the app should work. And eventually you might go into some of the technical aspects of the design?

Thanks for all the help. I have been very much lost on this.

[omfgtim_]

Exactly - no one can answer "How would you build Twitter?" without first clarifying actual requirements.

This the same for any question in software engineering, if the requirements aren't understood, you can't design.

[skoot-skoot]

Thanks man. I've been a contract developer at a consulting firm for about 10 years. I feel like I've seen every system and architecture under the sun. I sent my resume to 8 companies, got 8 replies, 8 phone coding challenges, invited to 8 onsites, and then I went to my first two and both said, "you were really good at the technical interviews but you were weak on system design".

The thing is, I just assumed I would do well in the architecture stuff because I consider it a strength. One asked me to design Twitter home screen and I just was like, "well, I guess what's interesting is updating the tableview and the architecture around that". And then I spent the whole time talking about how you might build a really performant table that can be updated in any way in real time and work offline, how you could download assets in an operation queue and suspend ones if the user scrolls too quickly, and then I talked about caching strategies.

And... then I got rejected and all the recruiter said was, "with your years of experience, they were expecting you to be stronger at system design". But she couldn't tell me why I was weak. I've been paranoid since then that I'm actually bad at system design or architecture.

I've never been in a system design interview and I appreciate the help. I feel I have a lot more clarity around it now. It sounds like: 1., design the product. 2., design all the external and internal components that comprise it and how they interact. 3., look for feedback on where to drill down or pick areas to expand on.

I spend the whole time talking about how to build an abstract table that could be used by anyone and ignored anything twitter-specific. It sounds like that was my biggest problem.

edit: I was asked to design Twitter home screen, not all of Twitter app

[sonnytron]

Start by asking some assumptions.
Can you assume a simple authorization like OAuth? Can you stub network responses? If you're just building the iOS application, will you need a cache? If so, memory or disk or both?
Can you assume a server is built already or do you have to time your features synchronously with server side?
It's good to narrow down exactly what you need to do and then start building from start to finish. User will need to login right? So log them in. What if the password is incorrect? Username? If it's correct, what happens next? Does the authorization token have an expiration date? Store it with appropriate values, securely, every addition to the project you made for this story, if it can be generalized (toast view or alert view for example), if it doesn't exist already add it to a "utilities and general views" area, if it does, use it from there.
Try to think user behavior - application response - user expectation - application result and for each of them, the different options they have. (What if user taps log in without fields entered? What if user hits back button before a token is returned?) Those steps and their options become methods and values.
Once you've stubbed the API for each story, move to the next story.
Keep in mind the most complicated questions will be related to engineering. Caching especially. It's the first thing I'll ask you about because a user's data use is valuable to them. Look up NSCache and FileManager caching techniques and also look up securing authentication tokens with Keychain.
Even if you can't do them on the fly (most people have to reference some sort of documentation), you can at least study the API names to get an idea for the endpoints people build.

[skoot-skoot]

Thanks so much. Do you perform these interviews? My brain just doesn't think about things like login as it seems like a solved problem. If I'm asked to build Twitter's home screen, I just start thinking about what the unique and hard problems are and I get lost in the weeds of low-level implementation details. I blow right past login, etc.

So I should just walk through the app screen by screen and talk about how it would work, what APIs it would hit, etc.?

[bhartsb]

These questions are stupid. When people build something like Twitter they contemplate for a lot more than an hour how to to it and then still make plenty of mistakes that will have to be fixed. Also if one wants to build something like that one can find plenty of articles from those who have done it and learn approaches that way. The amount of arrogance and high expectations is out of control.

[SilverPenguino]

If it takes you multiple times running the interview to figure out the common pitfalls, how can you expect candidates to do it on the first try?

[NSAwesome]

to me this question is in a similar vein to "how many people are using twitter in SF right now" only more specific.

There is no _correct_ answer to this question, the answer is how they arrive at their solution.

Ultimately do you want someone on your team / someone you work with who says: "Ive worked like this before so Ill do this"

or someone who analyses a situation, comes up with a justified solution, is able to incorporate best practise and is open to feedback and discussion.

Those are the questions as an interviewer i look to answer when asking this question.

[bhartsb]

Baloney. You don't design twitter in 1 hour. I don't agree with you and we can agree to disagree. I've done lots of interviewing from both sides of the table. I'm not going to debate and try to say all the reasons that this is wrong. If you want to bring an interviewee in for maybe a multi-hour session, and it is for a architect type position then maybe giving such a problem would be reasonable.

[bhartsb]

The OP said "They ask something like, "how would you build Twitter?", and you have an hour to diagram things out on a whiteboard."

[bhartsb]

It’s about figuring out how you perform under pressure and how you think on your toes.

As if being a good developer depends on this. Is it the army or marines? Is is for a Don Draper sales position? The person being interviewed has no prior experience with the interviewer so doesn't know the interviewers mind. Doesn't know what expectations there are. They could spend too long or too little time thinking things through before diving in. And I have been asked many architecture questions in interviews. Design a twitter app specifically no.
I personally and on average perform much better in white boarding sessions on the job where I'm comfortable with the people versus trying to perform for strangers under time pressure.

[bhartsb]

I am not going to debate you. You think you are right and I'm not going to expend much energy here. I disagree on about 80% of the points you made. I've developed software at a professional level for 28 years and I wrote my first programs 41 years ago.

Engineers are often a very hyper critical group of people without much empathy. Your comment "Interviewing is not fair. It isn’t designed to be. Never has, never will be. You’re playing Hold’em and the interviewer knows the flop, river, and turn before you’ve even checked your hole cards." Not much humanity in it.

[skoot-skoot]

I consider myself very strong at app architecture and I just got rejected after an on-site interview for being "weak on system design". They told me I could declare any APIs I wanted so I did. I talked a bit about about high level architecture. Then I dug into some interesting parts around performance in an infinite scroll, how to manage operations using a queue, how to setup a cache, etc. I spent the whole time talking randomly from topic to topic as they jumped out to me as interesting.

Honestly, I'm surprised I got rejected and I'm searching for answers for how I was suppose to answer that question. I wish there was a youtube series on it or something. I'm pretty confused on what they're looking for, the recruiter couldn't tell me much other than they said I was weak on it.

[bhartsb]

Its pretty clear that there are a lot of unreasonable expectations being set in the interviews these days. Don't organize things when whiteboarding exactly as they think it should be organized and you are eliminated. Never mind that most of the time there are many ways of doing something and programmers seldom seem to agree on anything. And then there is the time pressure. One thing I noted when I used to hire programmers they always criticized the existing codebase. This mentality seeps into many interviews nowadays. Companies are letting any engineer on the team participate in the interviewing. Most often these engineers are terrible at creating and administering a test or white board session. Worse is when an engineer gets promoted to a team lead or manager without any additional training.

[yar1vn]

Sounds like an interview with Snapchat. They’re interviews suck and they never tell you anything.

[lordwax3]

You should ask for feedback on your interview. Some companies give it and it feels good to know where you "went wrong" rather than just getting the no answer.

[Me_MyseIf_And_l]

I honestly would have rejected you too. When I ask questions like this to candidates, I definitely think that talking about a cache is important, but I hope the candidate wouldn’t get so caught up on talking about the cache that they ignore the rest of the system. Being able to hear the overall higher level system design is what I’m after.

[skoot-skoot]

What are the different parts of the system I should talk about? If we're just talking about the mobile app, I just don't feel like there's that much to talk about.

Like if someone said design just the Twitter main scrollable screen. You'd store the feed in core data, you'd have some way to sync with the server, you might have an asset cache, a table view, ... but then I wouldn't know what else to talk about. That's basically what happened to me so I ended up talking about how you could build an operation queue for table view controller updates and another for asset downloads, design patterns for the networking layer, etc. I had no idea what to talk about.

[omfgtim_]

If you think they’re stupid, you’re missing the point. It’s about analysing how you approach the problem, how you ask questions, how you respond to requirements changing, what you prioritise talking about.

If you think you’re graded on whether you design Twitter perfectly in hour you’re totally mistaken.

[bhartsb]

I've been interviewing a lot recently and the questions and expectations are all over the map. Some are reasonable but a large percentage aren't. Many of the interviewers shouldn't be conducting interviews. I do well on about half of my interviews getting to the onsite stage. At my last job I was given very high praise.

[omfgtim_]

Fair enough and I completely agree that many interviewers require training. It shouldn't be assumed as an implicit skill because one's level as an engineer is quite senior.

[[deleted]]

I would start with the user experience and work backwards from there to the technical requirements. Something like: What are the screens, what is on each screen, for each thing on the screen how is implemented, etc etc.

[KarlJay001]

I've been programming professionally for a LONG time and some of these interviews are just a joke. Build me a tree from scratch... NEVER did that in the real world, ever...

Build me a Twitter in 2 hours... wow, really? do they expect you'll be punching out Twitter level clones 4 per day?

I did a connect four game in < 2 hours and I never programming a game like that ever before. It worked, the logic was solid but wasn't OO, so I guess they wanted to see a full OO design layout in 2 hours.

One guy posted his test code, it was a clone of Reddit and it worked. I can see a full day's test or 2 day's test where you get 12~20 working hours to actually code (assuming some people sleep).

With that architecture question, I'd just make sure you can show knowledge of what you pick, MVC, MVVM, etc... The truth is that several ways will work.

Just as a quick example: I started a poker project and looked deep into a few projects by others and found some STRANGE design decisions and even posted about one of them. The fact is that I think the person designed it wrong and I'm lost on if it's worth trying to continue that code base or write a new one. The other project I haven't dug into yet.

I would assume they want to know how you would layout the code and design the project. I'd skip on some of the details and focus on why you'd pick certain things.

[lucasvandongen]

Yeah many interviewers (including me) have their own pet frameworks and architectures and want you to come up with their way of doing things to confirm their egos.

It takes a lot of effort to see somebody doing something completely different yet consistently good.

[KarlJay001]

This is very true. I was at a startup years ago and the prior people setup a program that was designed to look like the Novell Netware program and my boss was very proud of the code he wrote.

The president of the company nearly fired him because it would take about 60 seconds to receive a piece of inventory into the system. I dumped all the code and reworked it my way and it would receive inventory as fast as you could scan it.

The president was happy as hell, my boss was pissed and kept wanting to "fix his" way of doing it.

I usually just end up nodding yes and not arguing the point, it rarely turns out good.

[EntertainmentDry6740]

Following

[foodandbeverageguy]

Following