AECOM Software Engineer Interview Guide

The 60-second brief

Candidates describe AECOM as an infrastructure firm, and the software engineer role sits on its digital side. Reported examples include custom digital platforms, geospatial data pipelines, automated design tools, enterprise cloud applications, web apps for asset management, workflow engines that connect to building information modeling systems, and backend code that processes sensor and environmental data. Candidates describe working with domain specialists, digital leads and project managers.

This guide is for candidates applying to AECOM as a Software Engineer, including graduates and interns who will talk through a capstone or internship project. It covers the three reported rounds, the twenty reported questions (databases, Git, JSON validation, API design, a 2D canvas tool, sensor data batches, performance diagnosis, third-party integration, project deep dives and behavioral prompts) and a plan for rehearsing them aloud.

Candidates report three rounds over roughly 3-5 weeks: an HR Screening, a Technical Assessment (a panel or a take-home project is mentioned) and an In-Person Interview that includes meeting potential colleagues.

Focus areas

• Resume-based technical discussion
• Technical interviewing
• Engineering knowledge & fundamentals

Overview

The reported technical questions are practical rather than puzzle-style. They cover relational versus non-relational storage, a Git workflow on a shared feature branch, parsing and validating a JSON configuration file, validation and error handling in APIs, and making a web tool accessible and documented for non-technical users. Candidates describe the overall level as average and applied, so the goal is working detail you can defend: the exact SQL you would write, the exact branch commands you would run, the exact checks your validator performs.

Candidates also report that the resume is the centerpiece of much of the conversation. Reported questions cover a capstone or internship architecture, the hardest technical problem you solved, the languages and frameworks you used, scripting you wrote to remove manual work, and a trade-off between delivery speed and technical debt. Every technology on your CV is something you may be asked to explain, so cut or refresh anything you cannot discuss.

The scenario questions point at the kind of software the role builds: an interactive 2D canvas for manipulating objects and rendering layout geometry, a batch of sensor or field survey data to process, a slow internal application under heavy use, and custom code that has to talk to third-party APIs or design automation tools. Candidates also mention a cloud backend that lets many engineers upload design files at once. Prepare each as a sequence of steps you can say out loud, with the failure cases named.

The behavioral side is reported as important because the work is multi-disciplinary. Candidates describe four evaluation themes: role-related technical knowledge, practical problem-solving, communication with civil engineers, project managers and clients, and fit with values such as safety, sustainability and innovation. Prepare stories where the audience was non-technical, the requirements moved, or something went wrong.

The AECOM interview process

Candidates describe three stages, with the technical stage varying by office and team. Treat the order as the reported pattern, not a guarantee.

HR Screening

The reported first stage is a phone or virtual call with recruiting that mostly covers your background, technical basics and why you want the role. It is the first place you give your story, so approach it as a structured pitch: who you are, the one or two projects that best match this role, and a specific reason for infrastructure software. Candidates also describe the 'why AECOM' question as part of the behavioral material, so have that answer ready here.

What to demonstrate

• Educational background and how it connects to software work
• Basic technical skills at the level of naming languages, databases and tools you have used
• Motivation for this role and for infrastructure technology

How to prepare

• Write a short walk through your CV and project list, with the languages and frameworks used in each (the languages-and-frameworks question is a reported one).
• Write your answer to why you want a Software Engineer role at AECOM and how infrastructure technology fits your career plan, naming a specific area such as geospatial data, BIM integration or web tools for engineers.
• Prepare two or three questions about the digital initiatives and tech stack of the team you would join.

Technical Assessment

Reports mention a technical panel or a take-home project at this stage, with a hiring manager involved. What you face depends on the office: a brief presentation on a topic given beforehand, a walk through code, or a spoken discussion of simple SQL and system behaviour. Entry-level and regional programs are also reported to add an online video assessment or a group assessment day ahead of the last technical stage. Because the format varies, prepare for every shape: a spoken technical answer, code you can walk through line by line, and a presentation with room for questions.

What to demonstrate

• Core software engineering knowledge such as databases, version control, API design and clean, testable code
• Practical problem-solving: breaking an ambiguous task into steps and stating trade-offs
• Ability to explain technical choices clearly in a presentation or walkthrough

How to prepare

