County of Alameda Software Engineer Interview Guide

The 60-second brief

The County of Alameda is a local government, and its Information Technology Department (ITD) is where candidates place this role. Engineers there build and maintain web portals the public uses and internal systems county employees rely on, covering areas such as healthcare, social services, public safety and property management. Candidates describe a mixed environment: modern web applications and cloud integrations sit next to older systems that are being modernised step by step. Day to day, the Software Engineer writes, tests and deploys code, keeps existing applications available, works with database administrators, security analysts and business analysts, and documents systems for the departments that use them.

This guide is for engineers applying to the County of Alameda as a Software Engineer, typically with a few years of professional development experience in C#, Java or JavaScript/TypeScript and a relational database such as SQL Server, Oracle or PostgreSQL. It covers every reported stage, the reported questions on database work, legacy integration, accessibility, endpoint security, incident response, prioritisation, stakeholder communication and motivation, plus a seven-day plan that includes timed writing practice.

Candidates report five stages over roughly four to six weeks: an HR screening, a phone screen with a hiring manager, panel interviews, a timed writing exercise held during the second-round panel, and a background check that can run from several weeks to six months.

Focus areas

• Coding interview problem solving
• Technical interviewing
• Software engineering fundamentals (general)

Overview

The reported questions are mostly experience-based rather than puzzle-based. Candidates describe prompts such as your SQL and database design background, how you would connect a modern web application to an older backend database, how you secure endpoints that carry personal data, and how you would approach a poorly documented codebase. Candidates also say a live whiteboard test of complex algorithms is rare, so the preparation effort belongs in concrete project stories, schema and query reasoning, and clear spoken explanations.

Many questions are situational: an application fails under pressure, several projects compete for the same deadline, or a department asks for a feature that conflicts with a security policy. Each one has a repeatable shape. Describe the situation briefly, state what you decided and why, name the risk you managed, and report the result. Candidates also report that panels ask every applicant the same list of questions, so your preparation is about building a complete, ordered answer for each prompt rather than steering a conversation.

The written side matters as much as the spoken side. A timed writing exercise is reported during the second-round panel, before the verbal questions, and the reported examples are an email to a department head about extending a maintenance window and a short guide for junior developers on a branching strategy. The role itself includes architecture diagrams, API specifications and user guides, so practise writing short, well-organised technical text for readers who are not engineers.

