Doxel · Software Engineer
Updated · 2026-10-02

Doxel Software Engineer
Interview Guide

THE 60-SECOND BRIEF

A Software Engineer at Doxel is at the forefront of digitizing the $15T construction industry. You are not just writing code; you are building the automated feedback loops that allow modern construction projects to stay on schedule and under budget. By bridging the gap between complex field data—such as 3D scans, videos, and IoT readings—and actionable insights, you enable the world’s largest contractors to operate with the same precision as top-tier software teams. Your work directly impacts the visibility, risk management, and execution of mega-projects like data centers and hospitals. You will collaborate with a multidisciplinary team of Computer Vision (CV) scientists, 3D visualization experts, and product designers to build high-performance, intuitive tools.

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

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

Full-Stack Web DevelopmentTypeScriptMultimodal Data Handling (Video/Image/Structured Forms)

22 min read

Browse Software Engineer questions

See the practice prompts

16Practice promptsAcross five skill areas

A Software Engineer at Doxel is at the forefront of digitizing the $15T construction industry. You are not just writing code; you are building the automated feedback loops that allow modern construction projects to stay on schedule and under budget. By bridging the gap between complex field data—such as 3D scans, videos, and IoT readings—and actionable insights, you enable the world’s largest contractors to operate with the same precision as top-tier software teams. Your work directly impacts the visibility, risk management, and execution of mega-projects like data centers and hospitals. You will collaborate with a multidisciplinary team of Computer Vision (CV) scientists, 3D visualization experts, and product designers to build high-performance, intuitive tools. Whether you are scaling backend data ingestion or crafting seamless mobile experiences for field workers, your contributions directly reduce global construction waste and drive massive efficiency gains.

01

Initial Screening

reported

The first step involves a review of your application and resume to assess fit for the role.

What to demonstrate

  • The first step involves a review of your application and resume to assess fit for the role
  • Depth in Full-Stack Web Development

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.
Doxel Software Engineer candidate reports ↗
02

Recruiter Screen

reported

A conversation with a recruiter to discuss your background, projects, and the role in detail.

What to demonstrate

  • A conversation with a recruiter to discuss your background, projects, and the role in detail
  • Depth in Full-Stack Web Development

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.
Doxel Software Engineer candidate reports ↗
03

Mid-Stage Depth Interviews

reported

In-depth technical interviews focusing on your specialized knowledge and architectural understanding.

What to demonstrate

  • In-depth technical interviews focusing on your specialized knowledge and architectural understanding
  • Depth in Full-Stack Web Development

How to prepare

  • Answer aloud and timed: How do you approach mentoring junior engineers or contributing to team architectural standards?
  • Answer aloud and timed: How would you design a system to ingest and process large volumes of 3D point cloud data or video streams?
Doxel Software Engineer candidate reports ↗
04

Final Executive Review

reported

A final assessment by executive leadership to evaluate overall fit and alignment with company values.

What to demonstrate

  • A final assessment by executive leadership to evaluate overall fit and alignment with company values
  • Depth in Full-Stack Web Development

How to prepare

  • Answer aloud and timed: What considerations do you make when building offline-capable mobile applications for remote, low-connectivity environments?
  • Answer aloud and timed: Compare and contrast different database strategies (OLTP vs. OLAP) for storing construction progress data.
Doxel Software Engineer candidate reports ↗

PracHub editorial advice for the preparation topics above.

01

Own your projects

Be prepared to dive deep into any project on your resume. You should be able to explain the "why" behind every architectural choice you made.

02

Focus on the "Field

Always tie your technical solutions back to the end-user—a construction worker on a job site who needs speed, clarity, and reliability.

03

Structure your answers

Use the STAR method (Situation, Task, Action, Result) for behavioral questions to keep your responses concise and impactful.

04

Communicate clearly

The interviewers value engineers who can explain complex technical concepts simply. Practice verbalizing your thought process during coding or design sessions.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

11 technical prompts0 include a worked solution

Find overlapping job attempts and peak concurrency from lease records

medium
sweep lineintervalsleases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach
  1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
  2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
  3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
  4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.
Follow-up
  • A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
  • Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Archive a resource graph without breaking live references or recursing

medium
graph traversaltopological ordertenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach
  1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
  2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
  3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
  4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.
Follow-up
  • The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
  • The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Track a rolling failure rate per destination for circuit decisions

