Interview guides · Central Intelligence Agency

Central Intelligence Agency Software Engineer Interview Guide

Central Intelligence Agency Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at the Central Intelligence Agency (CIA), you play a pivotal role in developing and maintaining the software systems that support the Agency’s mission of national security. This role is critical, as the information systems you build and maintain directly impact intelligence operations, analysis, and decision-making processes. You will engage with complex datasets, cutting-edge technologies, and innovative software solutions that contribute to the Agency's efforts in safeguarding the nation. The position is both challenging and rewarding, providing opportunities to work on state-of-the-art applications that require high reliability, security, and performance. As a Software Engineer, you will collaborate with cross-functional teams, including analysts and operators, to deliver solutions that enhance intelligence capabilities.

This guide is scoped to a Software Engineer candidate at Central Intelligence Agency.

Focus areas

Behavioral Interviewing
Security Clearance Process
Background Investigation

The Central Intelligence Agency interview process

Central Intelligence Agency candidates report 5 rounds over 4-6 weeks. The stages below are what candidates describe, not a published process.

Initial Screening Call

Candidates participate in an initial screening call to discuss their background and fit for the role.

What to demonstrate

Candidates participate in an initial screening call to discuss their background and fit for the role
Depth in Behavioral Interviewing

How to prepare

Be able to walk your CV end to end in two minutes, and say why this company specifically.
Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Screenings

Candidates undergo technical screenings to assess their software development skills.

What to demonstrate

Candidates undergo technical screenings to assess their software development skills
Depth in Behavioral Interviewing

How to prepare

Answer aloud and timed: Describe how you would optimize a SQL query.
Answer aloud and timed: What is your experience with agile development methodologies?

Behavioral Interviews

Candidates engage in behavioral interviews to evaluate their alignment with the Agency’s mission and values.

What to demonstrate

Candidates engage in behavioral interviews to evaluate their alignment with the Agency’s mission and values
Depth in Behavioral Interviewing

How to prepare

Prepare three examples from your own work, each with a decision you made and an outcome you can quantify.
Re-read the description of the behavioral interviews above and write down what you would ask to confirm before it.

Problem-Solving Evaluation

Candidates are evaluated on their problem-solving skills through complex scenarios.

What to demonstrate

Candidates are evaluated on their problem-solving skills through complex scenarios
Depth in Behavioral Interviewing

How to prepare

Answer aloud and timed: Tell me about a situation where you had to work under pressure.
Answer aloud and timed: How do you prioritize tasks when working on multiple projects?

Final Evaluations

Final evaluations are conducted to assess overall fit and competencies before making a decision.

What to demonstrate

Final evaluations are conducted to assess overall fit and competencies before making a decision
Depth in Behavioral Interviewing

How to prepare

Answer aloud and timed: Give an example of a time you had to persuade others to accept your viewpoint.
Answer aloud and timed: How do you handle conflicts within a team?

Where candidates lose points

Understand the Agency's Mission

Familiarize yourself with the CIA's objectives and how technology supports its goals.

Practice Behavioral Questions

Prepare specific examples from your past experiences that highlight your problem-solving skills and teamwork.

Stay Updated on Technology Trends

Knowledge of current technologies and trends in software engineering can help you stand out.

Be Ready for Security Questions

Given the nature of the CIA, expect questions related to security clearance and ethical dilemmas.

Questions & practice

Write a function to reverse a linked list.

Easy · Coding / Algorithms

Approach

Reverse the pointers in a single pass instead of moving values: each node's next is redirected to the node before it, so the old tail becomes the head. No extra list or stack is needed.
Track three references — prev, curr, and a saved nxt — because assigning curr.next = prev would otherwise lose the rest of the list. Loop while curr: save nxt, flip the pointer, advance prev and curr; return prev.
Complexity: O(n) time and O(1) extra space. The recursive version is also O(n) time but uses O(n) call stack, so a 100,000-node list blows past Python's default recursion limit of 1,000.
Edge cases: an empty list (None) and a single node come back unchanged, and the old head's next must end as None — forgetting that in the recursive version leaves a two-node cycle.
Verify by building a list from a Python list, reversing, and reading it back; also reverse twice and check the original order returns, which catches dropped or duplicated nodes.

Worked solution (10 min)

Define a minimal ListNode with val and next, plus helpers to convert to and from Python lists for testing.
Walk the list with prev starting at None; before redirecting a node's pointer, stash its successor so the traversal can continue.
When curr falls off the end, prev holds the former tail — return it as the new head.
Show the recursive variant for comparison: reverse the rest, make the next node point back at head, and clear head.next.

from typing import List, Optional


class ListNode:
    def __init__(self, val=0, next=None):
        self.val = val
        self.next = next