• Practise the SQL versus NoSQL answer, the multi-developer Git branch workflow, the JSON configuration validator and API validation and error handling until each is a clear spoken answer with a concrete example.
• Rehearse the scenario questions as step sequences: the 2D canvas design, the sensor or field survey batch, the slow internal application, and third-party or design-tool integration.
• Prepare the cloud scenario of a backend that lets hundreds of concurrent engineers upload design files: presigned URLs to blob storage (S3 or Azure Blob), multipart or resumable uploads, a metadata row in SQL, virus scanning and processing through a queue, and file versioning.
• Build a short presentation on one project of your own, with an architecture diagram, one trade-off and time reserved for questions. If a take-home is set, keep the solution small, add tests and a README, and be ready to defend each decision aloud.

In-Person Interview

Reports describe a visit to the office and informal conversations with future teammates. No specific questions are reported for this stage, so treat it as preparation advice: practise talking about your projects in a natural way rather than reciting them, and keep your collaboration and communication stories ready.

What to demonstrate

• Working relationships with colleagues from other disciplines
• Communication of technical ideas to a mixed audience
• Depth behind the projects and decisions on your resume

How to prepare

• Prepare stories for a technical disagreement, a presentation to non-technical stakeholders, a project that missed its plan and shifting requirements, each in situation, task, action, result form.
• Be ready to discuss your capstone or internship architecture, including what you would change.
• Bring specific questions about the team's projects, tools and how engineers and domain specialists work together.

Where candidates lose points

Listing technologies on the resume that you cannot explain in depth

Candidates report that the CV is a centerpiece of the discussion. For each project, prepare the architecture, your own contribution, one hard problem and one trade-off, and remove tools you only touched once.

Describing the Git workflow as commands without a team process

For the multi-developer feature branch question, cover branch naming, small commits, pull requests with review and how you resolve conflicts. On a shared branch, bring main in with a merge (or a rebase only if the whole team agrees), rebase only your own unpublished commits, then say which you prefer and why.

Answering the JSON validation and API error-handling questions with only the happy path

Name the failure cases: malformed JSON, missing or wrongly typed fields, out-of-range design parameters, unknown keys and partial failures. Say how errors are reported (clear messages with the offending field, consistent status codes) and where validation lives.

Treating the scenario questions as abstract design with no sense of the users

For the 2D canvas, sensor batch and slow-application questions, state who the users are, what data volume to expect and how you would measure success. Mention performance steps in order: measure first, then fix the biggest cost.

Giving behavioral answers that stay technical or have no result

Use situation, task, action, result and finish every story with what changed. For stories about non-technical stakeholders or changing requirements, show how you adapted language and process to the audience.

Questions & practice

How would you structure a basic algorithm to parse and validate design parameters from a JSON configuration fi

Medium · Applied Technical Skills & Development P

How would you structure a basic algorithm to parse and validate design parameters from a JSON configuration file?

Approach

1. Structure the work as a pipeline: read the file (missing file, UTF-8 encoding), parse it (in Python, json.load raises json.JSONDecodeError with line and column), validate against a schema, convert to typed objects, and return either a valid config or a full list of errors.
2. Declare the rules rather than scattering if-statements: use a JSON Schema validator or a pydantic or dataclass model for required keys, types, enums and numeric ranges (a span length must be positive). Add cross-field rules in code, such as min <= max or a referenced material id existing.
3. Report every error, not just the first, each with its path (beams[3].length) and the expected versus actual value, so an engineer editing the file can fix everything in one pass.
4. Cover the edge cases: Python's json accepts NaN and Infinity by default (override with parse_constant), duplicate keys silently keep the last value (detect them with object_pairs_hook), isinstance(True, int) is True so booleans slip through number checks, and quoted numbers such as "12" should be rejected or coerced by an explicit rule.
5. Complexity is linear in the document size. For very large files, a streaming parser such as ijson keeps memory flat. Unit tests should include a malformed fixture for each rule.

Follow-up

• How would you accept units written as "12 m" or "1200 mm" and normalise them?
• A parameter gets renamed in the next version. How do you keep old config files working?
• How would you show these errors to a civil engineer who does not read stack traces?

Describe the step-by-step sequence of operations required to process a incoming batch of sensor or field surve

Medium · Technical Scenarios & Applied Problem So

Describe the step-by-step sequence of operations required to process a incoming batch of sensor or field survey data.

Approach

