The T24 Interview Process

If you are reading this, you are probably preparing for a T24 interview. Or you have just had one and you are trying to figure out what happened. Or you have been in T24 for ten years and you are curious whether the interview process has changed since the last time you went through it. Spoiler: it has not. It is the same questions, the same vague answers, and the same moment where the interviewer asks something that sounds simple but is actually a trap.

This article is a guide to the T24 interview process. It covers the questions you will be asked, the answers that work, and the answers that do not. It also covers the questions you should ask, because an interview is a two-way process, and you deserve to know what you are getting into.

The structure of a T24 interview

T24 interviews follow a predictable pattern. There are variations, but the core structure is consistent across banks, consultancies, and product companies:

• The HR screen. A 30-minute call where someone from HR confirms you exist, asks about your notice period, and tries to figure out whether you are a contractor looking for a permanent role or a permanent employee looking for a contract. The answer to this question matters more than your T24 experience, because the hiring manager has a budget and a headcount constraint, and those two things do not always align.
• The technical round. A 60-minute call with a senior T24 professional who has been doing this for fifteen years and has strong opinions about everything. This is the round where you get asked about COB, AA, TPH, and the difference between TAFC and TAFJ. It is also the round where the interviewer decides whether you are someone they can work with, which is a decision that has nothing to do with your technical answers.
• The architecture round. A 60-minute call with a solution architect or a platform lead who wants to know whether you understand the big picture. This is the round where you get asked about integration patterns, upgrade strategies, and the future of T24. It is also the round where the interviewer tries to figure out whether you are a specialist who only knows one area or a generalist who can handle anything.
• The cultural round. A 45-minute call with a hiring manager or a director who wants to know whether you will fit in. This is the round where you get asked behavioural questions — "tell me about a time you handled a difficult stakeholder" — and the interviewer tries to figure out whether you are going to be a problem. The answer to this question is almost always "I handled it professionally," which is the interview equivalent of "I am fine."

Some banks add a fifth round — a presentation or a case study — where you are asked to present on a T24 topic of your choice. This is the round that separates the candidates who prepared from the candidates who did not. It is also the round where the interviewer learns more about you than you think, because the topic you choose says a lot about what you actually care about.

The questions you will be asked

There are questions that appear in every T24 interview. They are the classics. They have been asked since before you started working with T24, and they will be asked long after you retire. Here is what they actually mean and how to answer them:

"Tell me about your experience with T24."

This is the opening question. It sounds simple, but it is a test of how you frame your career. The wrong answer is a chronological list of every T24 project you have worked on since 2008. The right answer is a summary that covers: what versions you have worked with, what modules you know well, what environments you have supported (development, UAT, production), and what kind of work you have done (development, support, migration, upgrade). Keep it to two minutes. If you go longer, the interviewer will stop listening and start thinking about their next question.

"What is COB and what does it do?"

This is the most common technical question in T24 interviews. The interviewer wants to know whether you understand the batch cycle, not whether you can recite the list of COB stages. A good answer covers: what COB does (processes scheduled activities, runs end-of-day calculations, generates reports), what can go wrong (reverse replay, long-running stages, database contention), and what you do when it fails (check the COB log, identify the failing stage, restart from the failed stage). If you can also explain what reverse replay is and why it matters, you have passed this question.

"What is AA and how is it different from the legacy model?"

This question tests whether you understand the architectural shift from the legacy account-based model to Arrangement Architecture. The interviewer wants to hear that AA is product-driven, not account-driven; that arrangements have property classes and conditions; and that changes require Proof and Publish. If you can also explain why reverse replay is more common in AA than in the legacy model, you are doing well. If you can explain it without using the word "granular," you are doing exceptionally well.

"What is the difference between TAFC and TAFJ?"

This question is a trap. The obvious answer is that TAFC is the legacy runtime and TAFJ is the Java-based runtime. The interviewer knows this. What they actually want to know is whether you understand the practical implications — that TAFJ uses a different compilation model, that descriptor logic behaves differently, that DBTools replaces the SELECT command, and that the migration from TAFC to TAFJ is not a simple recompile. If you can describe a specific problem you encountered during a TAFC-to-TAFJ migration, you have answered this question perfectly.

"How do you handle a production incident?"

This is a behavioural question disguised as a technical question. The interviewer wants to know whether you panic, whether you can triage effectively, and whether you communicate well under pressure. A good answer covers: how you assess the severity, how you gather information (logs, system status, recent changes), how you identify the root cause, how you implement the fix, and how you communicate with stakeholders. If you can describe a specific incident where you did all of these things, you have answered this question. If the incident happened at 2am on a Sunday, even better.

