Interview guides · Asplundh Tree Expert

Asplundh Tree Expert Software Engineer Interview Guide

Asplundh Tree Expert Software Engineer interview guide: the 3 reported rounds, answers to 10 reported questions, and a 7-day prep plan.

The 60-second brief

Asplundh Tree Expert works in utility vegetation management, and candidate reports describe its operations as supporting power-grid reliability across North America with a large, distributed field workforce. Software engineers there build the systems that connect what crews do in the field with the company's enterprise data. The typical projects candidates describe are custom data visualization tools, integrations between older internal systems and cloud platforms, and automation of reporting that is still done by hand. Engineers are reported to work alongside project managers and operations staff, so much of the software has non-engineers as its users.

This guide is for a Software Engineer interviewing at Asplundh Tree Expert. The requirements candidates describe ask for Python, Java or C#, a solid grasp of SQL and database design, and Git, with AWS or Azure, mobile-first development and data visualization tools as extras; most successful candidates are reported to have roughly 3-7 years of experience. It covers the three reported rounds, approaches to the five technical and five behavioral questions candidates report, the domain topics in the reported topic breakdown, and a week of practice that produces spoken answers, a design outline and a story bank.

Candidates report three rounds over roughly 3-5 weeks: a recruiter screen, technical deep-dives with engineering leads, and behavioral interviews.

Focus areas

Software Engineering
Physical Substation Design (Domain)
Transaction Matching (Cash Applications)

Overview

The work candidates describe sits between field crews and back-office data: getting records from people working outdoors into systems that managers, finance and operations can query and chart. That shapes preparation. A design answer for this role has to cope with devices that lose connectivity, data that arrives late or twice, and older systems that cannot be replaced overnight. Candidates also report a tip to show how a technical solution helped an operations team in the field, so each project you bring should end with what changed for the people using it.

The reported technical questions are experience questions rather than puzzles: how you designed ingestion for high-volume data from remote field locations, how you debug a production issue in a distributed system, how you keep code maintainable in a team, how you integrate new tools with legacy infrastructure, and the monolith-versus-microservices trade-offs on a project you led. Each needs a real system from your past, with numbers, a decision and a consequence. Candidates also describe the technical assessment as a mix of architecture discussion and practical coding problems, so practise writing clean, working code in your main language as well as talking through designs.

The stack candidates list is ordinary enterprise engineering: Python, Java or C#, SQL with database design, Git, and some exposure to AWS or Azure. Reported example scenarios include tuning a database query that causes latency under heavy traffic, refactoring a large part of a codebase safely, and making software usable for field teams with limited connectivity. Rehearse an EXPLAIN-driven query tuning walkthrough and an offline-first sync design before anything else.

The reported topic breakdown also lists domain areas: Physical Substation Design, Transaction Matching (Cash Applications), Electrical Infrastructure Knowledge and Senior-Level Software Development. You do not need to be an electrical engineer, but you should be able to follow a question that uses substation or grid vocabulary, and you should be able to code a matching routine that pairs incoming payments with open invoices by reference and amount, with a tolerance and a clear rule for partial and unmatched items.

The Asplundh Tree Expert interview process

These are the three stages candidates report, in the order they describe them; candidates also note that the timeline can move depending on the hiring team.

Recruiter Screen

Candidates report a first conversation with a recruiter about background and fit for the role. Treat it as a check of your experience against the listed requirements: say plainly which of Python, Java or C# you work in, how much SQL and database design you have done, and whether you have touched AWS or Azure. Have one sentence on why software for field operations interests you, and use the end of the call to learn what the technical deep-dives contain, including whether a coding problem is part of them.

What to demonstrate

Background against the reported requirements: language, SQL and database design, Git, cloud exposure
Fit for the role and motivation for operational, field-facing software
Logistics such as location, remote or hybrid setup and timing

How to prepare

Write a two-minute walkthrough of your experience that names your main language, one database you designed or tuned, and one integration with an older system.
Prepare a one-sentence answer on why you want to build software used by field and operations teams, tied to a project where users were not engineers.
List questions for the recruiter: the format of the technical deep-dives, whether live coding is included, which team the role sits in, and the remote or hybrid arrangement.

