45 Spring Batch Interview Questions That Actually Get Asked in 2026 (With Answers Seniors Steal)

Here is the uncomfortable truth about Spring Batch interviews: most candidates memorize "what is a Job vs a Step" and then get quietly eliminated the moment the interviewer asks how chunk commits interact with skip and retry, or why their code still imports JobBuilderFactory in 2026.

The framework moved on. Spring Batch 5 (paired with Spring Boot 3 and a Java 17 baseline) deprecated and removed APIs that almost every older tutorial still teaches. If your answers sound like a 2019 blog post, the interviewer notices immediately.

This guide is built to fix that. It is organized the way real interviews escalate: fundamentals, then architecture, then the "show me you have actually run this in production" questions, then the Spring Batch 5 migration traps that catch experienced engineers off guard. Each answer is written to be said out loud, not just recognized.

If you want to rehearse these against a voice that pushes back and follows up like a real interviewer, you can practice on Skillora.ai after you read.

How to use this guide

Do not read it like a checklist. Interviewers rarely ask the textbook version. They ask the consequence version: not "what is a chunk" but "what happens to the records in a chunk when the writer throws on item number eight." Wherever it matters, the answers below give you the consequence, the trap, and the one extra sentence that makes you sound senior.

Jump to what you need:

• Section 1: Core fundamentals (questions 1 to 12)
• Section 2: Architecture and processing model (13 to 24)
• Section 3: Error handling, restart, and transactions (25 to 34)
• Section 4: Scaling and performance (35 to 40)
• Section 5: Spring Batch 5 and the migration traps (41 to 45)

Section 1: Core Fundamentals

1. What is Spring Batch, in one sentence a hiring manager will believe?

Spring Batch is a lightweight framework for building robust, restartable, high-volume batch jobs, the kind of "read a million rows, transform them, write them somewhere, and survive a crash halfway through" work that powers payroll runs, end-of-day reconciliation, ETL, and report generation. The keyword that matters in an interview is restartable: anyone can loop over a file, but Spring Batch exists so that a job that dies at record 600,000 can resume from the last commit rather than starting over.

2. What are the core building blocks?

There are five you must be able to name and distinguish cleanly:

• Job: the entire batch process, composed of one or more steps.
• Step: an independent phase of a job (read-process-write, or a single tasklet).
• JobInstance: a logical run of a job for a specific set of identifying parameters (for example, the payroll job for 2026-06-19).
• JobExecution: a single physical attempt to run a JobInstance. One JobInstance can have many JobExecutions if it fails and is restarted.
• StepExecution: the runtime record of one attempt at a step, holding the read count, write count, commit count, and skip count.

The distinction interviewers probe: a JobInstance is identified by its JobParameters, while a JobExecution is just one attempt at it. Get this wrong and the restartability questions later will fall apart.

3. What is the JobRepository and why can a batch job not function without it?

The JobRepository is the persistence layer for all batch metadata: which jobs ran, which steps completed, where they stopped, and how many items each processed. It is what makes restart possible at all. Without a durable repository, Spring Batch has no memory of what already succeeded, so it cannot resume.

The senior add-on: in production the JobRepository is JDBC-backed, writing to the BATCH_* metadata tables. In Spring Batch 5 the old map-based in-memory repository was removed, so even for tests you typically point it at an embedded database like H2.

4. What is a JobLauncher?

The JobLauncher kicks off a job. It exposes a run(Job, JobParameters) method and decides whether the job runs synchronously on the calling thread or asynchronously via a TaskExecutor. In Spring Boot 3, much of this is auto-configured, but you should know that the standard implementation is now TaskExecutorJobLauncher (the older SimpleJobLauncher name was deprecated).

5. Tasklet vs chunk-oriented processing: when do you choose each?

This is one of the most common screening questions, and the wrong answer is "tasklet is small, chunk is big."

