City of Austin Texas Software Engineer Interview Guide

The 60-second brief

City of Austin Texas is a city government, and candidates describe the Software Engineer role as building and maintaining the software behind city operations and services. The projects named range from transportation systems to public safety applications. Candidate descriptions of the work mention large-scale data analysis, system integrations and applications built around the people who use them, delivered alongside project managers, product owners and other engineers. Day to day, that means designing, coding and testing applications for city departments and keeping existing systems updated.

This guide is for engineers applying to City of Austin Texas as a Software Engineer, from the application review through the in-depth interviews and the coding assessments. It covers what candidates report about each of the four rounds, written preparation for the reported behavioral and troubleshooting questions, a way to approach the reported coding and algorithm questions, and a seven-day schedule that ties them together.

Candidates report four stages over roughly three to five weeks: Application Review, Initial Screening, In-Depth Interviews (several interviews, often with panels) and Coding Assessments.

Focus areas

• Problem Solving (General)
• Communication Skills
• Experience-Based Technical Reasoning

Overview

The reported questions fall into four groups. Technical and domain questions ask about the languages you know, a hard problem you solved, development methodology and code quality. Behavioral and leadership questions cover a difficult teammate, influencing a technical decision, prioritizing, leading a project and taking feedback. Problem-solving questions cover designing a solution, finding a root cause, troubleshooting under pressure, a late project and optimizing an existing application. The coding group is the shortest to list: reversing a string, searching a large dataset, comparing sorting algorithms, choosing data structures, and a recursion or dynamic programming problem.

Most of the questions invite you to talk about your own work, so the strongest preparation is a small set of well-chosen experiences rather than memorized answers. Candidates also report topics labelled Problem Solving (General), Communication Skills, Experience-Based Technical Reasoning, Skills Assessment Testing and Technical Fundamentals (Basic), which fits that picture: explaining how you reasoned matters as much as the conclusion. Build six or seven stories and map each one to several questions. A single story about a production incident can answer the pressure question, the root-cause question and the difficult-teammate question if it had that dimension.

The requirements candidates describe list Java, Python or JavaScript, web development frameworks, databases, and Agile practice across the software development life cycle. Cloud services such as AWS or Azure, data visualization and cybersecurity principles appear as extras. Choose one of the three listed languages for the coding stage and be able to discuss the others honestly. Refresh how a web application talks to a database, including indexes, transactions and a slow query. The responsibilities also include maintaining existing systems, so have an example of changing code you did not write.

The loop is formal and often involves several interviewers at once. Practise answering out loud to a group, check that each story states what you personally did, and keep one version of every answer that a non-technical listener could follow. The plan below spends two days on coding fundamentals, one on databases and optimization, two on stories, and one on a full mock.

The City of Austin Texas interview process

Candidates describe four stages, from a paper review to a hands-on coding stage, with the in-depth interviews in the middle. The descriptions below say what is reported about each one and how to prepare for it.

Application Review

Candidates describe the first stage as a review of your application for qualifications and fit, before any conversation. Nothing is answered live, so the preparation is on paper. The requirements candidates describe name Java, Python or JavaScript, web development frameworks, databases, and Agile practice across the software life cycle, with cloud services, data visualization and cybersecurity as extras. Make each of those visible in your application where it is true, and attach a result to every claim.

What to demonstrate

• How closely your experience matches the languages, web frameworks and databases listed for the role
• Evidence of Agile and software development life cycle experience
• Whether your history shows building and maintaining applications, not only studying them

How to prepare

• Rewrite each recent CV bullet as language plus framework plus database plus outcome, for example the stack you used and what the application did for its users.
• Add AWS, Azure, data visualization or security work only where you have actually done it, and prepare one sentence on each that you can defend.
• Include one bullet about maintaining or extending an existing system, since the role's responsibilities include upkeep of live applications.

Initial Screening

Candidates describe a preliminary interview that checks basic skills and experience. The reported technical and domain questions are the natural material: which languages you are strongest in and what you built with them, a challenging problem you resolved, your experience with Agile or Scrum, and how you keep code maintainable. Aim for short, concrete answers that name a project, your part in it and the result, because this stage precedes the longer interviews where the same ground is covered in more depth.