1. Ingest: store the raw file unchanged with a batch id, source, device and received time, plus a checksum, so a duplicate delivery is detected and any batch can be reprocessed from the original.
2. Parse and validate: check columns and types, convert timestamps to UTC with an explicit timezone, normalise units, confirm the coordinate reference system (geographic EPSG:4326 versus a projected system), and run range checks. Send bad rows to a quarantine table with a reason, rather than dropping them or failing the whole batch.
3. Clean and transform: deduplicate on (sensor_id, timestamp), sort and handle out-of-order or late readings, apply calibration offsets, flag outliers against physical limits or a rolling median, then resample or aggregate to the grain consumers need.
4. Load idempotently: upsert on the natural key (INSERT ... ON CONFLICT in PostgreSQL, MERGE in SQL Server) through a staging table inside one transaction, so rerunning a batch never double-counts.
5. Make each batch observable: record rows received, loaded and rejected, alert on anomalies, and keep lineage from output back to the raw file. Process in chunks so memory stays flat. Sorting is O(n log n); everything else is a linear pass.

Follow-up

• The same batch arrives twice an hour apart. What happens in your pipeline?
• How would the design change if the data arrived as a continuous stream?
• One sensor's clock has drifted by ten minutes. How do you detect and correct it?

If an internal engineering application you built experiences slow load times under heavy usage, how would you

Medium · Technical Scenarios & Applied Problem So

If an internal engineering application you built experiences slow load times under heavy usage, how would you diagnose and optimize its performance?

Approach

1. Measure before changing anything: reproduce the slowdown, define the metric (p50 and p95 response time, time to first byte, Largest Contentful Paint), and split the time between browser, network and server using the DevTools network waterfall and server-side timing or APM traces.
2. On the server, look at the database first: the slow query log, EXPLAIN ANALYZE, missing indexes, N+1 queries from the ORM, and connection-pool exhaustion. Then CPU and memory saturation, and lock contention.
3. Note the clue in the question: if it is fast for one user and slow under load, suspect shared limits (pool size, worker or thread count, locks, an unpaginated endpoint) before single-query cost.
4. Apply fixes in order of cost: index or rewrite queries, paginate, eager-load related rows, cache with an invalidation plan (HTTP caching, Redis), move heavy work to background jobs, compress responses, and code-split the frontend and serve static assets from a CDN. Scale out only once the bottleneck is known.
5. Prove the fix with a load test (k6, JMeter or Locust) before and after, then add a performance check or alert so a regression is caught early.

Follow-up

• The database looks healthy but latency still climbs with concurrent users. What do you check next?
• When is caching the wrong fix for a slow page?
• How would you stop this regression from shipping again?

How do you prioritize your workload when managing multiple tight deadlines across concurrent projects?

Medium · Behavioral, Culture Fit & Career Goals

Approach

1. Show a repeatable method: list every commitment, then rate each on impact, hard versus soft deadline, who is blocked by it, and effort. Sequence from that (an urgent/important grid works) rather than by whoever asked last.
2. Raise conflicts early: when the work does not fit, tell the stakeholders or your manager with concrete options (cut scope, move a date, add help) instead of quietly missing a deadline.
3. Protect execution: limit work in progress, block focused time, and split large tasks into pieces that can ship on their own, so partial progress still delivers value.
4. Back it with a real example that ends in a concrete outcome. The answer that sinks it is "I just work longer hours" or a claim never to have missed a deadline.

Follow-up

• Two project managers each say their request is the top priority. What do you do?
• Tell me about a deadline you did miss and how you handled it.
• How do you keep track of commitments across several projects?

What are the core differences between relational and non-relational databases, and when would you use SQL vs.

Medium · Applied Technical Skills & Development P

What are the core differences between relational and non-relational databases, and when would you use SQL vs. NoSQL for project management systems?

Approach

1. Separate the models: relational databases store rows in tables with a fixed schema, foreign keys, joins and ACID transactions across tables; non-relational stores come in families (document, key-value, wide-column, graph), each built around one access pattern, usually denormalised and easier to partition horizontally, often with tunable or eventual consistency.
2. Argue from the data: project management is relational by nature (projects, tasks, assignees, milestones, budgets). Queries like overdue tasks per manager need joins and GROUP BY, and foreign keys stop a task from pointing at a deleted project. Default to PostgreSQL or SQL Server.
3. Name where NoSQL earns its place: a high-volume activity or audit feed, a key-value cache for sessions or computed dashboards, or documents with very irregular shape. Note that PostgreSQL JSONB with a GIN index covers per-project custom fields without leaving SQL.
4. Weigh the trade-offs: schema migrations cost effort but enforce integrity; schema-on-read moves validation into application code; denormalised copies must be updated in several places. For an internal tool, a single primary plus read replicas usually scales far enough.
5. Edge case: task dependencies form a graph, and a WITH RECURSIVE query walks a dependency chain in SQL. Reach for a graph database only if traversal becomes the main workload.

