Skip to content
Sign inCreate account

Graduate Programs

Operations & Resilience Graduate Program

Two years of rotations across site reliability engineering, security operations and incident management.

Open roles on this program

3 open roles. Every listing shows its pay range.

You learn how always-on systems are run. You rotate through site reliability engineering, our Security Operations Center and incident management, join on-call shadow rotations, and deliver an automation project in each rotation.

Site reliability engineering

  • Reliability targets: help keep critical services within their agreed levels of availability and performance.

  • Capacity: track how systems and cloud resources are used, and plan changes before they run short.

  • Automation: replace repetitive manual work with scripts and infrastructure as code, which is the focus of your rotation project.

Security operations

  • Alert triage: work with endpoint detection and response and SIEM tools, and learn to tell a false alarm from a real attack.

  • Threat intelligence: track new threats and check whether they have reached client environments.

  • Response: help contain incidents and remove phishing emails across an organization.

Incident management

  • On call: shadow on-call engineers and learn how a 3 a.m. alert is handled.

  • Running an incident: keep the timeline and draft the updates that keep executives informed.

  • Learning from it: take part in root cause analysis and track the fixes until they are done.

Who should apply

Graduates from the last two years in IT, computer science or a similar field, with an interest in infrastructure and security. Each listing shows the location and pay.

Your two years

How the program is laid out

You start with a bootcamp, then rotate through site reliability engineering, the Security Operations Center and incident management, with an automation project in each rotation. Each rotation has a manager and a review at the end.

  1. Months 1–2

    Bootcamp

    Training on the frameworks our clients work under, such as HIPAA, CJIS and SEC and FINRA rules, and on how we run systems: our monitoring and logging, runbooks, change management and the incident process used across Global Resilience Operations.

  2. Months 3–8

    Rotation 1: site reliability engineering

    You help keep critical services within their service level objectives, plan capacity, and automate a piece of repetitive manual work as your rotation project.

  3. Months 9–14

    Rotation 2: Security Operations Center

    You triage alerts from endpoint and SIEM tools, follow threat intelligence, and help contain incidents in client environments, working shifts alongside experienced analysts.

  4. Months 15–20

    Rotation 3: incident management

    You shadow on-call engineers, keep incident timelines, draft executive updates and take part in root cause analysis, then track the fixes until they are done.

  5. Months 21–24

    Final rotation and placement

    You return to the team you want to join, take a place on a supported on-call rotation and deliver a larger automation or reliability project.

  6. Throughout

    Leadership development and reviews

    Sessions on decisions under pressure, communicating with executives and handling a crisis run alongside the rotations. You get regular feedback and a review at the end of each rotation, along the program’s path from Analyst to Senior Analyst to Associate.

Our operations follow the sun: Tier 1 and 2 teams in Manila and Mumbai cover the US night, and Tier 3 engineering escalates to core teams in New York, London and Sydney. Where you are based decides which part of the day you cover.

A day in the life

A Monday in the Security Operations Center rotation

This is an illustrative composite of a typical day shift in the Security Operations Center rotation, based in London. It is not one person’s account, and no two shifts are the same.

  1. 07:45

    Shift handover

    The team in Manila hands over a written summary: open alerts, anything escalated, and one client where a user reported a suspicious email late in their day. You read it twice and ask one question before they log off.

  2. 08:15

    Triage the queue

    You work through new alerts from the SIEM and endpoint tools in priority order. Most are explained quickly: a backup job, a known scanner, a user on holiday signing in from abroad. You write down why you closed each one, so someone else could check it.

  3. 09:30

    The reported email

    With a senior analyst, you check the email from the handover. It is a credential phishing attempt that reached 40 mailboxes at a health system client. You help find every copy and remove them, and check whether anyone clicked the link.

  4. 11:00

    Check the sign-ins

    Two people clicked. One also entered a password. You confirm their sessions were revoked and their passwords reset, look for unusual sign-ins in the hours since, and record what you found in the incident ticket.

  5. 12:30

    Lunch

    Away from the screen. The shift lead makes sure everyone takes a real break.

  6. 13:30

    Threat intelligence review

    A new vulnerability in a widely used file transfer product was published overnight. You check which client environments run it, using the asset inventory, and pass the list to the teams who patch them.

  7. 15:00

    Work on your automation project

    Your rotation project: when someone reports a phishing email, automatically find other copies of it and attach them to the ticket. Today you write tests for the matching logic so it never removes a legitimate email.

  8. 16:30

    Write the incident summary

    You draft a short summary of the phishing incident for the client’s security lead: what happened, what we did, what they should tell staff. The senior analyst reviews it before it goes.

  9. 17:45

    Hand over to New York

    You write the handover for the New York shift: what is open, what to watch and who is waiting for an answer.