def reverse_list(head: Optional[ListNode]) -> Optional[ListNode]:
    """Reverse a singly linked list in place; return the new head."""
    prev, curr = None, head
    while curr:
        nxt = curr.next   # save the rest before overwriting the pointer
        curr.next = prev  # flip this node to point backwards
        prev, curr = curr, nxt
    return prev           # the old tail is the new head


def reverse_list_recursive(head: Optional[ListNode]) -> Optional[ListNode]:
    """Same result, but uses O(n) call stack: fine only for short lists."""
    if head is None or head.next is None:
        return head
    new_head = reverse_list_recursive(head.next)
    head.next.next = head  # the node after head now points back to it
    head.next = None       # old head becomes the tail
    return new_head


def from_list(values: List[int]) -> Optional[ListNode]:
    head = None
    for v in reversed(values):
        head = ListNode(v, head)
    return head


def to_list(head: Optional[ListNode]) -> List[int]:
    out = []
    while head:
        out.append(head.val)
        head = head.next
    return out

Expected result: Given 1→2→3→4→5, reverse_list returns the head of 5→4→3→2→1. The iterative version runs in O(n) time with O(1) extra space; the recursive one needs O(n) stack.

Verify it yourself

reverse_list(None) returns None
to_list(reverse_list(from_list([1, 2, 3, 4, 5]))) returns [5, 4, 3, 2, 1]
A single node comes back as the same node with next set to None
After reversing from_list([1, 2, 3]), the old head's next is None (no cycle)
A 100,000-node list reverses iteratively without a RecursionError

Follow-up

How would you check whether a linked list is a palindrome in O(1) space? Find the middle with slow and fast pointers, reverse the second half with this same loop, compare the halves, then reverse it back.
How would you reverse only positions m through n? Walk to node m-1, reverse the next n-m+1 nodes with the same pointer loop, then reconnect both ends of the reversed segment.
How would you reverse in groups of k? Reverse each block of k with the same loop, link the previous block's tail to the new block's head, and leave a final partial block as-is unless the spec says otherwise.

How would you implement a binary search algorithm?

Easy · Coding / Algorithms

Approach

Binary search needs a sorted, random-access sequence; each comparison discards half the remaining range, so it runs in O(log n) time and O(1) space iteratively — about 20 comparisons for a million elements.
Pick one invariant and keep it. The half-open form lo, hi = 0, len(a), while lo < hi, with lo = mid + 1 when a[mid] < target else hi = mid, finds the first index whose value is >= target and always terminates.
The classic bugs: mixing closed and half-open bounds (an infinite loop when lo = mid meets a floor midpoint), overflow from (lo + hi) / 2 on 32-bit ints in Java or C++ (use lo + (hi - lo) / 2), and failing on an empty array.
Duplicates: a plain return-on-equality search returns an arbitrary match. Lower bound gives the first occurrence, upper bound (a[mid] <= target) gives one past the last, and their difference is the count — the same contract as bisect_left and bisect_right.
Generalize to binary search on the answer: any monotonic yes/no predicate works, such as the first failing build, the minimum capacity to ship within D days, or an integer square root.
Test the boundaries: empty input, one element, a target below the minimum and above the maximum, all-equal arrays, and every element of a small sorted array; compare against bisect on random inputs.

Worked solution (15 min)

Write lower_bound first: it returns the insertion point for target, which is the building block for every variant.
Inside the loop the midpoint is either too small (discard it and everything left of it) or a possible answer (keep it as the new right edge).
binary_search calls lower_bound, then checks that the index is in range and holds target; otherwise it returns -1.
upper_bound flips < to <=, and subtracting the two bounds counts occurrences in O(log n).

from typing import Sequence


def lower_bound(a: Sequence[int], target: int) -> int:
    """First index i with a[i] >= target, or len(a) if none. a must be sorted."""
    lo, hi = 0, len(a)             # half-open window [lo, hi)
    while lo < hi:
        mid = lo + (hi - lo) // 2  # overflow-safe form for fixed-width ints
        if a[mid] < target:
            lo = mid + 1           # answer lies strictly right of mid
        else:
            hi = mid               # mid itself may be the answer
    return lo


def upper_bound(a: Sequence[int], target: int) -> int:
    """First index i with a[i] > target, or len(a) if none."""
    lo, hi = 0, len(a)
    while lo < hi:
        mid = lo + (hi - lo) // 2
        if a[mid] <= target:
            lo = mid + 1
        else:
            hi = mid
    return lo


def binary_search(a: Sequence[int], target: int) -> int:
    """Index of the first occurrence of target, or -1 if absent."""
    i = lower_bound(a, target)
    return i if i < len(a) and a[i] == target else -1


def count_occurrences(a: Sequence[int], target: int) -> int:
    return upper_bound(a, target) - lower_bound(a, target)

