Skip to content
Sign inCreate account

Graduate Programs

Technology & Engineering Graduate Program

Two years of rotations across product engineering, platform and security, shipping production software from your first month.

Open roles on this program

3 open roles. Every listing shows its pay range.

You rotate through product, platform and security engineering teams and ship production software under senior mentorship from your first month. Structured training in secure development runs alongside the rotations.

Software engineering

  • APIs: design REST and GraphQL APIs used by mobile apps and partners, and learn versioning and backward compatibility.

  • Front ends: build dashboards in React or Angular for clinicians and traders, where a frozen screen can hold up urgent work.

  • Services: write focused services in Go or Java, and learn to handle distributed transactions without losing data.

Platform engineering and DevSecOps

Working within the Fusion Center:

  • Infrastructure as code: define environments in Terraform or Pulumi, with the same version control as application code.

  • Software supply chain: use tools such as Snyk and Dependabot to keep vulnerable libraries out of our products.

  • Site reliability: manage error budgets and service level objectives, and learn to debug production issues under load.

Data engineering and AI

With our Data Trust & Governance Labs:

  • Pipelines: build data pipelines from government and healthcare sources, with quality checks at the source.

  • MLOps: turn experimental models into reliable services and monitor them for drift.

  • Privacy engineering: build masking and tokenization into pipelines so analytics never expose personal information.

Who should apply

Graduates from the last two years in computer science, engineering or a similar field, with strong programming fundamentals. Each listing shows the location and pay.

Your two years

How the program is laid out

You start with a bootcamp, then move through three rotations of about six months each and a final placement. Every rotation has a manager, a project you own and a review at the end, so you always know where you stand.

  1. Months 1–2

    Bootcamp

    Training on the frameworks our clients work under, such as HIPAA, CJIS and SEC and FINRA rules, and on the Moraph stack: our cloud landing zones, CI/CD pipelines, observability tools and secure development standards. You finish by shipping a small change to a real service through the full pipeline.

  2. Months 3–8

    Rotation 1: product engineering

    You join a product squad building one of our SaaS applications. You own features end to end: design, code, tests, documentation and the demo to product directors at the end of the sprint.

  3. Months 9–14

    Rotation 2: platform and DevSecOps

    You work in the Fusion Center on the infrastructure under our products: Terraform modules, deployment pipelines, software supply chain checks and service level objectives.

  4. Months 15–20

    Rotation 3: security or data

    You choose between application security, where you threat-model features and fix findings, and the Data Trust & Governance Labs, where you build pipelines and put models into production with privacy controls built in.

  5. Months 21–24

    Final rotation and placement

    You return to the team you want to join, or try one more, and take on a larger piece of work with less supervision. The aim is that you finish the program already doing the job you will stay in.

  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.

Rotations can cross business units. A common pattern is building an API in the Fusion Center and then helping Government Solutions deploy it to a client.

A day in the life

A Tuesday in the platform rotation

This is an illustrative composite of a typical day in the platform and DevSecOps rotation, based in New York. It is not one person’s account, and no two days are the same.

  1. 08:45

    Read the overnight handover

    Engineers in Yerevan worked on the same service while New York slept. Their handover note says a nightly job failed once and passed on retry. You add it to the list to look at, because a job that fails “once” usually fails again.

  2. 09:15

    Stand-up

    Fifteen minutes with the squad: what you finished, what you are doing today, what is in your way. Yours: a Terraform module for a new HIPAA-ready environment is waiting on a review from the security team.

  3. 09:30

    Pairing session

    A staff engineer pairs with you on the module. You learn why the storage bucket needs encryption with a client-managed key and why logging must go to a separate account that the application team cannot change.

  4. 11:30

    Fix a failed security scan

    Your pull request from yesterday failed the dependency scan: a library has a known vulnerability. You upgrade it, check the changelog for breaking changes, rerun the tests and ask for review again. Code that fails the scan does not merge.

  5. 12:30

    Lunch

    With two graduates from other tracks. One is in the Security Operations Center rotation and explains how the alert you saw in the handover note looked from their side.

  6. 13:30

    Chase the flaky job

    You find the nightly job fails when it runs at the same moment as a database backup and hits a connection limit. You write up the cause, propose moving the schedule and adding a retry with backoff, and open a ticket with the evidence.

  7. 15:00

    Design review

    A product squad presents a change to a public API used by a credit union’s mobile app. You listen to the discussion on versioning: the old version must keep working until every client has moved.

  8. 16:15

    Deploy to staging and check the error budget

    Your module goes to staging. You watch the dashboards for the service level objectives you are responsible for and confirm nothing moved.

  9. 17:15

    Write the handover

    Before you log off, you write a short note for the team in Sydney: what changed today, what to watch and who to call. Follow-the-sun only works if the handover is good.

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:

