cswork / libraryOpen practice workspace

Interview guides · Odoo

Odoo Software Engineer Interview Guide

Odoo Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

At Odoo, a Software Engineer is more than just a coder; you are a problem-solver who bridges the gap between complex business requirements and elegant, scalable technical solutions. You will work on the core of an open-source ERP platform, building and maintaining modular applications that power operations for businesses worldwide, from accounting and inventory to CRM. This role is critical to the Odoo ecosystem because your work directly impacts the efficiency and growth of small to medium-sized businesses. You will navigate a diverse technical stack, including Python, JavaScript, and PostgreSQL, while collaborating with cross-functional teams to resolve real-world challenges. Whether you are debugging critical support tickets or architecting new features, you are expected to be proactive, technically sharp, and deeply empathetic toward the end-user. 02 · Compensation

This guide is scoped to a Software Engineer candidate at Odoo.

Focus areas

  • Algorithms & Problem Solving
  • HTML Syntax Validation / Tag Matching
  • Coding Assessments (Online OA)

The Odoo interview process

Odoo candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Online Assessment

Initial assessment to filter for core programming skills.

What to demonstrate

  • Initial assessment to filter for core programming skills
  • Depth in Algorithms & Problem Solving

How to prepare

  • Answer aloud and timed: Validate a string of HTML tags to ensure correct nesting (similar to balanced parentheses).
  • Answer aloud and timed: Solve a "MinStack" implementation problem.

HR Screening

Discussion of your background and interest in the company.

What to demonstrate

  • Discussion of your background and interest in the company
  • Depth in Algorithms & Problem Solving

How to prepare

  • Be able to walk your CV end to end in two minutes, and say why this company specifically.
  • Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Interview

In-depth technical interview involving multiple problem-solving tasks.

What to demonstrate

  • In-depth technical interview involving multiple problem-solving tasks
  • Depth in Algorithms & Problem Solving

How to prepare

  • Answer aloud and timed: Implement Run-Length Encoding on a string.
  • Answer aloud and timed: Design a UML diagram for a car dealership (Users, Cars, Sales, Mechanics).

Where candidates lose points

Think Out Loud

Even if you know the answer, explain your reasoning. Interviewers want to see how you navigate complexity.

Master the Basics

Don't skip over SQL and OOP concepts; they appear frequently in technical discussions.

Know Your Projects

Be prepared to discuss every line of code in the projects you list on your resume.

Practice Under Pressure

Use a timer when practicing coding problems to mirror the actual interview experience.

Questions & practice

Validate a string of HTML tags to ensure correct nesting (similar to balanced parentheses).

Medium · Algorithmic Problem Solving

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Solve a "MinStack" implementation problem.

Medium · Algorithmic Problem Solving

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Flatten a nested data structure.

Medium · Algorithmic Problem Solving

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Find the shortest path in a graph from the first to the last node.

Medium · Algorithmic Problem Solving

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Implement Run-Length Encoding on a string.

Medium · Algorithmic Problem Solving

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Create a database schema for a course hosting system (Professors, Students, Classes).

Medium · Database Design & SQL

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Write complex SQL queries involving joins, group by, and aggregations.

Medium · Database Design & SQL

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Design a UML diagram for a car dealership (Users, Cars, Sales, Mechanics).

Medium · Database Design & SQL

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Explain the purpose and impact of database indices.

Medium · Database Design & SQL

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

One customer endpoint stalls deliveries to every other destination

Medium · bulkhead · timeouts · saturation

The egress service delivers about 1.5k webhooks/second across 40,000 destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. Throughput falls to 300/second, queue depth climbs, and p99 delivery latency for unaffected destinations goes from 200 ms to minutes, while the error rate barely moves. One tenant holds 900 destination rows whose URLs share a hostname that now answers in 9.5 seconds. Explain the mechanism with the arithmetic, then give the containment in the order you would apply it.