Expected result: binary_search([1, 3, 5, 7, 9], 7) returns 3 and binary_search([1, 3, 5, 7, 9], 4) returns -1. Each call is O(log n) time and O(1) space.

Verify it yourself

binary_search([1, 3, 5, 7, 9], 7) returns 3
binary_search([1, 3, 5, 7, 9], 4) returns -1
binary_search([], 1) returns -1
binary_search([2, 2, 2, 3], 2) returns 0 (first occurrence)
count_occurrences([1, 2, 2, 2, 5], 2) returns 3

Follow-up

How would you search a rotated sorted array? With distinct values one half around mid is always sorted, so test whether the target lies in its range and drop the other half; duplicates such as [1, 1, 1, 0, 1] can force O(n).
How would you search a sorted sequence of unknown length? Double an upper bound (1, 2, 4, …) until it passes the target, then binary search that window, which is O(log i) for a target at index i.
Why not just use a hash set? It gives O(1) average membership but no ordering, so it can't answer range, floor/ceiling, or insertion-point queries the way a sorted array can.

Solve a problem that requires finding the shortest path in a graph.

Medium · Coding / Algorithms

Approach

Clarify the graph first, because it picks the algorithm: unweighted → BFS in O(V + E); non-negative weights → Dijkstra; negative edges → Bellman-Ford in O(VE), which also detects negative cycles; all pairs on a small dense graph → Floyd–Warshall in O(V^3). Assume weighted, non-negative, single pair.
Dijkstra's insight: always expand the unsettled node with the smallest tentative distance. With non-negative edges nothing found later can make it cheaper, so its distance is final when popped; then relax each outgoing edge if d + w < dist[v].
Use an adjacency list, a dist map, a predecessor map, and a binary min-heap of (distance, node). Python's heapq has no decrease-key, so push duplicates and skip stale entries where d > dist[u]; the total cost is O((V + E) log V).
Record prev[v] = u on every successful relaxation, stop as soon as the target is popped, and rebuild the path by walking predecessors from the target back to the source and reversing.
Edge cases: an unreachable target (return infinity and no path), source equal to target, parallel edges, and zero-weight edges. Reject negative weights explicitly — Dijkstra silently returns wrong distances on them.
For grids, treat cells as implicit nodes: BFS when every step costs 1, 0-1 BFS with a deque for 0/1 costs, and A* with a consistent heuristic, such as Manhattan distance on a 4-connected grid or octile distance when diagonal steps cost √2, to explore fewer nodes toward one target.

Worked solution (25 min)

Build a defaultdict(list) adjacency list from (u, v, weight) triples, rejecting negative weights and adding the reverse edge for undirected graphs.
Seed the heap with the source at distance 0; a counter in each heap tuple breaks ties so nodes of different types are never compared.
Pop the cheapest entry, skip it if a shorter distance is already recorded, and break early once the target comes off the heap.
Relax each neighbor, storing the new distance and predecessor, then follow predecessors back from the target to produce the path.

import heapq
from collections import defaultdict
from itertools import count


def shortest_path(edges, source, target, directed=True):
    """Dijkstra for non-negative weights.

    edges: iterable of (u, v, weight). Returns (distance, path) or (inf, None).
    """
    graph = defaultdict(list)
    for u, v, w in edges:
        if w < 0:
            raise ValueError("Dijkstra requires non-negative edge weights")
        graph[u].append((v, w))
        if not directed:
            graph[v].append((u, w))

    dist = {source: 0}
    prev = {}
    tie = count()  # tie-breaker so the heap never compares node objects
    heap = [(0, next(tie), source)]
    while heap:
        d, _, u = heapq.heappop(heap)
        if d > dist[u]:
            continue           # stale entry: u was already settled cheaper
        if u == target:
            break              # popped target, so its distance is final
        for v, w in graph[u]:
            nd = d + w
            if nd < dist.get(v, float("inf")):
                dist[v] = nd   # relax the edge and remember how we got here
                prev[v] = u
                heapq.heappush(heap, (nd, next(tie), v))

    if target not in dist:
        return float("inf"), None
    path = [target]
    while path[-1] != source:
        path.append(prev[path[-1]])
    return dist[target], path[::-1]

Expected result: With EDGES = [('A', 'B', 4), ('A', 'C', 2), ('C', 'B', 1), ('B', 'D', 5), ('C', 'D', 8)], shortest_path(EDGES, 'A', 'D') returns (8, ['A', 'C', 'B', 'D']). It runs in O((V + E) log V) time and O(V + E) space.

Verify it yourself

