Skip to content
Sign inCreate account

Internships

Engineering & Product Internship

Ten to twelve weeks in a product squad, shipping features to one of our SaaS products.

Open roles on this program

3 open roles. Every listing shows its pay range.

There are no throwaway intern projects. You join a product squad, own real features and ship them to products used by banks, hospitals and public agencies, under the same security and quality standards as everyone else on the team.

Software engineering

  • Own a feature: for example, an API endpoint that lets a patient cancel an appointment. You design it, build it, test it and document it.

  • Modernize code: break a large legacy function into smaller services without breaking anything that depends on it.

  • Design APIs: build REST or GraphQL APIs that other teams and clients use, with versioning and clear documentation.

Product management

  • User research: join calls with nurses, bankers and government clerks, and turn what you hear into requirements and user stories.

  • Prioritization: help decide what the team builds next quarter, weighing engineering effort against value.

  • Measurement: use analytics tools such as Amplitude or Pendo to see how people use a new feature.

Data engineering and AI

You work with our Data Trust & Governance Labs:

  • Pipelines: build data pipelines with Python and dbt.

  • Models in production: put a data scientist's model behind an API so the product can use it.

  • Data quality: write tests that catch bad data before it reaches a dashboard.

How you'll learn

  • Pairing: scheduled sessions with senior and staff engineers, watching how they debug and design.

  • Code review: senior engineers review your code before it merges, and code that fails the security scan is fixed before it ships.

  • Demo days: at the end of each sprint you demo your work to product directors.

  • Real tools: AWS, Azure or Google Cloud; GitLab or GitHub Actions; Snyk or SonarQube; Snowflake, PostgreSQL or Kafka.

Who should apply

Students working toward a degree in computer science, engineering or a related field, comfortable in at least one programming language and available for the summer. Each listing shows the location and pay.

A day on the track

A Tuesday in week six

By week six you own a feature, you know your squad's rhythm, and your work is a few days from a sprint demo.

This is an illustrative day put together from how our product squads work. It is not one person's account, and your squad's times and tools will differ.

  1. 09:00

    Read the overnight handover

    Before you open your editor you read the handover note from the follow-the-sun teams. Overnight, Manila flagged a slow query on the appointments service your squad owns. It isn't yours to fix, but you now know why the staging dashboard looks odd.

  2. 09:30

    Stand-up

    Fifteen minutes with your squad, half in New York and half in Yerevan. You say what you finished yesterday (the database migration for appointment cancellations), what you're doing today (the endpoint itself) and what's blocking you (you need a decision on how far ahead a patient may cancel).

  3. 10:00

    Ten minutes with the product manager

    The cancellation window is a clinic policy, not a technical one, so it becomes a setting each health system controls rather than a number in the code. You update the user story in Jira so everyone sees the decision.

  4. 10:30

    Build and test

    You write the endpoint and its tests. The tricky part is retries: a phone on a weak signal may send the same cancel twice, and the patient must only be refunded once. You add an idempotency key, then a test that proves the second request changes nothing.

  5. 12:30

    Lunch with your intern cohort

    Interns from every track eat together on Tuesdays. Today someone from the Global Resilience Operations track explains what happens when an alert fires at 3 a.m., which turns out to be useful for the logging you add this afternoon.

  6. 13:30

    Pairing with a staff engineer

    Your scheduled pairing session. You walk through your design, and the staff engineer asks what the audit log records when a cancellation happens. Under HIPAA the record of who did what to a patient's data matters as much as the feature, so you add it.

  7. 15:00

    Open a merge request

    The pipeline runs your tests and the security scan. The scan flags a dependency with a known vulnerability, so you upgrade it before asking for review. Two senior engineers review your code; one asks for clearer error messages for the mobile app team.

  8. 16:30

    Catch up with your sponsor

    A fortnightly half hour with your sponsor, a director outside your reporting line. You mention you'd like to see how a feature is rolled out to a live hospital, and they arrange for you to sit in on next week's release call.

  9. 17:15

    Write tomorrow down

    You note where you stopped and what the reviewer asked for, so tomorrow starts quickly. Your squad in Yerevan has already signed off; the release notes are theirs to read first thing.

What we look for

Three things we assess

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

Problem solving in code

You can break a problem down, write working code in a language you know well, and test it. We care about how you reason through edge cases more than whether you remember a library call.

Care for the people using it

Our software is used by nurses, bank staff and public servants under pressure. We look for people who ask who will use a feature, what happens when it fails, and what data it touches.

Working in a team

You explain your thinking, take feedback on your code without getting defensive, and ask for help when you are stuck rather than after a week of silence.

Sample interview questions

What we might ask

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

Online exercise

Given a list of appointment bookings with start and end times, return every pair that overlaps.

