Interview guides · Allegheny County

Allegheny County Software Engineer Interview Guide

Allegheny County Software Engineer interview guide: phone screen and panel rounds, reported questions on resume, app design, R and onsite logistics.

The 60-second brief

Allegheny County is a local government in the Pittsburgh area. Candidates describe the Software Engineer role as building and maintaining the software its departments and residents rely on: internal administrative tools, public-facing web and mobile applications, and tools that link applications to datasets. Project examples reported for the role include a web dashboard for data mining and a mobile app for tracking public transit. The work starts from a department's written requirements and runs through design, coding, deployment and upkeep, including bug fixes and keeping applications connected to their databases.

This guide is for candidates applying to Allegheny County as a Software Engineer, from early-career applicants with academic projects to engineers with shipped applications. It covers the two reported rounds, the twelve reported questions in their three groups (background and experience, application design and strategy, behavioral and logistics), and the stack candidates mention: Java, Python or C#, relational databases, and optional SAS, R and Android. It contains no algorithm drills, because candidates describe a conversational loop built around resume and design discussion.

Candidates report two rounds over roughly 2-4 weeks: a Phone Screen with a team member, then a Panel Interview of two to four people that goes through your resume and a project-design discussion.

Focus areas

R Programming
Android App Development
Application Development Strategy

Overview

The loop is short and conversational, so preparation is mostly about telling your own story precisely and thinking aloud about design. Candidates describe a phone screen focused on your background and the role, followed by a panel that reads your resume closely and asks how you would build an application from a provided requirements document. Reports contrast it with loops that lean on algorithm whiteboards, so the best use of your time is a rehearsed project narrative and two or three practised design walkthroughs rather than a long list of coding problems.

The reported questions fall into three groups. Background questions ask for a walk through the courses and projects on your resume, the technologies you chose for your last application and why, and how a tool such as SAS prepares you for the work. Design questions ask how you would start from a project description, sketch a rough system, connect a front-end application to a required dataset, and begin a brand-new project. Behavioral and logistics questions cover learning quickly, unfamiliar tools such as R, your start window, Pittsburgh residence and onsite work, and changing requirements.

Data access is the thread running through the design questions. The role as candidates describe it involves large local datasets, relational databases and tools that integrate data, so any design you sketch should say where the data lives, how the front end reaches it, how you keep it correct, and who is allowed to change it. Have a concrete example ready of connecting an application to a database or an external dataset.

The stack is broad: Java, Python and C# appear as example languages, SAS and R as useful extras, and Android as a possible platform. You are unlikely to know all of it. Prepare an honest map from what you do know to what you do not, and a believable first-week plan for each gap. Then settle the plain facts, your earliest start date and your Pittsburgh situation, so that those answers are short, firm and consistent with each other.

The Allegheny County interview process

Candidates describe two stages, a Phone Screen and a Panel Interview, with the whole process taking about 2-4 weeks. The descriptions below are what candidates report, not a published process.

Phone Screen

Candidates report an initial phone conversation with a team member about your background, with room for you to ask early questions about the role and the county's technology stack. It is described as a two-way fit conversation rather than a technical exam. Use it to get the resume story straight, because the panel afterwards goes through the same material in more depth. The reported background questions (courses and projects, technology choices, learning a new tool quickly) are the natural practice material for it.

What to demonstrate

How clearly you summarise your courses, projects and technology choices in a short spoken answer
How your experience lines up with the languages and relational-database work the role lists
The questions you ask about the role and the stack

How to prepare

Prepare a two-minute spoken summary of your courses and projects that ends on the application you most want to discuss.
Write three or four questions about the team's stack and the kinds of applications it maintains, since the call leaves room for them.
Have plain answers ready for your start window and your Pittsburgh location, because candidates report both topics in the loop.

Panel Interview

Candidates report an in-person panel of two to four team members, from senior engineers to project managers, often held at the county's Pittsburgh offices. It covers your technical background, a detailed read of your resume, and how you would approach a specific project from a provided requirements document. The tone is described as courteous, professional and practical. Treat it like a project kickoff: read the requirements, say what is unclear, state assumptions, then walk through front end, back end and database, and finish with how the application reaches the dataset. The panel mixes technical and non-technical people, so explain each choice in terms an engineer can check and a project manager can follow.

What to demonstrate

Depth on your resume: courses, projects, technology choices and your own contribution to each
Turning requirements into a rough design across front-end, back-end and database layers
Your plan for connecting the application to the required dataset
How you handle a tool you have not used, such as R or SAS