shortest_path(EDGES, 'A', 'D') returns (8, ['A', 'C', 'B', 'D'])
shortest_path(EDGES, 'D', 'A') returns (inf, None) because the edges are directed
shortest_path(EDGES, 'A', 'A') returns (0, ['A'])
A negative edge weight raises ValueError
With parallel edges (1, 2, 10) and (1, 2, 3), the distance from 1 to 2 is 3

Follow-up

How would you return the fewest-edge path among equal-cost shortest paths? Relax on (distance, hops) tuples, so a tie on distance is broken by edge count.
How would you find the k shortest paths? Let each node be popped from the heap up to k times instead of once, or use Yen's algorithm when the paths must be loopless.
The graph has 100 million nodes and doesn't fit in memory — what now? Store a compact adjacency array on disk or memory-mapped, search bidirectionally or with A* to touch fewer nodes, or precompute contraction hierarchies for repeated queries.

Describe how you would optimize a SQL query.

Medium · Technical / Domain Questions

Approach

Measure first: capture the real plan with EXPLAIN ANALYZE (PostgreSQL, MySQL 8) or the actual execution plan (SQL Server), find the node where time goes, and compare estimated vs actual row counts — a big mismatch points to stale statistics.
Index the predicate: equality columns first, then one range or ORDER BY column, e.g. (customer_id, created_at); cover it with INCLUDE (PostgreSQL, SQL Server) or extra key columns (MySQL). A plain index on low-selectivity status rarely helps; a partial index on a rare value (WHERE status = 'failed') can.
Make predicates sargable: WHERE DATE(created_at) = '2026-01-01', LOWER(email) = ?, implicit type casts, and LIKE '%term' all defeat a plain index. Rewrite as a range (created_at >= '2026-01-01' AND created_at < '2026-01-02') or add an expression index.
Cut the work: select only needed columns instead of SELECT *, filter before joining and aggregating, turn correlated subqueries into joins or EXISTS, and prefer NOT EXISTS to NOT IN, which returns no rows if the subquery yields a NULL.
Check the join grain: a one-to-many join that inflates rows and is then patched with DISTINCT is slow and often wrong, so aggregate the child table first. Join on columns of the same type and index the foreign-key side.
Go beyond the query only if needed: keyset pagination instead of deep OFFSET, date partitioning so pruning skips old data, or a materialized summary table. Re-run the plan after each change and weigh the write cost every new index adds.

Follow-up

Why might the planner ignore an index you just added? Low selectivity, stale statistics, a function or cast on the indexed column, or a table small enough that a sequential scan is cheaper.
How do you fix a slow OFFSET 100000 page? Switch to keyset pagination — WHERE (created_at, id) < (?, ?) ORDER BY created_at DESC, id DESC LIMIT 50 — backed by an index on those columns.
Why is the query fast in staging but slow in production? Different data volume and distribution, stale statistics, or a parameter-sensitive plan; compare both plans on production-sized data.

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
How do you honour an erasure request while resource_revision.actor_user_id still references this table?

Explain the concept of polymorphism in Java.

Easy · Technical / Domain Questions

Approach

Polymorphism means one reference type can refer to objects of many concrete classes, and a call like shape.area() runs the code of the object's actual class. Java has two main kinds: runtime (overriding) and compile-time (overloading); generics add parametric polymorphism.
Runtime polymorphism: a subclass or interface implementation overrides an instance method with the same signature, and the JVM picks the body from the runtime class, not the declared type. Animal a = new Dog(); a.speak(); runs Dog.speak() via dynamic dispatch.
Compile-time polymorphism: overloads share a name but differ in parameter lists, and the compiler picks one from the declared types of the arguments. Given f(Object) and f(String), calling f(x) with Object x = "hi" runs f(Object) — a classic trap.
Know what is not polymorphic: static methods are hidden rather than overridden, fields resolve by declared type, and private and final methods cannot be overridden. Calling an overridable method from a constructor is risky because subclass fields are not yet initialized.
Explain why it matters: callers depend on abstractions (List<String> xs = new ArrayList<>()), new types plug in without editing callers (open/closed principle), and switch-on-type chains become overridden methods. @Override makes the compiler catch signature typos.

Follow-up

Is overloading resolved at compile time or runtime? At compile time from the arguments' declared types; only the receiver of an overridden method is chosen at runtime, because Java is single-dispatch.
How does the JVM keep overridden calls fast? A virtual call is an indexed lookup in the class's method table (vtable), and the JIT inlines call sites that profiling shows see only one or two receiver types, behind a type guard.
Can an override change the return type? Only to a subtype (covariant return); it also cannot reduce visibility or throw broader checked exceptions than the method it overrides.

What are the differences between an abstract class and an interface?

Easy · Technical / Domain Questions

Approach

