Explain LLMs, AI-native vs. conventional apps, daily AI use, and the dangers of AI

In the phone screen for a staff-level backend engineering role, roughly 20 to 25 minutes are set aside for a conversation about AI. It is not a coding exercise. The interviewer wants to gauge how comfortable you are with modern AI systems and how carefully you apply them, and expects to dig into any AI work on your resume. Answer the four prompts below as you would out loud, spending a few minutes on each. Pitch the explanations at an audience of experienced engineers: precise and concrete, without equations. ### Constraints and Clarifications - The round is conversational. No code is required, but examples from systems you have built, operated or used carry more weight than textbook definitions. - Assume you may draw on classic machine-learning work as well as LLM-based products, as long as you are clear which one you are talking about. - The four prompts share one time slot, so depth on a few points beats a shallow tour of everything. ### Clarifying Questions - Should the explanation of LLMs cover how they are trained, or stay with how they behave once deployed? - For AI-native applications, does the interviewer want consumer examples, internal tools, or products close to what this team builds? - For the risks question, is the focus on harm to end users of an AI feature, on the business shipping it, or on engineers using AI tools in their own work? ### Part 1 — Explain what an LLM is Explain what a large language model is to a backend engineer who has never worked with one: what it is trained to do, how it produces a response, and which of its behaviors surprise people used to deterministic software. ```hint Start from the objective Anchor the explanation in what the model is optimized to do during training, then connect that objective to the behaviors a user actually sees. ``` #### What This Part Should Cover - The training objective and the stages that turn a raw pretrained model into a usable assistant - How a response is generated at inference time, including context limits and sampling - Behaviors that matter to engineers integrating a model, and why they arise - How an LLM differs from a classic task-specific model ### Part 2 — AI-native versus conventional applications What distinguishes an AI-native application from a conventional application that has added AI features? Give an example of each and explain how the difference shows up in architecture, product design and day-to-day operation. ```hint Switch the model off Imagine each example with its model unavailable and ask what is left of the product. ``` #### What This Part Should Cover - A definition sharper than "it uses AI" - One concrete example of each kind - Engineering consequences for testing, failure handling, data and cost - When adding AI to an existing product is the better choice ### Part 3 — How you use AI day to day How do you use AI tools in your own work? Name concrete workflows, where the tools save real time, where you have stopped trusting them, and how you check their output before it reaches production. ```hint Show your guardrails The interviewer learns more from how you verify and constrain a tool than from the list of tools you use. ``` #### What This Part Should Cover - Specific workflows rather than product names - A verification habit attached to each workflow - Discipline about what data and code may be shared with a tool - Honest limits: tasks where the tools mislead or slow you down ### Part 4 — The dangers of AI What are the main dangers of AI, both for people using AI-powered products and for the teams that build and ship them? For each risk you raise, say how you would reduce it in a system you own. ```hint Sort the risks Group the risks by who is harmed and how quickly a failure becomes visible, then attach a control to each group. ``` #### What This Part Should Cover - Risks to end users and to the business shipping an AI feature - Risks that come from engineers relying on AI tools - A concrete mitigation for each risk rather than a list of worries - Controls scaled to the stakes of the use case ### What a Strong Answer Covers - Technically accurate explanations pitched at the audience, without hype or hand-waving - Concrete examples from systems the candidate has built or operated - Treats model output as probabilistic and designs around that fact - A balanced view that pairs the value of AI with specific controls for its risks - Staff-level framing: effects on teams, processes and product direction, not just one feature ### Follow-up Questions - Your team wants to add an LLM feature to a product whose behavior is fully deterministic today. What would you require before it launches? - How would you choose between calling a hosted model API and running an open-source model yourselves? - How would you tell whether an AI feature actually helps users rather than merely being used? - A product manager asks why the model answers the same question differently on different days. How do you explain it, and what can you change?