Arizona State University Software Engineer Interview Guide

The 60-second brief

As a Software Engineer at Arizona State University, you play a vital role in building and sustaining the technological infrastructure that drives a world-class educational institution. This position is central to designing, developing, and troubleshooting complex software applications, enterprise systems, and automated workflows that empower students, faculty, and staff across the university community. Whether you are building robust APIs, automating network orchestration, or developing dynamic web applications, your work directly impacts millions of interactions and operational processes. The scope of this role spans multiple dynamic technological domains within the institution, including Enterprise Technology, Business and Finance Information Technology, and Educational Outreach and Student Services.

This guide is scoped to a Software Engineer candidate at Arizona State University.

Focus areas

• Git (version control)
• Python (development and scripting)
• Data structures

The Arizona State University interview process

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

Recruiter Screening

Initial contact to discuss background, qualifications, and mutual fit.

What to demonstrate

• Initial contact to discuss background, qualifications, and mutual fit
• Depth in Git (version control)

How to prepare

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

Technical Evaluations

Includes a practical take-home design challenge and conceptual knowledge checks.

What to demonstrate

• Includes a practical take-home design challenge and conceptual knowledge checks
• Depth in Git (version control)

How to prepare

• Answer aloud and timed: These inquiries test your core programming skills, database management, and familiarity with required frameworks. How do you convert software specification requirements into programming languages like Python or C#? Can you write a basic SQL query to retrieve and analyze output data patterns? What is your experience with IAM management concepts and identity security? How do you implement automated testing, such as unit testing and integration testing, in your web applications?
• Answer aloud and timed: These questions explore your communication style, past work experience, and alignment with a customer-focused institutional culture. How do you handle a situation where system requirements are ambiguous or conflicting? Can you describe a past project where you had to present technical applications to non-tech personnel? How do you prioritize tasks when supporting end users who report critical software failures? What does working in a values-driven, collaborative team environment mean to you?

All-Team Panel Interview

Present past work, discuss hypothetical scenarios, and interact with team members.

What to demonstrate

• Present past work, discuss hypothetical scenarios, and interact with team members
• Depth in Git (version control)

How to prepare

• Work Git (version control) until you can explain it without notes
• Work Python (development and scripting) until you can explain it without notes

Where candidates lose points

Be descriptive in your explanations

Interviewers frequently highlight the importance of clear, detailed communication. When walking through a technical problem or a past project, explain your reasoning step by step rather than just giving the final answer.

Prepare for a presentation style discussion

Expect to discuss or present applications you have built. Practice explaining your work as if you are addressing a mixed audience of technical peers and non-technical management.

Brush up on your Git workflows

Given that version control and collaboration workflows appear frequently in screening discussions, make sure you are fully comfortable discussing branching strategies, rebasing, and resolving merge conflicts.

Emphasize user support and accessibility

Keep in mind that educational technology places a high value on usability and accessibility standards. Mentioning your commitment to building inclusive, user-friendly software will resonate strongly with your interviewers.

Questions & practice

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

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

Approach

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

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

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

1. 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.
2. 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.
3. 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.
4. 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?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

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

Approach

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

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

These inquiries test your core programming skills, database management, and familiarity with required framewor

Medium · Technical and Domain Knowledge

These inquiries test your core programming skills, database management, and familiarity with required frameworks. How do you convert software specification requirements into programming languages like Python or C#? Can you write a basic SQL query to retrieve and analyze output data patterns? What is your experience with IAM management concepts and identity security? How do you implement automated testing, such as unit testing and integration testing, in your web applications?

Approach

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

Follow-up

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

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

These questions assess your ability to design scalable systems, plan API integrations, and structure clean sof

Medium · System Design and Architecture

These questions assess your ability to design scalable systems, plan API integrations, and structure clean software solutions. How would you approach designing a design challenge assignment for a new application? Can you explain your experience with RESTful and SOAP based APIs? How do you document system architecture and solutions for both technical and non-technical stakeholders? What strategies do you use when evaluating third-party applications and vendor-supplied system software?

Approach

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

Follow-up

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

Relay committed events to the log without gaps or reordering

Medium · transactional outbox · at-least-once · ordering

outbox_event rows are written in the same transaction as the state change and carry aggregate_type, aggregate_id, aggregate_version, payload and status, with a partial index on (created_at, event_id) WHERE status = 'pending'. The relay publishes about 4k events/second to a partitioned append-only log keyed by aggregate_id, with one leader per partition range holding a lease. Consumers must never miss an event; they may see one twice. Design the claim-publish-mark loop, and state exactly what consumers observe when a leader's lease expires while it is mid-batch.

Approach

