Behavioral Round: STAR Stories, the Bank Context and Questions to Ask

The technical rounds decide whether you can do the job. The behavioral round decides whether they want you on the bridge call at 2 a.m., whether they trust you with a change ticket against a cluster that clears payments, and whether application teams will enjoy being onboarded by you. At a bank there is a third thing being graded that most candidates miss: process discipline. Every story you tell is listened to for evidence that you follow change management when nobody is watching, write things down, and stay calm while a Sev-1 is open. This post gives you a STAR format that fits in two minutes, twelve story prompts mapped to the job description, dignified answers for the awkward questions, twelve questions that make you sound like the senior person in the room, and a plan for the day itself.

How the behavioral rounds run for a vendor placement at a bank

A vendor placement means two organisations interview you for one seat, and they grade different things. Post 18 covered the whole loop; this is the behavioral slice.

The vendor recruiter and account manager decide whether to put your profile in front of the client and whether the placement will stick. Expect practical questions before soft ones: earliest start date, whether you can commit to the hybrid schedule in downtown Toronto, expectations on contract length and rate, and consent to the bank's background checks. Answer plainly and consistently; a candidate whose availability changes between the recruiter call and the client round loses the seat. The vendor's "fit" questions ("tell me about your OpenShift experience", "why are you looking?") check that you talk fluently, because they will summarise you to the client in three lines.

The client hiring manager round is run by the person who will lead your team. They have read the technical panel's notes, so they are not re-testing oc commands; they want to know how you behave. Bank-style panels consistently score five things:

• Risk awareness. Do you ask "what is the blast radius?" before "what is the fix?" Do your stories mention windows, approvals and rollbacks unprompted?
• Documentation. Do the things you fixed end up in a runbook, a standard or a Git repo, or in your head?
• Collaboration. Can you work with network, security, cloud and application teams without a hierarchy forcing you to, and without blaming them?
• Calm under pressure. Does your Sev-1 account sound structured (cadence, roles, decisions) or frantic?
• Ownership. Does the story continue through the RCA and the automation that prevents the repeat, or end when the pager stops?

The "fit" questions ("how do you handle conflict", "describe your ideal team") are the same five things asked sideways. Every answer shape below is built to hit at least two.

STAR that actually works

STAR = Situation, Task, Action, Result, the format most panels score against. Candidates know the acronym and still lose points, because they spend a minute on Situation and ten seconds on Result. The version that works is lopsided on purpose:

• Situation, one sentence. Environment, scale, stakes.
• Task, one sentence. Your role, specifically.
• Action, three to five steps, first person. What you did, in order, with the real commands and decisions. "I" for what you did; name others only for what they did.
• Result, with numbers and a lesson. Time to restore, hours saved, alerts that fired before impact. Then what you would do differently, because a panel that hears "and it was perfect" stops believing you.

Time it: 90–120 seconds spoken. Longer and the interviewer plans their follow-up instead of listening; shorter and there was no Action. The four mistakes that cost the most: "we" instead of "I" (the panel cannot score a team, and "what did you do?" deflates the story); no result ("and then it was fixed" is half graded); backstory (start at the moment the problem existed); and blame ("the developers deployed without testing" tells the panel how you will describe their teams in six months).

A worked example: leading a production incident

Situation: "On a production OpenShift 4.14 cluster serving about forty application namespaces, a Sev-1 was declared at 01:40 when the mobile-banking API began returning intermittent 503s through its Route."

Task: "I was the on-call platform engineer, so I owned the technical investigation on the bridge and the RCA afterwards."

Action: "I set the bridge cadence first: a fifteen-minute update from me, and I asked the application team to hold redeploys so we were looking at a stable system. oc get co was clean, but oc get nodes showed one infra node NotReady with DiskPressure, and oc get pods -n openshift-ingress -o wide showed a router pod stuck Terminating on it while the external load balancer still sent it half the traffic. I cordoned the node and force-deleted the stuck pod so the load balancer's health check on that node failed and traffic drained to the healthy router; the 503s stopped within four minutes. Once stable, oc debug node/ showed the disk full of container logs from a debug-level app, and I confirmed the KubeletConfig that sets log rotation had been applied to the worker pool but never to the infra pool."

