Autodesk Coding Interview Questions: Geometry, 3D Performance, and C++ at Scale

Autodesk's best-known products include AutoCAD for drafting and design, Revit for building information modeling (BIM), and Fusion for product design and manufacturing. Their users are professionals - an architect coordinating a building, a structural engineer checking a model, a machinist preparing toolpaths for a part - and the software has to be precise enough to build from, responsive on models with enormous numbers of elements, and dependable through sessions that last all day. Much of it is desktop software with a long history that is increasingly connected to cloud services.

This guide covers the process candidates commonly describe, where the engineering problems come from, the domain themes worth preparing, representative problem types, and a two-week plan. We describe problem types and themes rather than specific questions: interview content rotates, and the skills underneath are what you can actually prepare.

The Autodesk interview process, as candidates describe it

Candidate reports tend to outline the stages below. Autodesk hires for many products, teams, and locations, so the format varies by team, level, and region, and processes change over time. Treat the table as a rough outline, and confirm your own schedule, including which programming languages you may use, with your recruiter.

Stage	What candidates commonly describe	Worth preparing
Recruiter conversation	Role, product area, level, and logistics	A clear reason this product area interests you
Technical screen	Live coding; some teams reportedly use an online assessment or a take-home instead	Clean, tested code in your strongest language
Later interviews	Coding, technical depth or design, and behavioral conversations	Depth in your area: geometry, graphics, desktop C++, or cloud services
Decision	Debrief and recruiter follow-up	Consistency across every conversation

Where the engineering problems come from

Each product implies its own set of hard problems, and knowing which one your team works on tells you where to spend prep time. The table sketches the kinds of problems each area naturally raises; it is not a description of any team's interview.

Product area	What it models	Problems it naturally raises
AutoCAD	Precise 2D drawings and 3D models built from geometric entities	Geometry predicates, spatial indexing for selection and snapping, long-lived file compatibility
Revit	Buildings as connected elements with parameters, such as walls that host doors on a given level	Dependency tracking, parametric updates, many people working in one model
Fusion	Parts and assemblies, with manufacturing and simulation in the same product	Parametric history, solid modeling, toolpath data, cloud-connected projects
Platform and cloud services	Design data exposed through APIs and viewed in the browser	Translating and streaming large models, versioning, permissions across companies

Coding topics to weight beyond the basics

Standard data structures and algorithms are the floor for every team. On top of that, weight your practice toward:

• Vector math. Dot and cross products, projections, and transforms between coordinate systems.
• Geometry predicates. Orientation tests, intersections, point-in-polygon, and polygon area.
• Graphs. Topological order and cycle detection, which sit underneath parametric models - our graph algorithms guide covers both.
• Spatial data structures. Grids, quadtrees and octrees, R-trees, and bounding volume hierarchies.
• C++ fluency for desktop teams. Value types, const-correctness, and choosing containers with performance in mind.
• Modeling the domain. Representing building elements or part features as clear, extensible types.

Computational geometry: precision is the product

In many applications, a result that is off by a tiny amount goes unnoticed. In CAD, a missed intersection can mean a wrong drawing, a part that does not fit, or a model that fails to export. Geometry questions are a natural fit for geometry-heavy teams, and the bar is correctness in the awkward cases, not just the typical one. The ideas to be comfortable with:

• Floating-point tolerance. Exact equality rarely works on computed coordinates, so comparisons use a tolerance - and choosing it is a real decision, because an absolute tolerance does not carry over from a millimeter-scale part to a site plan hundreds of meters across.
• Degenerate cases. Collinear points, zero-length segments, coincident vertices, and shapes that touch without crossing are exactly where naive code fails.
• Orientation. The sign of a cross product says whether three points turn left, turn right, or lie on a line, and a surprising number of geometric algorithms reduce to it.
• Units and scale. Designs mix units and span enormous ranges of size, so conversions must be explicit and precision loss must be considered.
• Curves and solids. Real models contain arcs, splines, and solid bodies, not only line segments; know at a conceptual level what NURBS curves and boundary representations (B-rep) are.
• Display versus exact geometry. Curved surfaces are tessellated into triangles for display at a chosen tolerance, while the exact definition is kept for measurement and manufacturing.

A classic problem in this space is deciding whether two line segments intersect, including the cases where they only touch or overlap along the same line. Here is a version built on orientation tests:

#include <algorithm>

struct Point { double x, y; };

// Twice the signed area of triangle (a, b, c):
// positive = counter-clockwise, negative = clockwise, zero = collinear.
double Cross(const Point& a, const Point& b, const Point& c) {
    return (b.x - a.x) * (c.y - a.y) - (b.y - a.y) * (c.x - a.x);
}

int Orientation(const Point& a, const Point& b, const Point& c, double eps) {
    double v = Cross(a, b, c);
    if (v > eps) return 1;
    if (v < -eps) return -1;
    return 0;                                   // collinear within tolerance
}

// Assumes p is collinear with segment a-b.
bool OnSegment(const Point& a, const Point& b, const Point& p, double eps) {
    return p.x >= std::min(a.x, b.x) - eps && p.x <= std::max(a.x, b.x) + eps &&
           p.y >= std::min(a.y, b.y) - eps && p.y <= std::max(a.y, b.y) + eps;
}

