City Of Fresno Software Engineer Interview Guide

The 60-second brief

City Of Fresno is a city government, and candidates describe the Software Engineer role as building and maintaining the software that supports city operations and services. Reported project areas include applications for public engagement, systems for managing city resources, and data analysis that feeds city planning. The role is described as working alongside product managers, designers and other engineers. The requirements candidates list name Python, Java or JavaScript, web frameworks such as React and Angular, and SQL or NoSQL databases, with AWS or Azure and data analytics tools as extras.

This guide is for engineers applying to City Of Fresno as a Software Engineer. Candidates describe the typical applicant as having a few years of software development experience, with public-sector technology work counted as a plus rather than a requirement. It covers each of the six reported stages, answer plans for all 25 reported questions (coding, design, debugging and estimation, behavioral), and a 7-day plan that ends in a full mock loop.

Candidates report six stages over roughly 4-6 weeks: Initial Screening, Technical Assessments, Interviews with Technical Team, Interviews with Non-Technical Team, Final Interview and Offer Discussion.

Focus areas

• Problem Solving
• Software Engineering (General)
• Programming Fundamentals

Overview

The reported work is application software for a city: tools residents use, systems that track and allocate city resources, and analytics that support planning. The requirements candidates list are a mainstream web stack. Python, Java or JavaScript for the language, React or Angular on the front end, SQL or NoSQL underneath, and cloud services and analytics tools as extras. For preparation that means one language you can code in fluently under observation, plus enough breadth to talk about the rest of the stack without bluffing.

The reported questions fall into five groups. Technical and domain questions ask about your languages, object-oriented principles, code quality, a hard past problem and Git. Design questions ask about handling a large volume of requests, a web application you built, schema optimisation, API design and security. Problem-solving questions cover debugging a crashing application, finding trends or anomalies in a dataset, tight deadlines, changing requirements and estimation. The coding group is classic fundamentals: reverse a linked list, longest substring without repeating characters, depth-first versus breadth-first search, anagrams, and binary search. Candidates also report topic labels of problem solving, programming fundamentals, data structures and algorithms, and object-oriented design.

Candidates describe a loop with both technical and non-technical interviewers, and the reported advice stresses explaining technical ideas in plain language and showing interest in public service. Many of the design and problem-solving questions are really about your own past work, so the strongest preparation is a small set of projects you can describe precisely: what you built, what you decided, what broke, and what you would change.

Use the plan at the bottom of the page in order if you have a week, and repeat days 2 to 5 if you have more. Candidates report spending roughly 2-4 weeks preparing. The coding days reward writing real code and running it, not reading solutions, and the behavioral day rewards writing story outlines in first person with your own actions and a measurable result.

The City Of Fresno interview process

Candidates describe six stages in a fixed order spanning roughly 4-6 weeks. The reports give each stage only a short description, so what follows says what each one covers and how to prepare for it.

Initial Screening

Candidates report an initial screening to check fit for the Software Engineer role. The reports do not say who runs it or what format it takes, so prepare for a conversation about your background and your reasons for applying. Make it easy to see how your experience lines up with the listed stack (a mainstream language, a web framework, a database) and the typical experience range candidates mention.

What to demonstrate

• Fit for the Software Engineer role, as candidates describe this stage
• How your experience maps to the languages, web frameworks and databases the role lists
• Your reasons for a public-sector engineering job

How to prepare

• Write a short summary of your career that ends on the stack the role lists: Python, Java or JavaScript, React or Angular, SQL or NoSQL.
• Prepare a specific answer to "What draws you to work for a government organization like City Of Fresno?" that names the kind of project (public engagement, resource management, data for planning) rather than a general wish to help people.
• Rehearse the question about which programming languages you are most comfortable with: name one language, a real project in it, and where it falls short.

Technical Assessments

Candidates report technical assessments aimed at programming skills and problem-solving ability. The reports do not say whether this is live coding or a take-home exercise, so prepare for both: working code in your strongest language, and a spoken explanation of why it is correct. The coding questions candidates report are fundamentals that reward clean code and edge-case handling over exotic algorithms.

What to demonstrate

• Programming skill, shown through working code
• Problem-solving ability, shown by how you break down and verify a task
• Command of core data structures and algorithms

How to prepare

• Write the reported coding questions from scratch in one language and run them: reverse a linked list, longest substring without repeating characters, anagram check, binary search.
• Be able to compare depth-first and breadth-first search, including the data structure each uses and when each is the better choice.
• After each solution, state time and space complexity and list the edge cases you tested: empty input, a single element, duplicates.

Interviews with Technical Team

