This is about my loop for a Staff Software Engineer opening at Intuit, based in Mountain View, CA. I sent out a few online applications, and a recruiter then contacted me.
Background
I'm based in the US and did my master's here, after arriving in 2013. Meta let me go in September 2025.
Before that I put in 3.5 years at AWS, where I mostly did backend work for AWS services.
After that came 6 years at Meta. On my first team there, the work was a mix of research and engineering: someone would have an idea, we built it up to an MVP, and then it moved over to a product team. It was all AI-driven products, but not LLMs. My next team was full stack, and most of what I did was add code to the huge Hack/PHP monolith.
Preparation
My honest take is that in this job market, luck matters more than hard work.
I prepared for roughly two months and did nothing else during that time. The first stretch was 6-7 hours daily, which I cut to 2-3 hours once interviews were happening. I only applied to Senior and Staff positions.
Coding: I started with easy LeetCode problems, a few of them, and then moved on to mostly mediums plus some hand-picked hards, around 50-75 of those. Cover many topics instead of grinding a huge number of problems. Graphs got special attention from me: DFS, BFS, topological sort, bipartite graphs, Dijkstra, spanning trees and even Eulerian circuits. DFS and BFS should be second nature, to the level where you write the traversal correctly the first time. As for the remaining data structures, if you have done interviews before, you mainly need to refresh your memory. Do not count on it coming back naturally during the interview, because I blanked on some very easy problems under pressure. Go through the LeetCode top 75 and top 100 lists.
Coding rounds expect you to execute your solution on HackerRank or CoderPad against a set of ready-made tests, and failing some of them will probably get you a No Hire or Weak Hire. Get used to creating your own test cases too, which I had never bothered with. The interviewers want every path covered, malformed input included. If you are at the Senior or Staff level, take a second to think about spreading the solution over several machines, and about what you do when the data can't fit in memory. Pretty much every coding interview I had included a follow-up along those lines.
System design: I studied from videos, which gave me a starting point for looking into specifics like Paxos, how databases work inside, and Kafka. Think about what extra depth Senior+ roles demand beyond the videos. I learn better by listening than by reading, so I played them on my walks as well.
Most system design questions follow a pattern. Train yourself to spot which pattern you are looking at, and have a brief script ready to explain it. One example is bringing in Elasticsearch for text search, then describing how it works and what makes those searches quick. Another is using change data capture rather than writing to two databases in two commits. I assembled a playlist of the standard problems and kept playing it, and I kept practicing the scripts I planned to use in the interview. Some interviewers stay stone-faced or come across as cold, which can throw you off, so practice enough that you stay confident regardless.
Low level design: only relevant at Senior+. Practice sketching class schemas and interfaces. Concurrency and multithreading are very important, so drill them. Be ready to code a BlockingQueue and the producer-consumer pattern, and to show a few ways of making code thread-safe and what each one costs. A few interviews are devoted entirely to concurrency, and you write actual code there, not pseudocode.
Behavioral: this is critical at Senior and Staff+. Take every question you come across online, put them all in a single document, and write a well-thought-out story for each. I spent serious time on this. STAR is the format to follow. Turn each story into a script and reread them from time to time so they are easy to recall.
At the Senior+ level my background has leaned toward research and prototypes. I had ChatGPT help me word my answers so they came across at a Staff level, and that was a big help. It was the part I was most anxious about, since I had no strong answer to "the most technically challenging thing you built" or "the hardest design decision you made". The script ChatGPT helped me write steered the discussion toward what I did well on that project. Around nine in ten interviewers accepted that, but a few pressed with something like "do you have another example from production?" My answer there was a plain no, since I wasn't going to make up an AWS project and pitch it as Staff work. Decide for yourself how to handle this. Also keep strong examples handy for conflict resolution and for the most critical feedback you have received.
Interview Experience
Recruiter Screen (20-30 mins)
It covered the usual recruiter ground: why I am leaving, why Intuit, what I did before, and my immigration status. If you were laid off, my suggestion is to bring it up here so there are no surprises later. You needn't announce it unless asked, but recruiters usually check whether you still work at your most recent employer. If your last day is behind you, saying you are no longer with them works. In my experience most recruiters didn't care, and just a few wondered why I had left. With the market the way it is, mentioning a layoff is fine. Again, use your own judgement.
Phone Screen (75 mins)
The start was one or two behavioral questions, which every senior and staff role at any company includes. After that came a single standard coding problem at LeetCode medium level. The exact prompt escapes me, but it wasn't hard, and it came with follow-up questions about scaling the system and the problems that could arise. The final 20-25 minutes were questions about AI, something particular to Intuit. Since I have built AI applications, a lot of the questions went there. We also talked about AI-native apps versus ones that aren't, what an LLM is, how I use AI in everyday life, and the risks of AI. Basically they wanted to measure how comfortable you are with AI.
Onsite
Craft Demo (75 mins)
I opened with a 10-minute talk of 3-5 slides about my background, my hobbies and the project I am proudest of.
Next, there is a repository you receive ahead of time to set up and experiment with before the interview. It is a small Spring Boot application with a handful of endpoints that read data from a datastore, and a Python version exists too. In the interview you get some user stories and extend the app with new APIs to cover them. What they look at is how you tackle the problems, which things you choose to test and how you structure your classes. Running and verifying your work or adding unit tests matters less to them, but it does earn you additional credit. My basic implementation was done and I checked it with Postman, though I never got around to tests. I was told ChatGPT would be acceptable for that, because the point was deciding which parts deserve tests and how to approach unit testing, with syntax being irrelevant.
System Design (60 mins)
Here the topic was scalability and the high-level design of the same problem as before. We went deep on schema design and weighed the advantages and drawbacks of each proposal. A lot of follow-ups asked me to extend the original service with extra features and say how the database would change, how queries would perform, how certain databases could help make searching faster, and how I would add indexes. The conversation was thorough.
AI Accessor interview (30 mins)
This one tacked an AI feature onto the service from the first round. That service called an open source LLM API, and my job was to write an API for a recommendation use case. We discussed RAG, LLM hallucination and prompt engineering. As before, the point wasn't to completely finish the problem with test cases, but to show how you reason your way to a good prompt and apply it to the story.
Hiring Manager (30 mins)
This was a typical hiring manager conversation, and the person on the other side was the VP. It was behavioral questions, what energizes me at work, my superpowers, and similar topics.
Two days later the recruiter got back to me to say the team wanted to extend an offer.
Thinking back, I rate these interviews very highly, because they focused on what matters, with more weight on design and architecture for Senior and Staff candidates and less on heavy coding. To be honest, in two of those rounds I never completed the coding end to end with unit tests, and the feedback came back positive anyway. Talking with the interviewers was a pleasure.
Discussion
Loading comments…