What a strong answer covers:

  • A clear definition of overlap first, including whether an appointment ending at 10:00 overlaps one starting at 10:00.
  • A working solution, then a faster one: sorting by start time lets you compare each booking only with the ones still open, instead of every pair.
  • The cost of each approach in plain terms: comparing every pair grows with the square of the number of bookings.
  • Tests for the awkward cases: an empty list, one booking, identical times, and a booking that contains another.
Write a function that checks whether a string of brackets, such as "{[()]}", is balanced.

What a strong answer covers:

  • Using a stack: push each opening bracket, and pop and compare on each closing one.
  • Remembering the end state: a string such as "((" leaves items on the stack and is not balanced.
  • Handling characters that aren't brackets, and saying what you assumed.
This function is slow on large inputs. Find out why and fix it.

What a strong answer covers:

  • Reading the code before changing it, and saying what you think it does.
  • Spotting the hidden cost, often a lookup in a list inside a loop, and replacing it with a set or dictionary.
  • Showing the fix is still correct with a test, not only that it is faster.

Team interview

Design an API that lets a patient cancel an appointment from a mobile app.

What a strong answer covers:

  • The request and response: what the app sends, what it gets back, and the status codes for success, "too late to cancel" and "not your appointment".
  • Retries: the same request may arrive twice, so the cancellation must only happen once. An idempotency key is a good answer.
  • Who is allowed to cancel, and how the server checks it rather than trusting the app.
  • What gets logged for the audit trail, and what must not be logged, such as clinical details.
  • Versioning, so the app keeps working when the API changes.
Tell us about a bug you found hard to fix. How did you track it down?

What a strong answer covers:

  • A specific bug, not a general description of debugging.
  • How you narrowed it down: reproducing it, adding logging, testing one change at a time.
  • What you would do differently, and whether you added a test so it can't come back.
A product manager asks for a feature by Friday. You think it will take two weeks. What do you do?

What a strong answer covers:

  • Saying so early and explaining why, rather than working late and missing the date anyway.
  • Offering options: a smaller first version by Friday, or the full feature later.
  • Asking what Friday is for. The deadline often has a reason that changes the answer.
How would you store which users may see which patient records?

What a strong answer covers:

  • A sensible data model, for example users, roles, and an assignment of users to clinics or care teams.
  • Checking access on the server for every request, and denying by default.
  • An audit record of who viewed what, which regulated clients expect.

How you work

Tell us about a time someone criticized your work. What did you do with the feedback?

What a strong answer covers:

  • A real example with a real piece of work.
  • What you changed, and what you pushed back on and why. Disagreeing well is fine.
What would you want to learn in ten weeks with us?

What a strong answer covers:

  • Something specific, such as how code gets to production safely or how a team handles a security finding.
  • Why it matters to you. There is no right answer; we want to know what motivates you.
Why does it matter that our clients are regulated?

What a strong answer covers:

  • That mistakes have consequences for real people: a missed appointment, a frozen account, a delayed benefit.
  • That rules such as HIPAA shape design decisions, not only paperwork. You don't need to know the rules in detail.

Practice

Two puzzles to try

These are the kind of problems our engineers talk through at the whiteboard. Try them before opening the hint.

Puzzle · about 20 minutes

The double refund

Patients pay a $25 deposit when they book, and get it back when they cancel. A patient on a train tapped Cancel once, yet was refunded twice. Here is what the server logged:

08:14:02.110  POST /appointments/7781/cancel   request A received
08:14:02.115  appointment 7781 status = booked
08:14:07.120  request A: refund of $25 sent to payment provider
08:14:07.300  client timeout after 5 s, app retries
08:14:07.305  POST /appointments/7781/cancel   request B received
08:14:07.309  appointment 7781 status = booked
08:14:08.010  request A: status set to cancelled, 200 OK (client already gone)
08:14:12.400  request B: refund of $25 sent to payment provider
08:14:12.900  request B: status set to cancelled, 200 OK

Explain exactly why the patient was refunded twice, and how you would change the endpoint so it can't happen again, even if the app retries.

Hint

Look at when each request reads the appointment's status and when it writes it. Then think about what the app could send that would let the server recognise a retry.

Worked solution

Why it happened. The endpoint checks the status, calls the payment provider, and only then marks the appointment as cancelled. The refund call took five seconds, so the app timed out and retried. Request B read the status at 08:14:07.309, while it still said "booked", because request A didn't write "cancelled" until 08:14:08.010. Both requests passed the check, so both refunded. This is a check-then-act race made worse by doing slow work before saving the state.

A fix in layers:

  • Idempotency key. The app generates a unique key once per tap and sends it with every retry. The server stores the key with the result of the first request. A request with a key it has seen returns the stored result instead of doing the work again.
  • Change state atomically. Move the appointment from "booked" to "cancelling" in a single conditional update (for example, update where status = 'booked'). Only the request that changes the row goes on; the other sees nothing was updated and stops.
  • Make the refund itself idempotent. Payment providers accept their own idempotency key. Use the appointment and the cancellation as that key, so even a bug in our code can't refund twice.
  • Don't hold the request open. Record the refund as pending and process it in the background, so the client gets a quick answer and has no reason to retry.