• A Tasklet is a single execute() method that runs once and returns a status. Use it for a discrete operation: run a stored procedure, delete a staging table, move a file, send a notification.
• Chunk-oriented processing reads items one at a time, processes them, and accumulates them until a configured chunk size is reached, then writes the whole chunk inside one transaction. Use it for record-oriented work over large datasets.

The senior point: chunk processing exists because committing every single row is catastrophically slow, and holding everything in one giant transaction blows up memory and locks. The chunk is the compromise, a tunable transaction boundary.

6. Walk me through the lifecycle of a single chunk.

Say chunk size is 10. The framework calls the ItemReader ten times, passing each item through the ItemProcessor as it goes (read-process, read-process), buffering the processed results. Once ten items are buffered (or the reader returns null, signalling end of input), it hands the whole list to the ItemWriter once, then commits the transaction. Then it starts the next chunk.

The detail that wins points: the writer receives a list, not a single item. Candidates who write a writer that processes "the item" instead of "the chunk of items" reveal they have never actually built one.

7. What do ItemReader, ItemProcessor, and ItemWriter each do?

• ItemReader: pulls one item per call from a source and returns null when exhausted. Examples: FlatFileItemReader, JdbcCursorItemReader, JdbcPagingItemReader, JpaPagingItemReader.
• ItemProcessor: transforms, enriches, or filters an item. Returning null from a processor filters the item out so it is never written, which is a deliberate and useful pattern.
• ItemWriter: writes a chunk (a list) to a destination. Examples: FlatFileItemWriter, JdbcBatchItemWriter, JpaItemWriter.

8. What is the difference between a cursor-based and a paging ItemReader?

A cursor reader (like JdbcCursorItemReader) keeps a single open database cursor and streams rows over one connection. A paging reader (like JdbcPagingItemReader) issues repeated queries with LIMIT/OFFSET-style pagination.

Why it matters: cursor readers are simple and fast but hold a connection open for the whole step and are not safe to use across multiple threads. Paging readers are thread-safe and the correct choice for multi-threaded or partitioned steps. This single distinction is a frequent senior-screening question.

9. What are JobParameters and why do they matter for identity?

JobParameters are the typed inputs to a job, and crucially they form the identity of a JobInstance. Two runs with the same identifying parameters are the same JobInstance, which is why you cannot accidentally complete the exact same job twice. This is also why people add a timestamp or run-id parameter when they genuinely want to re-run the "same" job.

10. What is a JobIncrementer / RunIdIncrementer?

Because JobParameters define identity, running a job a second time with identical parameters throws a "job instance already exists" error. A RunIdIncrementer automatically adds an incrementing run.id parameter so each launch is a new, unique JobInstance. It is the standard fix for "I want to run this nightly job every night."

11. How do you configure a job in modern Spring Batch?

With Java configuration. In Spring Boot 3 you typically do not even need @EnableBatchProcessing because auto-configuration provides the JobRepository, JobLauncher, and transaction manager for you. You define @Bean methods for your Job and Step using the JobBuilder and StepBuilder (more on why not the old factories in Section 5).

12. What is StepScope and why would a bean need it?

@StepScope (and @JobScope) ties a bean's lifecycle to a single step (or job) execution, which unlocks two things: late binding of values that are only known at runtime (injecting a JobParameter or a value from the execution context with @Value("#{jobParameters['inputFile']}")), and a fresh instance per step so stateful readers and writers do not leak state across runs or threads. If someone injects a filename into a reader without step scope, it gets bound once at context startup and never updates, a classic bug.

Section 2: Architecture and Processing Model

13. How does Spring Batch represent the flow between steps?

A Job is a directed flow of steps with transitions based on exit status. You wire transitions like .on("COMPLETED").to(stepB) and .on("FAILED").to(errorStep). This lets you branch, loop, and short-circuit based on outcomes rather than running steps in a blind sequence.

14. What is a JobExecutionDecider?