Finally, the stack the role lists shapes what you should be able to discuss: at least one enterprise language (C#, Java or modern JavaScript/TypeScript), relational databases, Git and web application security, with AWS or Azure, legacy migration experience and WCAG/ADA knowledge listed as nice-to-haves. Prepare one honest example for each area you have used and be clear about the areas you have not.

The County of Alameda interview process

These are the five stages candidates describe, in the order they report them. The writing exercise is held during the second-round panel rather than as a separate sitting, and the background check follows the interviews.

HR Screening

Candidates describe the HR screening as the stage that checks you meet the minimum qualifications for the Software Engineer position. The requirements candidates describe are a degree in computer science, information systems or a related field with two to four years of development experience, with equivalent professional experience often accepted in place of a degree. Treat it as a matching exercise: your application should make each requirement easy to find.

What to demonstrate

• Whether your experience matches the minimum qualifications for the Software Engineer position
• Whether your languages and databases line up with the requirement list (C#, Java or JavaScript/TypeScript; SQL Server, Oracle or PostgreSQL)

How to prepare

• List each listed requirement (enterprise language, relational database, Git, web application security) next to a project and the years you used it, so every claim has a date and a place.
• If your qualifications rest on experience instead of a degree, write a short statement of that equivalence and keep your employment dates consistent with what a later background check will verify.

Phone Screen

The phone screen is reported as a follow-up call with a hiring manager to talk about the role and your fit. Little more is reported about its format, so prepare the two things any such call needs: a clear account of your experience and a reasoned answer to why you want this job in public service.

What to demonstrate

• Fit between your background and the Software Engineer role as discussed with a hiring manager
• How clearly you describe your experience and your reasons for choosing a county role

How to prepare

• Rehearse a short summary of your SQL and database design work with one concrete project, since database experience is the first technical theme in the reported questions.
• Write your answer to why you want to work as a Software Engineer for the County of Alameda and what public service means to you, using one example from your own work where reliability or access for real users mattered.
• Prepare two or three questions about the systems and departments the role supports, including which databases and languages the team uses and whether the assignment is hybrid or onsite.

Panel Interviews

Candidates report formal panel interviews with three to four engineers or IT professionals, sometimes including people from other divisions, running about 30 to 45 minutes, with the same pre-set questions for every candidate. Reported topics cover SQL and database design, integrating web applications with legacy databases, accessibility, endpoint security, incident response, prioritising competing deadlines, inheriting an undocumented codebase and handling a request that conflicts with a security policy. Expect to address several people at once, some more technical than others.

What to demonstrate

• Technical competence in SQL, database design, API integration, security and accessibility as reported for this role
• Situational judgment on incidents, competing deadlines, legacy code and policy conflicts
• Clear, well-ordered answers delivered to a mixed technical audience

How to prepare

• Write a one-page outline for each reported question and speak it aloud against a timer, covering the database design and SQL question, the legacy integration question and the endpoint security question first.
• Prepare one real incident story, one prioritisation story and one story about a stakeholder request that conflicted with security rules, each in the order situation, decision, risk, result.
• Practise explaining a technical choice twice: once for an engineer and once for a department representative, because the panel can include both.

Writing Exercise

Candidates report a timed 20-minute writing exercise during the second-round panel interview, before the verbal questions begin, to assess professional communication. Reported example tasks include an email to a department head explaining why a maintenance window must run two hours longer, and a short guide for junior developers on a version control branching strategy. An incident report is also mentioned as a less common task.

What to demonstrate

• Written communication of technical ideas to a non-technical reader
• Organisation of a response with a clear purpose, headings and bullets
• Professional tone under a fixed time limit

How to prepare

• Do the maintenance-window email as a timed exercise: open with the decision and the new end time, then give the reason, the effect on users, and what happens next.
• Write a branching-strategy guide for junior developers with short headings, a numbered workflow, and one example of a feature branch merged into the main line.
• Practise a short incident report with a fixed layout: what happened, who was affected, the cause, the fix, and the follow-up actions, then reread for jargon a department head would not know.

Background Check

The background check is reported as a thorough final stage that includes criminal history checks and reference verification, and candidates say it can take from several weeks up to six months. There is no interview content here, so preparation is administrative: make verification quick and keep your other options in mind while it runs.

What to demonstrate

• Verification of criminal history and references
• Completion of the check before a start date is finalised

How to prepare

• Confirm that your employment dates, titles and the contact details of your references are accurate and that each reference knows to expect a call.
• Ask the HR contact what the check involves and what timeline to expect, and plan around the reported range if you are weighing other offers.

Where candidates lose points

Answering the database and SQL question with a list of tools and no schema, query or plan

Bring one project with a named engine (SQL Server, Oracle or PostgreSQL), the tables involved, one hard query, and the index or plan change you made. For a slow-query question, check the plan before adding an index and say how you measured the change.

Telling the application-failure story as a heroic fix with no impact, no mitigation and no prevention

Order the story as impact, containment, diagnosis, fix, then the test or alert you added. State who was affected and what you told them, so the answer shows judgment as well as debugging.

Treating the conflicting-feature question as a choice between saying yes and refusing

Ask what the stakeholder needs, name the risk the policy guards, offer a compliant alternative, and send a real conflict to the policy owner with a written record of the decision.

Using the 20-minute writing exercise to explain background first and leaving the decision or request at the end

Practise a fixed layout: the point first, then the reason, the effect on readers and the next step, with short headings or bullets. Reread for jargon before time runs out.

Giving a generic reason for wanting a county job, such as stability, without tying it to the work

Name the kinds of services the systems support, one piece of your own experience that fits, and one example of why reliability for ordinary users matters to you.

Questions & practice

How do you approach prioritizing your tasks when you are assigned to multiple projects with competing deadline

Medium · Situational & Problem Solving

How do you approach prioritizing your tasks when you are assigned to multiple projects with competing deadlines?

Approach

1. Put every commitment in one visible list with its deadline, its requester and the cost of missing it. Most priority conflicts come from work that only one person knows about.
2. Separate hard deadlines (legal or regulatory dates, a scheduled go-live, anything that stops a public service) from soft ones. Rank by consequence and urgency, not by who asked last or most loudly.
3. Estimate the work early so a collision shows up weeks ahead, not the day before. When capacity really is short, take options to your manager or the competing stakeholders: cut scope, move a date or add help. Let them decide the trade-off.
4. Tell the waiting stakeholders what is delayed, why, and when they will hear from you next, then keep that promise. Silent slips cause more damage than the delay itself.
5. Back it up with one specific story: two named projects, the trade-off you made, who agreed to it and how both turned out. Explain how you protected focus time against interruptions.

Follow-up

• What do you do when two managers each tell you their project comes first?
• Tell me about a time you missed a deadline anyway. What did you change afterwards?
• How do you re-plan when a production incident lands in the middle of a crunch week?

If you inherit a poorly documented legacy codebase, how do you go about understanding it and planning updates?

Medium · Situational & Problem Solving

Approach

1. Get it building and running in a non-production environment first. Record the real build steps, configuration, dependency versions and deployment process, because those are usually the least documented parts.
2. Map it from the outside in. Trace one real user flow end to end, read the database schema and stored procedures it relies on, and use logs, version control history, old tickets and conversations with the people who use or once maintained it.
3. Before changing behavior, write characterization tests that capture what the code does today, including the odd cases. Then a refactor that changes output is caught by a failing test instead of by a user.
4. Write documentation as you learn: an architecture diagram, a data-flow note and a runbook. The next person then starts where you stopped.
5. Plan updates by risk. Fix unsupported dependencies and security issues first, then make small reversible changes behind feature flags. Replace pieces gradually with the strangler fig pattern rather than a big-bang rewrite, and explain why a full rewrite rarely pays off.

Follow-up

• When would you argue for a full rewrite instead of incremental changes?
• How do you safely remove code you suspect is dead?
• How would you change a critical module that has no tests and no one left who understands it?

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

Easy · hashing · at-least-once · aggregation

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

Approach

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

Follow-up

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

Stop tag and share joins from fanning out a page

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

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

Approach

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

Follow-up

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

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?

How do you approach integrating modern web applications with legacy backend databases?

Medium · Technical & Domain Knowledge

Approach

1. Put a service layer between the web app and the legacy database instead of letting the new app query legacy tables directly. That layer translates legacy schemas and codes into clean API responses (an anti-corruption layer), so the schema can later change behind it without breaking the front end.
2. Treat the legacy database as the system of record and avoid dual writes from the app. If data has to reach a new store, use a transactional outbox or change data capture so one transaction can never update one store and miss the other. Give write endpoints idempotency keys so a retry after a timeout cannot apply the same change twice.
3. Protect the old system. Use parameterized queries or the stored procedures the DBAs already own, a connection pool sized to what the legacy server can handle, and caching or a read replica for heavy read and reporting traffic. Check the execution plans of new queries before they reach production.
4. Plan for legacy data quirks: padded CHAR columns, dates stored as strings, blanks used where NULL belongs, odd character encodings. Write contract tests against a copy of the real schema, not hand-made fixtures.
5. Roll out piece by piece with the strangler fig pattern: route one feature at a time to the new path behind a feature flag, compare old and new outputs, and keep a rollback path for each step.

Follow-up

• How would you keep the legacy database and a new datastore consistent while both are in use?
• What would you do if the new portal's traffic started to slow down the legacy system for internal users?
• How would you test against realistic data without copying residents' personal information into a dev environment?

Describe your familiarity with web accessibility standards (such as ADA compliance and WCAG) and how you imple

Medium · Technical & Domain Knowledge

Describe your familiarity with web accessibility standards (such as ADA compliance and WCAG) and how you implement them in your code.

Approach

1. Name the standards and how they connect. The 2017 Section 508 refresh incorporates WCAG 2.0 Level A and AA, and the 2024 DOJ ADA Title II rule for state and local government web content uses WCAG 2.1 Level AA. Build to WCAG 2.1 AA or later and you meet both.
2. Start with semantic HTML. Use a real button instead of a clickable div, a label tied to every input, headings in order, and landmarks such as nav and main. Add ARIA only when no native element does the job, because a wrong ARIA role is worse than none.
3. Make every flow work with a keyboard: a logical tab order, a visible focus indicator, no keyboard traps, and focus moved deliberately when a modal opens or a single-page app changes route. Return focus when the modal closes.
4. Cover the perceivable rules. Give meaningful images alt text, meet AA contrast (4.5:1 for normal text, 3:1 for large text), never use color as the only signal, link form errors to their fields with aria-describedby, and announce status changes through an aria-live region.
5. Test it. Automated tools such as axe-core or Lighthouse catch only part of the issues, so run them in CI and add a manual keyboard pass plus a screen reader check (NVDA, JAWS or VoiceOver) before release. Make that part of the definition of done.

Follow-up

• How would you make a custom dropdown or date picker accessible?
• An existing public form fails an audit with dozens of issues. Which do you fix first?
• How do you handle PDFs and documents that residents have to read or fill out?

What is your process for securing application endpoints and protecting sensitive user data?

Medium · Technical & Domain Knowledge

Approach

1. Authentication: use a central identity provider through OIDC/OAuth 2.0 instead of rolling your own. On every request, validate the token's signature, issuer, audience and expiry. Keep tokens short-lived, and if you use cookies, set HttpOnly, Secure and SameSite.
2. Authorization: check it server-side on every endpoint and deny by default. Add an object-level check that the requested record belongs to the caller or is allowed by the caller's role. This prevents IDOR, where someone changes an ID in the URL and reads another person's record.
3. Input and output: use parameterized queries everywhere to prevent SQL injection, validate request bodies against a schema, encode output to prevent XSS, protect cookie-based sessions from CSRF, and rate-limit login and lookup endpoints.
4. Data protection: use TLS in transit and encryption at rest, with field-level encryption or tokenization for the most sensitive fields such as SSNs. Collect only the data you need, mask sensitive values in logs, keep secrets in a vault instead of code or config files, and give the app's database account least privilege.
5. Verification: keep an audit log of who accessed which sensitive record, run dependency and static scanning in CI, review against the OWASP Top 10 or ASVS, and arrange a penetration test before a public launch.

Follow-up

• How would you stop a logged-in resident from viewing another resident's case by editing the ID in a request?
• Where do you store database credentials, and how would you rotate them without downtime?
• What do you log for a sensitive-data endpoint, and what must never appear in the logs?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

The plan follows the reported loop: requirements and motivation first, then database and technical answers, incident and stakeholder stories, and timed writing, ending with a full panel rehearsal. Practice-library questions are pointed to where they build the same skills.

Day 1 — Map the five stages and the requirement list

• Write the five reported stages in order and note what you can prepare for each, marking the writing exercise as part of the second-round panel.
• Match each listed requirement (enterprise language, relational database, Git, web security, plus any cloud or legacy migration work) to a project, with dates, and mark the gaps.

Deliverable: A one-page loop map and a requirement-to-project table with the gaps marked.

Day 2 — Your database and SQL story

• Write the database design and complex SQL story: schema, the hardest query, the index or plan change and the measured result.
• Work the practice question on stopping joins from fanning out a page to rehearse reasoning about join shape and row counts.
• Rehearse the slow-query walkthrough aloud: reproduce, read the plan, check indexes and statistics, change one thing, measure.

Deliverable: A written database story outline, a solved practice question and a recorded spoken walkthrough of a slow query.

Day 3 — Technical answers: legacy integration, accessibility and security

• Outline an answer for connecting a modern web application to a legacy database, including a service layer, parameterised queries and a migration path.
• Outline an accessibility answer covering WCAG, semantic HTML, keyboard use, labels, contrast and how you test.
• Outline an endpoint-security answer covering authentication, authorisation, input validation, encryption and logging, and add the first steps for an undocumented codebase.

Deliverable: Three one-page answer outlines, each with a concrete example from your own work.

Day 4 — Incident story and diagnosis

• Write your application-failure story in the order impact, containment, diagnosis, fix, prevention.
• Work the practice debugging question on one log partition stalling while others drain, naming each check in the order you would run it.
• Speak the story aloud and trim it until the containment step is stated before the root-cause step.

Deliverable: A written incident story and a one-page diagnostic checklist from the practice debugging question.

Day 5 — Timed writing exercise

• Write the maintenance-window email to a department head in 20 minutes, then reread for jargon.
• Write the branching-strategy guide for junior developers in 20 minutes, with headings and a numbered workflow.
• Write a short incident report using a fixed layout and compare all three against a checklist: purpose first, plain words, next step stated.

Deliverable: Three timed written pieces and a revised checklist of your own recurring mistakes.

Day 6 — Stakeholder, conflict and prioritisation stories

• Write the stakeholder-versus-security-policy answer with a compliant alternative and an escalation step.
• Write the non-technical explanation story and the technical disagreement story, each naming your own actions.
• Outline your prioritisation method for competing deadlines and the sentence you use to tell a stakeholder their deadline will slip.

Deliverable: Four story outlines in situation, decision, risk, result order.

Day 7 — Full panel rehearsal

• Run a full mock panel with a friend or a recording: motivation, database story, one technical question, incident story, stakeholder story.
• Work the practice problem on collapsing a redelivered event batch to keep your reasoning sharp, then review the recording and cut filler.
• Finish by checking your references and employment dates against what a background check will verify.

Deliverable: A recorded mock panel, a list of three fixes, and a confirmed reference list.

Panel stories for a county IT role

Candidates describe panels that ask the same set of questions of every applicant, with a mix of technical, situational and behavioral prompts. Prepare one story for each: a failure you resolved, a competing-deadline decision, a security-policy conflict, an explanation to a non-technical person, a technical disagreement, and your reason for choosing public service. Use first person singular and name what you personally did.

1. Describe a major technical project you completed from end to end, highlighting your specific contributions and how you measured success.

Explain your experience with database design and writing complex SQL queries.

Medium · Technical & Domain Knowledge

Approach

1. Choose one project where you owned database work and say what the system stored and who used it. Then walk through the schema: the main entities, primary and foreign keys, constraints that enforce rules, and where you normalised or deliberately denormalised and why.
2. For the complex SQL part, name the query shape you wrote: multi-table joins, aggregation with GROUP BY and HAVING, CTEs, window functions such as ROW_NUMBER or running totals, or a recursive query. Say which engine you used (SQL Server, Oracle or PostgreSQL) and only claim dialect features you have used.
3. Show how you checked the result: read the execution plan with EXPLAIN or the engine's plan viewer, added an index chosen from the filter and join columns, and compared timing or row counts before and after.
4. Separate your work from the DBA's. State what you decided yourself (query design, index suggestions, migration scripts) and what you handed over, so the panel hears your contribution rather than the team's.
5. Close with the result and one lesson, for example a report that went from timing out to usable, or a constraint that caught bad data before it reached users.

Follow-up

• How do you find out why a particular query is slow, and what would you check first?
• When would you denormalise a table, and what does it cost you in maintenance?
• How would you change a table that is in use without breaking the application that reads it?

Describe a time when a critical application failed. What steps did you take to diagnose, troubleshoot, and res

Medium · Situational & Problem Solving

Describe a time when a critical application failed. What steps did you take to diagnose, troubleshoot, and resolve the issue under pressure?

Approach

1. Pick a real failure you helped resolve and open with the impact in plain terms: which application, who could not use it, and what was at risk, such as a public portal being down or records being wrong.
2. Describe the sequence in order: how you detected it (alert or ticket), how you scoped it, and what you did to stop the damage first, such as a rollback, disabling a feature or failing over, before looking for the root cause.
3. Then the diagnosis: which logs and metrics you read, what recently changed (a deploy, a data load, a configuration or an upstream dependency), how you narrowed to a cause, and how you confirmed it before applying the fix.
4. Cover communication under pressure: who you updated, how often, and in what words for non-technical stakeholders.
5. End with the follow-up that stops a repeat: a test, an alert, a runbook entry or a review of the release process, and say what changed because of it. A story that stops at the fix is incomplete.

Follow-up

• How did you decide between rolling back and fixing forward?
• What did you tell the affected business users while it was still down?
• What monitoring or test did you add afterwards, and did it catch anything later?

How would you handle a situation where a department stakeholder requests a feature that conflicts with standar

Medium · Situational & Problem Solving

How would you handle a situation where a department stakeholder requests a feature that conflicts with standard security policies?

Approach

1. Start with the need behind the request. Ask the stakeholder what outcome they are after, who needs access or visibility, and what problem it solves, because the stated feature is often only one way of meeting it.
2. Name the specific policy and the risk it guards against, such as exposure of personal data or weak access control, and say it in terms the stakeholder cares about, not as a rule you recite.
3. Offer compliant options: a role-limited view, masked or aggregated fields, an approved sharing channel, extra audit logging, or a phased delivery. Explain what each gives them and what it costs in time.
4. If no alternative meets the need, take it to the security analysts or policy owner for a decision and keep the stakeholder informed. Do not build around the policy quietly and do not refuse without an alternative.
5. Record the outcome in writing: what was requested, the decision, who made it and the follow-up date, so the next engineer is not asked the same thing without context.

Follow-up

• What would you do if the stakeholder escalated to your director?
• How would you respond if no compliant way of delivering the feature existed?
• How would you document an approved exception so it is reviewed later?

Describe a situation where you had to explain a complex technical concept to a non-technical stakeholder. How

Medium · Behavioral & Collaboration

Describe a situation where you had to explain a complex technical concept to a non-technical stakeholder. How did you ensure they understood?

Approach

1. Choose a concept the listener needed in order to make a decision, such as why a maintenance window has to run longer, why a data change affects a report, or what an access restriction means for their staff. State who the listener was and what they had to decide.
2. Lead with the consequence for them, then the reason. Use an analogy from their own work (a records office, a case file, a counter queue) and avoid acronyms; define any term you cannot avoid.
3. Describe the check for understanding: you asked them to restate the plan in their own words, walked through one concrete scenario, or asked what they would tell their team. A nod is not confirmation.
4. Mention the written follow-up, such as a short email with the decision, the date and the next step, because the exercise and the role both involve writing for non-technical readers.
5. State the result: a decision made, a risk avoided or a request withdrawn. The weak version of this story is one where you only simplified the language and never confirmed they understood.

Follow-up

• How would you adapt the same explanation for someone who needs more technical detail?
• What did you do when the stakeholder still disagreed after the explanation?
• How did you confirm in writing that everyone had the same understanding?

Tell us about a time you had a disagreement with a team member or supervisor regarding a technical decision. H

Medium · Behavioral & Collaboration

Tell us about a time you had a disagreement with a team member or supervisor regarding a technical decision. How did you resolve it?

Approach

1. Choose a disagreement with a real technical substance, such as a data model, a framework choice, a release approach or how much to refactor, and state both positions fairly. If your account makes the other person look foolish, the story fails.
2. Say what you did to settle it with evidence: a small prototype, a benchmark, a comparison against criteria like maintainability, risk and delivery date, or a review of what the existing standards required.
3. Describe the resolution honestly. It may be that you changed your mind, that you reached a compromise, or that your supervisor decided against you and you carried out the decision fully. Each of those is acceptable if you explain it.
4. Show the working relationship afterwards: you kept collaborating, documented the decision, and checked later whether it held up.
5. Keep it to one decision and your own actions. Avoid saying we decided without naming what you personally argued and did.

Follow-up

• What would you do if your supervisor decided against your recommendation and you still thought it was wrong?
• What did the outcome show about the option you argued for?
• How has this changed the way you raise technical disagreements?

Why do you want to work as a Software Engineer for the County of Alameda, and what does public service mean to

Medium · Behavioral & Collaboration

Why do you want to work as a Software Engineer for the County of Alameda, and what does public service mean to you?

Approach

1. Give three connected parts: why this work, why this employer, and why you. For the work, connect to what the role covers: public-facing portals and internal systems that support services such as healthcare, social services, public safety and property management.
2. For you, name experience that fits the reported needs: modernising or maintaining older systems, database work, security-minded development or accessible interfaces. Tie each to a short example, not a list of adjectives.
3. Describe what public service means to you through something concrete: a time you built or fixed something where the people on the other end had little choice but to use it and needed it to work.
4. Show you know the working conditions you are choosing, including a structured hiring process, formal review and compliance steps, longer timelines than a startup, and a preference for stable systems over experimental ones, and say why that suits you.
5. Avoid reasons about job security or pay as the main point, and avoid claims about the County you cannot support. Keep it to what you have read in the job posting and what you have done.

Follow-up

• How would you cope with a slower, more process-driven environment than your current one?
• Which part of your experience transfers most directly to a county department?
• What would you want to learn in your first few months in this role?