The interviews I had at Apple were surprisingly straightforward compared to those at many other tech companies. I didn’t find the need to memorize anything, in part because I knew the concepts they were questioning me about after putting them in practice during the last decade of work, but also because the questions were quite straightforward, almost akin to general knowledge, for example:
• What is an SSL certificate? Follow up question: What is inside them?
• How would you go about designing a modern NTP to sync a fleet of local-first systems?
• Do you see a security problem with this code? If yes, what is it and how would you fix it?
• Same question as above but with twelve different pieces of code, each one more complicated than the previous one.
• What would you consider Personal Identifying Information (PII) in a food delivery app?
• Explain XSS, SQL, XSRF…
• Hashing vs. Encryption
• How to protect customers from phishing attacks?
• Say you discover a data leak, for example, a backup in a public S3 bucket. Communicate leak or not? If yes, who will you communicate with? How will you communicate?
• Improve event processing logic and performance of the following Java application. Our company revolves around processing events, quickly. Implement the alarm system to monitor incoming events for any delays in processing events by other event processors. (If you find it surprising that Apple uses Java, I share that sentiment. Interestingly, I opted for Go instead of Java to solve the problem during the interview, and the interviewers were pleased to explore a new programming language. I believe this aspect earned me some additional points.)
• Design a table booking system for a restaurant (database, API endpoints, etc.)
• A continuous integration (CI) build step fails (in tests), what do you do?
• What is your ideal Developer→Customer feedback loop? Realistically, what would a bad one look like?
• How would you design macOS Photos.app? (The best part of the interview was a discussion about what to do with content that is out of view and the performance implications of different solutions.)
• Third-party company wants Apple’s data to show ads. What do you do? (The obvious answer is you don’t give the raw data to them, but if you have to, how do you anonymize it?)
• so on and so forth.
There was this interviewer who appeared to be commited to ask me one hundred questions in the span of an hour, and while I didn’t count, I think we got pretty close to a hundred. The questions started at an easy level, for example, what is HTML, and increased in complexity every five minutes or so. Fortunately, I realize what type of interview this was and proceeded to give very one-sentence answers, sometimes just 2-3 words before jumping to the next question. One of the funniest, craziest, most exhausting, but somehow rewarding interviews I have ever had in my whole career. At times I thought the interviewer was some sort of artificial intelligence and the webcam was fake. Later, I met the interviewer in person and we became friends.
Now, having become an insider, I can attest that it’s acceptable to some extent to memorize responses for coding exercises and rehearse answers for behavioral questions. As you rightly point out, many other candidates engage in these practices as well. However, if a candidate’s proficiency is limited to merely regurgitating code without a genuine understanding and, consequently, an ability to articulate the underlying concepts in both the programming and behavioral interviews, that candidate is likely to face failure.
Before landing the job at Apple, I was also in the interview process for a position at Microsoft. The nature of the work appeared to be significantly more fulfilling than what I currently have. The level of technical expertise required during the interviews was remarkable, with the two medium and hard level LeetCode-style questions being the relatively easier segment. Memorizing answers was technically impossible based on the interviewing style. I would have unquestionably accepted that job if it weren’t for the fact that I needed additional income to continue providing for my extended family and covering my mortgage.
In conclusion, if you decide to memorize LeetCode problems, ensure that you also grasp the underlying concepts. Unless all your interviewers are gullible, it will become quite apparent if you're just mechanically writing code without a genuine understanding of the problem or the interview's objectives.
This simply doesn't work without grinding, and grinding happens to be sufficient (whereas understanding is not).
You aren't just supposed to solve a problem (and can't think back to your college years, pull out your copy of CLRS, or whatever). You are supposed to rapidly pattern-match to a specific problem type, and implement. You only have 20-30 minutes (because the rest of the hour gets eaten up by small talk) and this includes testing. Anyone who thinks they can do this with just their knowledge of algorithms without any grinding is in for a shock.
• What is an SSL certificate? Follow up question: What is inside them?
• How would you go about designing a modern NTP to sync a fleet of local-first systems?
• Do you see a security problem with this code? If yes, what is it and how would you fix it?
• Same question as above but with twelve different pieces of code, each one more complicated than the previous one.
• What would you consider Personal Identifying Information (PII) in a food delivery app?
• Explain XSS, SQL, XSRF…
• Hashing vs. Encryption
• How to protect customers from phishing attacks?
• Say you discover a data leak, for example, a backup in a public S3 bucket. Communicate leak or not? If yes, who will you communicate with? How will you communicate?
• Improve event processing logic and performance of the following Java application. Our company revolves around processing events, quickly. Implement the alarm system to monitor incoming events for any delays in processing events by other event processors. (If you find it surprising that Apple uses Java, I share that sentiment. Interestingly, I opted for Go instead of Java to solve the problem during the interview, and the interviewers were pleased to explore a new programming language. I believe this aspect earned me some additional points.)
• Design a table booking system for a restaurant (database, API endpoints, etc.)
• A continuous integration (CI) build step fails (in tests), what do you do?
• What is your ideal Developer→Customer feedback loop? Realistically, what would a bad one look like?
• How would you design macOS Photos.app? (The best part of the interview was a discussion about what to do with content that is out of view and the performance implications of different solutions.)
• Third-party company wants Apple’s data to show ads. What do you do? (The obvious answer is you don’t give the raw data to them, but if you have to, how do you anonymize it?)
• so on and so forth.
There was this interviewer who appeared to be commited to ask me one hundred questions in the span of an hour, and while I didn’t count, I think we got pretty close to a hundred. The questions started at an easy level, for example, what is HTML, and increased in complexity every five minutes or so. Fortunately, I realize what type of interview this was and proceeded to give very one-sentence answers, sometimes just 2-3 words before jumping to the next question. One of the funniest, craziest, most exhausting, but somehow rewarding interviews I have ever had in my whole career. At times I thought the interviewer was some sort of artificial intelligence and the webcam was fake. Later, I met the interviewer in person and we became friends.
Now, having become an insider, I can attest that it’s acceptable to some extent to memorize responses for coding exercises and rehearse answers for behavioral questions. As you rightly point out, many other candidates engage in these practices as well. However, if a candidate’s proficiency is limited to merely regurgitating code without a genuine understanding and, consequently, an ability to articulate the underlying concepts in both the programming and behavioral interviews, that candidate is likely to face failure.
Before landing the job at Apple, I was also in the interview process for a position at Microsoft. The nature of the work appeared to be significantly more fulfilling than what I currently have. The level of technical expertise required during the interviews was remarkable, with the two medium and hard level LeetCode-style questions being the relatively easier segment. Memorizing answers was technically impossible based on the interviewing style. I would have unquestionably accepted that job if it weren’t for the fact that I needed additional income to continue providing for my extended family and covering my mortgage.
In conclusion, if you decide to memorize LeetCode problems, ensure that you also grasp the underlying concepts. Unless all your interviewers are gullible, it will become quite apparent if you're just mechanically writing code without a genuine understanding of the problem or the interview's objectives.