Interview guides · Alameda County Water District

Alameda County Water District Software Engineer Interview Guide

Alameda County Water District Software Engineer interview guide: four reported rounds, exam prep, panel question outlines and a 7-day plan.

The 60-second brief

Alameda County Water District (ACWD) is a public water district that supplies drinking water to residents and businesses. Candidates describe the software role as internal engineering for that operation: applications that help hydrogeologists work with groundwater data, integrations with SCADA (Supervisory Control and Data Acquisition) systems, dashboards, automated data pipelines, and relational databases that hold records used for state and federal environmental compliance. They also describe upkeep of older systems, including code audits, security patches and database migrations with no downtime. The users are colleagues such as engineers, hydrogeologists and water quality staff, not consumers.

This guide is for candidates applying to the Software Engineer position at Alameda County Water District, from recent graduates to engineers with a few years of enterprise experience (candidates mention Engineer 1 and Engineer 2 bands). It covers the four reported stages, the reported technical, behavioral and scenario questions, answer outlines for each, and a seven-day plan that mixes written-exam skills, database and debugging practice, and story preparation.

Candidates report four stages over roughly 3-5 weeks: Phone Screen, Written Entrance Exam, Panel Interview and Final Interview. The exam is described as a gate before the panel, and the final interview as a step for the strongest panel candidates.

Focus areas

Hydrogeology Fundamentals
Software Engineering Fundamentals
Water Quality Engineering Concepts

Overview

The work candidates describe is data stewardship more than product building. The databases hold compliance records, the dashboards and scripts surface groundwater and water quality readings, and the legacy systems have to keep running while they are patched or migrated. Preparation should therefore lean on relational databases and SQL, data integrity during a migration, debugging a failure that raises no error, and secure coding, because those are the skills the reported technical questions and the role requirements point at.

The reported question set falls into three groups. The technical group covers migrating records from a legacy database, debugging a silent production failure, REST versus SOAP, tuning a slow SQL query and securing software against common vulnerabilities. The behavioral group covers working inside regulatory or procedural constraints, a technical disagreement, why a public water district rather than a private tech company, learning something new quickly, and vague or shifting requirements. The scenario group covers an internal application going down during a major operational event, a feature request that needs three months but is wanted in three weeks, and replacing a manual data-entry process a team has used for ten years.

Candidates also report a panel that mixes HR staff with technical staff, standardized questions asked of every candidate, and in some loops a printed list of questions handed over shortly before the panel. That makes two skills worth drilling beyond the technical content: outlining a structured answer quickly, and explaining a technical point once in plain language and once with technical detail. No water quality or hydrogeology background is reported as required, but a one-sentence working definition of SCADA, GIS and IoT sensor data is cheap preparation because candidates mention them as less common topics.

The Alameda County Water District interview process

These are the four stages candidates describe, in the order they report them. Each entry separates what is reported from how to prepare for it.

Phone Screen

Candidates report an initial call that checks baseline qualifications, experience and interest in the role against the job posting. It is described as administrative with a light technical check rather than a deep technical session. Treat it as a short, accurate match between your background and the posting: the languages, SQL experience and documentation habits the requirements list.

What to demonstrate

Whether you meet the minimum requirements in the posting, such as a relational database background and at least one major language
Whether your experience fits the role as posted
Whether you show interest in the role

How to prepare