Result: "Time to restore was 22 minutes. From the RCA I raised an emergency change to apply the KubeletConfig to the infra pool that night, a normal change for a node-filesystem alert at 80 per cent, and a pre-upgrade script that diffs KubeletConfig and MachineConfig targets across pools. The alert fired on two other nodes the next month before any impact. What I would do differently: check oc get nodes before oc get co, because Operator status stays green while a single node dies underneath it."

That story proves, without claiming it: calm (cadence first), method (nodes before Operators before pods, the order from Post 25), process (emergency and normal change named correctly), automation-first (a script, not a reminder) and honesty (the lesson).

Twelve story prompts mapped to the job description

Each JD soft-skill line becomes a question, followed by what the panel is really scoring, the shape of a strong answer, and a skeleton you fill with your own experience.

1. "Tell me about a time you led troubleshooting of a critical production issue."

Testing: "comfortable leading troubleshooting efforts and supporting critical production environments." Do you take charge of a bridge unasked and follow an ordered method under pressure?

Strong shape: The worked example: cadence first, method second, mitigation before root cause, an RCA whose follow-up is automation.

Skeleton: "A [severity] was declared when [symptom]. I owned [role]. I set [cadence], ruled out [layer] with [command], found [cause] with [command], mitigated by [action] in [minutes]. The RCA produced [change] and [automation]. I would now [lesson]."

2. "Tell me about a time you automated a manual process. What was the result?"

Testing: "strong automation-first mindset." Do you measure toil first, build something safe, and quantify the payoff?

Strong shape: The task and its cost; what you built (a Python script against the API, an Ansible playbook, a CronJob, a pipeline stage); how you made it safe (dry-run, idempotent, output logged to a ticket); hours or errors before and after. Post 32 has the patterns.

Skeleton: "[Task] took [time] every [frequency] and had caused [error]. I wrote [tool] that [does], with [safety]. We saved [hours] and [error] has not recurred in [period]."

3. "Tell me about a time you disagreed with a developer or an architect about a platform decision."

Testing: "collaborating across multiple engineering teams." Can you hold a position with evidence, without ego, and commit when it goes against you?

Strong shape: Both positions stated fairly, the data you brought (a load test, a scan, a cost estimate), proper escalation if needed (an architecture review, not a chat argument), and the outcome. Include a case where you were partly wrong.

Skeleton: "[Team] wanted [X]; I was concerned about [risk]. I proposed [alternative] with [evidence]. We agreed on [outcome] through [forum]. In hindsight, [lesson]."

4. "Tell me about a time you onboarded a team or taught others."

Testing: "support onboarding of application teams." Do you make the platform easier to consume, or hand people a wiki link?

Strong shape: A golden path (Project template, quotas, default NetworkPolicies, a Helm chart or Argo CD ApplicationSet), a walkthrough, and onboarding time falling from weeks to days. Post 26 is the reference.

Skeleton: "Teams took [time] to reach production because [friction]. I built [artifact] and ran [session]. Onboarding dropped to [time] and [ticket type] fell by [amount]."

5. "Tell me about a mistake you made in production. What did you do?"

Testing: Honesty and process. A bank needs to know you disclose immediately, contain the damage and fix the system, not the symptom. Someone who has "never made a mistake in production" has never touched production or will hide the next one.

Strong shape: A real, bounded mistake (wrong context, wrong namespace, a change outside the window), when you noticed, who you told within minutes, the rollback, and the guardrail you added (a prompt showing the current context, a pipeline check, an admission policy). No excuses, no drama.

Skeleton: "I [mistake] because [honest cause]. I noticed when [signal], told [people] within [minutes] and rolled back by [action]. Impact was [bounded]. I added [guardrail] so it cannot recur the same way."

6. "Tell me about a time you pushed back on a risky change, or had to make an emergency change."

Testing: Risk awareness and change discipline. Do you know when to say no, and how to say yes properly at 3 a.m.?

Strong shape: For push-back: the risk, the alternative you offered (a smaller change, a lower environment first, a proper window), the requester's response. For an emergency change: the criteria that justified it, the approver you woke, the record you left, the review next day. Use Post 18's vocabulary: standard, normal and emergency changes.

