JVM backend interview scorecard: bounded exports and resource lifetimes

Run the same bounded 60-minute discussion

This exercise assesses reasoning about a synthetic Java backend export. It is not a coding test, a production simulation or proof of implementation performance. Share the candidate packet, timebox, format and adjustment contact in advance. Use one facilitator and, where possible, one note-taker. Each interviewer rates independently before discussing evidence.

Administration: read the scenario as written and answer only factual clarification questions. Do not coach toward a cursor, isolation level, serializer, staging design or specific Java API. Ask each fixed prompt and its listed follow-up once. Stop at the time boundary even if the candidate is mid-answer. An unasked question is not a weakness; mark that dimension NO if there was no fair evidence.

Optional unscored extension: “What would you check if the production service also had Kotlin code?” Do not score syntax, Kotlin library memory or familiarity with this employer. A candidate can answer in Java terms and explain what they would learn from the Kotlin owner.

OPM's structured-interview guidance describes using the same predetermined questions, order, rating scale and standards. Its scoring FAQ recommends equal weights unless a different weighting has a clear documented rationale. These are process references; they do not validate this exercise: OPM structured interviews and OPM scoring FAQ.

↑ Back to sections

Give the candidate only the fixed scenario

The print packet contains the fixed scenario, interview format, five scored dimensions and task. It does not contain expected answers, interviewer prompts or scoring anchors.

The packet below is candidate-facing material and can be printed by itself.

For an agreed format adjustment, provide the same scenario in an accessible alternative format. Do not add expected answers to the candidate copy.

↑ Back to sections

Score bounded memory and JDBC resource lifetime

Fixed prompt, minutes 16–29: “How do you send this result without holding all rows in memory? Who owns the cursor and connection while the slow client reads?”

Fixed follow-up: “What would you verify in the deployed JDBC driver before trusting a fetch-size setting?”

Useful evidence traces each row from JDBC through any mapping and encoding to the HTTP writer. The candidate should avoid collecting all rows, building one giant JSON or CSV string, or keeping an unbounded queue between producer and socket. They can describe a forward-only result and bounded chunks, but should note that a nominal streaming API may buffer elsewhere. A small reusable output buffer can be reasonable; the important property is that memory does not grow with the full result size or with a slow consumer without an explicit bound.

Assess ownership as a lifecycle, not a vocabulary answer. A result set depends on its statement and connection, and a server-side cursor may depend on an open transaction and driver-specific conditions. The result cannot safely escape a `try` scope that already closed its owner. The slow HTTP write introduces backpressure: a direct pipeline may hold the query, transaction and pool connection while the client reads. A staged design can shorten that lifetime only if scratch storage has explicit limits, access controls, cleanup and retention; none are supplied as free resources in this exercise.

Strong candidates ask how simultaneous exports share the 8-connection pool and 256 MiB process envelope, then propose an admission or workload policy owned by the service. Do not demand a particular concurrency number, chunk size or framework. The follow-up is satisfied when the candidate says they would verify the exact driver/version, auto-commit and statement constraints, then demonstrate bounded fetching with synthetic data instead of relying on the setting name.

Evidence to record: what is bounded; which objects are live during a slow write; what owns and closes JDBC objects; how query/connection capacity interacts with four concurrent exports; and the specific test or measurement that would falsify the design.

pgJDBC documents its cursor-fetch requirements and warns that some conditions can cause whole-result fetching instead. Oracle documents deterministic closure of JDBC resources and the conditional `Statement.cancel()` contract: pgJDBC query results, JDBC resource closure and Java 17 Statement API.

↑ Back to sections

Probe authenticated tenant authorization

Fixed prompt, minutes 5–16: “Trace the request identity to the SQL and the response. Where must authorization occur, and what negative test would catch a cross-tenant leak?”

Fixed follow-up: “A client guesses a valid export identifier from another account. What prevents it from reading that result?”

The scenario gives no trusted tenant identifier from the request body. Look for identity derived from the authenticated server-side principal, an authorization or membership check at the request boundary, and a query/result lookup scoped to that identity. An export identifier is a locator, not permission. If a future implementation stores a staged artifact, access to that artifact must remain bound to the same authorized account; a signed URL or opaque key is not a substitute for deciding who may issue it and how long it works.

Do not prescribe a schema or policy product. A tenant predicate in SQL, defense-in-depth database controls or a service-level authorization layer may fit, provided the candidate can trace the trusted identity to every read. A useful test creates two synthetic accounts, requests an export for one, then tries the other account against both the initial request and any status/download route. The test should assert denial and no cross-tenant row or byte is emitted.

Score the boundary and verification, not confidence in UUIDs, middleware or an ORM. A strong answer names where the trust decision happens and how the test would fail if a developer accidentally removed the scope. A partial answer might identify authenticated identity but leave a later retrieval endpoint unscoped. A material gap is treating client-supplied account data or possession of an identifier as sufficient authorization.