Engineering fundamentals

You can write clear, correct code in at least one language, reason about data structures and performance, and test what you build. We care more about how you think through a problem than about which language you use.

Judgment about risk

Our clients are hospitals, banks and public agencies. We look for people who ask what could go wrong, who protect personal data by habit, and who know when to stop and ask before changing something in production.

Communication and teamwork

You will explain your work to engineers, product managers and sometimes clients, often in writing and across time zones. We look for clear explanations, good questions and the ability to take and give feedback.

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

Write a function that takes a list of appointment time ranges and merges any that overlap.

What a strong answer covers:

  • Sorting the ranges by start time first, then walking through them once and extending the current range while the next one overlaps.
  • Being explicit about edge cases: ranges that touch (does 10:00–11:00 overlap 11:00–12:00?), an empty list, a single range, ranges given in any order.
  • The running time: O(n log n) for the sort, O(n) for the merge.
  • A few test cases written alongside the code.
Here is a short function that totals payments. What is wrong with it, and how would you fix it?

What a strong answer covers:

  • Spotting that money is held in floating-point numbers, so totals can be off by fractions of a cent, and suggesting integer cents or a decimal type.
  • Asking what currency and rounding rules apply instead of assuming.
  • Noticing smaller issues too, such as no handling for an empty list or a negative refund, without losing sight of the main bug.
Given a file of API response times, how would you compute the 95th percentile? What changes if the file is too large to fit in memory?

What a strong answer covers:

  • The direct approach: sort and take the value at the 95% position, with care over how the index is rounded.
  • For large data: a single pass with a histogram of fixed buckets, or a streaming estimate, and an honest statement of the accuracy you give up.
  • Why the 95th percentile matters more than the average for a clinician waiting on a screen.

Team interview

Design an API that lets a patient cancel an appointment.

What a strong answer covers:

  • The resource and method (for example, a state change on the appointment rather than a delete), request and response shapes, and status codes for the cases that matter: already cancelled, too late to cancel, not your appointment.
  • Authentication and authorization: a patient can only cancel their own appointments.
  • Idempotency, so a retry after a timeout does not cause a second effect.
  • An audit record of who cancelled and when, and only the minimum personal information in requests and logs.
  • How you would version the API when it needs to change.
A service’s 95th-percentile latency doubled right after a deploy. Walk us through how you investigate.

What a strong answer covers:

  • Checking the timing against the deploy and deciding early whether to roll back while you investigate.
  • Narrowing it down: all endpoints or one, all clients or one, application time or a dependency such as the database.
  • Using traces, metrics and the diff of the deploy, and forming a hypothesis you can test.
  • Telling the right people what you see while you work.
When would you put a queue between two services, and what problems does that create?

What a strong answer covers:

  • Good reasons: absorbing bursts, letting one side be down without losing work, doing slow work outside a user’s request.
  • The costs: messages delivered more than once or out of order, harder debugging, the need for a dead-letter queue and monitoring of queue depth.
  • Making consumers idempotent as a direct consequence.
How do you keep personal information out of logs?