Skeleton: "[Requester] wanted [change]; the risk was [risk]. I proposed [alternative] and we [outcome]." Or: "At [time] we needed [change] to restore service. I got approval from [role], applied it with [command], recorded it in [ticket], and it was reviewed at [forum]."

7. "Tell me about a time you worked independently with little direction."

Testing: "work independently." Can you turn a vague goal into scoped work and check in at the right cadence rather than disappearing for a month?

Strong shape: The vague ask, how you scoped it (a one-page plan with success criteria), what you decided alone versus brought back for a decision, and the weekly update you sent unasked.

Skeleton: "I was asked to [vague goal]. I wrote [plan] with [criteria], decided [X] myself and raised [Y] for a decision. I delivered [result] in [time] with [cadence] updates."

8. "Tell me about a time you collaborated across teams: network, security, cloud."

Testing: Translation. Can you speak each team's vocabulary and share evidence rather than opinions?

Strong shape: A problem that crossed a boundary (an EgressIP and a firewall rule, a NetworkPolicy and a security review, an IAM role and IRSA), the evidence you brought each team in their terms (a packet capture, a policy diff, a CloudTrail event), and a documented pattern both teams now use.

Skeleton: "[Symptom] sat between [team A] and [team B]. I gathered [evidence] for each, ran [joint session], and we found [cause]. We documented [pattern] so the next case is a standard change."

9. "Tell me about a time you improved documentation or standards."

Testing: "contribute to standards and documentation." Do you leave the platform more legible than you found it, and do people use what you wrote?

Strong shape: A runbook that turned tribal knowledge into steps anyone on call can follow; a labelling standard enforced by policy rather than memo; docs-as-code with review. Measure adoption: incidents resolved from the runbook by someone other than you.

Skeleton: "[Knowledge] lived with [person]. I wrote [doc] in [place], reviewed by [team], enforced with [mechanism]. [Number] of the next [incidents] were resolved from it without escalation."

10. "Tell me about a time you handled a security or compliance finding."

Testing: The whole security and compliance bullet. Can you triage by exploitability rather than panic at a CVSS score, remediate through the pipeline, and produce evidence an auditor accepts?

Strong shape: The finding (a critical CVE in a base image, a privileged SCC granted too widely, audit logs not forwarded), the triage, the fix path (rebuild through CI, tighten the SCC in a lower environment first), the deadline met, the evidence filed. Post 31 covers the vocabulary.

Skeleton: "[Scanner or audit] raised [finding] with [deadline]. I triaged by [criteria], found [scope], remediated via [path], verified with [check], and attached [evidence] to [ticket]."

11. "Tell me about a time you learned a new technology fast."

Testing: "enjoys solving complex infrastructure challenges," and whether you can close the gaps the technical round found. Panels want a method, not enthusiasm.

Strong shape: The need, the deadline, the method (docs for the exact version, a lab, a colleague you paired with, one small thing shipped in week one), the result. Terraform modules, Argo CD, OVN-Kubernetes, a new Operator: any works.

Skeleton: "We needed [technology] for [reason] within [time]. I [method] and shipped [small thing] by [date]. By [later date] I had [larger outcome]."

12. "Tell me about a time you had to prioritise between competing incidents or requests."

Testing: Judgement under load. Do you rank by business impact, say out loud what you are not doing, and pull in help?

Strong shape: Two or three things arriving at once, the impact-and-urgency call and why, who you told about the queue, what you delegated or deferred, and the outcome of each.

Skeleton: "[Incident A] and [request B] arrived together. I ranked [A] first because [impact], told [stakeholders] that [B] would wait [time], and asked [person] to [task]. [A] restored in [time]; [B] delivered [when]."

Talking about a career gap or a return to work

If you have a gap, assume the panel has seen it and is waiting for you to raise it. Dodging it looks like hiding; three minutes on it looks anxious. The answer that works is three sentences long.

1. Own it in one sentence, neutral reason, no apology: "I took [period] away from full-time work for [family / health / study / relocation], and I am fully available now."
2. Pivot to currency. What you have done recently to stay sharp: a lab on OpenShift Local or an EKS sandbox, a GitOps repo you can show, a certification in progress, a structured study programme (this series counts; say what you built while reading it).
3. Pivot to what you bring. Years of production experience do not evaporate; incident instinct, change discipline and cross-team habits are exactly what this role is buying.

