Loading...
Nail the Infosys behavioral round with a rock-solid STAR answer for 'Tell me about a time you learned a new mainframe tool quickly.'
Let's be honest — when an Infosys interviewer asks "Tell me about a time you had to learn a new mainframe tool or technology quickly," they're not just making conversation. Infosys is one of the world's largest IT services companies, and mainframe modernization is a huge part of what they do for banking, insurance, and government clients.
Here's what the interviewer is really checking:
This is an intermediate behavioral question, which means a vague, surface-level answer will hurt you. The interviewer has heard "I read the documentation and figured it out" a thousand times. You need to show depth.
If you haven't internalized STAR (Situation, Task, Action, Result) yet, today's the day. It's the difference between a rambling 4-minute story and a punchy, confident 2-minute answer that makes the interviewer write "strong candidate" in their notes.
Here's the breakdown:
| Component | What It Covers | Ideal Length |
|---|---|---|
| Situation | Context — where, when, what project | 2-3 sentences |
| Task | Your specific responsibility or challenge | 1-2 sentences |
| Action | What YOU did, step by step | 60-70% of your answer |
| Result | Measurable outcome + what you learned | 2-3 sentences |
Most candidates blow up the Situation, rush through the Action, and forget the Result entirely. Don't be that person.
Let's build this out with a realistic scenario involving IBM SPUFI (a tool for running SQL queries in a mainframe DB2 environment) — a common tool in Infosys mainframe projects.
"During my final year internship at a mid-sized financial services firm, our team was onboarded onto a legacy mainframe migration project for a banking client. The existing system ran on IBM z/OS, and all database operations were handled through SPUFI — IBM's SQL Processing Using File Input utility. I had never worked with SPUFI or DB2 on z/OS before; my database experience was entirely in MySQL and PostgreSQL."
"Within my first week, I was assigned to validate data migration scripts by running batch SQL queries against the DB2 environment. My senior was travelling, and the client needed results by Friday — three days away."
This is where you slow down and get specific. Walk the interviewer through your process.
"First, I spent two hours mapping what I already knew. I created a quick reference document comparing MySQL syntax I was comfortable with to DB2/z/OS syntax — things like FETCH FIRST n ROWS ONLY instead of LIMIT, or how SPUFI handles nulls differently in sort operations.
Second, I reached out to a colleague who had mainframe experience and asked for a 30-minute walkthrough of the SPUFI interface — navigating the ISPF panels, setting up the output dataset, and reading the SQLCODE return values. I recorded notes and asked targeted questions rather than general ones.
Third, I built myself a small cheat sheet of the most common SPUFI panel options and SQLCODE error codes I might encounter. For example:"
-- In MySQL (what I knew)
SELECT account_id, balance
FROM accounts
WHERE status = 'ACTIVE'
LIMIT 100;
-- Equivalent in DB2 on z/OS (what I had to learn)
SELECT account_id, balance
FROM accounts
WHERE status = 'ACTIVE'
FETCH FIRST 100 ROWS ONLY;
"Fourth, I practiced on a test dataset first — running small queries, deliberately triggering errors like SQLCODE -204 (object not found) or SQLCODE -803 (duplicate key) so I understood what the error messages meant before touching the real migration data.
When I hit an unfamiliar SQLCODE — like -911, which indicates a deadlock or timeout — I didn't guess. I checked IBM's official DB2 for z/OS documentation and cross-referenced the project's internal runbook before acting."
"By Thursday evening, I had successfully validated all 47 migration scripts and flagged two data integrity issues — a duplicate primary key sequence and a null constraint violation — before they reached production. The client signed off on schedule. My manager later said this was the fastest any intern had ramped up on the mainframe stack, and I was given ownership of DB2 validation tasks for the remaining six weeks of the project."
Here's the thing most people miss — it's not enough to tell a true story. The framing matters just as much. Here's what a weak version of this answer sounds like:
"Yeah, I once had to learn SPUFI quickly. I just Googled it and read some manuals, and eventually I figured it out. It went fine."
The interviewer is internally screaming. Why? Because:
Mistake #1: Picking a technology that's too obscure or irrelevant
If you say "I learned a custom in-house tool that I can't really describe," you've lost the interviewer. Pick something recognizable — SPUFI, JCL (Job Control Language), SDSF, TSO/ISPF, CA7, Endevor, or CICS. If you're newer to mainframes, it's okay to pick a tool adjacent to mainframe work.
Mistake #2: Making it sound too easy
A common trap is wanting to sound competent, so you underplay the challenge. Do the opposite. Show that it was hard, and that you rose to it. Interviewers are looking for resilience, not superheroes.
Mistake #3: Using "we" instead of "I"
This is a behavioral question about you. Every time you say "we figured it out," the interviewer mentally deducts points. Say "I" and own your specific contribution.
Mistake #4: Forgetting to quantify the result
Numbers build credibility. "Validated 47 scripts" is stronger than "validated a bunch of scripts." Even approximate numbers work: "roughly 50 scripts," "3-day deadline," "6-week engagement."
Here's how you can open and navigate this answer in real-time:
Opening:
"Great question — this actually came up early in my internship. Can I walk you through a situation from a mainframe migration project? I think it captures exactly what you're asking about."
Signaling your structure (optional but impressive):
"I'll use the STAR format so I stay focused — Situation, Task, Action, Result."
When you're in the Action section:
"What I want to highlight here is my actual learning process, because I think that's the core of the question..."
If you get flustered or go blank:
"Let me take a second to make sure I'm giving you the most relevant part of this..."
Closing your answer:
"The key takeaway for me was that learning a tool quickly isn't about reading everything — it's about identifying the 20% of knowledge that gets you 80% of the way there, fast. That's a pattern I've carried forward."
That closing line? Interviewers love it. It shows metacognition — that you've reflected on your own learning style.
A strong STAR answer doesn't end the conversation — it starts one. Here are the follow-up questions Infosys interviewers commonly fire next:
"What would you do differently if you had more time?" Honest reflection is the right move here. Say something like: "I'd have spent more time understanding the underlying z/OS job scheduling before diving into SPUFI — knowing when and how queries run in batch context would have saved me some troubleshooting time."
"How do you stay current with new tools in your field?" Have a real answer ready: IBM documentation, mainframe-focused communities like IBM Developer, internal lunch-and-learns, or side projects. Be specific.
"Can you give me an example of a time you failed to learn something fast enough?" Don't panic. This is a maturity check. Own a real failure, explain what went wrong, and show what you changed afterward.
"How do you approach learning something when there's no documentation?" Show your problem-solving instincts: reverse-engineering existing scripts, pair programming with senior colleagues, reading error logs, or reaching out to IBM support channels.
These are the things that make interviewers lose confidence in you fast:
If your background involves JCL (Job Control Language) rather than DB2/SPUFI, here's a snippet you could reference to add technical credibility to your story:
//MYJOB JOB (ACCT),'YOUR NAME',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IEFBR14
//SYSOUT DD SYSOUT=*
//SYSIN DD *
This is a minimal JCL job for testing environment access
/*Being able to reference actual syntax — even briefly — shows the interviewer you're not just telling a story, you actually know what you're talking about. It's a subtle but powerful signal.
Here's what to carry into your Infosys interview:
You've got this. Walk in with a crisp story, own the challenge, and show them exactly how you think when the pressure is on. That's what Infosys is hiring for.