Duolingo application practice

Opening a learning app is not the same as learning. For Duolingo, prepare an experiment that separates notifications, completed practice and later recall. The useful application evidence is a decision about the learner's outcome, including when you would revise or stop an engaging feature that does not improve it.

Choose your application route

Work to compare: Engineering; product; design; learning/research; analytics.

Prepare one example: A learning experiment that separates app opens from practice completion and later recall.

Ask the team: How does the team measure learning rather than notification engagement?

Employer resource: Duolingo careers

Before applying: Check the vacancy’s degree or experience gate, term, worksite, pay basis and deadline. This is preparation guidance, not a verified 2027 internship list. A suggested work sample is not an application requirement.

Use the right official interview guide

Duolingo publishes separate engineering and product-design interview guides. The engineering guide describes role-dependent combinations of coding, pair programming, code review, and design conversations. Its pair-programming example involves working in an existing codebase, not simply producing a memorized algorithm. Some sessions are identified specifically for university candidates. Confirm the current plan and language options with the recruiter. Source: Duolingo engineering interviews

The product-design guide describes a portfolio review, recruiter and hiring-manager conversations, and a virtual onsite with presentation, design-sense, collaboration, and process discussions. It recommends presenting one or two end-to-end cases rather than merely browsing a portfolio website. These are published preparation examples, not a guarantee that every current role uses identical sessions or durations. Source: Duolingo product-design interviews

Start at Duolingo careers for current vacancies. Match the guide to the function and level rather than treating an old candidate account as a universal schedule.

Build evidence for the work you want to do

Engineering. Prepare to write, read, test, and discuss code. Choose a project where you can explain a difficult implementation decision and its user consequence. Practice making a small change in unfamiliar code because a clean solution in an empty editor does not demonstrate the same skill.

Product design. Show interaction judgment, craft, iteration, and collaboration. Include the problem definition and constraints before the final screens. Explain how feedback changed the design, what you left unresolved, and how you would evaluate the result.

Data and product. Prepare a decision involving competing metrics. Distinguish engagement, task completion, learning evidence, revenue, and user trust rather than assuming one number represents all of them. State what the data cannot establish.

Content, learning, and research roles. Use the qualifications in the posting to identify the required expertise. Prepare examples of accurate content, clear instruction, evaluation, or research design as applicable. Do not imply that enjoying language learning establishes every specialized credential.

Marketing and business roles. Explain the audience, objective, execution, and result of your work. A memorable campaign still needs a defensible account of what it achieved and how it supported the product or business.

Write a resume that leads to a useful conversation

For each important requirement, select a project that shows the capability at the right level. Include your personal contribution, measurement, and a relevant limitation. A concise set of strong examples is better than a broad list of tools and courses.

Fictional engineering example: "Reworked progress synchronization in a mobile study app, added offline-recovery tests, and reduced lost-progress reports from 23 to four during comparable release windows." The detail creates a technical discussion about synchronization, testing, user experience, and measurement. It does not prove causality by itself; be ready to explain other changes.

A design example could describe reducing confusion in a lesson-navigation flow after observing users. An analytical example could show why a proposed metric was misleading and what decision changed. Use real outcomes, not invented numbers or a claim that a speculative redesign improved a live product.

For new graduates, identify which work was coursework, independent practice, team work, or deployed software. Describe scale honestly. A small project with thoughtful tests and a clear explanation can support stronger follow-ups than a large team project with unclear ownership.

Practice engineering as collaborative problem solving

Prepare three modes: solving a bounded problem, modifying existing code, and reviewing a change. Each reveals something different. In a coding exercise, state the assumptions, choose a baseline approach, test edge cases, and explain complexity when relevant.

For existing code, first identify entry points, data flow, tests, and the expected behavior. Ask focused questions about unfamiliar conventions. Avoid refactoring everything before addressing the task. Explain what you would change now versus later and why.

For code review, prioritize correctness, security, reliability, and maintainability over personal style preferences. Distinguish a blocking issue from a suggestion. A useful comment explains the risk and offers a concrete way to verify or repair it.

Duolingo's engineering guide explicitly discusses pair programming and code review as ways to evaluate work with existing code. Use that guidance to broaden preparation beyond puzzle repetition, while still following the actual recruiter brief. Source: Engineering interview types

Prepare a design presentation with decisions, not just polish

Choose one or two cases with a clear beginning, middle, and outcome. Start with the user problem and the decision you needed to make. Explain the evidence, show the alternatives, and identify the constraints that shaped the final result.

Keep the main presentation selective. Put detailed research, iterations, and design-system work in supporting material for questions. The objective is not to prove that you produced a large volume of screens; it is to make your judgment understandable.

Practice a live critique of a small interaction. Separate observation from interpretation: what is visible, what a user might misunderstand, and what evidence would confirm that concern. Offer a concrete improvement and its tradeoff rather than criticizing aesthetics in the abstract.

The official design guide also includes collaboration and process conversations. Prepare a real example of feedback, disagreement, and revision. Explain your colleague's concern fairly and describe what changed in the work, not just that everyone eventually agreed. Source: Product-design interview guide

Prepare motivation and behavioral answers honestly

Explain which part of the role interests you and which prior work makes that interest credible. Personal experience with learning can provide context, but connect it to a professional capability: careful experimentation, effective instruction, reliable software, or a better user interaction.

Prepare a mistake, a disagreement, and an example of revising your understanding. For each, explain what you believed at the time and why. Avoid making every failure story end in an implausibly perfect outcome.

Confirm assessment tool rules, including AI assistance, before the session. Public discussion of AI-enabled products does not establish what is allowed in a candidate exercise. Practice in the authorized environment and disclose assistance when the instructions require it.

Ask the interviewer which user or business outcome the role would influence first, how the team balances near-term results with longer-term product quality, and what feedback a new hire receives. These are questions for evaluating fit, not claims about confidential team practices.

Related career guides

Automattic job guide | Notion job guide | Etsy job guide

Evidence date