Write a short walk through your experience that names your strongest language (Python, Java, C# or C++ are the ones listed) and your SQL work
Prepare a brief answer to why a public water district rather than a private tech company, using the outline in the matching question guidance
Decide in advance which Engineer band your experience fits and be ready to explain why
Ask what the written entrance exam covers so you can prepare for its format

Written Entrance Exam

The Written Entrance Exam is a standardized test that candidates report you must pass before the panel. In summary, it covers logic, interpreting data such as tables and charts, and basic programming including SQL and debugging. Candidates describe it as easy with a solid computer science foundation and not an algorithm whiteboard, but also as a filter, so prepare for fundamentals rather than puzzles.

What to demonstrate

Logical reasoning on conditional statements and simple control flow
Accurate reading of tables, charts and data sets, including conclusions drawn from them
Basic SQL querying, debugging and general programming principles

How to prepare

Hand-trace short snippets with nested if/else and loop conditions, writing the value of each variable at each step
Practise reading a table of readings and computing averages, maximums, ranges and percent changes without a spreadsheet
Write SELECT, JOIN, GROUP BY, HAVING and NULL-handling queries from memory against a samples table with a site, a date and a result
Practise finding off-by-one, wrong-operator and unit-mismatch bugs in short code listings

Panel Interview

Candidates describe the Panel Interview as a multi-stage conversation with HR representatives and technical staff, run to a standardized rubric with the same questions for every candidate. A printed list of questions may be handed over a few minutes beforehand, and the panel may take notes without much conversational feedback. Reported topics center on a secure internal tool and legacy database integration, gathering requirements from non-technical users, and handling shifting deadlines, regulations and technical disagreements. SCADA, IoT sensor data, GIS software and public data security standards come up less often. Reported example scenarios include explaining a technical limitation to a non-technical stakeholder, designing a schema for daily water quality samples from several testing sites, and prioritising urgent requests from different departments.

What to demonstrate

Technical skills, which is the stated purpose of the panel
Cultural fit, also reported as a purpose of the panel
Answers that work for both the HR representatives and the technical staff in the room

How to prepare

Sketch a schema for daily water quality samples: sites, samples, parameters, results with units and collection time, and a uniqueness rule that stops duplicate readings
Plan how periodic sensor or SCADA readings would load into that schema: timestamps stored in UTC, idempotent loads keyed on site, parameter and time, and a rule for late or missing readings
Prepare one plain-language explanation of a technical limitation, then a second version with the technical detail underneath
Outline STAR stories for the regulatory-constraint, disagreement and changing-requirements prompts before the loop, and write a prioritisation rule you can state aloud for competing urgent requests (operational impact, deadline, effort)

Final Interview

The Final Interview is described as an executive or director-level conversation for the top candidates, usually the top three from the panel, to finalize the hiring decision. Little else is reported about its content, so the advice here is the writer's: prepare for a senior audience by having your motivation for public-sector work, your two or three strongest examples, and a few questions about the software team ready.

What to demonstrate

Reported purpose: it finalizes the hiring decision after the panel
Reported access: it is reserved for top candidates, usually the top three from the panel
What a senior listener may want to hear is not reported, so treat your strongest examples and your reasons for the role as preparation, not as a known criterion

How to prepare

Rehearse the answer to why a public water district rather than a private tech company until it is short and cites one concrete experience
Pick two stories from the panel round and shorten each to a headline, an action and a result with little jargon
Prepare questions about the current tech stack, modernization work and how the software team works with the hydrogeology staff, which candidates are advised to ask
Know the difference between SCADA, GIS and a general database system well enough to use each term correctly

Where candidates lose points

Spending the pre-read time on the technical questions and walking into the behavioral ones unprepared

Candidates report that a printed list of questions may be handed over shortly before the panel. Prepare STAR outlines for the regulatory-constraint, disagreement and changing-requirements prompts beforehand, then use the pre-read time to select a story and write a few bullet points, not a script.

Treating the written entrance exam as too easy to prepare for

Candidates call it easy but report that it works as a filter before the panel. Spend a session on hand-tracing conditionals, reading tables and writing basic SQL (joins, grouping, NULL handling) so a careless mistake does not end the process.

Answering the migration question with a list of tools instead of a verification plan

Say what you check and in what order: row counts per table, key and constraint checks, checksums or sampled record comparison, reconciliation of totals, a dry run on a copy, a rollback plan and a parallel-run period before cut-over.

Answering the mixed HR and technical panel in only one register

Open each answer with a plain-language headline, then add one layer of technical detail. Candidates report both HR and technical staff on the panel, so an answer that is pure jargon or pure generality leaves one half of the room without what it needs.

Presenting procedure and compliance as obstacles you worked around

In regulatory and disagreement stories, show how you worked inside the rule: the control you added, the approval you obtained, the documentation you left. Candidates describe following procedure and accuracy as central to the role, so a story about bypassing a step works against you.

Questions & practice

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

Easy · hashing · at-least-once · aggregation

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

Approach

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

Follow-up

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

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

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?

How would you optimize a SQL query that is taking too long to execute on a massive dataset?

Medium · Technical and Domain Knowledge

Approach

Measure before changing anything: get the actual plan (EXPLAIN ANALYZE in PostgreSQL, the actual execution plan in SQL Server, EXPLAIN ANALYZE in MySQL 8) and find the most expensive node, sequential scans on large tables, sorts or hashes spilling to disk, and places where estimated and actual row counts differ widely (stale statistics: run ANALYZE or UPDATE STATISTICS).
Index for the predicate: a composite B-tree with the equality columns first and the range column last, for example (site_id, sample_date) for 'readings for one site in a date range'. For a covering index, PostgreSQL 11+ and SQL Server accept INCLUDE columns; MySQL has no INCLUDE, so append the extra columns to the composite key instead. Weigh the extra cost every index adds to inserts and updates.
Make predicates sargable: replace WHERE YEAR(sample_date) = 2024 with a date range, avoid implicit type conversions on indexed columns and leading-wildcard LIKE '%x', and select only the columns you need instead of SELECT *. ORs across different columns can often still use separate indexes (PostgreSQL BitmapOr, SQL Server index union); rewrite as UNION ALL only when the plan shows a full scan.
Cut the work: filter before joining, check that no join is unexpectedly one-to-many, rewrite correlated subqueries as joins or EXISTS, and paginate with a keyset (WHERE id > last_id) rather than a large OFFSET. For very large time-series tables, partition by date so the planner prunes old partitions, or serve repeated reports from a summary table or materialised view.
Verify on production-sized data, compare plans and timings before and after, and build indexes on a live table without blocking writes (CREATE INDEX CONCURRENTLY in PostgreSQL, ONLINE = ON in SQL Server Enterprise).

Follow-up

The index exists but the plan still shows a full scan. What are the likely reasons?
The query is fast in development and slow in production. What do you compare first?
When would you decide not to add an index?

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?

How do you ensure data integrity when migrating records from a legacy database to a new system?

Medium · Technical and Domain Knowledge

Approach

Profile the legacy data before moving anything: row counts per table, null rates, duplicate natural keys, orphaned foreign keys, character encoding (legacy Windows-1252 vs UTF-8) and mixed date formats. Turn that into a field-level mapping that states the type conversion and the rule for every bad case: reject, default, or route to a quarantine table.
Load into a staging schema first, then into a target that enforces NOT NULL, UNIQUE, FOREIGN KEY and CHECK constraints, so bad rows fail loudly instead of slipping in. Key each load on the source primary key and use upserts, so a rerun after a failure cannot create duplicates; commit in batches so one bad batch rolls back cleanly.
Reconcile after every run: row counts per table and per natural partition (for example per sampling site per month), SUM/MIN/MAX of numeric columns, and a per-row hash of normalised column values compared between source and target. Add a spot check where the people who own the data confirm a sample of records.
Plan the cutover: rehearse on a copy of production, capture changes made during the migration window (a last-modified timestamp or change data capture) and apply the delta, keep the legacy system read-only as a rollback path, and log every rejected row with its reason.
Call out the quiet corruptions: timezone and daylight-saving shifts on timestamps, float-to-decimal precision loss on measurements, trimmed or padded strings, and codes whose meaning changed over the years in the legacy system.

Follow-up

The legacy system has to stay in use while you migrate. How do you handle records written during the migration?
How would you show an auditor that no record was lost or altered in the move?
What do you do with rows that fail validation and nobody can say what the right value is?

Explain the differences between REST and SOAP APIs, and when you might use one over the other.

Medium · Technical and Domain Knowledge

Approach

REST is an architectural style: resources identified by URLs, standard HTTP methods with defined semantics (GET, PUT and DELETE are idempotent; POST is not), HTTP status codes for outcomes, stateless requests and any representation (usually JSON). GET responses can be cached by HTTP intermediaries when the server sets Cache-Control or ETag headers; caching is not automatic. A contract is optional, often written in OpenAPI.
SOAP is a protocol: an XML Envelope with Header and Body, errors returned as a Fault element, usually sent as HTTP POST, and a formal contract in WSDL with XSD types that tools use to generate strongly typed clients. It comes with the WS-* standards, such as WS-Security for message-level signing and encryption.
Trade-offs: SOAP payloads and tooling are heavier, but the contract is strict and its security travels with the message through intermediaries. REST is lighter and works directly from browsers and scripts, and relies on TLS for transport security plus tokens such as OAuth 2.0 for authorisation.
When to choose: REST for new internal tools, dashboards and data APIs. SOAP when the system you integrate with only exposes a WSDL (common in older enterprise and vendor products), or when a formal contract or message-level security is required. A practical middle path is to put a REST adapter in front of a SOAP vendor service so the rest of the codebase never touches XML.

Follow-up

How would you call a vendor's SOAP service from a Python or C# application?
Which HTTP methods are idempotent, and why does that matter when a client retries after a timeout?
How would you version a REST API without breaking clients that already depend on it?

What steps do you take to ensure the software you build is secure against common vulnerabilities?

Medium · Technical and Domain Knowledge

Approach

Organise the answer around the OWASP Top 10. For injection, use parameterised queries with bind parameters and never build SQL by string concatenation. For XSS, encode output for its context. For CSRF, use anti-CSRF tokens and SameSite cookies.
Access control: check authorisation on the server for every request, not just by hiding buttons in the UI (broken access control is first in the 2021 OWASP list). Apply least privilege everywhere, including database accounts that get only the grants the application needs, and require MFA for administrative access.
Secrets and data: keep credentials out of source control and load them from a secrets manager or environment, use TLS in transit and encryption at rest, and hash passwords with bcrypt, scrypt or Argon2, never MD5 or SHA-1. Never write secrets or personal data to logs.
Build it into the process: dependency scanning (pip-audit, npm audit, Dependabot) and static analysis in CI, a security item on the code-review checklist, a regular patching schedule, and a short threat model for any feature that adds an external interface.
For integrations that touch operational systems such as SCADA data feeds, give the application read-only access where possible, segment it at the network level, and log security-relevant events (logins, permission changes, failed access) so they can be audited.

Follow-up

Explain how a SQL injection attack works and exactly why a bind parameter stops it.
A scan flags a critical CVE in a library a legacy application depends on and the upgrade breaks it. What do you do?
How would you store and rotate the database password a scheduled job uses?

If a critical internal application goes down during a major operational event, what are your immediate first s

Medium · Scenario and Problem-Solving

If a critical internal application goes down during a major operational event, what are your immediate first steps?

Approach

Triage and communicate first: confirm the scope (which users and functions are affected, since when, fully down or degraded), have one person coordinate, and tell operations staff what is known and when the next update will come.
Restore service before chasing the root cause, but save evidence first: capture logs, metrics and timestamps so the cause can still be found afterwards. Then check what changed most recently and roll back a recent deploy or configuration change, and check dependencies in order: database, network and DNS, authentication, disk space, memory, expired certificates. Restart or fail over as needed.
If service cannot be restored quickly, switch operations to the documented manual fallback so the operational event is not blocked by the software. Deciding when to fall back is part of the answer.
After recovery, check for data gaps from the outage window (entries or readings that were never recorded), backfill them from the source and verify the result. Close with a blameless post-incident review: a timeline, the root cause, and concrete actions such as a monitoring alert, a runbook update or removing a single point of failure.

Follow-up

The rollback does not fix it. What do you check next?
How do you decide when to stop debugging and move operations to the manual fallback?
What would you put in the runbook so the next responder recovers faster?

You are tasked with automating a manual data-entry process that a team has used for ten years. How do you appr

Medium · Scenario and Problem-Solving

You are tasked with automating a manual data-entry process that a team has used for ten years. How do you approach the transition to ensure they adopt the new software?

Approach

Shadow the current process before designing anything: watch people enter the data, record every step, the checks they do in their heads, the exceptions they handle informally, and where the data goes afterwards. Measure a baseline (time per record, error or correction rate) so improvement can be shown later.
Design the software around those rules: required fields, range checks and dropdowns for controlled values, importing directly from existing sources (instrument exports, CSV files) instead of retyping, and an audit trail of who entered or changed each record and when.
Migrate the historical records with reconciliation (counts, totals, spot checks), then run the new system in parallel with the old process for a defined period and compare the outputs before cutting over.
Plan for adoption: recruit a member of the team as an early tester and champion, release the most painful step first, provide hands-on training and a short written guide, keep a clear feedback channel, and keep the old process available as a fallback until the outputs match.
Cover the edge cases the manual process absorbed without anyone noticing: rare record types, corrections to past entries, entry from the field without a connection, and who owns the data once the spreadsheet or paper form is retired.

Follow-up

A senior team member refuses to switch and keeps using the old process. What do you do?
How would you show that the new system is more accurate than the manual process?
The historical records contain years of inconsistent entries. How do you handle them in the migration?

Walk us through your process for debugging an application that is failing silently in production.

Medium · Technical and Domain Knowledge

Approach

Pin down the symptom before forming theories: which output is wrong or missing (a report with fewer rows, a job that writes nothing), since when, and for which inputs. Then list what changed around that time: deploys, configuration, upstream schema changes, expired credentials or certificates, a full disk, a scheduler change.
Look for where the error is being swallowed: catch-all exception handlers that log nothing, background jobs whose exit codes nobody checks, a log level that hides the relevant messages, retries that give up quietly, dead-letter queues. Check scheduler history and database logs, not only application logs.
If the code has no visibility, add it: structured log lines with a correlation id at each stage, plus records-in and records-out counters per stage. Bisect the pipeline by finding the first stage where the counts diverge.
Reproduce with the failing input in a non-production environment loaded with production-like data, write a failing test, fix it, and confirm the test passes. Avoid experimenting directly on the production system that holds operational data.
Make the next failure loud: alert on zero records processed, a missing heartbeat or a stale last-success timestamp, and replace the swallowing handler with one that logs and re-raises.

Follow-up

The logs show nothing at all for the failing period. What do you do next?
The bug only reproduces in production. How do you investigate without risking operational data?
How would you make sure this class of silent failure gets caught automatically in future?

Suggested practice checklist

The plan follows the reported loop: the written exam fundamentals first, then the reported technical questions on databases, debugging, APIs and security, then the behavioral and scenario stories, and a final full rehearsal of a panel with a short pre-read window.

Day 1 — Map the loop and your evidence

Write the four reported stages in order and note what each one asks of you: a posting match, an exam, a mixed panel and a senior conversation.
List the posting's requirements (relational databases and SQL, one major language, technical documentation) and next to each write one project that proves it.
List six possible stories from your own work: a rule you worked within, a disagreement, learning a new area quickly, changing requirements, a hard stakeholder conversation and an outage.

Deliverable: A one-page loop map plus a table of requirements against evidence and six named story candidates.

Day 2 — Written exam fundamentals

Write ten SQL queries from memory against a samples table (site, sample date, parameter, result): filters, joins to a sites table, GROUP BY with HAVING, and NULL handling.
Hand-trace five snippets with nested conditionals and loops, writing the variable values at each step.
Take a table of daily readings and compute average, maximum, range and percent change by hand, then check with a spreadsheet.

Deliverable: Ten written queries with expected output, five annotated traces and one worked data-interpretation table.

Day 3 — Databases: migration, schema and tuning

Design a schema for daily water quality samples from multiple testing sites, with keys and a uniqueness rule, and write the three queries you would run most often.
Write a migration checklist for moving records from a legacy database: row counts, key checks, checksums, sampled comparison, dry run, rollback and parallel run.
Take a slow query, read its execution plan, and write down the index or rewrite you would try and why.

Deliverable: A schema diagram, a migration verification checklist, a tuning write-up for one slow query, and a worked solution to the concurrent-edit exercise.

Day 4 — Debugging, APIs, security and outage response

Write a step-by-step sequence for a silent production failure: what changed, logs and instrumentation checks, reproducing, narrowing down and confirming the cause.
Build a REST versus SOAP comparison covering message format, contracts, transport, error handling and when each fits an integration with an older system.
Write a security checklist for an internal tool: input validation, parameterised queries, authentication and authorization, secrets handling, patching and logging.
Write a first-steps runbook for an internal application going down during a major operational event.

Deliverable: A debugging sequence, a REST/SOAP comparison table, a security checklist and an outage runbook, each short enough to explain aloud.

Day 5 — Behavioral stories, part one

Write STAR outlines for the regulatory-constraint story, the technical-disagreement story and the learning-something-new story, with the result stated in numbers where you have them.
Say each story aloud and cut it until the situation takes two sentences and most of the time goes on your reasoning.
Add one follow-up answer to each: what you would change next time.

Deliverable: Three one-page STAR outlines and a recording of each story told aloud.

Day 6 — Motivation, stakeholders and scenarios

Write and rehearse the answer to why a public water district rather than a private tech company, with one concrete experience in it.
Script the three-months-versus-three-weeks conversation with a hydrogeologist: clarifying questions, three options and the written follow-up.
Outline how you would replace a ten-year-old manual data-entry process: observe the team, run old and new in parallel, train, collect feedback, then retire the old one.
Write your method for vague or changing requirements: acceptance criteria, a thin first slice and a change log.

Deliverable: A short motivation answer, a scripted stakeholder conversation, a transition plan and a requirements-handling method.

Day 7 — Full panel rehearsal

Give a friend or a recorder a printed list of five reported questions and allow yourself a short pre-read window to outline them, then answer all five aloud.
Answer each technical question twice: once in plain language and once with the technical detail.
Prepare three questions to ask the panel about the tech stack, modernization work and how the software team works with the hydrogeology staff, and a closing summary for a senior listener.

Deliverable: A recorded rehearsal with a list of answers to fix, three panel questions and a short closing summary.

Stories for a mixed HR and technical panel

Candidates report that HR representatives sit on the panel with technical staff and that questions are standardized, so your stories have to be clear to a non-engineer and still show engineering judgment. For this role the stories that fit best involve procedure and accuracy, working with non-technical users, and learning an unfamiliar area quickly.

Describe a time you had to explain a complex technical limitation to a non-technical stakeholder. How did you ensure they understood?

Tell us about a time you had to work within strict regulatory or procedural constraints. How did you handle it

Medium · Behavioral and Public Service Alignment

Tell us about a time you had to work within strict regulatory or procedural constraints. How did you handle it?

Approach

Choose a story where a rule shaped your design: an audit trail, change-approval step, retention requirement, access restriction or sign-off. Candidates describe the role as maintaining databases that track regulatory compliance, so a story about records, auditability or controlled change maps closely.
Name the constraint precisely in the first two sentences, then show how you translated it into checkable controls: what you logged, who approved, what you documented, and how you proved the work met the rule.
Show judgment inside the constraint. Describe where the procedure slowed you down and how you shortened lead time legitimately, for example by getting approval early or reusing a pre-approved template, instead of bypassing the step.
Close with the result in concrete terms: the audit or review passed, no rework was needed, or the documentation let someone else repeat the process. Say what you would keep or change next time.

Follow-up

What did you do when the procedure was unclear or seemed to conflict with the schedule?
Did you ever suggest changing the process, and how did you raise it?
How did you document the work so another engineer could follow the same procedure?

Describe a situation where you disagreed with a colleague on a technical decision. How did you reach a resolut

Medium · Behavioral and Public Service Alignment

Describe a situation where you disagreed with a colleague on a technical decision. How did you reach a resolution?

Approach

Choose a disagreement over a real technical choice with two defensible options, such as patching a legacy component versus rewriting it, or one schema design versus another. A trivial disagreement or a personality clash gives you nothing to reason about.
State your colleague's position fairly before yours, then say what criteria you agreed to judge by, for example data integrity, maintenance cost, time to deliver or operational risk.
Show the evidence that moved the decision: a small prototype, a measurement, a review of past incidents, or a short written comparison. If a senior person had to decide, say how you presented both sides neutrally.
Be honest about the outcome. The story can end with you conceding, a compromise, or your option winning, as long as you describe what the working relationship looked like afterwards. Avoid casting the other person as simply wrong.

Follow-up

What if your colleague's approach had turned out to be the better one?
What would you have done if no data could settle the question?
How did you work with that person on later projects?

Why are you specifically interested in working for a public water district rather than a private tech company?

Medium · Behavioral and Public Service Alignment

Approach

This is a motivation question, not a STAR story. Give three parts: what about the work draws you (software tied to water quality records, groundwater data, monitoring and operations as candidates describe the role), why your working style fits it, and evidence from your own history.
Tie your style to what candidates report about the role: accuracy and procedure matter more than rapid iteration, systems run for years, and documentation is expected. A past project where correctness, testing or longevity mattered more than speed is your proof.
Be honest about background. Candidates report that water or hydrogeology experience is not required, so say what you already know, what you would learn, and give a one-line example of how you learned an unfamiliar domain.
Do not rely on stability or benefits as the main reason, and do not criticise private tech. State what the public setting gives you that you want, and keep the answer short.

Follow-up

What would you miss about working at a private tech company?
What do you already know about how the district operates, and what would you need to learn?
Where would you like your skills to be after a couple of years in this role?

Tell us about a time you had to learn a completely new technology or domain on the fly to complete a project.

Medium · Behavioral and Public Service Alignment

Approach

Choose a story with a real deadline and a real gap: a language, a data format, an integration or a regulated domain you had not used before. Name the date and what depended on the result.
Show your learning method instead of saying you learn quickly: you scoped the minimum you had to understand, read the primary documentation, asked someone who knew the area, and built a small spike before touching the real system.
Show how you checked your own understanding: tests, a code review by someone experienced, or a comparison against known-good output. Say what you got wrong at first and how you caught it.
Finish with what shipped and what you left behind, such as a short write-up or runbook. Candidates mention SCADA, GIS and sensor data as less common topics, so a story with unfamiliar domain data, or an unfamiliar legacy system, is a natural fit.

Follow-up

How did you decide you knew enough to ship?
What was your first wrong assumption, and what exposed it?
How did you pass on what you learned to the rest of the team?

How do you handle situations where project requirements are vague or constantly changing?

Medium · Behavioral and Public Service Alignment

Approach

Open with a mechanism instead of a trait. Turn each vague request into written, testable acceptance criteria, confirm them with the requester, and keep a short change log so later changes are visible decisions rather than drift.
Show how you reduce risk early: a thin working slice or mock-up the user can react to in the first days, and a design that keeps the likely-to-change parts, such as report fields or thresholds, in configuration rather than scattered through code.
Say what you do when a change arrives: assess its size, then renegotiate scope or date with the requester instead of absorbing it silently. Candidates describe non-technical users such as field engineers and water quality scientists, so say how you ask questions in their vocabulary.
Back it with one real project in which requirements moved, naming what changed, what you did and the outcome. Do not blame the stakeholder or answer with only 'I adapt quickly'.

Follow-up

What do you do when two stakeholders give conflicting requirements?
How do you stop a changing request from becoming unlimited scope?
When would you refuse to continue until the requirements were pinned down?

A hydrogeologist requests a new feature that you know will take three months to build, but they need it in thr

Medium · Scenario and Problem-Solving

A hydrogeologist requests a new feature that you know will take three months to build, but they need it in three weeks. How do you handle this conversation?

Approach

Do not answer yes or no first. Ask what is behind the three-week date: which decision, report or regulatory deadline depends on it, and which part of the feature they actually need then.
Offer options, each with its trade-off, in the requester's terms: a reduced version in three weeks, such as the one view, export or script that supports the immediate decision; the full feature in three months; or an interim manual workaround while the full feature is built. I would say: 'I can give you X in three weeks and the whole feature in three months; which of these helps your decision?'
Be explicit about what the shortcut costs. Because accuracy matters for operational data, say that you will not cut testing or validation to hit the date, and name what the reduced version will not do.
Agree the plan in writing and set a checkpoint. If the request competes with other urgent work, bring in your manager to set priorities instead of deciding alone. This is a scenario question, so answer as a plan, then add a real example if you have one.

Follow-up

What if they insist the whole feature must be ready in three weeks?
What would you cut first, and what would you refuse to cut?
How would you handle it if their supervisor asked for the same date?