What to demonstrate

• Basic skills and experience across the languages you list
• Ability to describe past projects clearly and briefly
• Technical fundamentals at a basic level, which candidates report as a tested topic

How to prepare

• Write a two-minute spoken walk through your CV that ends on the type of work you want to do for city services.
• Prepare the languages answer as a table: language, one project, what you personally built, one thing it was bad at.
• Rehearse the code quality answer with specifics: review practice, automated tests, naming and small functions, and one change you made because of a maintainability problem.

In-Depth Interviews

Candidates report several interviews in this stage, often with panels, mixing technical and behavioral questions. The reported material includes a difficult team member, influencing others to adopt a technical solution, prioritizing across projects, leading a successful project, handling criticism, designing a solution from a scenario, finding the root cause of a problem and troubleshooting under pressure. Because panels are reported, practise speaking to several people and keep each story short enough to leave room for follow-up questions.

What to demonstrate

• Technical reasoning grounded in your own experience
• Problem-solving approach on scenario and root-cause questions
• Communication with colleagues and with non-technical stakeholders
• Collaboration and conflict handling, as the reported team questions cover

How to prepare

• Build a story bank of six experiences, each with situation, your actions, a measured result and one thing you would change, then map each to at least two of the reported questions.
• Practise a repeatable root-cause sequence: reproduce, check what changed, narrow with logs and metrics, confirm the fix, prevent recurrence. Use it for both the root-cause and pressure questions.
• For the design-from-a-scenario question, rehearse opening with clarifying questions about users, data and constraints before naming components.
• Do one mock where two friends interrupt you with follow-ups, so you are used to being redirected mid-answer.

Coding Assessments

Candidates describe practical problem-solving exercises that show your technical ability. The reported coding themes are reversing a string, implementing a search over a large dataset, comparing sorting algorithms and their efficiencies, using data structures well, and a recursion or dynamic programming problem. Skills Assessment Testing is also a reported topic. Reports do not say whether the exercises are live or on a platform, so prepare for both: practise writing correct code without an editor's help and also explaining it aloud.

What to demonstrate

• Working code on practical problems
• Knowledge of algorithms, data structures and their costs
• Ability to explain choices such as why one sort or one structure fits the data

How to prepare

• Pick one of Java, Python or JavaScript, the three languages the requirements list, and write every practice solution in it with your own test cases.
• For each coding question, state the brute-force version and its complexity first, then improve it, and name the edge cases: empty input, one element, duplicates, very large input.
• Be able to compare insertion, merge, quick and heap sort on stability, extra memory, worst case and nearly sorted input, and say what your language's built-in sort uses.
• Solve one recursion problem both ways, plain recursion and with memoization, and state the time and space of each.

Where candidates lose points

Naming Java, Python and JavaScript without a project behind each one

For the languages question, give each language a project, your own part in it and a limitation you hit. A list of names invites the follow-up you cannot answer.

Treating the reverse-a-string question as too easy to think about

State the approach, the cost and the edge cases (empty string, one character, strings that are immutable in your language, characters made of more than one code unit) before and after you write it. Test it aloud with at least three inputs.

Reciting sorting algorithm complexities with no sense of when each one fits

Compare the algorithms on stability, memory use, worst case and nearly sorted input, and say what your language's standard library sort does. Tie the choice to the data you describe.

Telling every story as 'we' in front of a panel

Mark in each story what you decided or built personally. Prepare the stories out loud to more than one listener, so you know how to look around the group.

Answering Agile and code quality questions with vocabulary instead of practice

Attach a concrete example to each term: a retrospective that changed the process, a review rule you adopted, a test suite that caught a regression. Terms alone sound like a glossary.

Questions & practice

Write a function to reverse a string.

Medium · Coding / Algorithms

Approach