Candidates report interviews with technical team members in which they discuss their expertise and past experience. Expect to talk through projects you built, the principles behind your code (object-oriented design, quality, version control) and the design-style questions candidates report, such as handling a large volume of requests or designing an API. Your own projects are the raw material, so be ready for depth on any one of them.

What to demonstrate

• Depth of technical expertise and past experience
• Understanding of object-oriented principles and code quality practices
• Ability to reason about architecture, data and API decisions

How to prepare

• Pick two projects and write down architecture, data model, one decision you would reverse, and one failure you handled; this answers the web application architecture and challenging-problem questions.
• Prepare a clear explanation of encapsulation, abstraction, inheritance and polymorphism with a small code example from your main language.
• Work through the volume-of-requests design, schema optimisation, API design and security questions with a sketch: clients, API, database, cache, failure modes.

Interviews with Non-Technical Team

Candidates report that this stage is with non-technical interviewers, covering cultural fit and communication skills. The reported advice is to explain technical ideas in simple terms and to show an understanding of public service. Prepare stories where the audience was not engineers: a stakeholder, a department, or a user who needed a technical decision explained.

What to demonstrate

• Communication skills with a non-technical audience
• Cultural fit, as candidates describe this stage
• Teamwork and conflict handling in cross-functional settings

How to prepare

• Take one project and explain it aloud with no jargon: what problem it solved, for whom, and what changed afterwards.
• Prepare stories for the difficult team member, prioritising multiple projects, and handling feedback questions, each in first person with a result.
• Prepare an answer to "How do you see technology impacting public service?" using a concrete example rather than a slogan.

Final Interview

Candidates report a final interview about overall fit and how well you line up with the city's mission. Treat it as the place to join your technical record, your stories and your reasons for choosing public service into one consistent picture. Candidates are also advised to bring questions about the city's technology initiatives and ongoing projects.

What to demonstrate

• Overall fit for the role, as candidates describe this stage
• Alignment with the city's mission and community focus
• The questions you ask about the work

How to prepare

• Review your story outlines so your reasons for applying, your leadership example and your project summary agree with each other.
• Write three questions about the kinds of projects the role lists, such as public engagement tools, resource management or data analytics, and about how the team works with product managers and designers.
• Prepare an answer for what motivates you to keep learning, with one example of something you picked up and applied.

Offer Discussion

Candidates list an offer discussion as the sixth and last stage. The reports give no detail about its content, so use it to settle practical questions about the role and your start, not to relitigate earlier answers. Candidates report that most roles require presence in Fresno while some allow flexibility, so ask which applies to yours.

What to demonstrate

• Your understanding of the role's scope and expectations
• Logistics such as location arrangements and start timing

How to prepare

• Write down your questions about the role's scope, team structure and on-site expectations before the conversation.
• Decide ahead of time what you need to know to make a decision and what you would ask to have confirmed in writing.

Where candidates lose points

Solving the linked-list, substring, anagram and binary-search questions without testing edge cases

After writing each solution, run the empty list, a single node, an empty string, a string of identical characters, differing case in the anagram check, and a target below the first or above the last element in binary search. Binary search is where off-by-one errors in the midpoint and loop bounds sink answers, so write it with explicit invariants and test it on tiny arrays.

Answering the volume-of-requests design question with a list of buzzwords such as caching, queues and load balancers

Start from who calls the service and what a request does, split reads from writes, find the first thing that breaks (usually the database), and only then add a cache, replicas or a queue, saying what each adds in complexity and staleness. Include one security layer, such as authentication, input validation and least-privilege database access.

Describing your own web application's architecture vaguely because you picked a project you only half remember

Choose a project you can defend in detail: components, data model, deployment, one decision you would change, one incident. Rehearse it aloud until you can answer why you chose that database, framework or API shape over an alternative.

Telling behavioral stories in which "we" does everything and there is no result

Write each story as situation, your specific actions, result, what you would change. Use "I" for what you decided and did, name the stakeholders, and give a measurable or observable outcome. For the difficult-team-member story, describe behavior and impact, not the person's character.

Giving generic answers about public service, or explaining projects to non-technical interviewers in jargon

Name the kinds of work the role lists, public engagement tools, resource management and data analytics for planning, and say which interests you and why. Practise explaining one project aloud in plain words: the problem, who was affected and what changed.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Iterative version: prev = None, curr = head; while curr: nxt = curr.next; curr.next = prev; prev = curr; curr = nxt; return prev. Saving next before overwriting the pointer is the whole trick. O(n) time, O(1) extra space.
2. Recursive version: reverse the rest of the list, then set head.next.next = head and head.next = None. It is O(n) time but uses O(n) call-stack space, so a long list can exceed Python's default recursion limit of about 1000.
3. Edge cases: empty list, single node, two nodes. Make sure the old head ends up pointing to None, or you create a cycle.
4. Test by building a list from an array, reversing it, and walking it back into an array to compare.

