Loading...
Ace your Infosys Mainframe Developer behavioural interview with STAR-format answers, insider tips, and exact phrasing to impress your interviewer.
Here's something I see all the time: brilliant COBOL developers who can write a flawless file-handling routine in their sleep — but the moment someone asks, "Tell me about a time you handled a production issue under pressure," they freeze up like a JCL job with a missing DD statement.
You're a technical person. You'd rather talk about VSAM structures or optimise a DB2 query than talk about feelings. I get it. But here's the thing most people miss — at Infosys, the behavioural interview for a Mainframe Developer role is not a box-ticking exercise. The interviewer is checking whether you can be trusted with mission-critical legacy systems that power banks, insurance companies, and government agencies. The stakes feel high because they are.
Let's walk through exactly how to prepare.
When an Infosys interviewer asks a behavioural question to a mainframe candidate, they're not just listening to your story. They're scoring you on a mental rubric that looks something like this:
| Signal | What They Want to See | Red Flag |
|---|---|---|
| Ownership | You took responsibility for outcomes | Blaming teammates or legacy systems |
| Structured thinking | Clear, logical storytelling | Rambling without a point |
| Domain awareness | You understand mainframe-specific risks | Generic answers that could apply to any tech |
| Collaboration | You worked across teams (e.g., ops, QA, business) | "I just wrote the code and handed it off" |
| Growth mindset | You learned something and applied it | Repeating the same mistakes |
A strong answer at Infosys specifically shows that you understand the gravity of mainframe environments — downtime isn't just inconvenient, it can mean millions lost or regulatory breaches. The interviewer wants to know you feel that weight.
You've heard of STAR: Situation, Task, Action, Result. The problem is most candidates spend 70% of their answer on Situation and Task ("So we had this batch job, and it ran every night, and the business relied on it...") and then rush through the Action and Result in 15 seconds.
Flip that ratio. The interviewer already gets the context quickly. What they care about is what you specifically did and what changed because of it.
Here's a rough time split to aim for:
This is almost guaranteed. Every mainframe interviewer asks some version of this.
What they're testing: Can you stay calm, use systematic debugging, and communicate clearly under pressure?
A common trap: Jumping straight to the technical fix without explaining how you identified the problem. The interviewer wants your diagnostic process, not just the answer.
Example STAR Answer:
Situation: "At my previous project, we supported a nightly batch cycle for a large insurance client. One Monday morning, the operations team flagged that a critical policy-renewal batch had abended with an S0C7 — data exception — in the COBOL processing module."
Task: "As the lead developer on duty, it was my responsibility to identify the root cause, communicate status to the client stakeholders, and restore the job within the SLA window — we had two hours."
Action: "I started by pulling the job log and core dump to identify the exact offset of the failure. I traced it to a numeric field in our WORKING-STORAGE that was receiving a non-numeric value from an upstream file. I used XPEDITER to step through the logic and confirmed that a new file layout from the feeder system had added an extra character to one field — shifting all downstream data by one byte. I coordinated with the feeder team, implemented a quick patch using INSPECT to validate and clean the field before arithmetic, and ran the job in our test LPAR using a copy of the production data."
Result: "We restored the batch within 90 minutes, inside SLA. I then documented the root cause and proposed a validation subroutine that we added to all batch entry points — which prevented two similar incidents in the following quarter."
Notice how the Action covers the thought process, the tool used (XPEDITER), the coordination, and the verification step. That's what an Infosys interviewer wants to see.
What they're testing: Adaptability and self-directed learning — especially relevant as mainframe teams are asked to modernise or integrate with newer systems.
A common trap: Picking something too trivial ("I learned a new COBOL keyword") or too recent that you can't speak to the outcome.
Example scenario you can model your answer on:
Imagine your project suddenly required you to expose a COBOL batch routine as a REST API for a microservices integration. You'd never used IBM z/OS Connect EE before. A strong STAR answer would cover:
Here's a rough sketch of what that code integration might look like — just enough to show an interviewer you actually did the work:
* COBOL program exposed via z/OS Connect EE
IDENTIFICATION DIVISION.
PROGRAM-ID. GETCUSTMR.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-CUST-ID PIC X(10).
01 WS-CUST-NAME PIC X(50).
01 WS-RETURN-CODE PIC 9(4) VALUE 0.
PROCEDURE DIVISION.
MAIN-LOGIC.
* Receive customer ID from JSON request body (mapped by z/OS Connect)
MOVE FUNCTION TRIM(WS-CUST-ID) TO WS-CUST-ID
PERFORM FETCH-CUSTOMER
STOP RUN.
FETCH-CUSTOMER.
EXEC SQL
SELECT CUST_NAME INTO
You don't need to demo this in the interview — but referencing what you built and why it was technically challenging makes your story credible and specific.
What they're testing: Emotional intelligence, professionalism, and ability to work in Infosys's large delivery model.
Red flags to avoid:
How to frame it: Pick a technical disagreement — these are easier to discuss professionally. For example, a disagreement about whether to refactor a legacy VSAM file structure or keep it stable. Show that you listened, proposed a compromise, and the team was stronger for it.
"I can't think of any examples" — This is preparation failure, not memory failure. Before your interview, map out 6-8 stories from your career covering: a bug fix, a deadline crunch, a learning moment, a conflict, a process improvement, and a project you're proud of. Mainframe work is full of these moments.
Being too vague about tools: Saying "I debugged the issue" is weak. Saying "I used XPEDITER to trace the ABEND to a specific PERFORM paragraph" is strong. Interviewers at Infosys know mainframe — they'll respect specificity.
Forgetting the result: You solved the problem. Great. So what? Always quantify or qualify: "We saved 4 hours of manual rework per week," or "The client renewed the contract for another year."
Underselling team contributions: The opposite problem — some candidates say "my team did..." throughout without clarifying their personal role. Use "I" strategically: "I identified the issue, I proposed the solution, and I coordinated the fix with the ops team."
Let me give you some exact phrasing you can use to buy yourself thinking time and structure your answer on the fly.
Opening a behavioural answer:
"Sure — let me think of a good example for this. There was a situation at [Company/Project] where..."
Transitioning to your action:
"My specific role here was to... what I did first was... and the reason I chose that approach was..."
Handling a follow-up you didn't expect:
"That's a good question — I hadn't considered that angle at the time, but in hindsight, I think the better approach would have been..."
Closing strongly:
"The main thing I took away from that experience was [lesson], and I actually applied it later when [brief example]."
That last line — connecting your story to a future application — is what separates a good answer from a great one. It shows growth.
Infosys interviewers are trained to probe. Here's what they'll likely throw at you after your story:
"What would you do differently if you faced this again?" — Have a genuine reflection ready. Don't say "nothing, it went perfectly."
"How did your manager respond?" — This checks whether you looped in leadership appropriately or went rogue.
"How did you communicate the delay/issue to the client?" — Client-facing communication is huge at Infosys. Show that you translated technical problems into business language.
"Did anyone disagree with your approach?" — They want to see how you handle pushback.
For the JCL/ops context, sometimes they'll even ask: "Walk me through the JCL you'd write to recover that job." Be ready to bridge from behavioural into technical:
//RCVRBAT JOB (ACCT),'RECOVERY RUN',CLASS=A,MSGCLASS=X
//STEP001 EXEC PGM=GETCUSTMR,PARM='RESTART'
//STEPLIB DD DSN=PROD.LOADLIB,DISP=SHR
//INFILE DD DSN=BACKUP.POLICY.DATA,DISP=SHR
//OUTFILE DD DSN=PROD.POLICY.OUTPUT,
// DISP=(MOD,CATLG,DELETE),
// SPACE=(CYL,(50,10)),
// DCB=(RECFM=FB,LRECL=200,BLKSIZE=20000)
//SYSOUT DD SYSOUT=*
//SYSABEND DD SYSOUT=*Being able to pivot from a story to a technical detail like this signals that you're not just rehearsed — you actually lived the experience.
You've spent years mastering one of the most powerful and enduring platforms in enterprise computing. The behavioural interview is just your chance to tell that story well. Walk in prepared, structured, and specific — and you'll stand out from the 80% of candidates who wing it.