"Where do you see T24 going in the next five years?"

This question is not about your forecasting ability. It is about whether you are paying attention to the industry. The interviewer wants to hear that you know about cloud migration, event-driven architecture, ISO 20022, and the shift from on-premises to SaaS. You do not need to be an expert in all of these areas, but you need to be aware that they exist. If you say "I think T24 will still be running on JBoss in five years," the interview will end shortly after.

The questions you should ask

An interview is a two-way process. You are evaluating the bank as much as they are evaluating you. Here are the questions that will tell you whether you actually want to work there:

"What version of T24 are you on and when was the last upgrade?"

This tells you everything about the state of the platform. If they are on a version that is more than three years old, the upgrade is coming and it will be painful. If they are on the latest version and they upgrade regularly, the platform is well-managed. If they do not know what version they are on, run.

"How many L3 modifications do you have?"

This tells you how much technical debt the platform has. If the answer is "none" or "a handful," the platform is clean. If the answer is "we do not track that" or "a lot," you will be spending your first six months dealing with upgrade conflicts. If the answer is "what is an L3 modification?" the interview is over and you should leave.

"What is your approach to testing?"

This tells you whether the bank has a proper testing process or whether they test in production. If they have a dedicated test environment, a regression test suite, and a formal UAT process, the platform is well-governed. If they say "we test in UAT and then promote to production," ask follow-up questions about what UAT actually involves. If they say "we have a production environment and a non-production environment," ask which one is which, because sometimes the answer is not what you expect.

"What is the on-call rotation like?"

This tells you about the work-life balance. If they have a formal on-call rotation with escalation paths and post-incident reviews, the team is well-organised. If they say "we do not really have an on-call rotation, everyone just helps out when things break," you will be on call every night until you quit. If they say "what is on-call?" they are either lying or they have never had a production incident, and both are bad signs.

"Why is this position open?"

This tells you whether the previous person left, was promoted, or was fired. If the position is new, that is a good sign — the team is growing. If the previous person left, ask why. If the answer is vague or uncomfortable, trust your instincts. If the answer is "they moved to another team internally," that is neutral — it could mean the team is a good place to work from, or it could mean they escaped.

What not to say

There are things that candidates say in T24 interviews that immediately disqualify them. Some of them are obvious. Some of them are less obvious but equally fatal:

"I know everything about T24."

Nobody knows everything about T24. The product is too large, too complex, and too varied across versions and implementations. Anyone who claims to know everything is either lying or delusional. The right answer is "I know these areas well, and I am comfortable learning new areas as needed."

"I prefer TAFC over TAFJ."

Even if this is true, do not say it in an interview. TAFJ is the future. TAFC is the past. Saying you prefer TAFC tells the interviewer that you are resistant to change and that you will be difficult to work with during the migration. If you genuinely prefer TAFC, frame it as "I have extensive experience with TAFC and I am also comfortable with TAFJ."

"I do not do production support."

In T24, everyone does production support. The developers support their code. The architects support their designs. The managers support their teams. If you say you do not do production support, the interviewer will assume you are not a team player and that you will disappear when things go wrong. Even if the role is purely development, you will be expected to help with production incidents occasionally. If that is not acceptable to you, T24 might not be the right field.

"I have never had a production incident."

This is either a lie or a sign that you have not been in T24 long enough to have meaningful experience. Everyone has production incidents. The question is how you handle them. If you say you have never had one, the interviewer will assume you are either inexperienced or dishonest. Both are disqualifying.

The honest truth

T24 interviews are not like other IT interviews. The product is niche. The community is small. The questions are specific. And the people doing the interviewing have usually been in T24 long enough that they can tell within the first five minutes whether you know what you are talking about.

The best preparation for a T24 interview is not memorising answers to common questions. It is understanding the product deeply enough that you can answer any question honestly, and knowing when to say "I do not know, but here is how I would find out." That answer, by the way, is almost always better than making something up. The interviewer has been doing this long enough to know when you are bluffing. They have done it themselves. They know the signs.

And if you do not get the job, do not take it personally. The T24 job market is small and the competition is fierce. Sometimes the other candidate just had more experience with the specific version or module the bank is using. Sometimes the interviewer was having a bad day. Sometimes the chemistry was not right. It happens. The important thing is to learn from the experience and apply again. The next interview will be better. And if it is not, at least you will have a good story to tell.