bool SegmentsIntersect(const Point& p1, const Point& p2,
                       const Point& q1, const Point& q2, double eps) {
    int d1 = Orientation(q1, q2, p1, eps);
    int d2 = Orientation(q1, q2, p2, eps);
    int d3 = Orientation(p1, p2, q1, eps);
    int d4 = Orientation(p1, p2, q2, eps);

    if (d1 * d2 < 0 && d3 * d4 < 0) return true;            // proper crossing
    if (d1 == 0 && OnSegment(q1, q2, p1, eps)) return true;   // touching or overlapping
    if (d2 == 0 && OnSegment(q1, q2, p2, eps)) return true;
    if (d3 == 0 && OnSegment(p1, p2, q1, eps)) return true;
    if (d4 == 0 && OnSegment(p1, p2, q2, eps)) return true;
    return false;
}

The strong answer explains the structure - a proper crossing needs each segment's endpoints on opposite sides of the other segment's line, and the collinear cases are handled separately - and then turns to the part that matters most in CAD: the tolerance. Here eps is an absolute threshold on a cross product, which has units of area, so a value tuned for a small part behaves differently on a large site plan. Good follow-ups to raise yourself: scale the tolerance to the size of the inputs, merge nearly coincident points before testing, or use exact or adaptive-precision predicates where robustness matters more than speed. Then say how you would test it: randomized inputs, points just inside and just outside the tolerance, and the same configuration translated far from the origin.

3D graphics and performance on very large models

Performance in design software is often about model size and interactive editing. A building model or a large assembly can contain an enormous number of elements, and users still expect to orbit, select, and edit without waiting. Concepts worth being able to discuss:

• Tessellation and level of detail. Decide how finely to triangulate curved surfaces based on how large they appear on screen, and cache the results rather than recomputing them every time the view changes.
• Instancing. A building repeats the same window many times and an assembly repeats the same fastener; store the geometry once and draw many transformed copies.
• Culling and picking. Skip what is outside the view, and use a bounding volume hierarchy (BVH) or octree to find the object under the cursor without testing every triangle.
• Incremental updates. When one dimension changes, recompute and redraw only what depends on it rather than the whole model.
• Loading and memory. Open large models progressively so something useful appears quickly, stream detail on demand, and keep memory in check with compact representations.
• Large coordinates. Models placed at real-world locations can sit far from the origin, where 32-bit floats lose precision and geometry visibly jitters; rendering relative to a nearby local origin avoids it.

Whatever you propose, say how you would measure it, and cover memory as well as time.

Working in large, long-lived C++ codebases

Several of Autodesk's desktop products have histories measured in decades, and their public extension APIs hint at the technology around them: AutoCAD offers ObjectARX for C++ alongside .NET and AutoLISP, Revit has a .NET API, and Fusion has an API for Python and C++. For product teams the relevant skill is not only writing new code but changing large existing code safely. Our Epic Games interview guide covers C++ ownership, memory, and object lifetime; the themes below matter more for long-lived design software:

• Compatibility. Customers open files created many releases ago and run add-ins built against older SDKs, so file formats and public APIs change carefully, with versioning and deprecation paths.
• Binary interfaces. Changing a class layout or a function signature in a public header can break compiled plug-ins; be ready to explain why ABI stability matters and how interfaces are designed to survive change.
• Safe refactoring. Tests that pin down current behavior before a change, small reviewable steps, and flags that let risky behavior roll out gradually.
• Testing geometry. Regression suites built from real-world files, comparisons with tolerances rather than exact equality, and randomized inputs for predicates.
• Debugging from evidence. Crash reports, memory dumps, and a customer file that reproduces a problem only on one machine.
• Platforms and threads. Some products ship on both Windows and macOS, and moving work onto background threads is delicate when a document model was designed around a single thread.

The shift to cloud-connected design data

Autodesk has spoken publicly about moving from file-based workflows toward cloud-connected, more granular design data, through Autodesk Platform Services (formerly Forge) and industry clouds such as Forma for architecture, engineering, and construction and Fusion for design and manufacturing. For cloud and platform roles, that shift is rich material for design discussions:

• Files to data. Rather than downloading a whole file to read one value, expose elements and their properties through APIs; discuss how you would model, index, and version that data.
• Translation pipelines. Converting uploaded design files into formats a browser viewer can stream is long-running and failure-prone work; design it with queues, retries, progress reporting, and idempotent steps.
• Version history. Designs move through many versions that people compare and roll back, so think about immutable versions, differences between them, and storage cost.
• Cross-company access. One project can involve an architect, several engineering firms, and a contractor, each needing different permissions on shared data.
• Desktop and cloud together. Desktop applications sync with cloud services, so consider offline work, conflicting changes, and slow networks.

If real-time co-editing comes up, our Figma interview guide explains the concurrency concepts involved. For building and product data, also prepare for questions about very large data sets, versions, and permissions that cross organizations.

Domain-aware engineering for architects and engineers