What a strong answer covers:

  • Logging identifiers rather than names or contents, and masking fields such as account or record numbers.
  • Structured logging with an allow list of fields, rather than dumping whole request bodies.
  • Tests or scanners that catch mistakes, and limits on who can read logs and for how long they are kept.
How would you store user passwords and the API keys your service uses?

What a strong answer covers:

  • Passwords hashed with a slow, salted algorithm designed for passwords (such as Argon2 or bcrypt), never encrypted or stored as plain text.
  • API keys kept in a secrets manager, injected at runtime, never committed to source control, and rotated.
  • What you would do if a key leaked.

How you work

Tell us about a bug you shipped or a mistake you made in code. What happened next?

What a strong answer covers:

  • A real example, told plainly, including your part in it.
  • How it was found and fixed, and what you changed afterwards so it would not happen again.
  • We are listening for ownership and learning, not for a story where nothing went wrong.
Describe a code review where you disagreed with the reviewer, or they with you.

What a strong answer covers:

  • What the disagreement was about and how you checked who was right, with evidence rather than seniority.
  • How it was resolved and how the working relationship came out of it.
What have you taught yourself recently, and how did you go about it?

What a strong answer covers:

  • Something specific, how you learned it and what you built or did with it.
  • Where you got stuck and how you got unstuck.
You need a decision from a colleague whose working day starts as yours ends. How do you get it?

What a strong answer covers:

  • Writing a message that can be answered without a conversation: the context, the options, your recommendation and the deadline.
  • Planning ahead so you are not blocked, and having something else useful to work on in the meantime.

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 25 minutes

A payment notification that must count once

A payments provider sends our service a notification each time a credit union member’s card payment settles. Each notification has an event_id, an account_id, an amount_cents and a settled_at time. The provider promises to deliver every notification at least once. In practice it sometimes delivers the same notification two or three times, and occasionally delivers notifications out of order. If our service does not answer with a success within 10 seconds, the provider sends it again.

Today the service adds amount_cents to the account balance each time a notification arrives. Design a version that never credits the same payment twice, never loses one, and stays correct if two copies arrive at the same moment on different servers.

Hint

The database can enforce uniqueness for you. Think about what has to happen in the same transaction, and about when you tell the provider “success”.

Worked solution

Keep a table of processed events with event_id as its primary key. For each notification, in one database transaction:

  1. Insert the event_id into the processed-events table.
  2. If the insert fails because the key already exists, this is a duplicate: do nothing else and answer success.
  3. Otherwise, write the payment to a ledger table and update the balance.
  4. Commit, then answer success.

Because the uniqueness check and the balance change commit together, two copies arriving at once on different servers cannot both succeed: one insert wins and the other fails on the key. Answering success only after the commit means a crash before the commit leads to a retry, not a lost payment.

Out-of-order delivery does not matter for a running total, because addition does not depend on order. It would matter if notifications could change the same payment (for example, settled and then reversed). Then you store each event against the payment and apply a state only if it is later than the one you have, using settled_at or a sequence number from the provider.

Two more points a strong answer includes. Keep the work inside the 10-second window small, and if it cannot be, record the event first and process it from a queue. And keep the ledger of individual payments rather than only a balance, so the balance can always be rebuilt and audited.

Puzzle · about 20 minutes

Three failed sign-ins in ten minutes

A table sign_ins has the columns user_id, at (a timestamp) and status ('ok' or 'failed'). The security team wants every user who had three or more failed sign-ins within any ten-minute window. Write the SQL, then say which users these rows return.

user_id | at    | status
u1      | 09:00 | failed
u1      | 09:04 | failed
u1      | 09:07 | ok
u1      | 09:09 | failed
u2      | 09:00 | failed
u2      | 09:06 | failed
u2      | 09:12 | failed
u3      | 10:00 | failed
u3      | 10:20 | failed
u3      | 10:25 | failed
u3      | 10:29 | failed
Hint

Keep only the failed rows first. Then, for each failed sign-in, look at the failed sign-in two before it for the same user.