Answer for modern Java: since Java 8 interfaces can hold default and static method bodies, and Java 9 added private ones, so "interfaces have no implementation" is the outdated answer that marks a weak response.
State is the real divide: an abstract class can have instance fields, constructors, and protected or package-private members; an interface has no instance state, its fields are implicitly public static final, and its abstract methods are implicitly public.
Inheritance: a class extends at most one class but implements any number of interfaces, and an interface can extend several. If two unrelated interfaces supply the same default method, the class must override it (delegating via A.super.method()); if one extends the other, the more specific default wins.
Use an interface for a capability or contract that unrelated classes share (Comparable, Runnable, a repository API), and an abstract class for a family of closely related types that share state and a template-method skeleton.
Mention the combination the JDK uses: an interface for the type plus an abstract skeletal class implementing most of it (List with AbstractList), so callers depend on the interface and implementers get reuse. Neither can be instantiated directly.

Follow-up

Why add a default method instead of an abstract one? It evolves a published interface without breaking existing implementers, which is how Collection.stream() was added in Java 8.
If a superclass method and an interface default clash, which wins? The class method wins (the "class wins" rule); interface defaults apply only when no class in the hierarchy provides the method.
Can an abstract class have a constructor if it can't be instantiated? Yes; subclasses call it through super(...) to initialize the shared fields it declares.

How do you ensure the security of your code?

Medium · Technical / Domain Questions

Approach

Answer with defense in depth across the lifecycle — design, code, verification, dependencies, runtime — and name concrete practices. "I'm careful" or "we run a pen test before release" is the weak answer.
Design: threat-model new features by listing assets, trust boundaries, and entry points (STRIDE is a handy checklist), then settle authentication, authorization, and least-privilege access for every service account before coding.
Code: treat all input as untrusted and validate it server-side against allowlists; use parameterized queries, context-aware output encoding against XSS, no shell string interpolation, and safe deserializers. Check authorization on every object access to block IDOR.
Secrets and crypto: keep credentials out of source code and images, load them from a secrets manager at runtime, enforce TLS 1.2+ in transit, and hash passwords with bcrypt or Argon2 from a vetted library instead of writing your own cryptography.
Verify automatically: SAST and secret scanning in CI, dependency scanning against a lockfile, fuzzing for parsers, tests for the unauthorized path (expect a 403), and code review against the OWASP Top 10 as a baseline checklist.
Runtime: least privilege, fail closed on errors, security headers, prompt patching, and audit logs of security events that never record secrets or passwords. If you have one, back the answer with a real vulnerability you caught and fixed.

Follow-up

How do you prevent SQL injection with a user-chosen sort column? Placeholders can't bind identifiers, so map the input to an allowlist of known column names and reject anything else.
A transitive dependency has a critical CVE and no fix yet — what now? Check whether the vulnerable path is reachable, pin to an earlier release that predates the flaw if one exists, else add a compensating control and track the advisory.
A secret was committed to the repo — now what? Rotate it immediately, since deleting the commit doesn't revoke it; then purge history, review access logs, and add pre-commit secret scanning.

Describe the steps you would take to design a system for processing large volumes of data.

Hard · Problem-Solving / Case Studies

Approach

State the interpretation: a pipeline that ingests records from many sources, validates and enriches them, and makes them queryable. Ask batch or streaming and the freshness target; assume e.g. 5 TB/day, 100k events/s at peak, results visible within 5 minutes.
Data flow: producers → a durable partitioned log (Kafka) read by two paths: a sink that lands records unchanged in an immutable, date-partitioned raw zone on S3, and stream processors (Flink or Spark) that parse, validate, and enrich into curated Parquet tables, a warehouse, and a lookup store.
Data contract: versioned schemas (Avro or Protobuf in a schema registry), and every record carries a stable event_id, event_time, and source. Records that fail validation go to a dead-letter queue with the error, so one bad record never stalls a partition.
Scale horizontally: throughput grows with partitions, and active consumers in a group can't exceed the partition count, so size partitions for peak plus headroom. Choose a partition key that spreads load (no hot keys) and autoscale consumers on lag.
Decide two tradeoffs out loud: streaming vs batch (freshness vs cost and simplicity; both can read the same log) and delivery semantics. At-least-once delivery plus idempotent writes (upsert on event_id) is the pragmatic route to effectively-exactly-once results.
Handle failure: consumers resume from committed offsets after a crash, watermarks with allowed lateness handle out-of-order events, and the raw zone allows replay after a bug fix. Monitor lag, throughput, error rate, and data-quality checks; encrypt in transit and at rest.

Follow-up

What if one source suddenly sends 10x its normal volume? The log absorbs the burst, consumers autoscale on lag up to the partition count, and per-producer quotas stop one source from starving the others.
How would you reprocess six months of data after fixing a transform bug? Replay the raw zone with a batch job into a new table version, validate it, then switch readers over atomically.
How do you stop one hot key from overloading a single partition? Salt it into N sub-keys and merge downstream, accepting that per-key ordering is lost so the merge must tolerate reordering, or pre-aggregate before the shuffle.