Follow-up

• How would you store custom fields that differ from one project to the next?
• Write the query that returns overdue tasks per assignee, including assignees with none.
• Where in this system would eventual consistency cause a visible bug?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

How do you ensure code accessibility, maintainability, and thorough documentation when delivering a web tool f

Medium · Applied Technical Skills & Development P

How do you ensure code accessibility, maintainability, and thorough documentation when delivering a web tool for non-technical internal users?

Approach

1. Pick an accessibility target and say how you meet it: WCAG 2.1 AA, semantic HTML (a real button, not a clickable div), labels tied to inputs, full keyboard operation with a visible focus ring, text contrast of at least 4.5:1 (3:1 for large text), and status never shown by colour alone. Use ARIA only where no native element does the job.
2. Test accessibility rather than assuming it: run automated checks (axe, Lighthouse) in CI, then do a manual keyboard pass and a screen-reader pass (NVDA or VoiceOver), because automated tools catch only part of the issues.
3. Build in maintainability: TypeScript or type hints, small single-purpose components, business logic kept out of UI code and unit tested, linting and formatting enforced in CI, pinned dependencies, and code review on every change.
4. Write documentation in layers for different readers: task-based user help with screenshots, plain-language error messages that say what to do next, in-app hints, then a README with setup steps, an architecture overview, decision records and generated API docs for developers.
5. Before release, run a short usability session with a few real users, then keep a feedback channel and a changelog. For data-heavy screens, offer pagination, sorting and CSV export, because non-technical users often take the data into spreadsheets.

Follow-up

• How do you keep documentation from going stale after the first release?
• How would you make a custom drag-and-drop widget usable from the keyboard?
• What would you hand over if you left the project tomorrow?

Can you explain your typical Git workflow when working on a multi-developer feature branch?

Medium · Applied Technical Skills & Development P

Approach

1. Lay out the branch structure: branch from an up-to-date main. On a shared feature branch, each developer works on a short-lived sub-branch and opens pull requests into it. Commits stay small, each with a message that says why the change was made.
2. Keep history safe: rebase only your own unpublished commits (git pull --rebase), never rewrite a branch others have pulled, and bring main into the shared branch with a merge, or with a rebase the whole team agrees on. If you must force-push a personal branch, use --force-with-lease, which refuses when the remote has moved since your last fetch.
3. Gate merges: CI runs tests and lint on every push, branch protection requires review and green checks on main and the feature branch. Know the merge options: squash gives a clean history but loses individual commits; a merge commit keeps the full record; rebase-merge keeps the history linear.
4. Resolve conflicts locally, rerun the tests, and talk to the other author when the conflict is in logic rather than formatting. Merge often to keep conflicts small, and use feature flags so incomplete work can reach main without long-lived branches.
5. Know recovery: git revert undoes published commits safely, git reset is for local work only, and git reflog recovers commits that a bad rebase or reset appeared to lose.

Follow-up

• Someone force-pushed the shared branch and your commits vanished. How do you recover them?
• Would you squash-merge or keep merge commits on this team, and why?
• How would you ship a half-finished feature without keeping a branch open for weeks?

What considerations do you make for data validation and error handling when building APIs?

Medium · Applied Technical Skills & Development P

Approach

1. Validate at the boundary: check path, query and body against a schema (types, required fields, lengths, ranges, enums), parse into typed objects, and pick a policy for unknown fields. Business rules (end date after start date, referenced project exists, caller may edit it) go in the service layer.
2. Use status codes consistently: 400 for malformed input, 401 unauthenticated, 403 forbidden, 404 missing, 409 for conflicts or duplicates, 422 for well-formed input that fails semantic validation, 429 for rate limits, 5xx only for server faults. Return one error shape (RFC 9457 problem details) with field-level messages and a request id.
3. Handle security as part of validation: bind parameters instead of string-built SQL, payload size limits, authorisation checked per resource and not just per route, and no stack traces or internal ids leaked in error bodies.
4. Make retries safe: PUT and DELETE are idempotent by definition, and POST can be made so with an idempotency key. Use ETag with If-Match for optimistic concurrency, returning 412 when the version is stale.
5. Make failures observable: structured logs carrying the request id, separate metrics for 4xx and 5xx, and timeouts with retry and backoff on downstream calls so one slow dependency does not hang every request.