1. Clarify the input: language, whether strings are immutable, whether null or empty input is possible, and whether non-ASCII text (accents, emoji) must survive reversal.
2. Idiomatic answers: Python s[::-1]; Java new StringBuilder(s).reverse().toString(), which keeps surrogate pairs intact; JavaScript [...s].reverse().join(''), which iterates by code point. s.split('').reverse().join('') splits UTF-16 units and corrupts emoji.
3. Then write it by hand with two pointers on a character array: swap arr[i] and arr[j], move i forward and j back until they meet. That is O(n) time and O(1) extra space on a mutable array (O(n) overall when the language forces a copy of an immutable string).
4. Mention edge cases: empty string, one character, odd and even lengths, and grapheme clusters such as combining accents or emoji sequences, which even code-point reversal splits (JavaScript's Intl.Segmenter handles those).
5. Avoid a recursive version for long input: it is O(n) stack depth (Python's default recursion limit is 1000), and building it with slices or concatenation makes it O(n^2).

Follow-up

• Reverse the order of words in a sentence, in place if you can.
• Check whether a string is a palindrome, ignoring case and punctuation.
• How would you reverse a string containing emoji or combining accents correctly?

How would you implement a search algorithm for a large dataset?

Medium · Coding / Algorithms

Approach

1. Clarify the search: exact key lookup, range query, prefix or full-text search; whether the data is static or frequently updated; and whether it fits in memory.
2. Baseline: linear scan is O(n) per query. If queries are frequent and the data is mostly static, sort once in O(n log n) and binary search in O(log n) per query.
3. Write binary search carefully: keep the invariant on lo and hi, compute mid as lo + (hi - lo) / 2 (avoids int overflow in Java), and use a lower-bound variant to find the first occurrence when keys repeat. Test empty input, one element, a missing key and duplicates.
4. For exact-match lookups in memory, a hash map gives O(1) average lookups at the cost of extra memory and no ordering. For frequent inserts with range queries, use a balanced tree (Java TreeMap, O(log n)) instead of a sorted array, where each insert is O(n).
5. When the data lives on disk, use a database B-tree index for keys and ranges (O(log n) page reads), and an inverted index (PostgreSQL tsvector with a GIN index, or Elasticsearch) for text search.

Follow-up

• Find the first and last positions of a value in a sorted array with duplicates.
• The data is updated thousands of times a second. What structure do you use now?
• How would you search a sorted array that has been rotated?

Explain the differences between various sorting algorithms and their efficiencies.

Medium · Coding / Algorithms

Approach

1. Simple sorts: insertion sort is O(n^2) in the worst case but O(n) on nearly sorted input, stable and in place, so it is good for small or almost-sorted arrays. Selection and bubble sort are O(n^2) and mainly teaching examples.
2. Merge sort is O(n log n) in every case and stable, but needs O(n) extra memory. It also suits linked lists and external sorting.
3. Quicksort averages O(n log n) and is in place (O(log n) stack with a good pivot), but its worst case is O(n^2) on bad pivots and it is not stable. Randomised or median-of-three pivots reduce that risk. Heapsort guarantees O(n log n) with O(1) extra space but is not stable.
4. Comparison sorts cannot beat Omega(n log n) in the worst case. Counting sort (O(n + k)) and radix sort (O(d(n + k))) get around that for bounded integer keys.
5. Know the library sorts: Python's sort is a stable Timsort-family merge sort; Java uses dual-pivot quicksort for primitives and stable TimSort for objects; JavaScript's sort has been required to be stable since ES2019 but compares as strings by default, so [10, 9, 1].sort() gives [1, 10, 9] unless you pass (a, b) => a - b.

Follow-up

• How would you sort a file that is too large to fit in memory?
• When does stability matter? Give a concrete multi-key example.
• Implement quicksort and explain how your pivot choice avoids the worst case.

Can you demonstrate how to use data structures effectively in your code?

Medium · Coding / Algorithms

Approach

1. Pick the structure from the access pattern and say so: 'I need membership checks, so a set; I need ordering by priority, so a heap.' Then give a before-and-after example with complexities.
2. Hash map or set: replacing a list membership check (O(n) each) with a set (O(1) average) turns an O(n*m) duplicate check into O(n + m). Use a dictionary to group or count records in one pass.
3. Queue and heap: Python's list.pop(0) is O(n), while collections.deque.popleft() is O(1), so use a deque for BFS and work queues. A heap (heapq, Java PriorityQueue) gives top-k in O(n log k) without sorting everything.
4. Ordered and graph structures: a balanced tree (Java TreeMap) for range queries and nearest-key lookups in O(log n); an adjacency list for networks such as routes, with BFS or Dijkstra over it.
5. Edge cases: Python lists are unhashable as keys, Java keys whose hashCode changes after insertion get lost in a HashMap, HashMap iteration order is unspecified (use LinkedHashMap if order matters), and memory overhead per entry adds up at scale.

Follow-up

• Implement an LRU cache with O(1) get and put.
• When would a plain array beat a hash map?
• Which of these structures need extra care when several threads share them?

Solve a problem involving recursion or dynamic programming.

Medium · Coding / Algorithms

Approach

1. Define the recursion before coding: the state, the base cases and the transition. For coin change (fewest coins), the state is the remaining amount, f(0) = 0, and f(a) = 1 + min over coins c <= a of f(a - c).
2. Point out that naive recursion recomputes subproblems and is exponential, then memoise (Python functools.cache, or a HashMap in Java) or tabulate bottom-up. Complexity is the number of states times the work per state: O(amount x coins) time and O(amount) space here.
3. Handle edge cases: amount 0 returns 0, an unreachable amount returns -1 (initialise the table with infinity), and decide how to treat an empty coin list.
4. Prefer bottom-up when depth is large: top-down recursion uses O(n) stack, Python's default recursion limit is 1000, and Java throws StackOverflowError. Many 1-D DPs only need the previous row or two values, so space can drop to O(1) or O(k).
5. Practise one problem from each family: Fibonacci or climbing stairs (1-D), coin change (unbounded choice), 0/1 knapsack (2-D or a reverse-iterated 1-D table), and longest common subsequence (2-D over two strings).

Follow-up

• Count the ways to make the amount instead. How does loop order separate combinations from permutations?
• How would you reconstruct which coins were used, not just how many?
• Rewrite your recursive solution iteratively to avoid stack overflow.

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

What programming languages are you most proficient in, and how have you applied them in past projects?

Medium · Technical / Domain Questions

Approach

1. Lead with one primary language from the requirements candidates describe for this role (Java, Python or JavaScript) and say plainly which others you know less well. A ranked list sounds more credible than claiming all of them equally.
2. Anchor each language to one project, naming the framework and database it ran against, e.g. 'I built the API in Python with Flask and PostgreSQL, and the front end in JavaScript.'
3. Name language features you chose on purpose and why: Python generators to stream a large CSV without loading it into memory, Java's ExecutorService for bounded concurrency, JavaScript async/await for parallel I/O with Promise.all.
4. Show depth with a pitfall you actually hit: Python's mutable default argument (evaluated once, when the function is defined), JavaScript's == type coercion, or comparing Java Strings with == instead of equals().
5. Close with tooling around the language: the test framework (pytest, JUnit, Jest), the linter or type checker (mypy, TypeScript, Checkstyle) and how the code was packaged and deployed.

Follow-up

• What is a bug that language let you write, and how would you prevent it now?
• If you had to pick a language for a new internal web service, how would you decide?
• How do you get productive in a codebase written in a language you know less well?

Can you explain a challenging technical problem you faced and how you resolved it?

Medium · Technical / Domain Questions

Approach

1. Choose a problem that was technically hard, not just long: a race condition, a memory leak, a slow query, a data-corruption bug or an integration that failed intermittently. Name the system and give the symptom with a number (error rate, latency, failed records).
2. Say what made it hard: it only reproduced under load, the logs were missing, or two systems each blamed the other.
3. Walk through the hypotheses in order and what evidence ruled each one out, in the first person: 'I added request IDs to the logs, which showed the duplicate writes came from client retries.'
4. Explain the fix by its mechanism (an idempotency key, a database index, a lock, a corrected time-zone conversion) and the trade-off it carried.
5. End with verification and prevention: the metric that returned to normal, the regression test and the alert or check added so it would not recur.

Follow-up

• What other fix did you consider, and why did you reject it?
• How did you confirm the fix worked, rather than the problem just going quiet?
• What would you do differently if the same symptom appeared tomorrow?

How do you ensure code quality and maintainability in your projects?

Medium · Technical / Domain Questions

Approach

1. Describe quality as layers, each catching a different class of defect: automated tests, code review, static analysis and CI gates, rather than one silver bullet.
2. Tests: unit tests on pure logic, integration tests against a real database for queries and migrations, and a small number of end-to-end tests on the main user paths. Test behaviour, not implementation details, so refactors do not break the suite.
3. Automation: formatters and linters (Black or Ruff, ESLint and Prettier, Checkstyle) plus type checking (mypy, TypeScript) run in CI on every pull request, so review time goes to design instead of style.
4. Review and design habits: small pull requests, clear names, functions that do one thing, and a short written record of non-obvious decisions. Add dependency and security scanning (for example Dependabot or npm audit) for long-lived systems.
5. Trade-off: a coverage percentage used as a target gets gamed. I track escaped defects and how often a change breaks something unrelated as better signals of maintainability.

Follow-up

• How would you add tests to a legacy module that has none and is risky to change?
• What do you do when a reviewer and you disagree about an approach?
• Which quality check would you drop first under deadline pressure, and which never?

Given a specific scenario, how would you approach designing a software solution?

Medium · Problem-Solving / Case Studies

Approach

1. Start by clarifying requirements: who the users are, the core use cases, expected volume, availability needs and how sensitive the data is (personal data changes the design). Write the answers down before drawing anything.
2. Model the data first: the main entities, their relationships and which queries must be fast. For a practice scenario like a request-tracking web app, that means requests, users, statuses and an audit history, in a relational database with indexes on the lookup columns.
3. Lay out the components: a web or mobile client, an API layer with authentication, the database, and a queue with background workers for slow work such as notifications, imports or report generation.
4. State the trade-offs explicitly: a single deployable service versus several, synchronous calls versus a queue, and SQL versus a document store. Justify each choice from the requirements rather than habit.
5. Cover failure modes and operations: input validation, role-based access, logging and monitoring, backups, and what the user sees when a dependency is down.

Follow-up

• How does the design change if traffic grows tenfold?
• Where does it fail first, and how would you detect that?
• How would you protect personal data stored in this system?

If a project is falling behind schedule, what steps would you take to address the situation?

Medium · Problem-Solving / Case Studies

Approach

1. Quantify the slip first: the remaining work against the team's actual throughput (a burndown chart or completed stories per sprint) gives a realistic finish date instead of a feeling.
2. Find the cause, because the remedy depends on it: scope creep, underestimated work, a blocked dependency, unclear requirements or people pulled onto other work.
3. Lay out options with their costs: cut or defer scope (sort features into must-have and nice-to-have), re-sequence so the must-haves ship first, remove blockers, or move the date. Adding people late usually slows things down first because of onboarding and coordination (Brooks's law).
4. Tell stakeholders early, bringing the options and a recommendation rather than just the bad news, and agree on the trade-off in writing.
5. Do not quietly cut testing or security work to hit the date. Afterwards, compare estimates with actuals so the next plan is better calibrated.

Follow-up

• What if the stakeholder refuses to cut scope or move the date?
• When, if ever, would you add engineers to a late project?
• How would you stop the same slip happening next time?

Describe your approach to optimizing an existing software application.

Medium · Problem-Solving / Case Studies

Approach

1. Define the target and measure a baseline before changing anything: p95 latency of a specific endpoint, page load time, memory, or cost, measured under realistic data and load.
2. Profile to find where the time actually goes: cProfile or py-spy for Python, Java Flight Recorder or VisualVM for Java, browser DevTools for front-end JavaScript, and EXPLAIN ANALYZE in PostgreSQL for slow queries.
3. Fix the biggest hotspot first. Common ones: N+1 queries (batch them or use a join), a missing index, an O(n^2) loop doing list membership checks (switch to a set), unbounded result sets (paginate), and repeated expensive calls (cache them).
4. Name the cost of each fix: an index slows writes and uses storage, and a cache adds staleness and needs an invalidation rule or a TTL.
5. Re-run the same benchmark to show the gain, confirm correctness with the existing tests, and add monitoring so a regression shows up.

Follow-up

• The query is fast locally but slow in production. What do you check?
• How would you decide when cached data must be invalidated?
• How do you make sure an optimisation did not change behaviour?

How do you identify the root cause of a problem in a software application?

Medium · Problem-Solving / Case Studies

Approach

1. Scope the problem before theorising: which users, endpoints or inputs are affected, since when, and how often. Reproduce it, or at least capture a failing request with its inputs.
2. Ask what changed around the time it started: a deploy, a configuration change, a dependency upgrade, a data change or a traffic shift. Line the change log up against the error-rate graph.
3. Narrow it by bisection: git bisect finds the offending commit in about log2(n) test runs, and disabling half of a pipeline or feature-flagging a change halves the search space the same way.
4. Test one hypothesis at a time against logs, metrics and traces, and keep separate the trigger (a deploy, a spike) and the underlying cause (an unhandled null, a missing index, a race).
5. Fix the cause, add a regression test that fails without the fix, and write a short postmortem covering detection, cause and what stops a repeat.

Follow-up

• How do you debug an intermittent failure you cannot reproduce locally?
• How do you tell a cause from a coincidence when two things changed at once?
• What logging or monitoring would have found this sooner?

Suggested practice checklist

The plan follows the reported loop: the application and screening material first, then coding fundamentals for the coding stage, databases and optimization, two days of stories for the in-depth interviews, and a closing mock that mixes everything.

Day 1 — Align your application and screening answers

• Rewrite five CV bullets so each names language, framework or database, and an outcome, using only experience you have.
• Write the languages answer as a table of language, project, your contribution and one weakness.
• Record a two-minute spoken CV walkthrough and play it back.

Deliverable: A revised CV bullet list, a languages table covering Java, Python or JavaScript, and one recorded two-minute walkthrough.

Day 2 — Coding fundamentals: strings, search and sorting

• Write string reversal in your chosen language three ways (built-in, two pointers, recursion) and list the edge cases you tested.
• Implement binary search iteratively and explain what has to be true of the data and what you do when it is too large for memory.
• Write merge sort and quick sort from memory and note stability, extra space and worst case for each.

Deliverable: Working, tested code for string reversal, binary search, merge sort and quick sort, plus a one-page sorting comparison table.

Day 3 — Data structures, recursion and dynamic programming

• Choose a data structure for four access patterns (lookup by key, ordered iteration, first in first out, repeated minimum) and justify each with its cost.
• Solve one recursion problem, then add memoization and state time and space for both versions.
• Solve one dynamic programming problem by writing the recurrence first, then the table version, and say how you would reduce its memory.

Deliverable: A table of four access patterns with the chosen structure and cost, and two solved problems with complexity written beside each.

Day 4 — Databases, optimization and root cause

• Take one slow query or page from your own experience and write the sequence you would follow to optimize it: measure, find the bottleneck, change one thing, measure again.
• Write your root-cause sequence as five steps and run a past bug through it.

Deliverable: Two solved SQL drills, a one-page optimization checklist with a worked example, and a five-step root-cause sequence applied to a real bug.

Day 5 — Stories: learning, teamwork, influence and Agile

• Write bullet outlines for four stories covering a quick technology ramp-up, a difficult teammate, persuading others to adopt a solution, and your Agile practice.
• For each outline, state the situation, your action, the result and what you would change, and cut it to about two minutes.
• Say each one aloud to a friend and ask them to mark every 'we' that should be 'I'.

Deliverable: Four written story outlines plus a record of which 'we' statements you converted to 'I'.

Day 6 — Stories: prioritizing, leading, feedback and pressure

• Write outlines for a prioritization example, a project you led with a measurable result, a feedback story and a production incident.
• For the incident, write the order of work: impact, communication, mitigation, diagnosis, fix, prevention.
• Prepare an answer for a project that is falling behind schedule: cut scope, add help or move the date, and who you tell first.

Deliverable: Four written story outlines, an incident timeline in six steps, and a short answer for the late-project question.

Day 7 — Full mock for the in-depth interviews

• Run a mock with two listeners: a design-from-a-scenario question, the code quality question and the challenging problem question.
• Solve one coding question live in your chosen language and explain each decision aloud.
• List the three weakest answers from the mock and rework them.

Deliverable: A recorded mock session, a rewritten version of the three weakest answers, and a final one-page list of stories and coding patterns to review before the interview.

Behavioral stories for the City of Austin Texas loop

The reported behavioral questions cover your working method (Agile, prioritizing, learning fast), your effect on others (a difficult teammate, influencing a technical choice, leading a project, taking feedback) and your conduct when something breaks. Candidates also report a panel format in the in-depth stage. Build each answer around one real experience, say what you personally did, give the result, and be ready to say what you would change.

Describe your experience with software development methodologies (e.g., Agile, Scrum).

Medium · Technical / Domain Questions

Approach

1. Name the actual practices you worked in: backlog refinement, sprint planning, daily stand-up, review, retrospective, and which of them you ran or only attended. Say whether the team used Scrum, Kanban or a mix, and why.
2. Give one concrete example of the process changing something: a retrospective that exposed stories carrying over sprint after sprint, followed by smaller slicing and a stricter definition of done, with what improved afterwards.
3. Show you understand why the practices exist rather than reciting them: short feedback loops with a product owner, visible work in progress, estimates as a planning aid and not a promise.
4. Be honest about a case where the textbook process did not fit, for example upkeep and bug-fix work that suits a Kanban board better than fixed sprints. That ties directly to maintaining existing systems.
5. Close with how you work with project managers and product owners: how requirements reach you, how you push back on scope, and how you report progress.

Follow-up

• How do Scrum and Kanban differ, and when did you choose one over the other?
• What did a retrospective change on your team, and how did you check it helped?
• How did you handle an urgent request that arrived in the middle of a sprint?

Discuss a time when you had to learn a new technology quickly to complete a project.

Medium · Technical / Domain Questions

Approach

1. Use STAR with a real deadline: say what the project needed, what you did not know, and the date that made learning on the job unavoidable.
2. Show your method for learning fast: build the thinnest end-to-end slice first, read the official documentation and one worked example, then widen. Name the resources you used and what you skipped on purpose.
3. Show how you verified your work while still new to it: tests you wrote, a review from someone who knew the technology, or a small spike you discarded after it taught you what you needed.
4. Give the result with evidence (shipped, working in use) and say what you would do differently, such as asking for the review earlier.
5. Avoid claiming mastery. A credible answer says what you understood well by the deadline and what you were still shaky on.

Follow-up

• How did you decide when you knew enough to commit to that technology?
• What did you get wrong at first, and how did you find out?
• How would you approach picking up one of Java, Python or JavaScript if it were new to you?

Tell me about a time you worked with a difficult team member. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Pick a conflict about how work was being done (missed handoffs, dismissive code review comments, going silent), not a clash of personalities, and describe the behavior and its effect on the work instead of labelling the person.
2. Show that you spoke to them directly and privately first, asked about their view or constraints, and listened before proposing anything. The story fails if the first step was going to a manager.
3. Describe the concrete agreement you reached, for example review turnaround, a shared task board or a pairing session, and what changed afterwards.
4. If it did not fully resolve, say so, say when you escalated and why, and what you did to keep the team's delivery unaffected.
5. End with the result and what you learned about your own part in the situation, without self-blame that sounds staged.

Follow-up

• What would you have done if the direct conversation had not worked?
• How did you keep the rest of the team's work from suffering in the meantime?
• Looking back, what did you misjudge about that person or the situation?

Describe an instance where you had to influence others to adopt a technical solution.

Medium · Behavioral / Leadership

Approach

1. Open with the problem in terms the audience cares about, such as fewer outages, less manual work or lower maintenance cost, then the solution you wanted adopted and why alternatives lost.
2. Show the evidence you brought: a small prototype, a benchmark, an incident history or a comparison table. Influence without authority works through evidence, not insistence.
3. Name the objections you heard and how you met them: a pilot on one component, a rollback plan, a migration path, or a compromise that took part of your idea.
4. Adapt to each listener: engineers get the technical trade-offs, product owners and project managers get effect on scope, risk and delivery.
5. Report the outcome honestly, including a case where you were overruled and how you committed to the decision anyway.

Follow-up

• Who was hardest to convince, and what finally moved them?
• What would you have done if the team had still said no?
• How did you explain the change to someone without a technical background?

How do you prioritize tasks when working on multiple projects?

Medium · Behavioral / Leadership

Approach

1. State a method before the story: list everything in flight, note deadlines, who is blocked on each item, user impact and effort, then rank by impact and urgency. Quick wins and blockers for other people move up.
2. Show the list is visible and shared (a board or tracker), so stakeholders see the order and the trade-offs instead of guessing.
3. Give a specific example with two real competing requests, which one you did first, and the conversation with the person whose request waited. Saying no with a date and a reason is part of the answer.
4. Explain how you handle interruptions: production problems preempt planned work, everything else goes to the queue and gets re-ranked at a regular point.
5. Mention re-checking priorities when estimates slip, and flagging early instead of absorbing the delay.

Follow-up

• What do you do when two managers both say their request is the top priority?
• How do you treat a production bug that arrives while you are mid-feature?
• What happened when your estimate turned out to be wrong?

Can you give an example of a successful project you led and the impact it had?

Medium · Behavioral / Leadership

Approach

1. Pick a project where you owned outcomes, even without a lead title. State the goal, the people involved and the constraint (deadline, legacy system, team size) in a few sentences.
2. Describe what leading meant in practice: breaking work into tasks, making the key technical decisions, unblocking others, and keeping stakeholders such as a product owner informed.
3. Use 'I' for your decisions and 'the team' for shared work. A story that is all 'we' hides your contribution.
4. Quantify the impact with figures from your own experience: users served, hours saved, errors reduced, release delivered. If you have no number, name the observable change and who noticed it.
5. Include one thing that went wrong and how you corrected course, and what you would change next time.

Follow-up

• How did you measure the impact after the project shipped?
• What did you cut or postpone, and who decided?
• How did you handle a teammate who fell behind?

How do you handle feedback and criticism regarding your work?

Medium · Behavioral / Leadership

Approach

1. Choose real, specific criticism, such as a code review that found a design flaw or a stakeholder who said your updates were unclear. A trivial or disguised-strength example sounds rehearsed.
2. Describe your first reaction honestly, then what you did: asked clarifying questions, checked whether the point was right, and agreed on what to change.
3. Show behavior change that others could see afterwards, for example a checklist before review, smaller pull requests or a different status update format.
4. Include a case where you disagreed with feedback and how you handled it: asking for an example, presenting your reasoning, and accepting the outcome.
5. Mention that you ask for feedback before it is offered, for instance from reviewers or a product owner at the end of a project.

Follow-up

• Tell me about feedback you disagreed with, and what you did.
• What is the most useful piece of feedback you have received, and what did it change?
• How do you give critical feedback to a colleague?

Discuss a time when you had to troubleshoot a critical issue under pressure.

Medium · Problem-Solving / Case Studies

Approach

1. Pick an incident with real stakes and say plainly what was affected and who was waiting, then show your order of work: assess impact, tell the people who need to know, stop the damage, then find the cause.
2. Describe mitigation before diagnosis: rolling back a release, switching off a feature flag or redirecting traffic, so users recover while you investigate.
3. Walk through the diagnosis as a sequence: what changed recently, what the logs and metrics showed, the hypotheses you ruled out, and how you confirmed the actual cause.
4. Cover communication: who got updates, how often, and what you said. Calm, regular updates are part of handling pressure.
5. Finish with the permanent fix, the review afterwards, and the prevention you added, such as an alert, a test or a deployment check. Avoid hero stories where you worked alone and told nobody.

Follow-up

• What did you tell stakeholders while the issue was still open?
• Why did you choose to roll back instead of fixing forward, or the reverse?
• What did you change afterwards so the same failure would be caught earlier?