A decider lets you make a runtime branching decision that is not tied to a step's own exit status. It inspects the JobExecution and StepExecution and returns a FlowExecutionStatus that determines the next step. Use it for "if there were zero records, skip the reporting step" type logic.

15. What are listeners and which ones matter?

Listeners are hooks that run around batch lifecycle events. The ones to name:

• JobExecutionListener (before/after job): setup, teardown, notifications, marking external systems.
• StepExecutionListener (before/after step): per-step logging, conditional exit status.
• ChunkListener (around each chunk): visibility into commits and failures.
• ItemReadListener, ItemProcessListener, ItemWriteListener: per-item hooks.
• SkipListener: the most operationally important one, it tells you exactly which records were skipped and why, so bad data does not vanish silently.

16. What is a CompositeItemProcessor?

It chains multiple processors so an item passes through each in sequence, the output of one becoming the input of the next. It keeps each transformation small, testable, and reusable instead of one giant processor doing five jobs. There is a corresponding CompositeItemWriter when you need to write the same chunk to multiple destinations.

17. How do you read from one source and write to two destinations?

Use a CompositeItemWriter (or ClassifierCompositeItemWriter if different items should go to different writers). The composite writer delegates the same chunk to each underlying writer. The classifier variant routes each item to a writer based on a classification function, useful for "valid records to the database, rejects to a file."

18. How do you read from a database and write a CSV?

Configure a JdbcPagingItemReader (or cursor reader) for input, an optional ItemProcessor for transformation, and a FlatFileItemWriter with a DelimitedLineAggregator for output. The thing interviewers listen for: did you mention setting the header callback and handling the field extraction, or did you just say "use FlatFileItemWriter" and stop?

19. What is the ExecutionContext and how is it different from JobParameters?

The ExecutionContext is a key-value scratchpad that Spring Batch persists between chunks and across restarts. There are two: a StepExecutionContext (per step) and a JobExecutionContext (shared across steps in a job). Readers use it to store their position (for example, the last line read) so a restart resumes from there. JobParameters are immutable inputs that define identity; the ExecutionContext is mutable runtime state. Confusing the two is a common stumble.

20. How do stateful readers survive a restart?

Stateful readers like FlatFileItemReader implement ItemStream, which saves their current position into the ExecutionContext at each commit. On restart, Spring Batch reads that saved position back and the reader skips ahead to where it left off. This is the mechanical answer behind the headline feature "Spring Batch can resume."

21. What is a multi-step job and why split work into steps?

Splitting work into steps gives you independent transaction boundaries, independent restart points, and the ability to branch. If validation, transformation, and loading are three steps, a failure in loading does not force you to re-validate. Steps are the unit of restart, so the granularity of your steps directly determines how much work you redo after a failure.

22. How do you pass data between steps?

The clean way is the JobExecutionContext (promote values from a step's context to the job's context using an ExecutionContextPromotionListener). Avoid static fields or shared singletons; they break under partitioning and multi-threading and they do not survive restart.

23. What is a FlatFileItemReader's biggest gotcha?

Line mapping and tokenization. You must configure a LineMapper with a LineTokenizer (delimited or fixed-width) and a FieldSetMapper to bind fields to your domain object. Malformed lines throw FlatFileParseException, and if you have not configured skip handling, one bad row kills the whole job. Knowing this connects directly to the skip/retry section.

24. When would you use a Tasklet over a chunk step in real life?

Cleanup and orchestration: truncating a staging table before a load, calling a stored procedure, decompressing or moving a file, or triggering a downstream system. Anything that is "do this one thing once" rather than "iterate over records" belongs in a tasklet.

Section 3: Error Handling, Restart, and Transactions

This is where interviews get real. Anyone can describe the happy path. Seniors are defined by how they handle the records that fail.

25. Explain skip vs retry. They are not the same thing.

This is the single most important distinction in the whole framework, and it trips up a lot of candidates.