How to prepare

Build a project narrative for one application you built: architecture, database connection, deployment, your own share of the work and one decision you would revisit.
Practise the requirements-to-design walk aloud on two invented briefs, for example an internal records-search tool and a resident-facing mobile app: assumptions, open questions, layers, data access, build order.
Write a short mapping from your strongest tool to R or SAS (data frames, grouping, reading files) and a first-week learning plan.
Prepare one example of a requirement that changed mid-project and how you absorbed it.

Where candidates lose points

Reciting your resume line by line without saying what you personally built

Prepare one project narrative that separates the team's work from yours: the architecture, the database connection, the deployment, your own contribution and one decision you would change. Candidates report the panel reads the resume closely, so every item on it needs a two-sentence explanation.

Starting to pick technologies the moment a project description is handed over

Open with the requirements: restate them, list assumptions, name what is unclear, and only then describe front end, back end and database. Finish with a build order and a first milestone, so the design reads as a plan for delivery.

Sketching a design that never says how the application reaches its data

Every design should state where the dataset lives, how the front end gets to it (an API layer or direct queries), how input is validated, and how you keep records correct. Candidates describe the role as data-heavy, so this belongs in every answer to the design questions.

Bluffing about R or SAS, or answering a flat no

Say plainly what you have and have not used, name the closest tool you know and what transfers, and give a first-week plan with a way to check your results against existing output.

Giving vague answers on start date and Pittsburgh location

Decide before the call: an earliest start date, the reason behind it, and where you live or when you move. Say them in one sentence each, and make sure the two answers fit each other.

Questions & practice

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

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

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.
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.
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.
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?

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

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.
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.
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.
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?

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?

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

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.
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.
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.
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?

Walk me through the courses and projects you have listed on your resume.

Medium · Background and Experience Review

Approach