What we look for

Three things we assess

Every interviewer scores you against the same competencies and writes their feedback before seeing anyone else’s. For this track they are:

Methodical troubleshooting

When something breaks, you form a hypothesis, test it and narrow things down instead of guessing. You know how the pieces fit: networks, operating systems, applications and the cloud.

Calm and careful under pressure

Incidents happen at bad times. We look for people who slow down enough to be right, check before acting on a production system, and ask for help early.

Clear written communication

Handovers, tickets and incident updates are read by people who were not there. We look for writing that is short, factual and can be acted on without a follow-up call.

Sample interview questions

Questions like the ones we ask

These are samples like the ones we use, not the exact questions. Open each one to see what a strong answer covers.

Online exercise

Here is an alert and ten lines of sign-in logs. Is this an attack, and what would you do next?

What a strong answer covers:

  • Reading the evidence before deciding: source addresses, timing, which accounts, whether any sign-in succeeded.
  • Naming what would change your mind, for example a known service account or a user travelling.
  • A proportionate next step, and a written reason for your decision either way.
Outline a script that finds the ten IP addresses with the most failed requests in a web server log.

What a strong answer covers:

  • Parsing each line, filtering to failures (for example 4xx or 5xx status codes, depending on what “failed” means here), counting by IP and sorting.
  • Handling malformed lines without crashing, and a log too large to load at once.
  • Asking what the result will be used for, since one IP can be a whole office behind a proxy.
A service has a 99.95% monthly availability target. How much downtime does that allow in a 30-day month?

What a strong answer covers:

  • The arithmetic: 30 × 24 × 60 = 43,200 minutes, and 0.05% of that is 21.6 minutes.
  • The difference between counting minutes of downtime and counting failed requests, and why partial outages matter.

Team interview

A clinician says the application is slow. Walk us through how you find out why, from their browser to the database.

What a strong answer covers:

  • Establishing scope first: one user, one site or everyone, and since when.
  • Working through the layers in order: the device and network, DNS, the load balancer, the application, its dependencies and the database, using metrics and traces rather than guesses.
  • Keeping the people affected informed while you work.
You are on call. A database server’s disk is 92% full and filling at 1% an hour. What do you do?

What a strong answer covers:

  • Working out the time available: about 8 hours to full, less if the rate rises.
  • Finding what is growing (logs, temporary files, a stuck job, real data) before deleting anything.
  • A safe short-term fix, the follow-up that stops it happening again, and when to wake someone.
A client’s employee reports a suspicious email. What happens next?

What a strong answer covers:

  • Checking the email safely, finding every copy across the organization and removing them.
  • Finding out who clicked or entered credentials, and resetting and reviewing those accounts.
  • Blocking the sender and links, and telling the client clearly what happened.
What makes a good runbook?

What a strong answer covers:

  • Written for someone tired at 3 a.m.: when to use it, exact steps, how to check each step worked, and when to escalate.
  • Kept up to date, tested and, where possible, turned into automation.
Draft the first update to executives 20 minutes into an outage.