easy
sliding windowring buffercircuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach
  1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
  2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
  3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
  4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.
Follow-up
  • The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
  • A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Built from the rounds and topics Doxel candidates report.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the Doxel loop
  • Write out the reported sequence: Initial Screening, Recruiter Screen, Mid-Stage Depth Interviews, Final Executive Review.
  • 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 4 reported rounds, with the weakest marked.

02Work Full-Stack Web Development
  • Spend the session on Full-Stack Web Development, which Doxel candidates report being tested on.
  • Write one worked example in Full-Stack Web Development and time yourself on it.

Deliverable: One timed worked example in Full-Stack Web Development.

03Work TypeScript
  • Spend the session on TypeScript, which Doxel candidates report being tested on.
  • Write one worked example in TypeScript and time yourself on it.

Deliverable: One timed worked example in TypeScript.

04Work Multimodal Data Handling (Video/Image/Structured Forms)
  • Spend the session on Multimodal Data Handling (Video/Image/Structured Forms), which Doxel candidates report being tested on.
  • Write one worked example in Multimodal Data Handling (Video/Image/Structured Forms) and time yourself on it.

Deliverable: One timed worked example in Multimodal Data Handling (Video/Image/Structured Forms).

05Answer out loud: Behavioral and Experience
  • Answer aloud, timed: Walk me through a project where you had to manage conflicting priorities and tight deadlines.
  • Answer aloud, timed: Describe a time you had to explain a complex technical decision to a non-technical stakeholder.

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

06Answer out loud: Technical and System Design
  • Answer aloud, timed: How would you design a system to ingest and process large volumes of 3D point cloud data or video streams?
  • Answer aloud, timed: What considerations do you make when building offline-capable mobile applications for remote, low-connectivity environments?

Deliverable: Spoken answers to 2 reported Technical and System Design question(s), under time.

07Dry run for Doxel
  • Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.

Expand any day for tasks and deliverables. Your progress is saved on this device.

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

Walk me through a project where you had to manage conflicting priorities and tight deadlines.

medium
Behavioral and Experience

Walk me through a project where you had to manage conflicting priorities and tight deadlines.

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 time you had to explain a complex technical decision to a non-technical stakeholder.

medium
Behavioral and Experience

Describe a time you had to explain a complex technical decision to a non-technical stakeholder.

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?

What draws you to the intersection of AI, computer vision, and the physical construction industry?

medium
Behavioral and Experience

What draws you to the intersection of AI, computer vision, and the physical construction industry?

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?

Tell me about a time you faced a significant technical failure; how did you handle it?

medium
Behavioral and Experience

Tell me about a time you faced a significant technical failure; how did you handle it?

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 approach mentoring junior engineers or contributing to team architectural standards?

medium
Behavioral and Experience

How do you approach mentoring junior engineers or contributing to team architectural standards?

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?
  • 01

    Walk me through a project where you had to manage conflicting priorities and tight deadlines.

  • 02

    Describe a time you had to explain a complex technical decision to a non-technical stakeholder.

  • 03

    What draws you to the intersection of AI, computer vision, and the physical construction industry?

  • 04

    Tell me about a time you faced a significant technical failure; how did you handle it?

PracHub preparation framework ↗
How difficult is the interview process?

Candidates generally describe the difficulty as average, but the rigor is high due to the number of interview rounds. Preparation and a clear understanding of your past projects will go a long way.

Doxel Software Engineer candidate reports ↗
How much time should I spend preparing?

Given the 6–7 round process, allocate at least 2–3 weeks of focused study. Review your system design fundamentals and be ready to talk in depth about your most complex technical challenges.

Doxel Software Engineer candidate reports ↗
Is there a specific focus on AI?

While you don't need to be an ML researcher, you should understand how to consume and integrate AI/CV model outputs into a user-facing product.

Doxel Software Engineer candidate reports ↗
What is the culture like at Doxel?

It is described as very friendly and collaborative. The team is mission-driven and focused on solving the massive problem of global construction waste. 12 · Compensation

Doxel Software Engineer candidate reports ↗
What topics does Doxel test in interviews?

Doxel interviews most often cover Portfolio Review, Hiring Manager Interview, 1:1 Interviews, Full-Stack Web Development, and Product Design Process. The exact emphasis depends on the specific role you apply for.

Doxel Software Engineer candidate reports ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.