Follow-up

• Reverse only the nodes between positions m and n.
• Reverse the list in groups of k.
• How does the code change for a doubly linked list?

How would you find the longest substring without repeating characters in a string?

Medium · Coding / Algorithms

Approach

1. State the brute force: check every substring for repeats, O(n^3) naively or O(n^2) with a set, and why it is too slow for long inputs.
2. Sliding window with a map of each character's last index: for right in range(n): if s[right] was seen at an index >= left, move left to that index + 1. Update last[s[right]] = right and best = max(best, right - left + 1). O(n) time, O(min(n, alphabet size)) space.
3. The >= left check matters: without it the left pointer can move backwards. On 'abba', the final 'a' was last seen at index 0, which is outside the current window, so left must stay at 2.
4. Edge cases: empty string returns 0, all one character returns 1, all distinct returns n. Ask about the character set: an array of 128 for ASCII, a dict for Unicode.

Follow-up

• Return the substring itself rather than its length.
• Find the longest substring with at most k distinct characters.
• How would you handle the input as a stream you cannot store?

Can you explain the difference between depth-first search and breadth-first search?

Medium · Coding / Algorithms

Approach

1. BFS uses a queue and visits nodes level by level, so in an unweighted graph it finds the shortest path by edge count. Its memory is the frontier, which can be very wide.
2. DFS uses a stack (or recursion) and goes deep before backtracking. Its memory is O(depth). It suits cycle detection, topological sort, connected components, backtracking and path existence.
3. Both run in O(V + E) with an adjacency list (O(V^2) with an adjacency matrix), and both need a visited set on graphs with cycles.
4. Implementation details: use collections.deque with popleft for BFS (list.pop(0) is O(n)). Recursive DFS can hit recursion limits on deep graphs, so know the iterative version with an explicit stack.
5. Neither gives shortest paths with weighted edges: that needs Dijkstra for non-negative weights.

Follow-up

• Which would you use to find the shortest route between two nodes, and what changes when edges have weights?
• How do you detect a cycle in a directed graph with DFS? (Track nodes on the current recursion stack, or use white/grey/black colouring.)
• Write DFS iteratively without recursion.

Write a program that checks if two strings are anagrams.

Medium · Coding / Algorithms

Approach

1. Clarify the rules first: case sensitivity, whether spaces and punctuation count, and whether input can be Unicode.
2. Return false immediately if the lengths differ. Then count: increment a counter for each character of the first string and decrement for the second, and check every count is zero. O(n) time, and O(1) space for a fixed alphabet (an int array of 26) or O(k) with a hash map for k distinct characters.
3. Alternative: compare sorted(s) == sorted(t). It is simpler but O(n log n) time and needs O(n) space for the sorted copies.
4. For Unicode, normalise (e.g. NFC) and casefold before counting, and use a map rather than a fixed array. Two empty strings count as anagrams.

Follow-up

• Group a list of words into sets of anagrams. (Key each word by its sorted letters or by a tuple of counts.)
• Find every start index in s where an anagram of p begins. (Sliding window of counts, O(n).)
• How would you compare two strings too large to fit in memory?

How would you implement a binary search algorithm?

Medium · Coding / Algorithms

Approach

1. State the precondition: a sorted, random-access array. Iterative: lo = 0, hi = n - 1; while lo <= hi: mid = lo + (hi - lo) // 2; return mid on a match, otherwise move lo = mid + 1 or hi = mid - 1; return -1. O(log n) time, O(1) space.
2. Explain the overflow issue: (lo + hi) / 2 can overflow a 32-bit int in Java or C++, so write lo + (hi - lo) / 2 (or (lo + hi) >>> 1 in Java). Python integers do not overflow.
3. Keep one invariant: closed [lo, hi] with lo <= hi, or half-open [lo, hi) with lo < hi and hi = mid. Mixing the two causes off-by-one errors and infinite loops.
4. For duplicates, write the lower-bound variant that returns the first index with a value >= target. Know the libraries: Python's bisect.bisect_left, and Java's Arrays.binarySearch, which returns -(insertion point) - 1 when the key is missing and does not guarantee which duplicate it finds.
5. Test: empty array, one element, target below the minimum, above the maximum, and repeated values.

Follow-up

• Find the first and last positions of a target in an array with duplicates.
• Search a sorted array that has been rotated at an unknown pivot.
• Binary search on the answer: find the minimum ship capacity that delivers all packages within D days.