What a strong answer covers:

  • What is affected, since when, what we know about the cause (and what we don’t), what we are doing, and when the next update will come.
  • No speculation presented as fact, and no technical detail the reader cannot use.

How you work

Tell us about a time something went wrong and you had to stay calm.

What a strong answer covers:

  • What happened, what you did first and why.
  • What you learned about yourself and about the system.
What have you automated, and why?

What a strong answer covers:

  • A real task, the time or errors it saved, and how you made sure the automation itself was safe.
How do you hand over unfinished work to a colleague in another time zone?

What a strong answer covers:

  • A written handover with state, next steps, risks and who to contact, readable without you being there.
  • Checking it was understood before you leave.

Practice puzzles

Two problems to try

These are the kind of problems you might meet in the online exercise or discuss with the team. Try them before opening the solution.

Puzzle · about 20 minutes

How much error budget is left?

A client-facing service has a target that 99.9% of requests succeed over a 30-day month. It receives a steady 2,000 requests a minute. It is now day 20 of the month, and there have been three incidents:

  1. A full outage lasting 12 minutes.
  2. 90 minutes during which 20% of requests failed.
  3. A bad deploy that made 1% of requests fail for 6 hours before it was rolled back.

The team wants to run a database migration this week. If it goes wrong, they expect 30 minutes of 50% errors before they could roll back. Should they go ahead?

Hint

Count the budget in failed requests, not minutes. Then compare what is left with the worst case of the migration.

Worked solution

The budget. A 30-day month has 43,200 minutes, so 43,200 × 2,000 = 86,400,000 requests. 0.1% of that is 86,400 failed requests.

Used so far.

  • Outage: 12 × 2,000 = 24,000.
  • Partial errors: 90 × 2,000 × 0.2 = 36,000.
  • Bad deploy: 360 minutes × 2,000 × 0.01 = 7,200.

Total 67,200, which is about 77.8% of the budget, with 19,200 failed requests left. Two-thirds of the way through the month, the service has used more than three-quarters of its budget.

The migration. The worst case is 30 × 2,000 × 0.5 = 30,000 failed requests, more than the 19,200 left. If it goes wrong, the service misses its target.

So: not as planned. Either wait until the new month, or reduce the blast radius. For example, move 10% of traffic first: the same failure would then cost 30 × 200 × 0.5 = 3,000 failed requests, well within what is left. Faster rollback would help too. A strong answer also notes that the error budget is a tool for a conversation with the client and the product team, not just a number.

Puzzle · about 25 minutes

Put the incident in order

After a sign-in problem for a client, you collect these records from three teams. Each team recorded times in its own local time. The incident happened on 14 January, when New York is UTC−5, London is UTC+0 and Manila is UTC+8.

Manila TAC ticket    15 Jan 02:14  Client reports staff cannot sign in
New York change log  14 Jan 13:05  Identity provider configuration deployed
London SOC alert     14 Jan 18:09  Spike in failed sign-ins from many IPs
Monitoring (UTC)     14 Jan 18:06  Sign-in error rate rises above 5%
Manila TAC ticket    15 Jan 02:31  Escalated to Tier 3 in New York
New York change log  14 Jan 13:40  Configuration change rolled back
Monitoring (UTC)     14 Jan 18:44  Sign-in error rate back to normal
  1. Put the events in order in UTC.
  2. What most likely caused the problem? What about the security alert?
  3. How long did it take to detect the problem and to fix it, and what would you improve?
Hint

Convert everything to UTC first. Manila’s early hours of 15 January are the previous evening in London.

Worked solution

In UTC, all on 14 January:

  • 18:05 identity configuration deployed (13:05 in New York).
  • 18:06 sign-in error rate rises.
  • 18:09 security alert for failed sign-ins.
  • 18:14 client reports the problem (02:14 in Manila).
  • 18:31 escalated to Tier 3 (02:31 in Manila).
  • 18:40 change rolled back (13:40 in New York).
  • 18:44 error rate back to normal.