Approach

  1. Look at saturation before errors. A flat error rate with collapsing throughput says nothing is failing, things are waiting, so the first signal to pull is in-flight request count or pool wait time rather than the error counter. This is the distinction that decides the whole investigation.
  2. Group in-flight work by resolved host, not by destination id. The cap is keyed per destination row, so 900 rows sharing one hostname buy 3,600 concurrent slots against a single host, each held for 9.5 seconds. The bulkhead was never a bulkhead for that host, and grouping by the wrong dimension is why the dashboard looked healthy.
  3. Do the arithmetic in both directions. Required concurrency is arrival rate times latency, so 1.5k/second at 200 ms needs about 300 in flight, which is entirely consumed by 3,600 slow slots; conversely whatever concurrency is left sustains rate equals concurrency divided by 9.5 seconds, which is the 300/second you are seeing. Matching both numbers is what promotes this from a plausible story to the mechanism.
  4. Explain why the circuit breaker never helped. It opens on consecutive failures, and a 9.5-second response inside a 10-second timeout is a success. Slow is not failing, so an error-rate breaker cannot see this; you need a slow-call ratio, a deadline propagated from the caller's remaining budget, or a concurrency limiter.

Follow-up

  • The host recovers to 80 ms. How long does the queue take to drain, and what does the drain do to the recovered host?
  • Where should the 10-second timeout number actually come from?

Suggested practice checklist

Built from the rounds and topics Odoo candidates report.

Day 1 — Map the Odoo loop

  • Write out the reported sequence: Online Assessment, HR Screening, Technical Interview.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 3 reported rounds, with the weakest marked.

Day 2 — Work Algorithms & Problem Solving

  • Spend the session on Algorithms & Problem Solving, which Odoo candidates report being tested on.
  • Write one worked example in Algorithms & Problem Solving and time yourself on it.

Deliverable: One timed worked example in Algorithms & Problem Solving.

Day 3 — Work HTML Syntax Validation / Tag Matching

  • Spend the session on HTML Syntax Validation / Tag Matching, which Odoo candidates report being tested on.
  • Write one worked example in HTML Syntax Validation / Tag Matching and time yourself on it.

Deliverable: One timed worked example in HTML Syntax Validation / Tag Matching.

Day 4 — Work Coding Assessments (Online OA)

  • Spend the session on Coding Assessments (Online OA), which Odoo candidates report being tested on.
  • Write one worked example in Coding Assessments (Online OA) and time yourself on it.

Deliverable: One timed worked example in Coding Assessments (Online OA).

Day 5 — Answer out loud: Algorithmic Problem Solving

  • Answer aloud, timed: Validate a string of HTML tags to ensure correct nesting (similar to balanced parentheses).
  • Answer aloud, timed: Solve a "MinStack" implementation problem.

Deliverable: Spoken answers to 2 reported Algorithmic Problem Solving question(s), under time.

Day 6 — Answer out loud: Database Design & SQL

  • Answer aloud, timed: Design a UML diagram for a car dealership (Users, Cars, Sales, Mechanics).
  • Answer aloud, timed: Create a database schema for a course hosting system (Professors, Students, Classes).

Deliverable: Spoken answers to 2 reported Database Design & SQL question(s), under time.

Day 7 — Answer out loud: Behavioral & Communication

  • Answer aloud, timed: Why are you interested in working with Odoo and our ERP platform?
  • Answer aloud, timed: Can you explain a complex project from your resume and your specific contributions to it?

Deliverable: Spoken answers to 2 reported Behavioral & Communication question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Why are you interested in working with Odoo and our ERP platform?

Medium · Behavioral & Communication

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Can you explain a complex project from your resume and your specific contributions to it?

Medium · Behavioral & Communication

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

How do you handle ambiguity when requirements are not fully defined?

Medium · Behavioral & Communication

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Describe a situation where you had to explain a technical issue to a non-technical stakeholder.

Medium · Behavioral & Communication

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?