1. Do not look up company values / leadership principles.
2. Do not prepare, instead try to answer all questions on the fly. Or memorize responses for questions and repeat them line by line during an interview.
3. Don’t be organized, never use STAR, instead just ramble for 10 mins straight for every question.
4. Lie about your contribution / impact.
5. Don’t ask any questions to the interviewer. Or ask questions that do not really tell you anything about your future team / org e.g. what is the pay? or how is the free food?

I wrote about how I prepare for behavioral interviews here.

But I think it is critical to understand what the behavioral interviews are meant to measure before you start preparing for individual questions.

Quite simply a behavioral interview is meant to look for passion.

1. Passion for software engineering,
2. Passion for the job/company you are applying for
3. Passion for cultivating great team culture.

If your answer to any question during the interview does not highlight passion for one of the three categories I mentioned above – you are wasting time.

The interviewer is constantly looking for signals that prove: you love to code, you care about the product they are building and that you care about the people you work with.

If your answer is not giving this signal, why are you talking?

This may seem harsh, but having faced and taken behavioral interviews over the years, I know this to be the truth.

Also, never lie. This seems obvious to me, but apparently people think you could lie in a behavioral interview and get by – people who take these interviews are extremely good at judging responses (both your words and your body language) and they know exactly the follow ups to ask to determine if you are being honest or not. So just don’t – lying guarantees hard rejection even if you had done extremely well on your DSA rounds.

In one word? Write.

1. Write your response in an excel document as if you were answering the question in an interview.
2. Re-read your response after a couple of days – you’ll likely notice how terrible it sounds 🙂
3. Go back to step one and revise. This is how you improve.

Over time, you’ll have a large excel sheet with two columns: Question and Response. This document will be incredibly helpful when you re-enter the interview process a couple of years down the line since all your history will be captured in one place.

I take it a step further and record and upload (private) YouTube videos of me answering these questions – this has helped me further fine tune the stories.

After a real interview, based how I feel about the responses I gave and any follow up questions that were asked; I go back and edit my responses to specific questions – after having done this for a couple of years, I now feel a lot relaxed knowing that I could re-prep any time I need to go looking for a job.

As for the questions here is the list I prep with: https://docs.google.com/spreadsheets/d/1TrNp34Denu0cpb7W407JO1yrSB6svR7LhWyd-iDfuoA/edit?usp=sharing

The list is editable – in case anyone reading wants to add to the questions I have.

So I had promised one article everyday – but failed on Day 5.

Now I have a choice: either give up and fall completely off the progress I have made so far.

Or just accept the mistake and keep going.

I choose the later.

Will write two articles today. (not counting this one lol)

A good resume is ‘skimmable’ and can be read in under 10 seconds – that’s the time a recruiter is going to spend on your resume before moving on to the next one.

• Your best results/accomplishments/impact has to be at the top of the resume.
• Keep it a one pager – yes you can do it. Get rid of non-impactful stuff and don’t waste space (i.e. objective section).
• Include links to the AppStore if the product/app you worked was released. Include ratings of the AppStore as well.
• Focus on impact, rather than the ‘how’ of things.
• Skip the ‘objective’ section – no one reads it.
  • (Unless you are changing your domain and want to use that section as a sort of cover letter explaining why you would be a good fit even though your resume does not have the experience required for the job)
• Move education to the bottom of the resume – unless you recently graduated.
• Either include a skills section or try to inject (ats) keywords into your descriptions so that your resume stands a better chance of not being rejected by automated systems.

This is the format I use – it is simple, does not waste space, is easy to scan and yes it includes a interests section – during an interview this has helped me at least a couple of times break the ice and have interesting conversations – I think its ok to show a little bit of your personality 🙂

I found this reddit thread super helpful as well – it goes a bit more detail into the template and why it works.

Sometime back I was invited for a party and the host had used an app to track invites – they had used https://rsvpify.com/ and after a quick look at the website, I realized that product is quite expensive – does a simple app that manages invites for you need to be that expensive?

Checked out a couple of other ‘invite’ management apps on the AppStore – most had unintuitive UI, were bloated with ads and seemed complex to use.

And since I hadn’t built anything in quite a while, decided to give it a try. And to keep myself accountable, I am going to build this in public with weekly updates till first launch – which would be on 2nd September 2024.

QuickRSVP would let the users:

• quickly create invites for a party
• The host can share the link to the party externally through social media apps, whatsapp etc
• See the status of the invites and nag people for a response.
• Invitees would be able to either accept or reject the invite.
  

The product would have a iOS app and a standalone web interface as well. For tech stack, the iOS app would SwiftUI to build the UI + SwiftData to persist locally -> this might feel like a overkill and it is. I am using this side project to ramp up my SwiftUI skillset – even though the product does not really need a iOS app.

The backend would be powered AWS lambda functions. For the web interface, I am planning to use Flutter but I haven’t made up my mind yet – again the stack here is not really decided by what the product needs, but instead what I want to learn.