How would you approach debugging a complex software issue?

Medium · Problem-Solving / Case Studies

Approach

Stabilize before root-causing: if it is in production, measure impact and mitigate first — roll back the latest deploy, disable the feature flag, or fail over. Record the exact symptom, error text, first-seen time, and who is affected.
Get a reliable reproduction, ideally minimal, in an environment matching production's version, config, and data shape. For intermittent failures, capture the conditions each time (load, input, timing, host) to find the common factor.
Ask what changed near the first occurrence: deploys, config, dependency upgrades, data volume, infrastructure. With a known-good and a known-bad version, git bisect finds the offending commit in about log2(n) test runs.
Let evidence drive hypotheses: read logs, traces, metrics, and stack traces, rank suspects by likelihood and cost to test, and change one variable at a time. Narrow the code path by halves with logging or breakpoints instead of reading everything.
Keep the usual suspects in mind, each with its own confirming check: races that vanish under a debugger (stress tests, race detectors), leaks of memory, connections, or handles (heap dumps, handle counts), deadlocks (thread dumps), config drift (diff the effective config), and bad data (replay the input).
Fix the root cause, not the symptom: write a failing regression test first, deploy, confirm the metric recovers, then write a blameless postmortem and add the alert that would have caught it sooner.

Follow-up

What if it only happens in production? Add targeted structured logging or tracing around the suspect path, capture a thread or heap dump, and diff production's config, data, and load against staging.
How would you debug a suspected race condition? Find shared mutable state, log with thread IDs and timestamps, stress-test at high concurrency, and use a race detector such as ThreadSanitizer or Go's -race flag.
When do you stop investigating alone and escalate? Time-box each hypothesis; if impact is growing or cheap tests are exhausted, bring in the owner of the suspect component along with your evidence.

Suggested practice checklist

Built from the rounds and topics Central Intelligence Agency candidates report.

Day 1 — Map the Central Intelligence Agency loop

Write out the reported sequence: Initial Screening Call, Technical Screenings, Behavioral Interviews, Problem-Solving Evaluation, Final Evaluations.
For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 5 reported rounds, with the weakest marked.

Day 2 — Work Behavioral Interviewing

Spend the session on Behavioral Interviewing, which Central Intelligence Agency candidates report being tested on.
Write one worked example in Behavioral Interviewing and time yourself on it.

Deliverable: One timed worked example in Behavioral Interviewing.

Day 3 — Work Security Clearance Process

Spend the session on Security Clearance Process, which Central Intelligence Agency candidates report being tested on.
Write one worked example in Security Clearance Process and time yourself on it.

Deliverable: One timed worked example in Security Clearance Process.

Day 4 — Work Background Investigation

Spend the session on Background Investigation, which Central Intelligence Agency candidates report being tested on.
Write one worked example in Background Investigation and time yourself on it.

Deliverable: One timed worked example in Background Investigation.

Day 5 — Answer out loud: Technical / Domain Questions

Answer aloud, timed: Explain the concept of polymorphism in Java.
Answer aloud, timed: What are the differences between an abstract class and an interface?

Deliverable: Spoken answers to 2 reported Technical / Domain Questions question(s), under time.

Day 6 — Answer out loud: Behavioral / Leadership

Answer aloud, timed: Describe a time when you faced a significant challenge in a project. How did you handle it?
Answer aloud, timed: Tell me about a situation where you had to work under pressure.

Deliverable: Spoken answers to 2 reported Behavioral / Leadership question(s), under time.

Day 7 — Answer out loud: Problem-Solving / Case Studies

Answer aloud, timed: How would you approach debugging a complex software issue?
Answer aloud, timed: Describe the steps you would take to design a system for processing large volumes of data.

Deliverable: Spoken answers to 2 reported Problem-Solving / Case Studies question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

What is your experience with agile development methodologies?

Easy · Technical / Domain Questions

Approach

This checks whether you have actually delivered in short iterations and understand why the practices exist, not whether you can recite Scrum vocabulary. Name the framework, cadence, team size, and your role in the first two sentences.
Describe what you personally did inside the process: splitting stories, estimating, reviewing, demoing to users, raising a retro item that changed something. e.g. "two-week Scrum sprints, team of six, I owned the API stories and ran our demos."
Show judgment about the method, not loyalty to it: one practice that worked and one you adapted, with the reason. Blanket praise of agile sounds rehearsed, and complaining about ceremonies sounds like you resist process.
Quantify what the process changed: release frequency, cycle time, committed-vs-delivered work per sprint, or escaped defects, e.g. "moved from monthly releases to every sprint". Use only numbers you can explain.
If your exposure is limited, say so and map what you have done — a capstone, internship, or open-source project with a backlog and frequent feedback — to agile principles. Claiming a role you did not hold falls apart under one follow-up.
Be ready to discuss agile under constraints such as fixed deadlines, external sign-offs, or hardware dependencies: keep iterating internally, deliver thin vertical slices, and make the constraint visible on the board.