• Retry is for transient failures. The same operation might succeed if you try again (a deadlock, a brief network blip, a lock timeout). You retry the same item.
• Skip is for permanent data failures. This record is bad and will never succeed (a malformed line, a constraint violation on garbage input). You skip it and move on so the rest of the batch completes.

The senior framing: retry buys time, skip buys progress. You configure both with .faultTolerant() on the step, then .retry(SomeTransientException.class).retryLimit(3) and .skip(SomeDataException.class).skipLimit(50).

26. What actually happens to a chunk when an item fails mid-write?

Here is the question that separates people who have read about Spring Batch from people who have operated it. When the writer throws on one item in a chunk, the entire chunk transaction rolls back. Spring Batch then does something clever: in fault-tolerant mode it re-processes the chunk one item at a time so it can isolate exactly which item failed, apply skip or retry to just that item, and commit the rest. This is why writers and processors should be idempotent and side-effect-free where possible, because they can be called more than once for the same item.

If you can explain this rollback-and-replay behavior, you sound like someone who has debugged a real batch failure at 2am.

27. Why must ItemProcessors be idempotent in fault-tolerant steps?

Because of the replay behavior above: when a chunk rolls back and is retried item-by-item, your processor runs again on items it already processed. If the processor has side effects (incrementing a counter, calling an external API, sending an email), those happen twice. Idempotency is not a nice-to-have; it is a correctness requirement under fault tolerance.

28. What is a SkipPolicy and when do you write a custom one?

A SkipPolicy decides, per exception, whether to skip and continue. The declarative .skip(...).skipLimit(...) covers most cases, but you write a custom SkipPolicy when the decision depends on more than the exception type, for example "skip parse errors freely but never skip a database error" or "skip up to 5% of records, then fail."

29. How do you capture which records got skipped?

A SkipListener. It fires with the offending item and exception for skips in read, process, and write phases. Without it, skipped records disappear silently, which is unacceptable in any system that touches money or compliance. Wiring a SkipListener that writes rejects to a dead-letter file or table is a hallmark of a production-grade job.

30. How does restartability actually work end to end?

When a job fails, its JobExecution is marked FAILED but the JobInstance remains incomplete. Relaunching with the same identifying JobParameters creates a new JobExecution for the same JobInstance. Spring Batch reads the JobRepository, sees which steps already completed, skips them, and resumes the failed step from its saved ExecutionContext position. Completed steps are not re-run (unless marked allowStartIfComplete).

31. What makes a step or job not restartable?

A few traps: marking a step allowStartIfComplete(true) changes rerun behavior; setting startLimit caps how many times a step may be attempted; and a job marked preventRestart() cannot be resumed at all. Also, if your reader is not state-aware (does not save position to the ExecutionContext), "restart" will silently reprocess from the beginning, which is worse than failing loudly.

32. How does transaction management work in a chunk step?

Each chunk runs inside its own transaction managed by the configured PlatformTransactionManager. Read and process happen, the writer flushes, and the transaction commits, all per chunk. Chunk size is therefore your transaction size: bigger chunks mean fewer commits (faster) but larger transactions (more memory, longer locks, more work lost on rollback). Tuning chunk size is tuning this tradeoff.

33. What is the no-rollback exception and why use it?

Sometimes an exception should be skipped but should not roll back the transaction (for example, a validation exception thrown by a processor that has no side effects). You configure .noRollback(SomeException.class) so the framework skips the item without paying the cost of rolling back and replaying the whole chunk. It is a performance and correctness optimization that few candidates mention.

34. How do you handle a poison record that keeps killing the job?

Combine skip with a SkipListener and a bounded skip limit. The job tolerates a configured number of bad records, routes each to a reject store, and only fails the whole job if the bad-record count crosses your threshold (a signal that the input itself is broken, not just a few rows). The anti-pattern is an unbounded skip limit, which silently swallows a totally corrupt file.

Section 4: Scaling and Performance

35. What are the ways to scale a Spring Batch job?

Know the ladder, from simplest to most powerful:

1. Multi-threaded step: a single step processes chunks on multiple threads via a TaskExecutor. Simple, but the reader must be thread-safe and ordering/restart guarantees weaken.
2. Parallel steps: independent steps run concurrently using a split flow.
3. Partitioning: one manager step splits the data into partitions, each handled by a worker step execution, often the best balance of throughput and restartability.
4. Remote chunking / remote partitioning: distribute work across multiple JVMs or nodes for true horizontal scale.

36. What is partitioning and how does it differ from multi-threading?

Partitioning splits the input data into independent slices (for example, by ID range or by file) using a Partitioner, and each partition gets its own StepExecution with its own ExecutionContext. Unlike a multi-threaded step, each partition is independently restartable and there is no shared reader contention, because each worker reads its own slice. This is why partitioning is usually preferred for serious throughput.

37. Why is a multi-threaded step risky?

Because the default readers are stateful and not thread-safe, and because saved state in the ExecutionContext can become inconsistent when multiple threads commit concurrently, which undermines clean restart. You either use a thread-safe/synchronized reader (SynchronizedItemStreamReader) and accept weaker restart guarantees, or you reach for partitioning instead. Saying "I'd just add a TaskExecutor" without naming these caveats is a red flag to a senior interviewer.

38. How do you process millions of rows without an OutOfMemoryError?

Chunk-oriented processing is the answer, but back it up with specifics: use a paging or streaming reader so you never load the full dataset into memory, keep chunk size sane (large enough to amortize commits, small enough to bound memory), avoid accumulating state in processors, and make sure the writer flushes per chunk. The failure mode candidates miss: a perfectly chunked job that still OOMs because someone collected results into a static list "for logging."

39. How do you choose a chunk size?

There is no universal number; it is an empirical tradeoff. Start in the hundreds to low thousands, then measure. Larger chunks reduce commit overhead and round-trips but increase memory, lock duration, and the amount of work redone on a rollback. The right answer in an interview is "I'd benchmark it against representative data and watch commit count, throughput, and GC," not "1000."

40. What is remote chunking vs remote partitioning?

Both distribute work across nodes. In remote chunking, a manager reads and sends processed items to remote workers that do the writing, good when processing is the bottleneck. In remote partitioning, the manager only sends partition metadata and each worker reads, processes, and writes its own slice, good when reading is the bottleneck and you want minimal data over the wire. Knowing which bottleneck each solves is the senior-level distinction.

Section 5: Spring Batch 5 and the Migration Traps (2026)

This is the section that gets people who have not touched the framework since Spring Boot 2. If your answers here are current, you instantly read as someone who keeps up.

41. What changed in Spring Batch 5 that breaks old code?

Spring Batch 5 ships with Spring Framework 6 and Spring Boot 3, and it raised the baseline to Java 17. The headline breakages:

• JobBuilderFactory and StepBuilderFactory are deprecated and removed in favor of constructing JobBuilder and StepBuilder directly.
• The map-based (in-memory) JobRepository and JobExplorer were removed; you now use a JDBC-backed repository even in tests (typically against an embedded database).
• @EnableBatchProcessing no longer exposes a transaction manager bean unconditionally, and with Spring Boot 3 auto-configuration you often should not use @EnableBatchProcessing at all.
• Metric counters like readCount and writeCount changed from int to long.

A candidate who names even two of these confidently signals real, recent experience.

42. Show me the before-and-after for job configuration.

The old way (Spring Batch 4) injected a factory:

// Spring Batch 4 (deprecated/removed)
@Autowired private JobBuilderFactory jobBuilderFactory;
@Bean public Job myJob(Step step) {
return this.jobBuilderFactory.get("myJob")
.start(step)
.build(); }

The new way (Spring Batch 5) constructs the builder directly and passes the JobRepository in explicitly:

// Spring Batch 5
@Bean public Job myJob(JobRepository jobRepository, Step step) {
return new JobBuilder("myJob", jobRepository)
.start(step)
.build(); }