Evidence to record: the trusted identity source, every access path in scope, where scope is enforced, and one concrete cross-tenant negative test.

↑ Back to sections

Probe consistency, cancellation and artifact truthfulness

Fixed consistency prompt, minutes 29–41: “The export must describe one point in time. What query and transaction shape would you choose or verify?”

Fixed follow-up: “If you use several keyset-paginated SELECT statements, what prevents a row update or insert between pages from making a mixed-time export?”

Give credit for distinguishing a single query from a sequence of queries and for tying the answer to documented database semantics. In PostgreSQL, transaction isolation determines which committed versions statements can see; `REPEATABLE READ` gives successive statements in a transaction the same snapshot after the first query. A single query under `READ COMMITTED` has statement-level visibility, but the candidate should verify how the actual cursor, query and driver execute and whether any separate reads are introduced. The point is not to recite an isolation level. It is to preserve the stated point-in-time contract and expose the cost of holding a transaction and connection for a slow consumer. A long active snapshot can delay reclamation of old row versions, so involve the database owner and measure transaction duration.

Fixed cancellation prompt, minutes 41–53: “The client disconnects during a slow write. What stops, what gets closed, and how will the client distinguish a complete file from a partial body?”

Fixed follow-up: “Suppose the HTTP worker is interrupted but the JDBC driver is still blocked in a fetch. What do you do next, and what must be true before the connection returns to the pool?”

Cancellation is cooperative across boundaries. `Statement.cancel()` asks the driver/DBMS to cancel if supported; it does not establish a portable completion time. Look for best-effort cancellation paired with deterministic cleanup: stop reading/writing, close result set and statement, end the transaction, release or invalidate the connection according to pool/driver guarantees, and record a terminal canceled/failed state. The client should accept only an explicitly complete artifact. For example, a row-framed format can include a final completion record or digest; another format may define completion through a verified length/checksum. The candidate should not claim that a server can replace an already-started successful HTTP status after streaming bytes. The product contract says an incomplete attempt is discarded and restarted from the beginning, not resumed.

Score whether the answer remains truthful when a query fails after bytes were sent. The service must not mark the artifact complete, send a success notification or return a connection that may still be busy merely because the client disappeared. Useful verification includes a test client that reads slowly then disconnects, an injected query/encoding failure, bounded cleanup assertions, and evidence that subsequent pool use still works. Avoid requiring a specific cancellation API or format until the team's HTTP/JDBC stack is known.

PostgreSQL describes its transaction snapshots and cursor lifetime; pgJDBC describes cursor fetching and transaction requirements. JDBC specifies statement cancellation only when supported by the DBMS and driver: PostgreSQL transaction isolation, PostgreSQL DECLARE cursor, PostgreSQL CLOSE, pgJDBC cursor fetching and Java 17 Statement.cancel().

↑ Back to sections

Use five evidence anchors without a hidden cutoff

Scale for each dimension: 1 = a material role risk remains after the fixed follow-up; 2 = partial evidence with an important gap; 3 = workable evidence for this stated role; NO = insufficient fair evidence to rate. Record a reason for NO. Do not convert it to 1, a zero or a missing-value penalty. Do not total the dimensions or apply an automatic cutoff.

There is no separate Kotlin fluency score. Java is required for the existing backend on day one; Kotlin conventions and APIs may be learned with support. The assessment measures equivalent backend/JVM reasoning regardless of the candidate's prior Kotlin exposure.

Write an observation before a rating: a choice, stated assumption, test or boundary. A rating describes evidence gathered for this role, not a person's general ability or future potential. If a candidate has a workable design but cannot name a specific driver guarantee from memory, ask the same follow-up and accept an evidence-based verification plan. The score is not a documentation recall test.

Do not total the five ratings into an automatic pass/fail value. Interviewers should compare observed evidence with the actual role brief, note what was not observed, consider the support the team offers and make a human decision. If the team later introduces weights, record a job-related basis and use it consistently. Have Java, database and security subject-matter reviewers inspect the prompts and anchors before the exercise is used with candidates.

↑ Back to sections

Print the interviewer packet and blank evidence sheet

Complete ratings independently before the debrief. Record job-related evidence only and keep the packet under the organization's candidate-data access and retention rules.

This packet repeats the scenario facts, candidate orientation, prompts and rating anchors so it remains usable when printed by itself.

Before using this scorecard

• Have Java, database and security reviewers confirm the facts match the intended role.
• Verify exact driver behavior against the team's pinned version; this document does not claim that the exercise was run or piloted.
• Dry-run timing with a non-candidate and revise unclear prompts before use.
• Share the format and duration in advance and offer an adjustment path.
• Keep candidate records only under the organization's access and retention rules.

This is an unpiloted discussion aid, not a validated assessment instrument, a live performance test, legal advice or an automated recommendation. People remain responsible for fair administration and the final hiring decision.

↑ Back to sections

Choose your next step