Follow-up

• When would you return 400 and when 422?
• A client times out on a POST and retries. How do you avoid creating the record twice?
• A bulk upload has 1,000 rows and 12 are invalid. Do you reject the whole batch or accept part of it?

Walk me through the technical architecture of your final year university capstone project or a recent complex

Medium · Project Experience & CV Deep Dives

Walk me through the technical architecture of your final year university capstone project or a recent complex internship project.

Approach

1. Open with the problem and the users in one or two sentences, then walk the architecture in layers (client, API or service, data store, external integrations, deployment), then trace one real request end to end through it.
2. Separate your own work from the team's by using "I" for what you built and naming teammates' parts. Every technology you name should come with the alternative you rejected and why.
3. Pick one hard trade-off (data model, sync versus async, hosting choice), what you measured or observed, and what went wrong. Only quote numbers you can defend.
4. Prepare to go one level deeper on every box: the schema and key indexes, how auth works, how it was tested, how it was deployed, and what you would rebuild now.
5. Keep a short version and a long version. Start with the short one and expand only the part the conversation turns to, rather than reciting everything.

Follow-up

• Why that database and not another one?
• What breaks first if usage grows a hundredfold?
• What would you design differently if you started it again today?

What was the most significant technical challenge you encountered in your previous role, and how did you resol

Medium · Project Experience & CV Deep Dives

What was the most significant technical challenge you encountered in your previous role, and how did you resolve it?

Approach

1. Choose a problem that was technically hard rather than just tedious (an intermittent bug, a performance wall, a painful integration), and state the symptom and the constraints (deadline, access, data) quickly.
2. Spend most of the answer on diagnosis: the hypotheses you formed, and how you confirmed or ruled out each one (reproduction, logs, profiler, git bisect, a minimal test case).
3. Explain the fix and the alternatives you rejected, with the trade-off behind the choice: time, risk, or how much code it touched.
4. Close with a result you can check (error rate, runtime, tickets) and what you put in place to stop it recurring: a regression test, monitoring or documentation.
5. The mistake that sinks it is a team story told entirely in the plural, where your own decisions never come through.

Follow-up

• How did you know you had the root cause and not just a symptom?
• What would you have done if your first fix had not worked?
• What did you change afterwards so the same class of problem could not come back?

What specific programming languages and digital engineering frameworks did you utilize in your previous projec

Medium · Project Experience & CV Deep Dives

What specific programming languages and digital engineering frameworks did you utilize in your previous projects?

Approach

1. Answer by project, not as a list: for each language or framework, say what you built with it and at what depth (shipped to users, coursework, brief exposure).
2. Connect your experience to what candidates report this role lists: Python, C#, JavaScript/TypeScript, Java or C++; SQL with PostgreSQL or SQL Server; React, Angular, Vue, .NET Core, Node.js or Django; GIS or CAD APIs; AWS, Azure or GCP and Docker. Only claim the ones you can defend.
3. Have one non-obvious detail ready for each tool you claim. In standard CPython the GIL stops threads running Python bytecode in parallel, so CPU-bound work uses multiprocessing. Python default arguments are evaluated once, at definition. LINQ queries in C# run lazily, when enumerated. JavaScript runs callbacks from an event loop.
4. Be honest about gaps, and show how you learn: a recent tool you picked up, how you did it (docs, a small project, reading source), and how long it took before you were productive.

Follow-up

• Explain something in your main language that surprised you when you first ran into it.
• Why did you choose that framework over its closest alternative?
• How would you get productive in C# or a GIS library you have not used before?

How have you applied custom automation or scripting to streamline manual or repetitive tasks in past projects?

Medium · Project Experience & CV Deep Dives

Approach

1. Set up the story: the manual task, how often it ran, who did it, and what it cost in time or errors. Then the automation itself (script, scheduled job, plugin, small web tool) and the language you used.
2. Show the engineering behind the script: inputs validated before anything runs, a dry-run mode, idempotent re-runs, clear logging, configuration instead of hard-coded paths, and the script in version control with tests.
3. Explain how you checked correctness: run the automated output alongside the manual output on real cases and compare them before switching over.
4. Quantify the result with numbers you actually measured (hours saved, errors avoided), and say how non-developers ran it and what documentation they got.
5. Mention what you left manual on purpose, such as rare or judgment-heavy steps, because that shows you considered the cost of automating as well as the benefit.

Follow-up

• What happens when the script fails halfway through a run?
• How did you convince people to trust its output over doing it by hand?
• Who maintains it now, and what did you leave them?