What factors do you consider when optimizing a database schema?

Medium · System Design / Architecture

Approach

1. Start from the access patterns: the main queries, the read/write ratio and expected row counts. A schema is optimised for its workload, not in the abstract.
2. Normalise to about third normal form to avoid update anomalies, then denormalise selectively for read-heavy paths, naming how you keep the copies consistent (triggers, application writes or a materialized view refresh).
3. Choose the smallest correct data types and enforce integrity in the database: NOT NULL, foreign keys, UNIQUE and CHECK constraints. Weigh surrogate vs natural primary keys.
4. Index the columns used in WHERE, JOIN and ORDER BY. A composite index serves queries on its leftmost columns, and a covering index can avoid table lookups. Every index slows writes and takes space, so confirm with EXPLAIN ANALYZE.
5. Plan for growth: partition large time-based tables by date, archive old rows, and change schemas without downtime (add a nullable column, backfill in batches, then add the constraint).

Follow-up

• Why might the database ignore an index you created? (A function applied to the column, a LIKE pattern starting with %, low selectivity, a type mismatch, or skipping the first column of a composite index.)
• When is denormalising worth the consistency cost?
• When would you choose a NoSQL store over SQL for part of this data?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

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

Approach

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

Follow-up

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

What programming languages are you most comfortable with and why?

Medium · Technical / Domain Questions

Approach

1. Lead with one primary language you have shipped real code in. If it is one the role requirements list (Python, Java or JavaScript), name the project, the version and what you built, not just that you like it.
2. Give technical reasons, not taste. Python: a large standard library, fast to write, and CPython's GIL pushes CPU-bound work to multiprocessing. Java: static typing, the JVM and java.util.concurrent. JavaScript: an event loop with promises/async-await that runs in the browser and in Node.
3. Name a weakness of your main language and how you guard against it, e.g. type hints checked by mypy in Python, TypeScript over plain JavaScript, or null handling with Optional in Java.
4. Show you pick the tool for the job: scripting and data work, a long-running API service, a React or Angular front end. Say which language you would choose for each and why.

Follow-up

• Which feature of your main language has caused a bug you had to track down, and how did you find it?
• How does your main language handle concurrency, and when would you avoid threads in it?
• How would you get productive in a language the team uses that you have not worked in?

Can you explain the principles of object-oriented programming?

Medium · Technical / Domain Questions

Approach

1. Name the four principles, each with a one-line definition and a small example. Encapsulation keeps state private behind methods (an Account whose balance changes only through deposit/withdraw). Abstraction exposes what an object does, not how. Inheritance reuses and specialises a base type. Polymorphism lets one interface call different implementations.
2. Separate the two kinds of polymorphism: runtime (overriding with dynamic dispatch through a base class or interface) and compile-time (method overloading in Java). Show a Shape interface with area() implemented by Circle and Rectangle.
3. Say when inheritance hurts: deep hierarchies and the fragile base class problem. Prefer composition when the relationship is has-a, and respect Liskov substitution (a subclass must work wherever its parent is expected).
4. Connect the principles to SOLID briefly, e.g. depending on interfaces (dependency inversion) so you can swap a real database client for a test double.

Follow-up

• In Java, when would you use an abstract class rather than an interface? (Abstract classes can hold state and constructors; a class can implement many interfaces, and interfaces have had default methods since Java 8.)
• How does Python handle encapsulation, given it has no private keyword?
• Give an example where you replaced inheritance with composition, and what got easier.

How do you ensure code quality and maintainability?

Medium · Technical / Domain Questions

Approach