Worked solution
WITH failed AS (
  SELECT user_id, at FROM sign_ins WHERE status = 'failed'
), windowed AS (
  SELECT user_id, at,
         LAG(at, 2) OVER (PARTITION BY user_id ORDER BY at) AS two_before
  FROM failed
)
SELECT DISTINCT user_id
FROM windowed
WHERE two_before IS NOT NULL
  AND at - two_before <= INTERVAL '10 minutes';

Filtering before the window function matters: if you computed LAG over all rows, the successful sign-in at 09:07 would sit between u1’s failures and hide them.

  • u1: failures at 09:00, 09:04 and 09:09. The third is 9 minutes after the first, so u1 is returned.
  • u2: failures at 09:00, 09:06 and 09:12, 12 minutes apart. Not returned.
  • u3: at 10:25 the failure two before is 10:00 (25 minutes); at 10:29 it is 10:20 (9 minutes). Returned.

The answer is u1 and u3. A strong answer also asks whether exactly ten minutes counts (here it does, because of <=) and notes that a successful sign-in in between does not reset the count, which may or may not be what the security team wants.

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

Why is the prior authorization screen so slow?

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

Background

A regional health system uses one of our applications to request prior authorization from insurers before procedures. Clinical staff say the screens are slow and sometimes fail, and that they retype requests when that happens. The system’s chief nursing officer has asked for a plan within a month. You have the API metrics for a typical weekday and a trace of a slow request.

Exhibit 1 · API endpoints on a typical weekday
EndpointCalls a dayMedian time95th percentileError rate
Submit a request18,000420 ms2,900 ms1.8%
Check a request’s status240,00085 ms310 ms0.2%
Check patient eligibility95,000650 ms4,800 ms0.9%
Upload a clinical attachment6,0001,100 ms9,500 ms3.5%
Exhibit 2 · Where the time goes in a slow eligibility check (95th percentile)
StepTime
Authenticate the user40 ms
Call the insurer’s eligibility service through a clearinghouse3,900 ms
Database reads and writes600 ms
Build the response260 ms
Total4,800 ms

Other facts: eligibility for a patient and insurer rarely changes during a day. Attachments are scanned documents of up to 25 MB, uploaded through the application server. Staff retry a failed submission by filling in the form again.

Your task

  1. Where do staff lose the most time, and where do most failures come from?
  2. What would you change first, and what improvement would you expect?
  3. What risks does your change carry for a health system, and how would you manage them?
One way to approach it

Total waiting time. Multiply calls by median time to see where staff spend their day waiting:

  • Eligibility: 95,000 × 0.65 s = 61,750 s, about 17.2 hours a day.
  • Status checks: 240,000 × 0.085 s = 20,400 s, about 5.7 hours.
  • Submissions: 18,000 × 0.42 s = 7,560 s, about 2.1 hours.
  • Attachments: 6,000 × 1.1 s = 6,600 s, about 1.8 hours.

The median understates the pain, because the slow tail is where people give up. But even on medians, eligibility dominates, and Exhibit 2 shows its slow cases are almost all the external call.

Failures per day. Eligibility 95,000 × 0.9% = 855; status 480; submissions 324; attachments 210. Attachments have the worst rate, but submissions hurt most per failure, because staff retype the whole form and may create a duplicate request.

What to change first. Cache eligibility results per patient and insurer for the rest of the day, refreshed in the background. If, say, 60% of checks were answered from the cache in about 50 ms, the saving at the median would be 57,000 × (0.65 − 0.05) s = 34,200 s, about 9.5 hours of waiting a day, and the slowest cases would disappear for those patients. In parallel: keep a submitted form when the call fails and retry it with an idempotency key, so a timeout never means retyping or a duplicate; and send attachments directly to storage with resumable uploads instead of through the application server.

Risks. A cached eligibility answer could be wrong if coverage changed that day, so show when it was last checked and re-check on submission. The cache holds protected health information, so it must be encrypted, kept in the same region and access-controlled, with a short expiry and audit logging. Roll out to one department first and measure the effect before going further.

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.