Being engineers, we all have dream companies we want to work for and make our mark by impacting the lives of millions. Apple is the dream company I always wanted to work for. And here I am…I made it! Here’s my story — It all began back in 2009 when I bought my first iPhone. I just fell in love with the experience and ease of the product which just works. That’s when I decided I will learn iPhone application development and make these beautiful applications. Hence I bought a Mac Book Pro during my master’s program which was difficult for me considering the state I was in with my financial situation. But I am glad I did that, fast forward a decade I am a successful iOS developer who will be now working at Apple! Here is How I Prepared In my opinion, when it comes to expectations from the mobile developers, companies test you on the following things: 1. Data Structure and Algorithms This section focuses on your capability to think, compare (weigh pros and cons), and solve a logical problem with a data structure. Every data structure offers different advantages and disadvantages when it comes to time and space complexity. Data structures range from simple arrays and dictionaries (map) to complex ones like trees and graphs. I prepared for a month and a half before my first screening interview and solved 5–10 questions every day on Leetcode.com. My advice: when you practice coding questions at the beginning of your preparation, attempt questions of the same data structure so that you completely understand a certain data structure and its nuances. Later on, evolve the practice to include a jumbled set of questions that span across multiple different data structures. 2. Mobile App System Design This section is focused on your ability as an engineer to look/understand the design of an application from a holistic level rather than the nitty-gritty of individual pieces. So you start from a high-level view and then you deep dive into individual components. When browsing on the internet I couldn’t find system design tutorials for mobile developers. So I watched different kinds of system design interviews tutorials and made my own custom script that made sense to me as a mobile developer. So here is the rundown of different sections I used to tackle the system design questions. I found that it worked for most questions. I will cover the detail of these sections with an example in another blog I will link here. Stay tuned! Here is a quick peek into an example of design an app that shows interesting positions around you. Functional Requirements — Define the use case and some features Non-Functional Requirements — Define performance, experience, and scale requirements. Assumptions — Define the boundary of the problem, any scale constraints, features, etc. Client-Server Communication — Define the connection options such as HTTP request, polling, server-side events. API Design — Define the endpoints for the feature that you are building. Data Models — Define data model fields of your objects. App Flow (Use cases flow) — Define and walk through the user flow for the feature you are designing. Performance & Tooling — Define how you will gather data and metrics to see how the app is performing — memory utilization, CPU utilization. ADA — Make sure you define the accessibility feature and how the app will be made accessible. Internationalization — How would you approach as the app grows internationally. Security — Define how you would secure the app. 3. Domain Knowledge and Language Proficiency This is where companies try to gauge your proficiency and experience in making mobile apps with the platform language. (Swift, Objective C for iOS and Java, Kotlin for Android). In my experience companies usually ask you to fetch some data from an endpoint and display it. The problem itself is very simple in a way that someone who barely started doing mobile development can do it too. What differentiates one developer from another is how you accomplish it. Things like were your code readable, modular, scalable, follows SOLID principles, etc. This helps to determine how experienced a developer is. 4. Behavioral We tend to pay less attention to this section in our preparation. In my experience being on both sides of the table, this section can make or break the deal. The majority of the time we work in teams. The ease with which you can work with other team members is very crucial for companies. So they are looking for these signs when they ask you to share a story for different situations you might have been in. My advice: Sit down and noodle a bit on your past experience, note some instances of things you are proud of, worked with a difficult person, navigated a tough stakeholder, helped a team member be successful. Prepare these stories to tell based on your experience and how you navigated the situation and the results you achieved. Having these prepared in your back pocket helps so you don’t have to scramble during the interview. Here is a that can help you in behavioral interview prep. link What Really Worked Here are some of the things that worked for me. — Once you make a plan, stick to it. You won’t see the impact of your preparation in a single day or a week, it will be a compound effect that you will experience later. Divide your preparation time into sections I mentioned above, you will get cumulatively better. 1. Be Consistent — From my personal experience I can say, there will be days you will feel like it is not working, but trust me, you just have to stick around a little longer. Things will work out, hang in there and believe in yourself that you can do it. 2. Believe in Yourself — Try to have mock interviews with your friends or someone you know who can help poke some holes in your prep. These mock session really helps a lot. It makes taking interviews second nature. 3. Mock Interviews Conclusion Getting your dream job is a game that is played with patience and consistency. Keep working hard and one day, things will click and it will all work out. Also know that if it does not work out, it’s for the best! The prep you did will work its magic in other ways.