The same pattern applies to steps: new StepBuilder("myStep", jobRepository) and you now pass the transactionManager explicitly to chunk steps. The reason for the change is honesty: the old factories hid the JobRepository and transactionManager dependencies; the new API makes them explicit so it is obvious what a step actually needs.

43. Why do chunk steps now require you to pass the transaction manager explicitly?

Because chunk-oriented steps commit each chunk inside a transaction, and the old StepBuilderFactory quietly supplied the transaction manager for you. In Spring Batch 5 you pass it in yourself: .chunk(10, transactionManager). This was deliberate. It surfaces a dependency that was always there but invisible, and it prevents the framework from forcing a transaction manager that conflicts with your own.

44. In Spring Boot 3, do you still need @EnableBatchProcessing?

Usually no, and this is a common gotcha. Spring Boot 3 auto-configuration provides the JobRepository, JobLauncher, and supporting beans as long as a DataSource is present. Adding @EnableBatchProcessing on top can actually disable that auto-configuration and force you to wire things manually. You only reach for it when you need to customize the infrastructure explicitly. Knowing when not to use an annotation is a strong senior signal.

45. How would you migrate a real Spring Batch 4 project to 5?

Give a plan, not a vibe:

1. Move to Java 17 and Spring Boot 3 first, since they are the baseline.
2. Replace every JobBuilderFactory/StepBuilderFactory usage with JobBuilder/StepBuilder, passing JobRepository and transactionManager explicitly. Automated tooling like OpenRewrite recipes can do most of this mechanically.
3. Swap any map-based repository in tests for an embedded JDBC repository (H2).
4. Re-check @EnableBatchProcessing usage and lean on Boot 3 auto-configuration.
5. Audit anything that depended on readCount/writeCount being int now that they are long.
6. Run the suite, because the migration also touched testing infrastructure (@SpringBatchTest and the job launcher test utilities changed).

A candidate who frames migration as "baseline, then API, then tests, then verify" sounds like someone who has actually shipped one.

The mistakes that quietly cost people the offer

After all of the above, here is what interviewers actually use to separate candidates:

• Saying "skip and retry are basically the same." They are opposites in intent. Transient vs permanent. Mix them up and you lose the section.
• Forgetting the writer takes a list. It instantly reveals you have never written one.
• Quoting JobBuilderFactory in 2026. It dates you to a removed API.
• Hand-waving restart. "Spring Batch just resumes" is not an answer; the ExecutionContext is.
• Ignoring idempotency under fault tolerance. The chunk replay behavior makes it mandatory, and almost nobody brings it up unprompted.
• Answering "chunk size?" with a magic number. The senior answer is "I'd benchmark it."

Bring up even two of these before you are asked, and the interviewer mentally moves you up a level.

How to actually prepare (not just read)

Reading answers builds recognition. Interviews demand recall under pressure, with follow-ups, out loud. Those are different skills, which is exactly why people who "knew the material" still freeze.

The fix is rehearsal against something that interrupts and digs in: "you said you'd skip that record, what does your SkipListener do with it?" That follow-up pressure is where real readiness is built.

You can practice these exact Spring Batch questions, out loud, against an AI interviewer that asks natural follow-ups and scores your answers on Skillora.ai. Run a mock, find the three questions where you ramble, tighten them, and walk into the real thing already warmed up.

Final word

Spring Batch interviews are not really testing whether you can recite "Job, Step, Reader, Writer." They are testing whether you understand the framework as a system for surviving failure at scale: chunk transactions, skip vs retry, restart via the ExecutionContext, partitioning, and the Spring Batch 5 API that most people still get wrong. Master the consequence-level answers in Sections 3 and 5 especially, and you will be in the small group of candidates who sound like they have actually run these jobs in production, because that is exactly who gets hired.

Want to rehearse out loud before the real thing? Practice these questions with realistic follow-ups on Skillora.ai.