Then stop talking. Do not volunteer medical or family detail, and do not ask whether the gap is a problem; the question hands them a reason to think it might be. If pressed, answer briefly and return to the present. Banks see returners often; they are checking that you are current and will not be surprised by the pace.

Support cases, vendors and two employers

Working a Red Hat case well is a soft skill

A surprising amount of platform work at a bank is working a support case well, and panels ask about it. Severity = the impact rating you assign when opening a Red Hat case, from Severity 1 (production down or critical business impact, engaged around the clock on the right subscription) to Severity 4 (a question). Choose honestly: Severity 1 for a lower-environment issue burns credibility with the engineer on the other end; under-rating a real outage costs hours.

A clear case has the exact cluster version (oc get clusterversion), a one-paragraph problem statement with business impact, what changed before it started, what you have tried and ruled out, and diagnostics attached. must-gather = the OpenShift diagnostics bundle from oc adm must-gather (add --image= for component-specific gathers such as storage or logging); oc adm inspect collects a targeted namespace or resource; for one node, oc debug node/<name>, chroot /host and a sosreport from the toolbox capture the host. Attach these before you are asked; the first reply on a case without them is a request for them, and that costs a day.

The soft skill is what you do while the case is open: keep troubleshooting, post what you learn on the case, and set expectations upward ("Red Hat has the must-gather; next update at 14:00"). "I opened a ticket and waited" is the sentence panels listen for and mark down. The same applies to storage, network and AWS support for EKS.

HCL is your employer; BMO is your client

A placement gives you two reporting lines, and the panel wants to see you understand them. The client manager directs day-to-day work: priorities, on-call, standards, the change process. The vendor manager owns your employment: contract, timesheets, reviews, compliance training and your next placement. The etiquette:

• Take direction from the client; keep your vendor lead informed with a short weekly note so nothing reaches them as a surprise.
• Technical or priority escalations go up the client chain (your client lead, then the platform manager). Contractual or employment issues go to your vendor lead, never to the client.
• Never let one side hear about a problem from the other first, and never share one side's internal information with the other.
• Do not disparage either organisation, in the interview or afterwards. The bank's security and conduct policies apply to you as if you were staff.

"What would you do in your first 30, 60 and 90 days?"

This checks whether you have a plan for becoming useful without breaking anything. The strong answer front-loads learning and ends with ownership.

• Days 1–30: learn the estate. Cluster inventory (how many, which versions, on-prem versus AWS, which are production), runbooks, the on-call rota, the change process as actually practised, the monitoring stack and its top ten alerts, the Git repos that hold cluster configuration. Shadow on-call and sit in on every bridge. Fix nothing in production unaccompanied; ship a small runbook improvement.
• Days 31–60: take a small automation win. Pick one piece of toil the team complains about (a pre-upgrade health check, a quota report, a certificate expiry check) and automate it with review. Join the rotation as secondary. Own one lower-environment upgrade end to end, including the change ticket.
• Days 61–90: own and propose. Primary on-call. Lead a production upgrade or MachineConfig rollout under the normal change process. Bring one standards proposal (labelling, onboarding template, alert hygiene) with a draft document and rollout plan. Write the RCA of your own onboarding and fix the docs that were hard to find.

Say it in under a minute. The ordering (learn, shadow, small win, own an upgrade in a lower environment, propose standards) is the point.

Twelve questions to ask the interviewer

"Do you have any questions for us?" is scored. A senior engineer asks about the estate, the on-call model and how success is measured; a junior asks about vacation days. Pick four or five per round, and ask the ones whose answers will help you decide whether you want the job.

Platform

• "How many clusters, on which OpenShift versions, and what is the upgrade cadence?" Signals you know lifecycle is the job; a hesitant answer tells you upgrades are overdue.
• "What is the split between on-prem and cloud, and where is EKS today: pilot, production, or a platform with tenants?" Shows you read the EKS bullet as a project and want to know whether you would build it or run it.
• "Is cluster configuration under GitOps, and what is managed by Argo CD versus by hand?" Separates someone who has run GitOps from someone who has heard of it, and tells you how much drift you will inherit (Post 30 has the follow-up vocabulary).
• "What is the monitoring and logging stack, and who receives the pages?" Whether the platform team is paged for application alerts tells you where the boundaries are.
• "What caused the most incidents in the last quarter?" The senior question: it shows you think in patterns and sets up the "what would you fix first" follow-up.