Technical Deep-Dives

Candidates report in-depth technical interviews with engineering leads, and describe the technical assessment as a mix of architectural design discussion and practical coding problems. The reported technical questions are about systems you have built, so come with two or three projects you can explain in depth: components, data flow, the volumes involved, what failed and what you changed. When you code, write readable code in your main language and explain the design choices as you go.

What to demonstrate

Depth of technical competency in your own stack and past systems
Architecture reasoning and the trade-offs you state for a design
Working, readable code on practical problems

How to prepare

Rehearse aloud the design-type questions candidates report: field data ingestion, legacy integration, and monolith versus microservices on a project you led, each with numbers from your own work.
Practise one query tuning walkthrough end to end: read an EXPLAIN plan, spot a sequential scan or a fan-out join, add or change an index, and measure again.
Solve two or three practical coding problems in Python, Java or C# with tests, including a payment-to-invoice matching routine for the transaction matching topic.

Behavioral Interviews

Candidates report behavioral interviews about alignment with company values and potential for growth, and report reliability, safety and practical problem-solving as values that come up. The behavioral questions candidates report cover explaining technical issues to non-technical people, competing priorities, acting on feedback, cross-functional collaboration and technical disagreements. Answer each with a specific story in STAR form, with your own actions in the first person singular and a result you can measure.

What to demonstrate

Communication with non-technical stakeholders and operations users
Judgement on priorities, feedback and disagreement
Alignment with the reported values and room to grow in the role

How to prepare

Build a bank of five STAR stories, one per reported behavioral question, each ending in a measured result.
Make at least one story about software that changed something for an operations or field team, since candidates report that link as a focus.
Prepare one story about reliability: an incident you handled or prevented, and the test or monitoring you added afterwards.

Where candidates lose points

Designing the field-data ingestion system as if devices are always online.

Put offline-first behaviour at the centre of the answer: a local store with client-generated ids, an outbox with retry and backoff, server-side deduplication, and a stated rule for late and conflicting records.

Answering the monolith-versus-microservices question in the abstract instead of for a project you led.

Name the project, give team size, deploy frequency and traffic, state what you chose and why, and say what you would change now. Generic pros and cons do not answer the question as asked.

Jumping straight to the fix in the distributed debugging question.

Rehearse the sequence: mitigate, build a timeline of changes, localise with metrics and trace ids, test one hypothesis at a time, then fix, add a regression test and an alert.

Behavioral stories told in the plural, ending in 'it went well'.

Say what you personally did in the first person singular and end with a measured result. For each of the five reported behavioral questions, write the result line before rehearsing the rest.

Freezing when a question uses the reported domain topics such as substations or cash application matching.

Learn the basic vocabulary of substations and grid equipment, and code a payment-to-invoice matching routine once, so you can reason through a domain question instead of guessing.

Questions & practice

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
Where does the fingerprint get computed relative to request decompression and the body-size limit?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
How do you honour an erasure request while resource_revision.actor_user_id still references this table?

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

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.
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.
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.
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 have you designed a system to handle high-volume data inputs from remote field locations?

Medium · Technical and Domain Expertise

Approach

Open with the shape of the input: what the field devices send (work records, GPS points, photos, forms), how many devices, peak records per hour, and how long a crew can be offline. These numbers decide everything else.
Design the client offline-first: write every record to a local store such as SQLite with a client-generated UUID, and keep an outbox that uploads in compressed batches with exponential backoff and jitter once a connection returns.
On the server, accept batches at an API endpoint that does only validation and enqueueing to a durable queue (Kafka, SQS, Azure Service Bus or Event Hubs). Consumers dedupe on the record UUID, so a retried upload cannot create duplicates, then write raw payloads to object storage and cleaned rows to the relational database.
Handle time explicitly: store device time and server receipt time, expect out-of-order and days-late arrivals, and pick a conflict rule for records edited on two devices (server-authoritative or per-field last-writer-wins) and say what it loses.
Close with operations: per-device last-sync time, queue lag and rejection counts as metrics, plus a versioned payload schema so old app versions in the field keep working while new ones roll out.

