Hey everyone, I recently went through the interview process for a Software Engineer role at Apple and unfortunately did not move forward. I wanted to share my experience in case it helps future candidates prepare better than I did.

I was caught off guard as I applied for Apple in May of 2025 and received the invite to interview in December of 2025. I hadn't practiced leetcode or interview style questions in over 3 months and I was using a different language at work from the one I usually use for leetcode type questions.

Interview structure (from my experience):

• Initial recruiter contact via email
• Hiring manager conversation, where I was only asked about my experience
• Technical interview focused on fundamentals and problem-solving (CoderPad style)

The interviewers were professional and respectful throughout. This post is not meant to criticize Apple, just to share lessons learned.

What I underestimated:

The hiring manager told me they don't do leetcode style questions, but focus more on system design and architecture. However, the recruiter said my technical round would include a CoderPad link and I would be asked to write code as well as answer questions on error handling and concurrency.

The question I was given wasn't leetcode style, instead it was more about creating a class, store and retrieve instances of this class from "storage", in this case because there was no database, so I had to mimic it using a dictionary.

I started very basic with the methods I needed to store and retrieve the data, and created a very basic class of what I was going to store. The interviewer asked about abstracting it out using inheritance so that I could store different objects that inherited from the same class. Also asked about using async/await for concurrency and error handling vs Exception handling using try/catch mechanisms.

I should have made my code work synchronously and then translate it into asynchronous code so I could show the interviewer the differences and also to guarantee my code ran. Instead, I ended up writing code that showed I understood the fundamentals, but certain areas were incomplete because the interviewer would ask me to deep dive on some topic and I would go that route and lose my train of thought.

Concurrency and threading fundamentals:

• Even if you use async/await daily, be prepared to explain:
• What actually happens under the hood
• Threading vs async execution
• Blocking vs non-blocking calls
• How resource contention is handled

Conceptual clarity mattered more than framework-specific answers.

Clear, structured thinking out loud:

The interviewers cared a lot about how I reasoned, not just the final answer. I should have slowed down, clarified assumptions, and walked through trade-offs more deliberately.

Language-agnostic fundamentals:

Even though I code mainly in C# and TypeScript, the questions were not about syntax. They were about:

• Data structures
• Async/Await
• Error/Exception handling

What I would do differently next time:

• If you use different languages like I do, make sure you know the libraries you can import to do X or Y. CoderPad has auto-complete so this is very useful.
• Re-study core CS fundamentals, especially concurrency and memory concepts.

I have mostly worked in Microsoft's stacks, but recently I switched to TypeScript and I was a bit rusty on C# during my interview. I asked the interviewer too many questions for validation which I believe ended up hurting me. On my day-to-day, I make decisions and usually evaluate what's better for our users, and I feel like I could have done the same, but because I wanted to satisfy the interviewer I did not show clear decision-making skills.

Overall, I learned a lot throughout the process, I gained confidence, and I'm gonna be studying hard in 2026 so I can be prepared when opportunities like this come my way. I hope this is helpful.

How concurrency and threads work