Choose the two or three items most relevant to the requirements candidates describe for this role: a core language such as Java, Python or C#, relational databases, data integration or mobile work. Lead with those. A chronological tour of every course spends the answer on the weakest material.
Give each project the same shape: the problem and who used it, what I personally built (kept separate from the team's work), the stack, one decision with the alternative I rejected, and what shipped or what it measurably changed.
Tie each course to something you built. 'In my databases course I designed a schema normalized to third normal form and wrote the queries behind a reporting app' can be checked. A list of course names cannot.
Audit the resume first. Every language or tool on it should hold up when someone asks how you used it. Remove or downgrade anything you cannot explain in depth.
Have a short version and a deep version of your strongest project. The deep version covers its data model, how the app connected to its database and how it was deployed.

Follow-up

Which part of that project would you build differently now, and why?
What was the hardest bug in that project, and how did you track it down?
How did the application store and retrieve its data?

What specific technologies did you use to build your last application, and why did you choose them?

Medium · Background and Experience Review

Approach

Name the stack one layer at a time (language, framework, database, hosting or device target) before justifying anything, so the listener sees the whole picture first.
Tie each choice to a constraint. Relational data with foreign keys and multi-row updates calls for a SQL database with transactions. Needing one codebase for phone and desktop browsers calls for a responsive web app instead of native Android. A tight deadline calls for a framework the team already knew.
Name the alternative I rejected and what it would have cost. For example, a document store would have made schema changes easier but moved joins and consistency checks into application code.
Own a real downside of the stack I picked and say how I dealt with it. One example is an ORM's lazy loading causing N+1 queries (one extra query per row), which I fixed with eager loading or an explicit join.
If a technology was assigned to me rather than chosen, say so plainly. Then explain what I learned about why it fit or did not fit.

Follow-up

What would you pick for the same application today?
How did you handle schema changes once the database held real data?
Where did that stack slow you down, and what did you do about it?

How does your background in [Specific Technology, e.g., SAS] prepare you for the work we do here?

Medium · Background and Experience Review

Approach

Answer in two parts. First, the skills that carry over from the tool: cleaning, joining and validating messy tabular data, and producing output other people rely on. Second, one concrete project where I did that work.
Map SAS ideas to their equivalents so the transfer is concrete. DATA step row transforms correspond to dplyr filter/mutate in R or pandas in Python. PROC SQL corresponds to plain SQL, PROC SORT to arrange or sort_values, and a MERGE with a BY statement to a join.
Show where the equivalents differ. A DATA step match-merge needs inputs sorted or indexed by the BY variables, and on many-to-many keys it does not produce the Cartesian product a SQL join does. SAS numeric missing values sort below every number. In R, NA propagates through comparisons and arithmetic unless handled with is.na or na.rm = TRUE.
Connect the tool to the application work in the requirements candidates describe for this role: data-integration tools and apps built on local datasets. Validation rules and well-defined transformations are what keep an application's data correct.
If your background is in a different tool, use the same structure: the concept that carries over, one project, and the gap you would still need to close and how.

Follow-up

How would you rewrite a typical SAS data-cleaning job in R or Python?
How would you verify that a migrated job produces the same output as the original?
What does SAS make easy that you would miss in another language?

Here is a brief description of a project we need completed. How would you proceed to develop this application?

Medium · Application Design and Strategy

Approach

Restate the project in one sentence, then ask clarifying questions before designing. Ask who the users are (residents, county staff or both), which features are must-haves, where the data lives and who owns it, how often it changes, who has to log in, and which devices it must run on.
Turn the description into a prioritized backlog. Start with a minimum version that delivers the core workflow end to end, then add increments. Write acceptance criteria for each must-have so that 'done' can be tested.
Choose the platform from the requirements. A responsive web app covers phones and desktops with one codebase. Native Android is justified by needs like offline use, background location, camera access or push notifications.
Order the delivery. Build the data model and data access first, because everything depends on them. Then build a thin vertical slice (one screen, one API call, one table) with automated tests and CI, deploy to staging, demo to the requesting department, and iterate.
Cover the cross-cutting requirements of public-facing software: accessibility (WCAG 2.1 AA is the usual target), authentication with separate roles for staff features, handling of personal data, logging, backups, and who maintains the app after launch.

Follow-up

The department wants the first release sooner. What do you cut, and what do you refuse to cut?
How would you get feedback from real users before launch?
What would make you choose a native Android app over a web app for this project?

Can you walk us through a rough design of how you would build this system?

Medium · Application Design and Strategy

Approach

Sketch the system in named layers: a client (web front end or Android app), an API service that owns business rules and authentication, a relational database, and a background worker for imports, scheduled jobs and notifications.
Walk one core request end to end. When a user submits a form: validate on the client, send an HTTPS POST to the API, validate and authorize on the server, insert inside a transaction, return a confirmation, and send any notification asynchronously.
Give the data model: the main entities, their keys and relationships, and indexes on the columns used for lookups and filters. Say which fields are personal data and how access to them is restricted.
Pick the simplest structure that fits. A modular monolith with one database suits a small team and modest load. Add caching, read replicas or separate services only when a stated requirement calls for them, such as heavy read traffic on public data or a separate release cycle.
Finish with operations: separate environments, CI/CD, logging and monitoring, backups with a tested restore, and role-based access with an audit trail for staff edits.

Follow-up

Where is the single point of failure in this design, and does it matter at this scale?
How would the design change if the app had to work offline?
How would you move users and data off an older system this one replaces?

How would you go about connecting this front-end application to our required dataset?

Medium · Application Design and Strategy

Approach

Put an API between the front end and the data. The browser or mobile app never holds database credentials, and the API enforces authentication, authorization and input validation.
In the API, use parameterized queries or an ORM so user input is never concatenated into SQL. Connect through a connection pool, and use a least-privilege, read-only database account for features that only read.
Shape responses to fit the screen. Return only the fields it needs, and filter and paginate on the server. Keyset pagination (WHERE id > the last id seen, ORDER BY id, LIMIT n) stays fast deep into a table. OFFSET pagination has to read and discard every skipped row.
If the dataset arrives as an external file or feed, load it on a schedule into a staging table. Validate types, required fields and duplicates, then upsert into the serving table on a stable key. Record the load time and row counts so stale or failed loads are visible.
Cover the front-end side too: loading, empty and error states; caching for data that changes slowly (Cache-Control or ETag headers); and CORS limited to the front end's own origin.

Follow-up

The dataset refreshes nightly and a load fails halfway through. What does the user see, and how do you recover?
A filter on a table with millions of rows is slow. How do you find and fix the cause?
The dataset contains personal information. What changes in your design?

What are the first steps you take when starting a completely new project?

Medium · Application Design and Strategy

Approach

Start with the problem and the people. Find out who asked for the project, who will use it, how they work today, and what result counts as success. Write these down as goals and acceptance criteria before picking tools.
List constraints early: data sources and access rights, systems the project must integrate with, security and privacy review, accessibility, hosting options and the deadline.
Sketch a rough design and list the riskiest unknowns, such as an unfamiliar dataset, a new language like R, or an undocumented integration. Test those first with small spikes, because they decide whether the plan holds.
Set up the foundation once: a repository with a branching convention, CI that runs tests and lint, dev and staging environments, and a seeded test database.
Build a thin end-to-end slice, demo it to stakeholders, and plan the rest in short iterations. That way changing requirements come up early instead of at launch.

Follow-up

What do you do when there is no requirements document at all?
Two stakeholders want conflicting features in the first release. How do you decide?
How do you estimate a project when the data source is still unknown?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Seven days built around the two reported rounds: resume and technology-choice stories first, then requirement-to-design practice with data access at the center, then unfamiliar tools, behavioral answers and a full mock panel.

Day 1 — Resume inventory and the walk-through

Write both reported rounds (Phone Screen, Panel Interview) at the top of a page, then list every course, project and technology on your resume.
Next to each item write one sentence on what you built or learned and one on your own contribution; mark anything you could not explain for two minutes.
Say the resume walk-through aloud and trim it until it ends on the project you want to discuss.

Deliverable: A resume inventory with a contribution sentence per item, and a two-minute spoken walk-through of your courses and projects.

Day 2 — Technology choices and tool mapping

For your most recent application, write each technology you used with the reason you chose it and one alternative you rejected.
Write the same for any SAS, R, Java, Python or C# experience, then mark which parts carry over to the work the role describes.
Practise the answers aloud for the technology-choice question and the question about how your background prepares you for the work.

Deliverable: A technology-choice table for your last application and a spoken answer for each of the two questions.

Day 3 — From requirements to a plan

Write a one-paragraph brief for an internal web tool that lets county staff search and update a dataset, then answer it as an interviewer's project description: restate, assumptions, open questions.
Break the brief into tasks and a build order with a first milestone.
Answer the question about the first steps on a brand-new project aloud, using the same structure.

Deliverable: A written assumptions list, open questions and task order for the brief, plus a spoken first-steps answer.

Day 4 — Rough design and the data connection

Sketch front end, back end and relational database for the brief from day 3, including where validation, authentication and error handling sit.
Write how the front end reaches the dataset: an API layer or direct queries, pagination, read-only versus write access, and how you check data integrity.
Work through the practice question on detecting a concurrent edit and the one on soft-deleted accounts, since both are about keeping relational data correct.

Deliverable: One annotated architecture sketch with a data-access paragraph, and notes from the two practice questions.

Day 5 — Unfamiliar tools: R, SAS and Android

Load a CSV in R (or Python if you have no R), filter, group, summarise and plot it, and compare the result with a number you can check another way.
Write a one-page mapping from your strongest tool to R or SAS, and a first-week plan for an R script you inherit.
Outline how an Android client would fetch from an API and keep a local copy, in plain language you could say to a non-engineer.

Deliverable: A working small R or Python analysis, the one-page tool mapping, and a spoken answer on comfort with unfamiliar technologies.

Day 6 — Behavioral stories and logistics

Write two stories in situation, action, result form: learning a tool quickly under a deadline, and a requirement that changed mid-cycle with the trade-offs you offered.
Write your exact start date, the constraints behind it, and your Pittsburgh situation, in one sentence each.
Say all four answers aloud and check that the dates and location facts agree with each other.

Deliverable: Two written stories, a start-date answer and a location answer, each rehearsed aloud.

Day 7 — Full mock panel

Ask a friend to play a mixed panel (one engineer, one project manager) and hand you a short requirements brief you have not seen.
Run the whole sequence: resume walk-through, technology choices, design from the brief with the dataset connection, then the behavioral and logistics questions.
List the three weakest answers and rework them.

Deliverable: A recording or notes from the mock panel and a short fix list for the three weakest answers.

Adaptability and logistics answers

Candidates report the behavioral part of this loop as a mix of adaptability stories and plain logistics: learning a tool fast, comfort with unfamiliar languages such as R, how you handle changing requirements, when you can start, and whether you live in Pittsburgh and can work onsite. Prepare two real stories, and give the logistics questions short, definite answers.

Describe a time you explained a technical decision to someone without a technical background.

Tell me about a time you had to learn a new technology or framework quickly for a project.

Medium · Background and Experience Review

Approach

Choose a project with a real deadline where the new tool was required for the work, not a course exercise you finished at leisure. Name the tool, why the project needed it, and what you already knew that was close to it.
Describe your learning method in order: the official docs or a short tutorial, then the smallest working slice of the real project, then reading existing code, then asking a colleague specific questions. Specific sequencing is what makes the story believable.
Say what you got wrong first (a misunderstood concept, a non-idiomatic pattern) and how you found out: a failing test, a code review comment, a bug in testing.
Close with the outcome that mattered: what shipped, when, and what you would tell the next person who has to pick up the same tool. Avoid claiming expertise after a few weeks; say what you would still want to deepen.

Follow-up

How did you decide what to learn first and what to skip until later?
How did you check that your code followed the tool's normal conventions and was not just working by accident?
What would you do differently if the same situation came up on a county project?

Are you comfortable working with technologies that you haven't used before, such as R programming?

Medium · Behavioral and Logistics

Approach

Answer the yes or no first and honestly. If you have not used R, say so in the opening sentence, then pivot to the nearest tool you do know (SAS, Python with data frames, SQL) and what carries over: tabular data, filtering, grouping, summaries, reading files, plotting.
Give a concrete first-week plan instead of a promise: install R, load a real CSV, reproduce one report you already produce in your current tool, then read the team's existing scripts and ask for a small ticket.
Describe how you would check your work in an unfamiliar language: reconcile row counts and summary statistics against known output from the old tool, test on a small slice with a known answer, and ask for review early.
Support the answer with one past instance where you picked up a tool you had not used and delivered with it. If your only evidence is coursework, say that plainly and describe what you built.

Follow-up

You inherit an R script nobody has documented. What do you do on day one?
How would you compare a SAS data step to the same logic in R or Python, and where do they differ?
How would you prove that a result produced in R matches the output of the system it replaces?

What is your availability to start over the next 3 to 4 months?

Medium · Behavioral and Logistics

Approach

Give a concrete window with dates, not a range of vague phrases. State your earliest possible start date and the latest date that still works for you, since the question mentions a 3 to 4 month horizon.
Name the real constraints behind the date: notice period at your current job, a graduation or end-of-term date, a lease, or a move. One sentence on each is enough, and it shows the date is reasoned.
Say what is fixed and what can move. If you could start sooner by shortening a handover or finishing a project early, say so, and say what it would take.
Keep it consistent with your location answer. If you are relocating, your start date should leave time for it, and the two answers should not contradict each other.

Follow-up

Is that date firm, or could it move earlier or later?
If the team needed someone sooner, what would have to happen for you to start earlier?
Does anything between now and then, such as a notice period or an exam, put your start at risk?

Do you currently reside in the Pittsburgh area, and are you comfortable working onsite?

Medium · Behavioral and Logistics

Approach

Answer directly: yes or no for living in the Pittsburgh area, then yes or no for working onsite. Candidates report this question is asked explicitly, so a clear answer matters more than a clever one.
If you live locally, mention where and that the commute is workable. If you are relocating, give the plan: whether the move is decided, the target date, and whether you can already attend an in-person panel in Pittsburgh.
Connect the answer to your start window so both tell one story. Do not promise to relocate without a plan behind it, and do not claim remote flexibility you have not been offered.
If you want to ask about hybrid arrangements, ask after you have said you are comfortable onsite, and treat it as a question about the team rather than a condition.

Follow-up

When would your move be complete, and would you cover the cost of it yourself?
Are you comfortable coming in person for the panel interview?
How many days a week in the office would work for you?

How do you handle changing requirements in the middle of a development cycle?

Medium · Behavioral and Logistics

Approach

Use a real example with the structure: what the original requirement was, what changed and why, who raised it, and when in the cycle it arrived. A story where the change came late is more useful than one where it came early.
Show your sequence: clarify the change and the reason behind it, estimate its impact on scope, design and schedule, then give stakeholders options with trade-offs (add it and move the date, swap it for something else, or defer it to the next release).
Say how you recorded the decision in writing: updated tickets or acceptance criteria and a short note to the people affected, so nothing lived only in a meeting.
Show how you kept the code healthy: isolating the parts most likely to change, relying on tests to catch regressions, and avoiding a quick patch that would make the next change harder. Avoid blaming the stakeholder; the strongest version treats change as normal.

Follow-up

How do you explain to a non-technical stakeholder that a change moves the delivery date?
What do you do when a new request contradicts something already signed off?
After many changes, how do you stop the design from becoming brittle?