Follow-up

What would you change about how your last team ran sprints? Pick one concrete retro-driven change, the problem it addressed, and whether it stuck.
How do you handle a story that won't fit in one sprint? Split it vertically into thin slices that each deliver something testable, rather than by layer (UI, API, database).
Scrum or Kanban — when would you choose each? Scrum for planned feature work with a stable team; Kanban with WIP limits for interrupt-driven flow such as support or operations.

Describe a time when you faced a significant challenge in a project. How did you handle it?

Medium · Behavioral / Leadership

Approach

This probes ownership and problem-solving when a plan breaks: how you diagnosed the obstacle, what you decided, and what you learned. Pick a challenge you personally drove to resolution, not one you watched a senior engineer solve.
Choose a story with real stakes and a genuine decision — an unfamiliar technology on a deadline, a migration that could lose data, a design that failed under load. Skip trivial bugs and interpersonal clashes, which belong to other questions.
Spend most of the time on why it was hard and the options you weighed: what constraint bound you, which two or three paths you considered, and why you chose one. That reasoning separates a strong answer from a narrated timeline.
Say "I" for your actions and "we" only for the team's, then give the result with numbers, e.g. "cut the batch job from 9 hours to 40 minutes" or "shipped two days late instead of three weeks".
Close with the lesson and where you applied it later. If part of the challenge was your own mistake, own it in one sentence and focus on the fix; hiding it and then being probed on it is worse.
State the stakes in one line before the story: what would have broken or slipped had it stayed unsolved (lost data, a missed launch, a breached SLA), so the listener can judge why the challenge was significant rather than just busy.

Follow-up

What would you do differently? Name one specific decision you would change, such as raising the risk earlier, and why — "nothing" signals no reflection.
What was your contribution versus the team's? Separate what you personally decided or built from what others did, with one concrete example of each.
How did you know the fix really worked? Cite the metric, test, or monitoring that confirmed it and how long you watched before calling it done.

Tell me about a situation where you had to work under pressure.

Easy · Behavioral / Leadership

Approach

This tests whether you stay methodical and communicative when time is short: do you triage, protect quality where it counts, and keep people informed, or do you panic or go silent.
Pick pressure that came from outside: a production outage, a moved-up deadline, a customer-blocking defect. Pressure you created by procrastinating only works if the story is about how you fixed that habit.
Hit the beats: the constraint (time available vs work needed), how you triaged what came first, what you cut or deferred, what you refused to cut (e.g. tests on the risky path), and how and when you updated stakeholders.
Show sustainable tactics — asking for help, negotiating scope, splitting work — rather than heroics. A story whose only lever was working through the night signals poor planning, not resilience.
Quantify the outcome, e.g. "restored service in 40 minutes" or "shipped the three must-have features on the date and the other two a week later", and end with the process change that made the next crunch less likely.

Follow-up

What did you decide not to do? Name the scope you cut or deferred and how you got agreement on it before the deadline.
How do you keep quality from slipping under a deadline? Keep tests and review on the risky paths, and log any shortcut as tracked debt with an owner and a date.
When do you tell your manager a deadline is at risk? As soon as the gap is visible, with the specific shortfall, options (cut scope, add help, move the date), and your recommendation.

How do you prioritize tasks when working on multiple projects?

Easy · Behavioral / Leadership

Approach

This checks for a repeatable prioritization method plus the judgment to escalate collisions, not a favorite to-do app. Describe the method in a few sentences, then prove it with one real example.
Rank work by impact and urgency (cost of delay is a good lens), separate truly fixed deadlines from soft ones, and do blocking work first — a two-hour task that unblocks three teammates beats a day of solo polish.
When two project owners both claim top priority, don't quietly pick one: lay out both requests with estimates and consequences, ask whoever owns the priorities to set the order, then tell both parties the outcome.
Execute with focus: limit work in progress (finish before starting), time-box investigations, keep the list visible on a board, and re-plan at a fixed cadence such as daily or weekly rather than on every interrupt.
Make the example concrete, e.g. "split time between a feature launch and on-call; unblocked the partner team first and moved a nice-to-have to next sprint with the PM's agreement", and state the outcome: dates met, blockers cleared.
Avoid answers built on multitasking or "everything is a priority"; they show no method. Explicitly declining or handing off low-value work is a strength worth mentioning.