Follow-up

A crew has been offline for three days and uploads ten thousand records at once. What happens to the queue and to the reports downstream?
Two devices edited the same work order while offline. Which version wins, and how does anyone find out about the conflict?
How do you change the payload format while older app versions are still installed on field devices?

What strategies do you use to ensure code quality and maintainability in a team environment?

Medium · Technical and Domain Expertise

Approach

Describe the review practice: small pull requests, a short checklist (tests, naming, error handling, migrations), and a protected main branch in Git that requires review and a green build.
Describe the automated gates in CI: formatter and linter for the language (ruff or black for Python, Checkstyle or SpotBugs for Java, analyzers and dotnet format for C#), type checks where available, and unit plus integration tests against a real database in a container.
Explain the testing shape and its trade-off: many fast unit tests, fewer integration tests on the database and external APIs, very few end-to-end tests, and a rule that flaky tests are fixed or quarantined the same week.
Cover maintainability beyond tooling: short architecture decision records, a tracked list of technical debt with a share of each cycle spent on it, and characterization tests before touching untested legacy code.
Anchor it in one example with a number: fewer production defects, shorter review time, or a module that became safe to change.

Follow-up

A teammate opens a two-thousand-line pull request before a deadline. What do you do?
You inherit a module with no tests that has to change this sprint. Where do you start?
How would you know whether these practices are paying for the time they cost?

How do you approach integrating new software tools with existing legacy infrastructure?

Medium · Technical and Domain Expertise

Approach

Start by mapping the legacy system: its interfaces (database tables, file drops, SOAP or REST endpoints, nightly batch exports), who owns it, how it fails, and what must never break for its current users.
Isolate it behind an adapter or anti-corruption layer so the new tool speaks its own model and only one component translates to the legacy format.
Pick the integration pattern and say why: change data capture from the legacy database, polling an API, or consuming file exports. Avoid writing directly into a database you do not own.
Make the sync idempotent and verifiable: stable record keys, safe retries, and a reconciliation job that compares counts or checksums between the two systems and reports differences.
Migrate gradually with a strangler approach: run the new path in shadow mode, compare outputs, switch traffic behind a feature flag, and keep a tested rollback until the old path can be retired.

Follow-up

The legacy system only offers a nightly CSV export. How do you give users data that is fresher than a day?
After cutover, how do you prove the old and new systems agree?
The vendor changes the export format without notice. What breaks, and what would have caught it?

Explain the trade-offs between a monolithic and a microservices architecture for a project you led.

Medium · Technical and Domain Expertise

Approach

Use a real project you led and set the context in numbers: team size, deploy frequency, number of distinct business domains, and traffic. The right answer depends on these, not on fashion.
Give the monolith side fairly: one deploy, in-process calls, local database transactions and easy refactoring; the costs are coupled releases, scaling everything together and a codebase that gets harder to own as the team grows.
Give the microservices side fairly: independent deploys and scaling, fault isolation and team ownership; the costs are network failures, distributed transactions (sagas or the outbox pattern), per-service observability and more operational work.
Mention the modular monolith as the middle path: clear module boundaries inside one deployable, split later along boundaries that have proven stable.
State what you chose, the evidence behind it, what went wrong, and what you would change now.

Follow-up

How did you decide where one service ends and the next begins?
How did you handle an operation that had to update data owned by two services?
What would make you merge two services back together?

Describe your process for debugging a production issue in a distributed system.

Medium · Technical and Domain Expertise

Approach

Start with impact and mitigation before diagnosis: who is affected, how badly, and whether a rollback, feature flag or traffic shift stops the damage while I investigate.
Build a timeline of what changed: deploys, config changes, traffic shape, dependency incidents, certificate or credential expiry. Line it up against when the error rate or latency moved.
Localise the failure with request-rate, error and latency metrics per service, then follow a correlation or trace id across service logs to find the first hop that misbehaves rather than the one that reports it.
Test one hypothesis at a time with a check that rules something out either way, and watch for distributed-specific causes: retries amplifying load, mismatched timeouts, a growing queue backlog, clock skew in timestamps, or a partial failure where one replica is bad.
Finish properly: reproduce if possible, fix, add a regression test and an alert that would have caught it earlier, and write a short blameless postmortem.

Follow-up

The system has no distributed tracing. How do you correlate one request across services?
The issue only appears in production and only a few times a day. What do you add to catch it next time?
How do you tell whether the deploy that coincided with the incident actually caused it?

Suggested practice checklist

Each day targets one part of the reported loop: the recruiter screen, the five technical questions, SQL and the reported domain topics, the five behavioral questions, and a final mock.

Day 1 — Recruiter screen and domain basics

Write a two-minute walkthrough of your experience naming your main language among Python, Java or C#, one database you designed or tuned, and any AWS or Azure work.
Write your questions for the recruiter: the format of the technical deep-dives, whether coding is live, and the remote or hybrid setup.
Read an introduction to utility vegetation management and to what a substation contains, and note ten terms you can define.

Deliverable: A timed two-minute walkthrough, a list of recruiter questions, and a ten-term domain glossary.

Day 2 — Field data ingestion design

Write an outline for the high-volume field-data question: client outbox, ingestion endpoint, queue, deduplicating consumers, raw and relational storage, metrics.
Solve the bounded-lateness stream merge practice problem and connect it to late-arriving field records.
Solve the redelivered-batch high-water-mark problem and explain how it prevents double-applied uploads.

Deliverable: A one-page ingestion design outline and two working coding solutions with tests.

Day 3 — Legacy integration and architecture trade-offs

Outline your answer to the legacy integration question using a system you actually worked with: interfaces, adapter, sync pattern, reconciliation, cutover.
Prepare the monolith-versus-microservices answer for a project you led, with team size, deploy frequency and the decision you made.
Solve the idempotency fingerprint practice problem and tie it to safe retries between old and new systems.

Deliverable: Two spoken answers recorded under your own time limit and one working idempotency solution.

Day 4 — SQL, query tuning and transaction matching

Take a slow query on a sample dataset, read its EXPLAIN plan, add an index or rewrite the join, and record the before and after timings.
Solve the soft-deleted re-registration and the join fan-out practice problems.
Code a routine that matches incoming payments to open invoices by reference, then by amount within a tolerance, and reports partial and unmatched items.

Deliverable: A written before-and-after tuning note, two SQL solutions, and a tested matching routine.

Day 5 — Debugging and code quality

Write the debugging answer as a numbered sequence around one real incident you handled, including the alert you added afterwards.
Prepare the code quality answer with the exact review rules, CI checks and test layout from a team you worked on, plus one number showing the effect.
Answer both aloud and cut anything that is not tied to your example.

Deliverable: Two rehearsed answers, each anchored in a real incident or team with a measured result.

Day 6 — Behavioral story bank

Write a STAR story for each of the five reported behavioral questions, each ending in a measured result.
Make sure at least one story shows software that changed something for operations or field users, and one shows a reliability or safety concern you handled.
Rehearse each aloud and replace every plural account of the work with what you did yourself.

Deliverable: Five written STAR stories with result lines, rehearsed aloud.

Day 7 — Full mock of the loop

Run a mock with a friend: recruiter walkthrough, one design question, one coding problem, and two behavioral questions.
Note every answer that lacked a number or a decision and fix those lines.
Write three questions to ask engineering leads, such as how the team balances new tools with maintaining older systems.

Deliverable: A completed mock with a list of fixed answers and three questions for the interviewers.

Behavioural preparation

Candidates report behavioral interviews about alignment with company values and growth potential, with reliability, safety and practical problem-solving named as values. The reported behavioral questions all concern working with people: non-technical stakeholders, competing projects, feedback, cross-functional teams and disagreements. Candidates also report a tip to show how your software helped operational teams in the field, so give at least one story that ends with a change for those users.

Tell me about a time you had to pivot your technical approach due to changing business requirements.