A good answer also adds a test that sends two identical requests at the same time and checks there is exactly one refund.

Puzzle · about 15 minutes

The rate limiter

Our public API protects itself with a token bucket for each client. The bucket holds at most 10 tokens and gains 2 tokens per second, added continuously. Each request uses 1 token; a request that arrives when the bucket has less than 1 token is rejected. The bucket starts full.

A client sends 12 requests at the same instant (t = 0 s), then one request every 0.25 s from t = 0.25 s to t = 3.0 s inclusive.

  1. How many requests are rejected in total?
  2. What is the smallest capacity and refill rate that would accept every request in this pattern?
Hint

Work through the first second by hand and look for a repeating pattern. How many tokens arrive in 0.25 s?

Worked solution

The burst. At t = 0 the bucket has 10 tokens, so 10 of the 12 requests pass and 2 are rejected. The bucket is now empty.

The steady stream. There are 12 more requests (at 0.25, 0.50 … 3.00 s). Every 0.25 s the bucket gains 0.5 tokens. At 0.25 s it holds 0.5, so the request is rejected. At 0.50 s it holds 1.0, so the request passes and the bucket is empty again. The pattern repeats: the requests at 0.25, 0.75 … 2.75 s (6 of them) are rejected, and those at 0.50, 1.00 … 3.00 s (6) pass.

Answer 1: 2 + 6 = 8 rejected; 16 of the 24 requests pass.

Answer 2: the steady stream is 4 requests per second, so the refill rate must be at least 4 tokens per second. The burst is 12 requests at once, so the capacity must be at least 12. With capacity 12 and 4 tokens per second, the burst empties the bucket and each later request finds exactly the 1 token that arrived since the last one.

A strong candidate also asks whether we should accept that pattern at all: a burst of 12 might be a client bug, and the limiter is there to protect other clients.

Practice case

Work through a product decision

In the team interview you may be asked to talk through a decision like this one. There's no single right answer; we want to see how you use the numbers and what you ask about.

Practice case · 45 minutes

Fewer empty appointment slots

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

Background

A regional health system uses our patient app for scheduling. Its clinics hold 40,000 appointments a month. 12% of patients don't turn up and don't cancel, and each empty slot costs the health system an average of $150 in lost revenue. Separately, patients already cancel 3,000 appointments a month in advance by phone, and today staff manage to rebook only 30% of those slots.

Your squad has 6 engineer-weeks of capacity next quarter and three candidate features.

Exhibit 1 · Candidate features
FeatureEffortExpected effect (from the client's pilot data)
A. Two-way text reminders4 engineer-weeks20% of patients who would not have turned up attend instead
B. Cancel in the app2 engineer-weeks10% of patients who would not have turned up cancel in advance instead
C. Automatic waitlist3 engineer-weeksRaises the share of cancelled slots that are rebooked from 30% to 70%

Your task

  1. Estimate the monthly value of each feature on its own.
  2. Which combination would you build within 6 engineer-weeks, and why?
  3. What would you want to check before committing, and how would you measure the result?
One way to approach it

The baseline. 12% of 40,000 is 4,800 no-shows a month, or $720,000 of lost revenue.

Each feature on its own:

  • A: 20% of 4,800 is 960 more patients attending, worth 960 × $150 = $144,000 a month.
  • B: 10% of 4,800 is 480 patients cancelling instead. Only rebooked slots are worth anything: at today's 30%, that's 144 slots, or $21,600 a month.
  • C: on the existing 3,000 cancellations, rebooking 70% instead of 30% fills 1,200 more slots, worth $180,000 a month.

Combinations that fit 6 weeks:

  • B and C (5 weeks): C is worth $180,000 on today's cancellations. B adds 480 cancellations, and with C, 70% of them are rebooked: 336 slots, or $50,400. Together about $230,400 a month, with a week spare.
  • A and B (6 weeks): A is worth $144,000 and leaves 3,840 no-shows. B turns 10% of those (384) into cancellations, of which 30% (about 115) are rebooked, worth about $17,300. Together about $161,300 a month.
  • A and C needs 7 weeks, so it doesn't fit.

A recommendation: build B and C. They are worth more together than apart, because C makes B's extra cancellations valuable. Use the spare week for monitoring and a careful rollout, and plan A for the following quarter.

What to check first: how reliable the pilot figures are and how large the pilot was; whether clinics will let software rebook their slots; how the waitlist treats patients fairly, for example by urgency rather than by who taps fastest; and what a text message may say, since a reminder should not reveal a diagnosis or a specialty.

How to measure it: roll out clinic by clinic, compare no-show and rebooking rates with clinics that don't have the feature yet, and agree the measures with the health system before launch.

Next steps

Prepare, then apply

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