Katkat
Back

Groom a Ticket to Replace a Store's 12+ Age Rating with a Pending Rating

PlaystationSoftware Engineer · Technical Screen
EasySoftware EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

A ten-minute ticket-grooming exercise in which a software engineer and a product manager groom a ticket that removes a game store's 12+ age rating and adds a Pending rating. It tests asking scope-changing questions, splitting the work into parallel tasks with clear dependencies, and giving a reasoned ETA.

In a 10-minute exercise, you play a software engineer grooming a ticket together with a product manager. The requirement on the ticket: the PlayStation Store is removing its 12+ age rating and adding a Pending age rating. Lead the grooming session: ask the questions you need answered, divide the work, and finish by giving an ETA.

Constraints and Clarifications

  • Ten minutes covers all three parts, so prioritize the questions that change the scope or the estimate.
  • Only the requirement above was given. The store's architecture, the team's size and any deadline are unknown: ask the PM, or state your assumptions.

Clarifying Questions

  • Is the interviewer playing the PM, so that your questions get answers during the exercise?
  • Does the ETA mean code complete, released behind a feature flag, or available to every user?
  • Which engineers and teams are available, and does this team own the store's client apps as well as its backend?

Part 1 — Questions for the PM

List the questions you would ask the PM before estimating, and explain why each one matters.

What This Part Should Cover

  • What happens to existing data rated 12+
  • The behavior of Pending wherever ratings are used, not only how it is displayed
  • Which surfaces, clients and regions are in scope
  • Deadline, rollout and compatibility constraints that shape the plan

Part 2 — Divide the work

Break the ticket into tasks that can be assigned and worked on in parallel, and identify the dependencies between them.

What This Part Should Cover

  • A breakdown into backend, client, data and release tasks with owners
  • The dependencies and the order of work
  • How tracks run in parallel, and how older clients keep working

Part 3 — Give an ETA

Give the PM an ETA and explain how you arrived at it.

What This Part Should Cover

  • An estimate built from the task breakdown, not a guess
  • A range with the assumptions it depends on
  • The risks that would move it, and when it will be firmed up

Hints

Hint 1

Follow the existing 12+ products: Think about every product and every user setting that refers to the 12+ rating today, and what must happen to each of them once that rating no longer exists.

Hint 2

An unknown rating still has to behave: List the systems besides the product page that read an age rating, and ask how each should treat a rating that is not known yet.

Hint 3

One change blocks everyone: Find the single decision every other task depends on, and how the other tracks can start before it ships.

Hint 4

Follow the longest chain: Size each task, find the longest chain of dependent tasks, and say which open answers would move the date.

Follow-up questions

  • The PM says the change must be live in every region by a fixed date that is earlier than your ETA. What do you cut or phase?
  • Older client versions cannot be updated quickly and would receive a rating value they do not recognize. How do you keep them working?
  • A product stays Pending for months. What should the store and parental controls do, and who owns resolving it?
  • Halfway through the work, you learn that one region must keep the 12+ rating. How does your design absorb that?