Find an interview coach to get job offers at Meta, Google, McKinsey, etc.

The most common agentic patterns discussed in interviews are: 1. Router – Classifies requests and selects the appropriate model, tool, agent or workflow. 2. ReAct / Tool-use loop – The model selects a tool, observes the result and decides the next action. 3. Planner–Executor – A planner decomposes the objective; an executor performs and verifies each step. 4. Sequential workflow – Specialized stages run in a controlled order, such as retrieve → analyze → generate → validate. 5. Orchestrator–Workers – A coordinator delegates independent tasks to specialized or parallel workers and aggregates their results. 6. Reflection / Critic – A reviewer evaluates an output and requests bounded improvements. 7. Agentic RAG – The system determines whether retrieval is necessary, rewrites queries, searches iteratively and verifies supporting evidence. 8. Memory-augmented agent – Uses short-term state and selectively retrieved long-term memory. 9. Human-in-the-loop – Requires approval for sensitive or irreversible actions such as payments, deployments or external communication. 10. Event-driven agent – Suspends and resumes long-running work when timers, messages or external events arrive. 11. Multi-agent collaboration or debate – Multiple agents propose, challenge or validate solutions before synthesis. In a strong interview answer, do not present autonomy as the objective. Explain that production systems normally use a deterministic workflow engine, with LLM reasoning restricted to controlled steps. Add typed tools, permissions, iteration and cost limits, idempotency, retries, observability, evaluation and human approval. For a deeper architectural treatment, I recommend my white paper on SSRN: read the paper. It provides useful preparation for discussing how agentic patterns should be structured and controlled in production systems.

Sure, here we go! Senior Engineering Manager, commonly L7 Typical loop: • System design, sometimes two rounds • Coding or code review • People management • Technical leadership and execution • Behavioral/“Googliness” Expected evidence: • Leading multiple teams or a critical platform • Strong architectural judgment • Hiring, coaching, and performance management • Resolving technical disagreements • Cross-team influence • Delivering through ambiguity • Quantified technical and business results They must remain technically credible. “My engineers handle the technical details” is weak. Director, commonly L8 The loop usually emphasizes: • Technical and product strategy • Organizational design • Managing managers • Portfolio and headcount allocation • Executive and cross-functional influence • Execution across several teams • Culture, succession and organizational health Directors may still receive technical architecture interviews, but they must connect the design to team structure, investment decisions, migration strategy, and a multi-year roadmap. Typical Director questions: • Describe an organization you redesigned. • How did you handle an underperforming manager? • Tell me about a major investment you stopped. • How did you secure executive alignment and resources? • How do you prioritize when every program is critical? • Describe a technical strategy spanning several organizations. Common rejection reasons: • Senior EM behaves like a strong IC or first-line manager. • Director behaves like an experienced Senior EM. • Weak people-management evidence. • No experience managing managers. • Stories lack measurable scope and personal contribution. • Strong strategy but insufficient technical depth—or the reverse. Current Google EM postings emphasize technical leadership, architecture, product strategy, and people management. A current Director posting asks for experience managing managers, executive influence, and leadership of a large multi-team organization.

L4 engineers build out solutions for well-defined problems with code output focus. That's why L4 candidates are not assessed on system designs. For growth opportunities, L4 engineers already working at Google could slowly take on system design opportunities to prepare for an L5 promotion. The roles and expectations of engineers at each level are clearly defined in writing at Google.

1) “Tell me about a time you used data or experimentation to drive a decision in a high-ambiguity environment.” • Skills assessed: Analytical thinking, comfort with ambiguity, ability to design experiments, data-driven decision-making. • What to highlight: How you framed the problem, the data or signals you gathered, the hypotheses you tested, and the tradeoffs you considered. End with the outcome and what you learned—even if the result wasn’t perfect. 2) “How would you explain a complex AI system to a non-technical stakeholder and get buy-in?” • Skills assessed: Communication, influence without authority, user empathy, ability to simplify complexity. • What to highlight: How you broke down technical concepts into simple analogies, how you tailored the message to the stakeholder’s goals, and how you balanced transparency about risks/limitations with a clear articulation of value. 3) “Imagine the model you launched is underperforming—how do you triage and prioritize next steps?” • Skills assessed: Problem-solving, prioritization, cross-functional collaboration, resilience. • What to highlight: Your structured approach—diagnosis (data quality, model accuracy, user adoption), prioritization of fixes, how you’d partner with engineering/data science, and how you’d communicate updates to stakeholders. Emphasize learning fast and iterating.

E5s are Meta's workhorses. Therefore, they have to be very productive and own the subsystem technical direction. They need to lead E4s and E3s along with collaborating with E6s. They need to be driven to action, work on their features and support other engineers when SEVs (site events) occur. They're also expected to participate in org wide initiatives and help streamline the developer experience and operational excellence initiatives

DoorDash essentially provides candidates with a lot of information about its product sense and product prioritization rounds, so I think they're really looking for a sharp, structured answer that covers everything they're looking for. I think there is slightly less room for error there compared to product case rounds at other companies. DoorDash places a huge emphasis on success metrics, experimentation, and navigating the complexities of a 3-sided marketplace like the one they operate in. Their margins are razor-thin, so it's really important to get the combination of supply, demand, pricing (and user experience) right to win and beat out competition.