Follow-up

How do you choose between a quick win and a long-term fix such as paying down tech debt? Compare cost of delay: debt that slows every sprint or causes incidents outranks a small feature, so reserve a fixed share of capacity for it.
How do you handle an urgent interruption mid-task? Confirm it's truly urgent, note where you stopped, and tell the owner of the displaced work about the delay.
How do you keep low-priority work from silently rotting? Keep it on a visible backlog, review it weekly, and explicitly drop or hand off what won't happen.

Give an example of a time you had to persuade others to accept your viewpoint.

Medium · Behavioral / Leadership

Approach

This tests influence without authority: moving people with evidence and listening rather than rank, volume, or persistence. A technical disagreement — design, tooling, a process change — with meaningful stakes makes the best story.
State the other side fairly: what they preferred and why it was reasonable. Steelmanning their view shows you listened; a story where everyone else was simply wrong sounds one-sided.
Show how you built the case — a prototype, benchmark, cost estimate, or incident data — framed around what they cared about (risk, deadline, maintenance), e.g. "a two-day spike showed the existing database met the latency target, so we skipped a new cluster."
Show how you reduced risk for skeptics: a time-boxed pilot with agreed success criteria, a rollback plan, or adopting part of their proposal. That turns a debate into an experiment people can accept.
Give the outcome and the state of the relationship afterward, with a number if possible. Avoid stories you won by escalating or wearing people down, and keep a backup story where you were persuaded, or disagreed and committed.

Follow-up

What if they still hadn't agreed? Disagree and commit: record your concerns, support the chosen path fully, and set a checkpoint to revisit it with data.
Tell me about a time someone changed your mind. Describe the evidence that moved you and how quickly you updated your position.
How would you persuade someone more senior? Ask what worries them before you pitch, since a senior skeptic often sees a risk you don't, then show how your proposal handles that specific risk.

How do you handle conflicts within a team?

Medium · Behavioral / Leadership

Approach

This tests whether you surface conflict early, separate the person from the problem, and reach a decision the team can commit to, not whether you avoid conflict or always win it.
Talk one-on-one first, not in a public channel or a meeting. Ask what is driving their position — deadline pressure, ownership, a quality worry — and restate it until they agree you understood it.
Move to shared goals and objective criteria: agree on what success looks like, then compare options against it using data or a quick experiment. Writing the options and tradeoffs down lowers the temperature.
If you are still stuck, use the team's decision rule — the owner decides, or the lead breaks the tie — and frame the escalation as "we need a decision" rather than a complaint about a colleague.
Pick a conflict over how the team works, such as code-review standards, an uneven workload split, or on-call ownership, rather than a design debate you won by persuasion. Don't disparage the colleague; close with the working agreement you created and how the relationship held up.

Follow-up

What if the conflict is personal rather than technical? Address the specific behavior and its impact privately, and involve your manager if it continues or affects the team.
What if you were the cause of the conflict? Acknowledge it directly, explain what you changed, and describe how you repaired the working relationship.
How do you handle a teammate who keeps missing commitments? Ask privately what's blocking them, offer help or re-scoping, and agree on check-ins before raising it further.

If given a project with vague requirements, how would you clarify the objectives?

Medium · Problem-Solving / Case Studies

Approach

This tests whether you turn ambiguity into a written, agreed target before building, and keep checking it, rather than guessing silently or stalling until someone hands you a spec.
Start with the problem behind the request: who the users and decision-makers are, what outcome they need, what they do today without it, and how they will judge success. Asking "what decision will this help you make?" often reveals a smaller, sharper goal.
Write it down in a one-page brief — goals, non-goals, users, success metrics, constraints, open questions — and get stakeholders to confirm it. Turn fuzzy words into testable criteria: "fast" becomes "p95 page load under 1 second".
Replace abstract questions with something concrete to react to: a wireframe, sample output, or a thin working slice. People are far better at saying "not that" than at describing what they want from scratch.
Deliver in small increments, demo often, and keep a log of assumptions and decisions, so a later change of direction is visible and costed rather than silent scope creep.
A strong example has this shape, e.g. "asked for 'a dashboard'; interviews showed users needed a daily alert on one metric; shipped that in a week." Avoid stories where you built for months on assumptions or blocked waiting for a perfect spec.

Follow-up

What if stakeholders disagree on the objective? Tie each proposed goal to a measurable success metric in the brief so the disagreement becomes a choice between numbers, and record who made the call.
What if requirements change halfway through? Assess the impact on scope and schedule, make the tradeoff explicit to stakeholders, and update the brief and acceptance criteria.
How do you know you've clarified enough to start building? When the first slice has a testable definition of done that stakeholders agreed to; remaining unknowns are logged as assumptions to verify.