Cause. The errors started one minute after the configuration change and stopped four minutes after it was rolled back. That is strong evidence the change caused it. The security alert was most likely a symptom, not an attack: when sign-ins fail, users and applications retry, which looks like many failed sign-ins from many addresses. The analyst should still check that no sign-in succeeded unexpectedly before closing it.

Times. The first automated signal came 3 minutes after the errors started (the alert at 18:09; the monitoring threshold was crossed at 18:06 but nobody was paged). It took 17 minutes from the client’s report to escalation, and 38 minutes from the start of the errors (18:06) to recovery (18:44).

Improvements. Page someone when the sign-in error rate crosses its threshold, rather than waiting for a client. Show recent changes next to alerts, so the SOC and TAC could have connected the spike to the deploy in minutes. Deploy identity changes gradually with automatic rollback on error rate. And record every timeline in UTC.

Practice case

Work through a case

In the team interview you may be given a case like this one and asked to talk through your approach. There is no single right answer: we are interested in how you use the evidence.

Practice case · 60 minutes

A security team drowning in alerts

The client and every number in this case are fictional, made up for practice.

Background

We run security monitoring for a regional health system. The client’s chief information security officer is worried: analysts cannot keep up with the alert queue, and last month a real compromise (a mailbox forwarding rule sending email outside the organization) sat in the queue for two days. There are 8 analysts on the account, each with about 30 hours a week for triage.

Exhibit 1 · Alert rules, a typical week
RuleAlerts a weekReal incidents a weekMinutes to triage each
R1. Sign-in from an unusual location1,40066
R2. Malware detected on a device1203015
R3. More than 10 failed sign-ins in 5 minutes2,60044
R4. Mailbox rule forwarding email outside the organization40820
R5. More than 2 GB sent to an unknown destination300312
R6. Administrator role granted90910
Exhibit 2 · Proposed tuning (tested against last month’s alerts)
RuleChangeEffect on alertsReal incidents missed
R1Exclude the corporate VPN and staff with approved travel70% fewerNone
R3Raise the threshold to 25 and alert once per account per hour85% fewer1 a week
R5Allow-list the backup provider’s destinations80% fewerNone

Your task

  1. How much triage work arrives each week compared with the team’s capacity?
  2. What would the proposed tuning do, and should the client accept missing one incident a week from R3?
  3. How would you make sure the next mailbox forwarding rule is caught within the hour?
One way to approach it

Work against capacity. Triage minutes a week: R1 1,400 × 6 = 8,400; R2 1,800; R3 2,600 × 4 = 10,400; R4 800; R5 3,600; R6 900. That is 25,900 minutes, about 432 hours, against 8 × 30 = 240 hours of capacity. The queue can only grow. Only 60 of the 4,550 weekly alerts (1.3%) are real incidents.

After tuning. R1 falls to 420 alerts (2,520 minutes), R3 to 390 (1,560 minutes) and R5 to 60 (720 minutes). With the other rules unchanged, the total is 8,300 minutes, about 138 hours: well inside the 240 available. There are 1,120 alerts a week, of which 59 are real (5.3%).

The missed incident. Don’t accept it silently. Ask what R3 is protecting against. If it is password guessing on one account, the health system’s multi-factor authentication and account lockout already cover much of it. If it is password spraying (a few attempts on many accounts), a new rule that counts failures across accounts from one source catches it better than R3 ever did. Agree the trade-off in writing with the client’s security officer.

Catching the next forwarding rule. Order the queue by how often each rule finds something real, not by arrival time: R2 (25%), R4 (20%) and R6 (10%) first; R1, R3 and R5 are below 1.5%. Give R4 a one-hour response target with a page to the on-shift analyst. And because this kind of rule usually means a compromised mailbox, add an automatic step that suspends external forwarding pending review. Report weekly on queue age and missed targets so the client can see it working.

Next steps

Prepare and apply

The first step is a short online exercise, followed by interviews with the team. Each listing shows the location and the pay.