1. Claim with SELECT ... WHERE status='pending' ORDER BY created_at, event_id LIMIT $batch FOR UPDATE SKIP LOCKED inside a transaction. SKIP LOCKED lets several relay workers share a range without serialising on each other's rows, and the partial index keeps the claim proportional to the backlog rather than to a table that is overwhelmingly published rows. At 4k/second a batch of 500 is eight claims per second, each an index scan of 500 entries.
2. Publish before marking, never the reverse, and say why it is a choice. Marking first loses the event outright if the process dies in the gap, and the loss is silent - nothing remains to retry, and it surfaces later as a projection missing a row. Publishing first can repeat the event, and repetition is what every consumer is already built to survive. That single ordering is the whole at-least-once guarantee.
3. Preserve the only ordering on offer. Partition by aggregate_id and never publish two events for one aggregate concurrently: claim in (created_at, event_id) order and publish sequentially within an aggregate, or hash aggregate_id to a worker slot. Order across aggregates is not available at any price here, which is why the event carries aggregate_version and the full fact rather than a delta - a consumer can then discard what it has already applied without coordinating with anyone.
4. State the failover behaviour precisely, because it is the consistency-versus-availability decision in this design. A lease expires because the holder is slow, and no mechanism distinguishes that from dead, so for the length of the lease window two leaders can publish the same claimed batch. The system accepts duplicates to avoid stalling publication for every aggregate in the range whenever one worker pauses. Consumers deduplicate on (aggregate_id, aggregate_version) and drop anything at or below what they have applied.

Follow-up

• The relay is down 40 minutes and 9.6 million rows are pending. What does catch-up do to the primary, and what changes in the claim loop to survive it?
• A consumer insists it never received an event. Which single query settles whether the relay lost it, and what does each answer look like?

Read latency spikes on a sixty-second sawtooth

Medium · cache stampede · single-flight · ttl

The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.

Approach

1. Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
2. Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
3. Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
4. De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.

Follow-up

• The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
• How does your answer change if the recompute takes 4 seconds instead of 250 ms?

Suggested practice checklist

Built from the rounds and topics Arizona State University candidates report.

Day 1 — Map the Arizona State University loop

• Write out the reported sequence: Recruiter Screening, Technical Evaluations, All-Team Panel Interview.
• For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

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

Day 2 — Work Git (version control)

• Spend the session on Git (version control), which Arizona State University candidates report being tested on.
• Write one worked example in Git (version control) and time yourself on it.

Deliverable: One timed worked example in Git (version control).

Day 3 — Work Python (development and scripting)

• Spend the session on Python (development and scripting), which Arizona State University candidates report being tested on.
• Write one worked example in Python (development and scripting) and time yourself on it.

Deliverable: One timed worked example in Python (development and scripting).

Day 4 — Work Data structures

• Spend the session on Data structures, which Arizona State University candidates report being tested on.
• Write one worked example in Data structures and time yourself on it.

Deliverable: One timed worked example in Data structures.

Day 5 — Answer out loud: Version Control and Collaboration

• Answer aloud, timed: This category evaluates your practical understanding of Git workflows, team coordination, and code maintenance strategies. How do you handle merge conflicts when multiple developers edit the same file? Can you explain the differences between rebasing and merging in Git? How do your team collaboration workflows ensure production-safe deployments? What steps do you take to recover from a mistake in a shared repository?

Deliverable: Spoken answers to 1 reported Version Control and Collaboration question(s), under time.

Day 6 — Answer out loud: System Design and Architecture

• Answer aloud, timed: These questions assess your ability to design scalable systems, plan API integrations, and structure clean software solutions. How would you approach designing a design challenge assignment for a new application? Can you explain your experience with RESTful and SOAP based APIs? How do you document system architecture and solutions for both technical and non-technical stakeholders? What strategies do you use when evaluating third-party applications and vendor-supplied system software?

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

Day 7 — Answer out loud: Technical and Domain Knowledge

• Answer aloud, timed: These inquiries test your core programming skills, database management, and familiarity with required frameworks. How do you convert software specification requirements into programming languages like Python or C#? Can you write a basic SQL query to retrieve and analyze output data patterns? What is your experience with IAM management concepts and identity security? How do you implement automated testing, such as unit testing and integration testing, in your web applications?

Deliverable: Spoken answers to 1 reported Technical and Domain Knowledge question(s), under time.

Behavioural preparation

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

This category evaluates your practical understanding of Git workflows, team coordination, and code maintenance

Medium · Version Control and Collaboration

This category evaluates your practical understanding of Git workflows, team coordination, and code maintenance strategies. How do you handle merge conflicts when multiple developers edit the same file? Can you explain the differences between rebasing and merging in Git? How do your team collaboration workflows ensure production-safe deployments? What steps do you take to recover from a mistake in a shared repository?

Approach

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

Follow-up

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

These questions explore your communication style, past work experience, and alignment with a customer-focused

Medium · Behavioral and Scenario-Based

These questions explore your communication style, past work experience, and alignment with a customer-focused institutional culture. How do you handle a situation where system requirements are ambiguous or conflicting? Can you describe a past project where you had to present technical applications to non-tech personnel? How do you prioritize tasks when supporting end users who report critical software failures? What does working in a values-driven, collaborative team environment mean to you?

Approach

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

Follow-up

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

Reverse your own decision and price the reversal

Medium · reversibility · measurement · migrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach

1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.

Follow-up

• What in that decision was irreversible, and did you know it was irreversible when you made it?
• How did you tell the people who had already built on top of the original decision?