Team

• "What is the on-call model: rotation size, hours, follow-the-sun, vendor and bank staff mixed?" You are asking how the job feels at 2 a.m. and showing you expect to be in the rotation.
• "How many platform engineers support how many application teams, and how do requests arrive?" The ratio is your load; the channel (tickets, portal, chat) is the platform's maturity.
• "What is the team's biggest pain right now?" An honest answer, and a chance to reply with a matching story from your sheet.

Process

• "Which changes are pre-approved standard changes, and what is the lead time for a normal change?" You expect to work inside the process and make it faster from the inside.
• "Who runs a Sev-1 bridge, and are the RCAs blameless?" Tells you whether incidents are formal and whether honesty is safe, which matters for the mistake story you just told.
• "How will you measure whether this hire succeeded at six months?" Gets you the real job description and shows you intend to be measured.

Growth

• "What does growth look like in this seat: conversion, support for EX280 or EX380, exposure to the EKS build-out?" Ambition framed as investment in the platform, the only framing a client manager can say yes to.

Red flags, and the phrases that land instead

Panels keep an informal list of sentences that end a candidacy. Most are habits of speech rather than character flaws, so they are cheap to fix.

The "I don't know" technique

Every senior candidate is asked something they do not know; the score depends on what happens next. Three moves, each with a form of words worth rehearsing:

• Adjacent experience plus a closing plan. "I haven't run Hosted Control Planes. I have run classic clusters with the control plane on dedicated nodes, so I understand what it replaces, and I'd start with the Red Hat docs for the current version and a lab before touching production."
• Reason from the mechanism. "I don't remember the exact field, but a KubeletConfig targets MachineConfigPools through a selector, so I'd run oc explain kubeletconfig.spec to find it." You have shown the model in your head, which is what they wanted.
• Clarify, then answer the half you know. "If you mean the CSI driver's snapshot support, yes, and here is how; if you mean the array's replication, that sat with the storage team and I'd need to check."

For a question you half-know, separate the halves out loud: "I'm confident about X; I'm less sure about Y, and here is how I'd confirm it." Blending a confident half with a guessed half is how strong candidates get caught, because the panel probes the guessed half.

Interview day logistics for a video panel

Most vendor and client rounds are video calls, and the mechanics are scored whether or not anyone admits it.

• Setup. Wired network if possible, camera at eye level, light in front of you, notifications off, a second device with the meeting link in case the laptop fails. Join five minutes early with your name set as it appears on your résumé.
• A notes page, not a script. One page off to the side: your twelve story titles with their result numbers, the interview-trap list from Post 33, and your five chosen questions. Glance, do not read; reading is visible on video.
• Pacing. Pause two seconds before answering; it reads as thought. Answer in 90 seconds and offer depth rather than supplying it: "I can go into the RCA if that's useful."
• Clarify before answering. "When you say cluster upgrade, do you mean a minor version step or the full EUS-to-EUS path?" A clarifying question is a senior move, and it buys you the two seconds.
• Close deliberately. When they ask if there is anything else, deliver a 30-second closing statement built on this template, said aloud until it sounds like you:

Thank you. To summarise why I think this is a fit:
[1] I've run production Kubernetes / OpenShift platforms under change control,
    including [upgrade / incident / onboarding] work like the story about [X].
[2] I'm automation-first: my default response to toil is a [script / pipeline /
    playbook], and I measure the result.
[3] I'm comfortable leading a bridge, working across network, security and
    cloud teams, and writing it all down afterwards.
I'd like to do this work here, on [estate detail you learned today],
and I'm available from [date]. What are the next steps?

Likely behavioral questions and the shape of a good answer

The questions the manager round reaches for most, with the shape of a strong answer. Fill each from your story sheet.

That is the track. For the final night, re-read Post 25 for the incident method, Post 33 for the question bank and its traps, and Post 34 for the scenarios, then put the story sheet from this post beside your camera. Everything else lives at the series home.