You do not need to be an architect or a mechanical engineer, but product-team interviewers may appreciate candidates who understand how professionals use the software. A little vocabulary goes a long way:

• Parametric design. Dimensions and constraints drive geometry, so changing one value updates everything that depends on it - a dependency graph that must be recomputed in a valid order and must reject cycles.
• Building information modeling (BIM). A building model is a database of elements with properties and relationships - a door hosted in a wall on a level - rather than lines on a drawing.
• Sketch constraints. Coincident, parallel, tangent, and dimensional constraints are solved together, and an over-constrained sketch needs a clear explanation for the user.
• Drawings from models. Plans, sections, and elevations are generated from the model, so one change must appear consistently everywhere.
• Interoperability. Projects exchange data through open standards such as IFC for buildings and STEP for mechanical parts, as well as DWG and DXF, so import and export fidelity matters.
• Trust. Professionals build real things from these files, so never losing work and never silently changing a dimension are product requirements, not polish.

Representative problem types

These are problem types that fit Autodesk's domain, alongside the standard data structures and algorithms problems candidates commonly report. Practice them as categories, not as a list of actual prompts:

• Geometry predicates. Segment intersection, point-in-polygon, polygon area and winding order, or the closest point on a segment, with degenerate cases handled.
• Spatial queries. All entities inside a selection window or near the cursor, using a grid, quadtree, or R-tree instead of a full scan.
• Dependency recompute. Given features and their dependencies, recompute in a valid order after a change, touch only what is affected, and report cycles.
• Mesh checks. Test a triangle mesh for a basic closed-surface condition - every edge shared by exactly two triangles - or count its connected pieces.
• Transforms and units. Compose rotation, scale, and translation matrices, move points between coordinate systems, and convert units without losing precision.
• Class design. Model a small building with levels, walls, and hosted openings, then extend it with a new requirement.
• Design (experienced roles). A model translation service, version history for design data, permissions for multi-company projects, or streaming a large model to a browser viewer.

What interviewers tend to value

• Correctness at the edges. Degenerate inputs and tolerances handled on purpose, not by luck.
• Numerical care. Units, precision, and scale raised without prompting.
• Performance with memory in mind. Complexity, plus what fits in memory and what can be recomputed incrementally.
• Engineering maturity. Changing existing code safely, testing thoroughly, and respecting compatibility.
• Respect for professional users. Precision, reliability, and never losing someone's work.

On integrity: geometry and design conversations move quickly into follow-ups - a new degenerate case, a much larger model, a second company on the project. Preparation that builds real understanding is what lets you work through those changes in the room, in your own words.

A two-week Autodesk prep plan

1. Days 1-3: Data structures and algorithms in your strongest language - hash maps, sorting, trees, graphs, and heaps - written as clean, tested code. Use C++ if your role is on a desktop product team.
2. Days 4-6: Geometry fundamentals: vectors, dot and cross products, orientation tests, segment intersection with a tolerance, point-in-polygon, and polygon area. Test each against degenerate inputs.
3. Days 7-8: Graph work for parametric models - topological order, cycle detection, and incremental recompute - plus a spatial index for selection queries.
4. Days 9-10: 3D and performance: transforms, bounding volume hierarchies, instancing, level of detail, and the large-coordinate precision problem, each explained out loud.
5. Days 11-12: Depth for your team. Desktop candidates review compatibility, ABI stability, and testing in large codebases; cloud candidates practice designing a model translation pipeline and version history for design data.
6. Days 13-14: Learn the vocabulary of the product you would work on, prepare behavioral stories about quality, collaboration, and a hard bug you tracked down, then finish with a timed solo mock.

FAQ

What kind of coding questions does Autodesk ask?

Candidates commonly describe standard data structures and algorithms problems, and some teams add questions that reflect their domain, such as geometry, graphics, or C++ behavior. The mix depends on the product area and level, and formats change over time, so check with your recruiter what your interviews will cover.

Is C++ required for Autodesk coding interviews?

For desktop product, geometry, and graphics teams, strong C++ is often expected, because much of that software is large native code. Cloud, web, and data teams may work in other languages. Check the job description and confirm with your recruiter which languages you can use in coding rounds.

How much computational geometry should I know for Autodesk?

For geometry, graphics, and modeling roles, be comfortable with vectors, cross and dot products, orientation tests, segment intersection, point-in-polygon, and transforms, and be able to explain floating-point tolerance and degenerate cases. For other roles, working knowledge of these ideas is usually enough, and it still helps you talk credibly about the products.

Do I need experience with AutoCAD, Revit, or Fusion?

It is usually not a hard requirement for software engineering roles, but familiarity helps you understand users and discuss the product with confidence. Autodesk has offered educational access for eligible students and educators and a personal-use option for Fusion, so check the current terms on its website and spend a few hours building something simple.

How does Autodesk's move to the cloud affect interviews?

For cloud and platform roles, design discussions may involve moving from whole files to granular design data, translating and streaming large models, version history, and permissions for projects shared across companies. Desktop roles may touch on syncing with cloud services. Autodesk has discussed this shift publicly, and its developer platform documentation is useful background.