Right now, I have most of the end-points already completed in AWS and I am working on the iOS app – struggling with SwiftUI quite a bit to be honest – but I think I should be able to wrap up most of the functionality by this the end of this week.

Getting the UI to look nice is whole another ball game though – I am not sure how to go about this. I have zero artistic abilities 🙂

Do people hire designers even for their side projects? Need to figure this out.

During the second week I will focus on the web app – need to ramp up on Flutter before that.

The V0 launch in September wont’ be pretty – but it should have all of the functionality that a RSVP app needs to have. If everthing goes well, I will push an update later that improves on the UI design.

For MVP, I want to focus on core functionality + deployment and being able to ship on time.

Here are some quick tips that have served me well in past system design interviews.

The interview would start with an open ended question – by the end of the interview, you should have covered:

1. The exact feature-set at least for the minimum viable product/feature.
2. The API design – what are the required APIs if any and their specifics (inputs, outputs etc)
3. The high level design of the app to cover the agreed upon feature set.
4. UI Architectural choice – what works best for this particular problem? MVC, MVVM or something else?
5. Low level design or a walkthrough of the most critical user flow of the app – this should include how the data flows through the app from the network to persistence (if the app persists data locally) to the UI.
6. Details on how would you build the UI – so that it is performant and easy to maintain/modify.
7. Details on how you would unit/scenario test the app (so that you can catch regressions before they ship into production) and specifics on what the oncall team should track to support the product.
8. Pointers on what could be improved/changed in the design when the scale/team size increases.
   

Chances are you might not cover all of it, but I think 1 to 5 are non-negotiable if you are applying for senior/staff roles.

Some general tips:

1. Be decisive. This means -> make architectural choices/design decisions for the product being designed – do not rely on the interviewer to make those decision.
2. Call out assumptions. As you define the system, call out any assumptions that you have in your mind. Do not assume the interviewer understands your reasoning.
3. Be upfront about the reasoning behind your choices. As you make decisions (tip #1), explain why you made that choice and what other options were considered. Don’t wait for the interviewer to ask ‘why you chose this path instead of that’?
4. Lead the interview. Act like the senior engineer you are interviewing for:
   • List out all the topics you want to cover right at the beginning.
   • Time yourself and pace the interview so that all topics are covered
5. Be flexible with your approach – be aware of the direction the interviewer is nudging you in. The interviewer may be throwing a hint when they feel you are going down the wrong path or if the design has a specific issue that you have’t caught yet. Remember it isn’t purely technical interview – the interviewer is also trying to figure out if they would want to work with you in the future – everyone loves to work with a team player.

In a future post, I will go through a concrete example – a real question – to explain these guidelines in a bit more detail.

After having gone through the hiring process for big tech twice, I feel, now I have a good handle on how to prepare for these types of interviews.

Not claiming to be an expert, but wanted to write down what has worked for me in the past and where I need to improve my own skill set.

Behavioral interviews: I struggled with these – mostly because like most engineers I focused on the technical prep and tried to ‘wing’ the behavioral interviews. This obviously does not work. Behavioral interviews in addition to finding cultural fit are also used to validate your communication and organizational skills. And so, you must be able to answer specific questions with clarity – your answer should not be too long, at the same time should not skip over important specifics of the story. So as you prepare for this type of interviews do use the STAR (situation, task, action result) method to construct your responses (I almost always add learnings to the story as well – so it becomes STARL for me). My prep strategy? (1) Write down responses for popular questions. (2) Record yourself (private YouTube videos) answering these questions – review your videos after a week or so after recording and then fine tune your answers. I will post a separate article with questions that I practice with.

LeetCode style coding interviews: Practice! a lot of it. This is the only way I think anyone can improve in these interviews. I stick to questions from the NeetCode 150 list when practicing since I feel that list covers all possible topics you can get in an interview. Before the interview I do try to look up the top questions asked by the company on LeetCode (you need premium for this). One tip – which I try to remind myself during interviews as well – it is not always bad if you get stuck and ask for a hint – this is perfectly fine. The interviewer is looking for signals during the interview – signals that you can think logically, that you can communicate technical details well, that you document assumptions and edge cases well. Being able to work with hints is also an important skill when working in a team settings – that shows that you are willing to accept feedback and incorporate it. So ask for help if you feel stuck.

System design interviews: I think the most important advice for senior engineers is to be decisive. System design interviews are open ended by design – so when you have different architectural choices in front of you – don’t ask the interviewer which one they prefer – instead chose one that you feel is the best given current constraints and then justify your decision. Present the options but chose one – never let the interviewer make that decision. A concrete example of this – if you trying to decide between using local persitence or not using it for an app – make that choice yourself based on what type of product you are using and how that product might grow or get used in the future. Make a choice and then explain why you made that decision – most likely the interviewer not going to argue with you (even if they disagree with your choice) – but they would appreciate the fact that you had an opinion and that your decision was backed by strong arguments.

So I wrote a piece yesterday -> https://indrajitshanbhag.com/2024/08/02/types-of-ios-dev-interviews/

And I realize it was not best writing – there are lot of grammatical errors in it, it feels like the article is not well structured as well.

But unless I write more, my writing is not going to improve anyway.

So with that, I have decided I am going to write an article here every day for the next 30 days.

Don’t think it will be easy – but I believe it will be worth it.

At the end of 30 days, I hope:

• I will be more at ease with putting myself out there. I hope I have gained enough confidence to write on other more public platform – at least LinkedIn to start off with.
• My writing quality has improved.
• I am less scared about staring at a blank page and have a excel full of writing ideas.

Wanted to write this quick note, in preparation for a video that I am going to record for my YouTube channel.

Had to change jobs in the beginning of this year and that experience reminded me (again!) that interviewing is a completely different skillset – and without practice you could get rusty even though your day job is still working as an iOS developer.

Recruiter call or intro call -> this is going to your first interaction with the company. This call normally is not technical. During this conversation the recruiter wants to gather some quick info on your background to confirm the fit (if you get this call, most likely the recruiter has already seen your resume and decided that you are a good fit, but they want to be sure and hence the call). This call is also your opportunity to ask questions about the company and the team that is hiring. This is also when you should ask about the interview process. There is really no reason to be hesitant in asking for details or help on interview prep – the recruiter is invested in your success and want to help you. A lot of companies have interview guides – you could ask for that. You could also ask about any tips on doing well in interviews – questions about where candidates generally do not do well.

At the end of this call, if everything goes well, the recruiter should share details about the next steps or get the ball rolling in scheduling the first technical interview.

Telephonic screen -> The objective here is to confirm you meet the minimum bar required to pass the full panel interview. It is expensive (both time and $$$) to interview candidates – so companies want to avoid spending too much time on candidates who are unlikely to perform well in interviews. As a result, this interview focuses on making sure you can code up an easy or medium difficulty question in 20-35 minutes. They are looking to evaluate your logical reasoning abilities and communication skills. They want to see you struggle on a technical problem – see how you work with another engineer when you can’t figure out a way on your own. Can you work with hints? Are you explaining your reasoning? Are you making sure the interviewer is able to follow your thought process? Are you considering time/space complexity tradeoffs?

Some companies might prefer to have multiple screens before they ask you for a onsite/full-panel interview. Others just do one.

For iOS developers, this interview might also cover some fundamental questions. – this could be anything from basics of Swift (class vs struct) to building the UI (SwiftUI or UIKit basics) to application life cycle. Ask your interviewer how much details are expected when you answer – most likely they prefer breadth over depth at this point.

By the end of this round of interview process, the company has evaluated if you meet the minimum bar to do well as an iOS dev. Also you as a candidate had an opportunity to talk with at least one engineering who works at the company – make sure you have questions about culture, release process or anything else that matters to you about the company/team – this is a great opportunity to get a better understanding of the team you might work with in the future.

On-side/ full-panel interview -> This the big day or multiple days as some companies do offer to split the interviews over multiple days. But this phase involves 5/6 interviews – each focusing on different skills sets.

Coding interview(s) -> Yep there could be more leetcode style coding interviews – these might be slightly harder than the telephonic screens or the same difficulty, but rules are the same – make sure you think out loud, ask for help when stuck and talk about tradeoffs – remember companies (at least the good ones) don’t want to hire code monkeys – they want to hire engineers who can think logically and work well within a team.

Behavioral interview(s) -> These interviews focus exclusively on your past achievements and struggles. Here the team wants to understand if you would be a good cultural fit. A good way to prep would be to go through the companies cultural memo and try to gather/prep stories from your background that demonstrate the qualities the company lists in their memo. Don’t be fooled – these interviews take a lot of effort to do well, you also need to practice answering follow up questions on your stories. The interiewer would most likely be a senior eng manager or a director – so know that they have taken a lot of behavioural interviews and are good at gauging your background.

System design interview(s) -> For iOS developer roles, this interview is a bit different than regular system design rounds. Here the team wants to understand how you think at a higher level given a not so well defined problem statement. Remember that the focus is as much on communication as on technical skills. The questions in this interview never have a fixed answer – but you must be able to weight in different ways to solve a problem and explain why you took a specific approach. A good way to practive is to try to design your favorite iOS apps from ground up -> this involves designing the required APIs, how would you model your data, how would you structure the UI components and the architectural choice. Again in this interview breadth is more important than depth – unless the interviewer asks you to go into detail about a specific subsystem, focus on getting at a complete app/system.

Hands on iOS coding interview(s) -> These interviews are fun. They could take multiple forms – the team might ask you to build a small app (most likely involving a feed of items) or debug an existing app that has bugs in it. The focus is on validating your hands on chops – they want to see you code using Xcode, see your comfort in getting your hands dirty. This interview would most likely involve some sort of UI development and making network calls, more than likely you would have to use a UICollectionView to show a list of items (how do you manager cell reuse?, how to you make sure network calls are not being made for things that are not on screen anymore, are you reusing previously downloaded network assets?, how would you unit test your code?).