Hello LeetCode Community,
Before sharing my interview experience with Apple, I would like to thank this community who helped me a lot to navigate this process.
General Stats
- YOE: 10+ in Software Engineering, ~8 with Apple platforms.
- Exercises done with Leetcode: Around 90 + other exercises from some books I own.
Prep and Routine
- I was dedicating one hour daily to Leetcode, from Monday - Friday.
- My general approach was to go thru as many LC exercises as I could on that daily hour.
- I created a Swift Playground to do the coding itself.
- Prioritize quality over quantity (i.e.: don't move ahead until I completely understand a particular solution).
- After a while (when started to feel like I was doing better) I started using the Pomodoro technique to attempt to solve a problem within 25 minutes. If I couldn't then I would look at the suggested solution, and attempt the exercise later.
- I got an actual whiteboard about 3 weeks into my routine/prep when doing the exercises.
- I had over 3 Zoom/Google Meet sessions with several friends/acquaintances who helped me with the behavioral and systems design mock interviews.
- I never got to the systems design interview - It is actually nice that Apple is splitting this process in between 2 days.
- A friend suggested https://excalidraw.com/ for the system design interview. I was impressed by it & ready to use it!
Apple Rounds Details
Phone Screen
The objective of the phone screen was to figure out where would I be a good fit for the group I was applying to. Interviewer was very polite and friendly. After some questions regarding my CV, it made a lot more sense to go "high-level". He also asked me about related low-level Apple APIs, but on this case I had minimal experience or just playing around with WWDC projects or tutorials at raywenderlich.com
The interviewer also asked me about some tech stack experience that could also be considered "low level", which is restricted to an undergraduate course more than 10 years ago.
The interviewer finished my screen with a iOS applicable problem: Given a UIView hierarchy and a tap event on the screen, how does UIKit knows which UIView instance should respond I was going halfway thru the problem when it dawned on me that this was a tree traversal where I know the root node (UIWindow) and a random node that (originally) registered the tap. Fortunately my "naive" approach was fairly close to a tree traversal algorithm, so I was able to "save face".
Overall a good experience.
Result
I was invited to the next phase: the interview round. Which were split in two days.
Day 1 - Round 1: Behavioral with Team Manager
- Common questions like handle conflicts with manager and peers.
- How do you handle negative feedback and/or giving feedback.
- Most proud project, least favorite project, etc.
I used the S.T.A.R. interview format here, plus I had some written down examples to minimize "umm, emm", etc. Felt like I did well there.
Day 1 - Round 2: Algo/DS Problem 1
- One interviewer, a software engineer.
- Problem was done thru Coderpad.io, they had a really nice setup with XCTests and everything!
- Interviewer asked me about the last project I worked on, give him an example of something that didn't go my way and how did I handle it. Used S.T.A.R interview format again and aced it IMHO.
- The problem I was given was:
Implement a MaxStack.I got the description of the max stack and a Swift protocol of the implementation I had to do. Thankfully I had done the LC minstack exercise recently so I had a good approach to getting quickly to aO(1)solution for getting the max. - Felt like it went well here.
Day 1 - Round 3: Algo/DS Problem 2
- Two interviewers: One asking the questions, another one quiet in the background (taking notes?).
- Interviewer started by asking me a lot of questions about iOS: memory management, concurrency, application lifecycle, Swift programming language, etc. At the beginning they were simple questions, but they started going deeper to gauge my knowledge. Eventually I found myself dealing with questions for which I didn't have an answer. I always said I am not sure but here's my "educated guess". Since this happened consistently, it eventually put me in a bad headspace.
- The problem I was given was:
Given two [Int] arrays how would you implement the union of both inputs.So here is where I unraveled: the previous iOS questions had put me in a bad headspace from which I never recovered. I tried my best to come up with a brute force solution to it (which I did) and then take it from there but the damage was done. - I screwed up badly here.
End of Day
At the end of the day I got email from recruiter saying that they decided to move on with another candidate. Thanking me for my time and that I will be considered for future opportunities. No further feedback was presented to me and I felt like it was pretty obvious what went wrong so I didn't push for any.
Postmortem
General
- I learned a lot of things in my journey and finally able to crack an interview at another company, getting an offer.
- I took a gamble with Apple and it didn't pay off. After Apple, I spent some time reviewing these resources which lead to better performance in my next interviews, building up to the offer I recently accepted:
- Try to enjoy the learning process, and take breaks. Back in school I loved programming (the part that evolved from playing around with my parent's 386 and 486 machines) but I was not very good at the problem solving - math application part of it. You don’t want to burn yourself out in the process.
- Try to get to 8 hours of sleep and eat well. Your mind will thank you for it.
Whiteboarding/Algorithms/DS
- Coding the solution is as important as sharing your thought process. Meaning there's no need to explain everything or every corner case. In my case, I noticed edge cases during a dry run.
- Find a support group or person to prepare with. In my case, having someone to do this for the behavioral interview upped my game exponentially. I wish I had done the same for Algorithms/DS. Perhaps this is a space ready for "disruption" - i.e.: a meetup.com group for people to practice ?
- I will second the recommendation on these forums to not make leetcode solving a target. For me it was more effective to cover topics until I got comfortable with them. Some topics are definitely more important than others, so it would make sense to do more questions of them over others. But knowledge of most of the topics makes you ready for the surprise.
- Only start doing time bound questions when you are already comfortable with the topic.
Behavioral
- I would heavily recommend going thru the exercise of doing a S.T.A.R. approach to the typical behavioral questions, and think of examples you have in your CV. Write them down and let the interviewer know that you have notes.
- No examples in your CV ? For example, if the interviewer says "Tell me about a co-worker you hated", you may think that you don't have an answer, e.g.: "Everyone is very nice to me... We are great co-workers". Even if that is true, try to stretch reality a bit. Take a story about a non-issue and spin it to your advantage. This is OK in my opinion as long as the solution you present actually reflects on what you would do.
- If you have the relationship (i.e.: didn't burn any bridges), reach out to past managers or peers and ask them about examples. You would be surprised at how helpfult people can be, including pointing out cases you don't consider relevant or straight don't remember!
Happy to answer more questions as they come along!