Can you explain how you made architectural tradeoffs between delivery speed and technical debt in a past initi

Medium · Project Experience & CV Deep Dives

Can you explain how you made architectural tradeoffs between delivery speed and technical debt in a past initiative?

Approach

1. Give the context: the deadline or constraint, the options on the table, and who had a stake in the decision.
2. Show the debt was deliberate (Fowler's deliberate/prudent quadrant): name the shortcut, why it was acceptable (isolated behind an interface, easy to reverse), and what you refused to compromise (data integrity, security, tests on the core path).
3. Say how you recorded it: a ticket or decision record with a trigger for repayment, such as a second customer or usage passing a threshold, so it did not quietly become permanent.
4. Close the loop: was it paid back, what did carrying it cost, and what you would decide differently now. An honest "it cost more than I expected" makes the answer more credible.

Follow-up

• How did you get time approved to pay the debt back?
• Which shortcut would you refuse even under heavy deadline pressure?
• How did you tell when the debt had become more expensive than fixing it?

How would you design an interactive 2D canvas application that allows users to manipulate objects and render l

Medium · Technical Scenarios & Applied Problem So

How would you design an interactive 2D canvas application that allows users to manipulate objects and render layout geometry?

Approach

1. Pin down requirements first: shape types (lines, polylines, polygons, text), operations (select, move, rotate, scale, snap, undo/redo), expected object count, units and precision, persistence and export formats, and whether several users edit at once.
2. Separate the model from the view: keep a document model of shapes in world units (for example millimetres), each with its own transform, plus a view transform for pan and zoom (screen = world x scale + offset). Rendering reads the model and never owns it, and the model serialises to JSON.
3. Choose the renderer by scale: SVG gives DOM hit-testing and accessibility but slows with many thousands of nodes; Canvas 2D is immediate-mode, so you write your own hit-testing; WebGL suits very large scenes. Redraw on requestAnimationFrame, use layered canvases (static geometry versus selection overlay), and scale by devicePixelRatio for sharp lines.
4. For interaction, hit-test with bounding boxes first, then exact geometry (ray-casting point-in-polygon, point-to-segment distance), with a quadtree or R-tree so a click checks a few candidates instead of all n shapes. Snap to grid and vertices, and handle dragging with a small state machine.
5. Implement undo/redo with the command pattern (each action knows how to apply and revert itself) or with immutable snapshots, trading complexity against memory. Autosave and export (SVG, DXF) come from the same model.

Follow-up

• How would you keep panning smooth with 50,000 shapes on screen?
• How would you add real-time editing by several users, and how would you resolve conflicting edits?
• How would a keyboard-only user select and move a shape?

What steps would you take to integrate custom code with third-party APIs or design automation tools?

Medium · Technical Scenarios & Applied Problem So

Approach

1. Read the contract before writing code: authentication (OAuth 2.0 client credentials or API keys), rate limits, pagination, versioning and deprecation policy, data formats, and SDK versus raw HTTP. For desktop CAD or BIM plugins, find out whether the host requires model changes inside its own transaction and on its main thread.
2. Wrap the vendor behind your own adapter interface (an anti-corruption layer) that maps their models to yours. Vendor changes then stay in one module, and tests can swap in a fake.
3. Build in resilience: timeouts on every call, retries with exponential backoff and jitter only for idempotent or keyed requests, honour 429 and Retry-After, a circuit breaker for a failing dependency, and a queue for long-running jobs.
4. Handle secrets and access: credentials in a secret store or environment, never in the repo; the smallest scopes that work; request logs with correlation ids but no tokens.
5. Test and monitor: contract tests against recorded responses, a vendor sandbox where one exists, pinned SDK versions, and alerts on error rate so silent format changes surface quickly.

Follow-up

• The API allows 100 requests per minute and you need to sync 50,000 records. How do you design the sync?
• The vendor changes a response field without notice. How would you find out?
• How do you test the integration without calling the real service in CI?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.

Approach

1. Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
2. Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
3. Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
4. Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.

Follow-up

• The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
• You now count takeovers. What alert fires on that counter, and at what threshold?

Suggested practice checklist

The plan starts with your own projects, since resume depth is reported as central, then covers the reported fundamentals, the practical scenarios, and the behavioral stories, and ends with a full mock.

Day 1 — Inventory your projects and tools

• List every project and technology on your resume and write a one-paragraph summary of each: goal, your role, stack, hardest problem.
• Answer aloud the question about which programming languages and digital engineering frameworks you used, naming one concrete use of each.

Deliverable: A project inventory with a one-paragraph summary per project, plus a recorded spoken answer on languages and frameworks.

Day 2 — Architecture and challenge stories

• Prepare the capstone or internship architecture walk-through with a diagram of components, data flow and storage.
• Write the most significant technical challenge story: symptom, diagnosis, fix, result.
• Prepare the speed versus technical debt story with the decision, its cost and what you would do now.

Deliverable: A diagram, two written outlines and a timed spoken run of each.

Day 3 — Databases, SQL, Git and validation

• Write a comparison of relational and non-relational stores for a project management system, with your pick and reasons.
• Do the hands-on SQL: write the overdue-tasks-per-assignee query with LEFT JOIN and GROUP BY so assignees with none still appear, then a project-status aggregation filtered by a spatial bounding box or ST_DWithin in PostGIS.
• Write out your feature-branch workflow with the exact commands and a conflict example.
• Write a JSON configuration validator in your strongest language, covering missing fields, wrong types and out-of-range values, with unit tests, then list the validation and error-handling rules you apply when building an API.

Deliverable: A written database comparison, two working SQL queries, a branch workflow cheat sheet, a tested validator and an API error-handling checklist.

Day 4 — Web tool quality, 2D canvas and performance

• Write your checklist for an accessible, documented internal web tool: keyboard use, labels, contrast, README, comments, tests.
• Outline a 2D canvas design: object model, hit testing, transforms, redraw strategy and undo.
• Write a diagnosis sequence for a slow internal application: reproduce, measure, find the biggest cost, fix, re-measure.

Deliverable: An accessibility and documentation checklist, a canvas design outline and a performance diagnosis runbook.

Day 5 — Data batches, integrations, cloud and automation

• Write the step sequence for processing an incoming batch of sensor or field survey data: intake, validate, clean, store, report.
• Outline how you would integrate custom code with a third-party API or design automation tool: authentication, rate limits, retries, versioning, tests against a sandbox.
• Outline a cloud backend for hundreds of concurrent engineers uploading design files: presigned URLs to blob storage (S3 or Azure Blob), multipart or resumable uploads, a metadata row in SQL, virus scanning and processing through a queue, and versioning.
• Pick a scripting project of your own and prepare it as a before-and-after story.

Deliverable: A pipeline outline, an integration checklist, a cloud upload design on one page and a written automation story with measured results.

Day 6 — Behavioral stories

• Write situation, task, action, result outlines for changing requirements, a technical disagreement, explaining to non-technical stakeholders and a project that missed its plan.
• Write your answer on why AECOM and how infrastructure technology fits your career plan, then outline how you prioritise multiple deadlines.
• Say each story aloud and trim until it is short and ends with a result.

Deliverable: Six story outlines and a recorded spoken version of each.

Day 7 — Presentation and full mock

• Build and deliver a short presentation on a technical approach, for example a custom 2D canvas drawing tool, leaving time for questions.
• Run a mock panel: a friend asks about your resume, the database and Git answers, a scenario and a behavioral question.
• List gaps, fix the top two and prepare your questions for the team.

Deliverable: A presentation with speaker notes, a mock recording, a gap list and a final list of questions for the team.

Behavioural preparation

Candidates describe the behavioral questions as centred on communication and teamwork across disciplines: civil engineers, project managers, digital leads and clients. Reported themes include technical disagreements, explaining complex material to non-technical people, shifting requirements and learning from a project that went wrong. Prepare stories where you made decisions and show the result.

1. How do you prioritize your workload when managing multiple tight deadlines across concurrent projects?

How do you handle situations where business requirements from non-technical stakeholders are ambiguous or chan

Medium · Technical Scenarios & Applied Problem So

How do you handle situations where business requirements from non-technical stakeholders are ambiguous or changing?

Approach

1. Choose a story where requirements were genuinely unclear or moved, ideally with a non-technical sponsor such as a project manager or domain engineer. State the situation in two sentences, then spend the time on what you did.
2. Show the sequence: ask clarifying questions about the underlying goal and users, write the requirements down as a short spec or acceptance criteria, and confirm them with the stakeholder in writing before building.
3. Describe how you contained change: deliver in small increments, show a working prototype early, keep a change log, and tell the stakeholder the cost of each change in effort and schedule so they can prioritise.
4. Close with the result in concrete terms (what shipped, what was cut, how the stakeholder reacted) and one habit you kept afterwards. The mistake that sinks this answer is blaming the stakeholder or saying you simply built whatever was asked.

Follow-up

• How did you decide which late change to accept and which to push back on?
• How did you record agreed requirements so they could not be disputed later?
• What would you do if the stakeholder could not describe what they wanted at all?

Why do you want to work as a Software Engineer at AECOM, and how does infrastructure technology fit into your

Medium · Behavioral, Culture Fit & Career Goals

Why do you want to work as a Software Engineer at AECOM, and how does infrastructure technology fit into your long-term career plan?

Approach

1. Make the answer specific to infrastructure software. Candidates report that software engineers at AECOM build things like geospatial data pipelines, automated design tools, BIM integrations and web apps for engineers, so pick the area closest to your experience and say why it interests you.
2. Link it to evidence from your own record: a project, course or scripting task where you built something for non-software users, with the result it had. This turns motivation into something checkable.
3. Give a believable career direction: skills you want to grow (for example spatial data handling or integrating with design software) and how this role gives you a way to learn them. Avoid generic praise for a big company or the brand.
4. Show that you researched the work: refer to a type of project or the reported evaluation themes of safety, sustainability and innovation only where they connect honestly to your interests, and end with a question for the team.

Follow-up

• Which kind of project, such as geospatial, BIM or internal tools, would you most want to work on, and why?
• Where do you want your skills to be in a few years, and what would you need to learn first?
• What would you do if the team's stack differs from the one you know best?

Tell me about a time you experienced a technical disagreement with a team member. How did you handle it and re

Medium · Behavioral, Culture Fit & Career Goals

Tell me about a time you experienced a technical disagreement with a team member. How did you handle it and reach a resolution?

Approach

1. Pick a real technical disagreement with stakes, such as a data model, a branching strategy, a library choice or a design pattern, and name both positions fairly. If you cannot state the other person's argument well, the story will sound one-sided.
2. Explain how you moved from opinion to evidence: a small prototype, a benchmark, a written comparison of trade-offs, a design note or a code review thread. Say which criteria you agreed on first, for example maintainability, delivery date, or performance.
3. State the outcome honestly, whether you were right, partly right or wrong, and what the team did next. A compromise or changing your mind is a good result if you can explain the reasoning.
4. End with the relationship and the lesson. The mistake that sinks it is casting the colleague as a villain or presenting the outcome as you winning.

Follow-up

• What would you have done if the two of you still could not agree?
• Did you ever turn out to be wrong in that disagreement, and how did you react?
• How did you work with that colleague afterwards?

Describe a situation where you had to present complex technical information to non-technical stakeholders or c

Medium · Behavioral, Culture Fit & Career Goals

Describe a situation where you had to present complex technical information to non-technical stakeholders or clients.

Approach

1. Choose an audience like the ones in this role: a civil engineer, project manager or client. Say who they were, what decision they needed to make, and why the technical detail mattered to them.
2. Describe how you adapted: lead with the decision or impact, replace jargon with plain terms or an analogy, use a diagram, a demo or a worked example, and cut everything that did not change their decision.
3. Show how you checked understanding, for example by asking them to restate the trade-off or the limitation, and what you sent in writing afterwards.
4. State the result: the decision made, the misunderstanding avoided or the scope adjusted. The mistake that sinks this answer is describing a long technical explanation with no sign the audience followed it.

Follow-up

• How would you change the explanation for an executive compared with a project engineer?
• What did you do when they asked a question you could not answer?
• How did you know they had understood the limitation you were describing?

Describe a time when a project or deliverable did not go as planned. What did you learn from that experience?

Medium · Behavioral, Culture Fit & Career Goals

Approach

1. Choose a project where you owned a real part of the miss, such as a missed deadline, a wrong estimate, a failed release or a rework. A story with no personal responsibility is the common way this answer fails.
2. Explain the cause precisely: what signal you missed or what assumption was wrong, and when you noticed. Then show your recovery steps, such as telling the stakeholder early, reducing scope, adding tests or splitting the work.
3. Give the outcome with numbers or concrete facts where you have them: what shipped, what slipped, what it cost.
4. Finish with a lesson that changed your behaviour afterwards, a specific practice such as earlier demos, a risk log or smaller releases, and show where you applied it later. A vague lesson such as communicating more is not enough.

Follow-up

• When did you first realise it was going wrong, and what did you do then?
• How did you tell the stakeholders, and how did they respond?
• What would you do differently if you ran the project again?