1. Describe layers of automated checks: unit tests on logic, integration tests on database and API boundaries, all run in CI and required before merge. Linters and formatters (ESLint/Prettier, ruff or flake8/black) run in pre-commit and CI so style never comes up in review.
2. Use static typing where the language allows it (TypeScript, mypy, Java's compiler) to catch whole classes of bugs before runtime.
3. Keep pull requests small and focused, review them against a short checklist (naming, error handling, tests for the change, no secrets) and explain the why in comments and commit messages.
4. Design for change: functions with one job, clear module boundaries, no copy-pasted logic, and no abstraction before a second real use case. Treat coverage as a floor, not a target, and track flaky tests.
5. Give one concrete example, such as adding characterization tests before refactoring an untested module, and what it prevented.

Follow-up

• How do you safely change legacy code that has no tests?
• What do you push back on in code review, and what do you let go?
• How much test coverage is enough, and what does coverage fail to tell you?

Describe a challenging technical problem you solved in a previous project.

Medium · Technical / Domain Questions

Approach

1. Choose a problem with a real technical root cause that you personally diagnosed or designed around, e.g. a slow query, a race condition or an integration that kept failing. Do not pick one where you mostly watched.
2. Structure it: the context in two sentences, the constraint that made it hard, the options you considered with their trade-offs, what you built or changed, and a measurable result (latency, error rate, hours saved).
3. Spend most of the answer on the reasoning: what you checked first, what each check ruled out, and the evidence that confirmed the cause.
4. Be explicit about your part versus the team's, and close with what you would do differently now.

Follow-up

• Which approaches did you reject, and why?
• How did you verify the fix worked and would not regress?
• If you hit the same problem tomorrow, what would you do faster?

How would you design a system to handle a large volume of user requests?

Medium · System Design / Architecture

Approach

1. Pin down numbers first: peak versus average requests per second, read/write ratio, latency target, payload and data size. Do a quick back-of-envelope so the design fits the load.
2. Keep application servers stateless behind a load balancer so you can scale horizontally with autoscaling. Hold sessions in a shared store such as Redis, or use signed tokens.
3. Take load off the database: a CDN for static assets, cache-aside in Redis for hot reads with a TTL and an invalidation plan, connection pooling, and read replicas for read-heavy paths (accepting replication lag). Shard or partition only when writes outgrow one primary.
4. Move slow work off the request path with a message queue and background workers. Protect the system with rate limiting (token bucket), timeouts, retries with backoff, and backpressure.
5. Watch p95/p99 latency, error rate and saturation, and load-test before peak days.

Follow-up

• A deadline day brings ten times the normal traffic in one afternoon: what fails first, and what do you change?
• What exactly would you cache, and how do you keep it from serving stale data?
• How do you stop a client retry from creating a duplicate submission?

Describe the architecture of a web application you built and the decisions you made regarding its design.

Medium · System Design / Architecture

Approach

1. Open with what the application did, who used it and at what scale, then sketch the components: client (React or Angular single-page app, or server-rendered pages), API layer, database, background jobs, hosting.
2. For each major decision, give the alternative and why you chose against it: relational vs NoSQL (joins and constraints vs flexible schema), monolith vs services, REST vs GraphQL, single-page app vs server rendering.
3. Cover the cross-cutting parts: authentication and authorization, deployment and CI, logging and monitoring, and how you tested it.
4. Name the decision that aged worst, what it cost, and what you would change now. Be precise about which parts you built versus inherited.

Follow-up

• Where was the bottleneck under load, and how did you find it?
• If usage grew tenfold, what would you change first?
• How did you deploy changes and roll back a bad release?

How do you approach API design for a new service?

Medium · System Design / Architecture

Approach

1. Start from the consumers and their use cases, then model resources and relationships. Use HTTP methods correctly: GET is safe, PUT and DELETE are idempotent, POST is not.
2. Write the contract first (an OpenAPI spec reviewed with consumers), with consistent naming, precise status codes (400, 401 vs 403, 404, 409, 422, 429) and one error body shape that callers can branch on.
3. Plan for growth: pagination (cursor-based for large or changing data, offset for small stable sets), filtering and sorting parameters, and versioning. Make only backward-compatible changes within a version, such as adding optional fields.
4. Build in security and safety: authentication with OAuth2/OIDC tokens, authorization checked per resource on the server, input validation, rate limits, and idempotency keys so a retried create does not double-apply.
5. Ship docs, examples and request logging with correlation ids.

Follow-up

• How would you roll out a breaking change without stranding existing clients?
• Cursor or offset pagination: which, and why?
• A client times out on a create call and retries. What happens, and how do you make it safe?

Discuss how you would ensure system security in your designs.

Medium · System Design / Architecture

Approach

1. Threat-model first: list the assets (personal data, credentials, admin functions), the actors and the trust boundaries, and walk through STRIDE to find what could go wrong at each boundary.
2. Authentication and authorization: least privilege, role-based checks on the server for every request (never only hidden in the UI), MFA for administrative access, short-lived tokens.
3. Handle input safely against the OWASP Top 10: parameterised queries with bind parameters against SQL injection, output encoding and a Content Security Policy against XSS, CSRF tokens or SameSite cookies, and server-side validation.
4. Protect data: TLS in transit, encryption at rest, secrets in a secret manager rather than in code or config, passwords hashed with bcrypt or Argon2 (never reversible encryption).
5. Operate securely: dependency scanning and patching, audit logs for sensitive actions, alerting on suspicious patterns, and rate limiting on login.

Follow-up

• How would you store user passwords, and why not SHA-256 alone?
• A developer commits an API key to the repository. What do you do first?
• Where in the code do you enforce authorization, and how do you test it?

Given a dataset, how would you identify trends or anomalies?

Medium · Problem-Solving / Case Studies

Approach

1. Profile the data first: schema, grain (one row per what), time range, missing values, duplicates, units. Then plot it, because a chart catches errors summary statistics hide.
2. For trends, aggregate by period and group (SQL GROUP BY, window functions such as a rolling average), fit a regression slope, or separate trend from seasonality with a decomposition such as STL.
3. For anomalies, start simple: a z-score threshold (e.g. |z| > 3) assumes roughly normal data. The IQR rule (below Q1 - 1.5IQR or above Q3 + 1.5IQR) or median absolute deviation resists outliers. With seasonality, flag large residuals after decomposition. For many features, try an isolation forest.
4. Validate each flagged point: is it a data error (pipeline bug, unit change, duplicate load) or a real event? Check findings with someone who knows the domain before acting.
5. Name the tools you would use (pandas, SQL, a notebook) and how you would hand over the result.

Follow-up

• How do you avoid flagging every Monday or holiday as an anomaly?
• How do you choose the threshold, and what does a false positive cost here?
• How would you turn this into a check that runs continuously on new data?

Describe your thought process when faced with a tight deadline on a project.

Medium · Problem-Solving / Case Studies

Approach

1. Find out what is actually fixed: why the date cannot move and what the minimum is that must ship by then.
2. Split scope into must, should and could (MoSCoW). Cut scope before cutting quality, and keep tests on the risky and data-changing paths.
3. Raise the trade-off early: as soon as the estimate exceeds the time, give stakeholders options (smaller scope, more help, a later date) rather than a surprise at the end.
4. Reduce risk first: tackle the unknowns early, check progress against the plan daily, refuse scope creep, and release behind a feature flag where possible.
5. Log every shortcut as tracked technical debt with a follow-up date, and back it with one real story.

Follow-up

• What did you cut, and who agreed to it?
• What did you do when it became clear you would still miss the date?
• How do you keep bugs from slipping in when time is short?

How would you handle a situation where a project requirement changes midway through development?

Medium · Problem-Solving / Case Studies

Approach

1. Understand the change before reacting: who asked, what problem it solves, and whether it replaces or adds to existing scope. Confirm it in writing.
2. Do an impact analysis: which built parts change, the extra effort, the risk and the schedule effect. Present options (absorb it, swap it for other scope, move the date) and let the owner decide.
3. Update the backlog, acceptance criteria, tests and documentation so the team works from one current version of the requirement.
4. Explain the engineering habits that make change cheap: modular code, good test coverage, feature flags and short iterations (Agile appears in the stack candidates describe for this role).
5. Use a real example, including what happened to work that was already done.

Follow-up

• What if the change arrives a few days before release?
• How do you handle requirements that keep changing every week?
• How did you handle the work that became obsolete?

Discuss how you would go about estimating the time required for a new feature implementation.

Medium · Problem-Solving / Case Studies

Approach

1. Break the feature into tasks small enough to estimate (a day or two each), and include the work people forget: tests, code review, migrations, deployment, documentation.
2. Anchor on past work of similar size (reference-class estimating). For uncertain tasks use a three-point estimate: PERT expected time = (optimistic + 4 x most likely + pessimistic) / 6.
3. Name the unknowns and dependencies on other teams. Run a short spike to shrink the biggest unknown before committing.
4. Give a range with a confidence level rather than one date, revise it as you learn, and compare actuals against estimates to calibrate.

Follow-up

• An estimate of yours was off by double. What happened, and what changed afterwards?
• How do you estimate when the requirements are still vague?
• Story points or hours, and why?

How would you approach debugging an application that is frequently crashing?

Medium · Problem-Solving / Case Studies

Approach

1. Gather evidence before theorising: crash logs, stack traces, error-tracker events, core or heap dumps. Find when it started and what correlates: a deploy, a config change, load, a specific input, one host.
2. If production is hurting, stop the damage first (roll back or turn off a feature flag), then investigate on the bad version in staging with the same config and similar data.
3. Reproduce and narrow: shrink the failing input. For intermittent crashes, suspect concurrency bugs or resource exhaustion (memory leak ending in an out-of-memory kill, file descriptors, exhausted connection pools), and graph memory and handles over time.
4. Bisect: git bisect between the last good and first bad commit finds the culprit in about log2(n) builds. Add targeted logging or metrics around the suspect code path.
5. Fix, add a regression test that reproduces the crash, confirm the crash rate drops after release, and write a short post-incident note.

Follow-up

• It only crashes in production and you cannot reproduce it locally. What next?
• How would you tell a memory leak apart from a genuine traffic increase?
• Would you roll back or fix forward here, and what decides it?

Suggested practice checklist

The plan follows the reported loop: fundamentals first because assessments come early, then design and past-project questions, then non-technical and behavioral stories, ending with a full mock run. Each day lists the reported questions it practises.

Day 1 — Map the loop and your stack

• Write the six reported stages in order and, for each, the question types it plausibly covers: coding and problem-solving early, project discussion with technical staff, communication with non-technical staff.
• Choose the one language you will code in from Python, Java or JavaScript, and list where you are strongest and weakest across the stack the role lists (React or Angular, SQL or NoSQL, cloud services).
• Write a short answer to which languages you are most comfortable with and why, naming one project.

Deliverable: A one-page loop map, a chosen coding language with a gap list for the stack, and a written answer on language comfort.

Day 2 — Coding fundamentals in one language

• Write and run reverse a linked list both iteratively and recursively; state time and space for each.
• Write the longest substring without repeating characters with a sliding window and a map of last-seen positions, then the anagram check with a character count; test both on empty and single-character inputs.
• Write binary search with explicit bounds and test it on arrays of length zero, one and two, and for targets missing from either end.

Deliverable: Four working, tested solutions with complexity written beside each and a list of the edge cases you ran.

Day 3 — Search, object-oriented design and code quality

• Implement depth-first search (recursive and with an explicit stack) and breadth-first search (queue) on a small graph, and write when each is the better choice, such as shortest path in an unweighted graph versus exhaustive exploration.
• Explain the four object-oriented principles with one short code example each in your chosen language.
• Write your answer on ensuring code quality and maintainability: reviews, automated tests, linting, small functions, naming, and a real example.

Deliverable: Working DFS and BFS code, four annotated object-oriented examples, and a written code-quality answer with one real example.

Day 4 — Design: requests, architecture, schema, API, security

• Sketch the design for handling a large volume of user requests: separate read and write paths, find the first bottleneck, then add caching or replicas and say what each costs.
• Write the architecture of a web application you built, covering components, data model, deployment and one decision you would reverse.
• Write schema optimisation factors (keys, indexes matching real queries, normalisation versus read speed) and an API design checklist (resource naming, error format, retries that cannot double-apply, versioning), then a security pass over both.

Deliverable: Four design sketches or outlines, one per reported design question, plus a short security checklist attached to them.

Day 5 — Debugging, data and project judgment

• Write a debugging sequence for an application that crashes frequently: find what changed, read logs and crash reports, reproduce, bisect, then separate the trigger from the cause.
• Write how you would find trends or anomalies in a dataset: check data quality first, summarise and plot, compare against a baseline, then test whether an outlier is an error or a real event.
• Outline answers for the tight deadline, changing requirement and feature estimation questions: scope cuts, communicating trade-offs, breaking work into pieces and adding contingency.
• Write up the challenging technical problem you solved, with the cause and your fix.

Deliverable: Written outlines for six reported problem-solving questions and one finished story about a hard technical problem.

Day 6 — Behavioral stories and public-service motivation

• Write story outlines in first person for the difficult team member, prioritising projects, taking the lead and feedback questions: situation, your actions, result.
• Write your answer on Git experience and your reasons for keeping your skills current, each with a concrete example.
• Write answers for "What draws you to work for a government organization like City Of Fresno?" and "How do you see technology impacting public service?" naming a kind of project from the role.

Deliverable: Six story outlines with results, plus two written public-service answers.

Day 7 — Full mock loop

• Run a mock technical stage: one coding question from day 2 written live and explained aloud, then your best project walked through for design decisions.
• Run a mock non-technical stage: explain that project in plain words, then answer two behavioral prompts from day 6 aloud.
• Write three questions about the city's projects and team to ask in the final interview, and list the three answers you would most like to improve.

Deliverable: A recorded or written mock run, three questions to ask, and a short list of last fixes.

Behavioral and public-service stories

Candidates report non-technical interviews that cover cultural fit and communication, and a final interview about overall fit and the city's mission. Prepare first-person stories with a result, and be ready to say why public service software appeals to you using a concrete kind of project. The reported prompts below come first.

1. What draws you to work for a government organization like City Of Fresno?

What is your experience with version control systems, such as Git?

Medium · Technical / Domain Questions

Approach

1. Name the Git workflow you have used (feature branches with pull requests, trunk-based development or Git Flow), and why that team chose it.
2. Show working knowledge: merge vs rebase (rebase rewrites history, so never on shared branches), resolving conflicts, interactive rebase to tidy commits before review, and git revert to undo a published commit instead of rewriting history.
3. Mention the commands that save time when debugging: git bisect to find the commit that introduced a bug, git blame and git log -p to understand why a line exists.
4. Cover hygiene: small commits with clear messages, protected main branch with required checks, and never committing secrets (and rotating a credential if one leaks, because rewriting history is not enough).

Follow-up

• When would you rebase instead of merge, and when is rebasing dangerous?
• How would you recover a commit you lost after a bad reset? (git reflog.)
• How do you handle a long-running feature branch that keeps conflicting with main?

Describe a time when you had to work with a difficult team member. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Choose a real friction with a peer, such as repeated missed handoffs or hostile code review comments, not a villain story. Describe the impact on the work in one or two sentences.
2. Show the order of your actions: first a private, direct conversation to hear their view, then agreeing on specifics (review turnaround, who owns what, how disagreements get settled), and only then involving a manager if it still did not improve.
3. Talk about behavior and its effect on the work, never about the person's character. Show one thing you changed about your own part in the dynamic.
4. Close with a result you can point to: reviews moving faster, a feature shipped, a working relationship that held up afterwards. The sinking mistake is a story where you were right and they were wrong with nothing learned.

Follow-up

• What would you have done if the conversation had changed nothing?
• At what point would you bring in a manager, and what would you tell them?
• What did that experience change about how you work with people you disagree with?

How do you prioritize tasks when working on multiple projects?

Medium · Behavioral / Leadership

Approach

1. Name a method before the story: list everything, rank by user or stakeholder impact, deadline, whether it blocks someone else, and effort, then decide the order and tell the people affected.
2. Use a concrete case with two or three competing items, for example a production bug, a feature with a date, and code reviews other people are waiting on. Say what you did first and what you consciously postponed.
3. Show that you made trade-offs visible: you told stakeholders what would slip and agreed it, rather than quietly trying to do everything. The role works with product managers, so say how you used them to settle conflicting asks.
4. Say how you re-prioritise when something new arrives, and how you protect focus time. The sinking mistake is answering with working longer hours and no decision about what was dropped.

Follow-up

• Two stakeholders both say their request is the urgent one. Who decides and how?
• How did you tell the person whose work slipped?
• A severe bug arrives in the middle of a planned piece of work. What happens to the plan?

Can you give an example of a situation where you took the lead on a project?

Medium · Behavioral / Leadership

Approach

1. Pick a project where you set direction, with or without the title: you scoped it, broke it into tasks, and made the technical calls. State the size of the team and what was at stake in a sentence.
2. Say what leading consisted of in practice: writing the plan or design note, dividing work by strength, unblocking others, setting the review standards, and reporting status to stakeholders.
3. Include a point where someone disagreed and how you handled it, plus a risk you spotted early and what you did about it.
4. End with the outcome and a lesson. The mistake to avoid is describing a project you were merely part of, or using "we" throughout so your own decisions never appear.

Follow-up

• How did you handle a teammate who disagreed with your plan?
• What did you delegate, and what did you deliberately keep?
• How did you know the project was on track before the deadline?

How do you handle feedback and criticism of your work?

Medium · Behavioral / Leadership

Approach

1. Choose real, specific feedback, for example a code review pointing out missing tests or an unclear abstraction, or a stakeholder saying your updates were hard to follow. Avoid disguised strengths like "I care too much".
2. Describe your first reaction honestly, then what you did: asked clarifying questions, separated the point from the delivery, and tested whether the feedback was right.
3. Show a change that persisted: a checklist, smaller pull requests, tests written first, or a different style of status update. Say how you confirmed it helped.
4. Add the other side briefly, how you give feedback in review, to show you treat it as a normal part of working together. The sinking mistake is defending the original work and showing no change.

Follow-up

• Tell me about feedback you disagreed with. What did you do?
• How do you give critical feedback on someone else's pull request?
• How did you check that the change you made after the feedback actually worked?

What motivates you to stay updated with industry trends and new technologies?

Medium · Behavioral / Leadership

Approach

1. Give concrete habits, not enthusiasm: release notes for the languages and frameworks you use, reading other people's code, a small side project, internal sharing sessions. Be specific about what you last learned.
2. Tell one story where learning changed a decision: you evaluated a library, framework or practice, compared it to the existing choice, and either adopted it with a plan or rejected it with reasons.
3. Tie it to the stack the role lists, such as Python, Java, JavaScript, React or Angular, or cloud services, and say what you would learn next and why it would help on that kind of work.
4. Show judgment, not trend-chasing: say what you decline to adopt, and how you weigh maintainability against novelty. The mistake is a list of buzzwords with nothing you have used.

Follow-up

• Tell me about a technology you decided not to adopt, and why.
• What is the last thing you learned that you applied at work?
• How do you stop a team's stack from churning with every new tool?