Background

IT administrators are responsible for knowing the health of every device across the organization at any given moment. A laptop battery dying in a boardroom, a MacBook overheating, an Android tablet that hasn't synced in three weeks, a Linux workstation with a disk almost full — these are real problems that cost time and money when discovered too late.

An agent is already running on every managed device. It continuously collects metrics the operating system exposes and sends them to your backend. On Windows that might be CPU, RAM, battery, disk health, and running applications. On Android it might be battery temperature, mobile data usage, and installed apps. On Linux it might be system load, open ports, and service status.

The agent is already doing the collection. Your job is to build the system that receives and stores that data, and a dashboard that makes it visible, useful, and configurable.

What You Need to Build

1. A backend that receives metrics continuously from every device
2. Efficient storage of that data
3. A dashboard builder where admins add widgets
4. Each widget configured by the admin — metric, devices, time range, display type
5. Live updates as new data arrives
6. Admin can save and return to their layout

What We Want to See

Agent to Backend Communication

• What does a single metric payload look like when it arrives?
• Windows and Linux both send CPU usage but measure it differently. How does your backend normalize this?
• Agents send data every 30 seconds from hundreds of devices simultaneously — how does your backend handle this?
• Some agents send metrics in batches, some one at a time. How does your ingestion endpoint handle both?
• Submission question: What does a single metric data point look like when the agent sends it and how does it look when stored in your database? Show both structures.

Cross-Platform Data Model

• iOS agents can't send a running process list the way desktop agents can. Android sends mobile signal strength that laptops never send. How does your schema handle platform-specific metrics?
• How do you design your data model so that when a new platform starts sending a new metric type, your system handles it without a schema change?
• How do you query efficiently across thousands of data points per device?
• How long do you keep raw metric data before aggregating or deleting?
• Submission question: How does your schema handle a metric that the Android agent sends but the iOS agent never sends?

Data Flow to Dashboard

• How does data get from the backend to the widget in real time?
• How does the dashboard feel live without running an expensive query every 30 seconds?
• What's different between handling a metric that updates every 30 seconds vs one that only changes when something significant happens?
• Submission question: Walk through exactly what happens from the moment the agent on a MacBook sends a CPU metric to the moment a number updates on the admin's screen.

Dashboard Builder

• Walk through the exact steps an admin takes to add a new widget.
• When the admin picks a metric, how does your system know which devices and platforms support it?
• How do you save and load a dashboard configuration?
• Submission question: What is the hardest design problem in the dashboard builder when dealing with agents on a mixed device fleet and how did you solve it?

Performance

• An admin has 10 widgets open showing data from 200 devices across 4 platforms. Agents send updates every 30 seconds. How does your backend handle this?
• How do you avoid running the same expensive database query multiple times for widgets with overlapping data?
• Submission question: What breaks first when you scale from 10 devices to 10,000 devices across 5 platforms?

Background

Employees log into devices using whatever the OS provides by default — local accounts on Windows, Apple ID or local accounts on macOS, Google accounts on Android, Apple ID on iOS, LDAP on Linux. IT has no central control over who can log into what device.

When an employee leaves on a Friday afternoon, IT has to chase through multiple different systems to revoke access. Something always gets missed. On some platforms changes take hours to propagate. On devices that are offline it may take days.

The goal is to replace all of these fragmented login systems with one. When an employee opens any managed device, they see a single unified login experience. IT admin blocks a user once. That user cannot log into any of their managed devices within seconds.

An agent is already running on every managed device — it is the bridge between your backend and the device.

What You Need to Build

1. A custom login experience on each device type that replaces or sits in front of the native OS login
2. A backend authentication system that validates credentials and manages account state
3. An IT admin dashboard to manage users — block accounts, reset passwords, force logouts, restrict device access, and view login history

What We Want to See

The Agent's Role in Authentication

• The agent is already on the device before anyone logs in. What role does it play?
• When an IT admin blocks an account, how does the agent receive and enforce that change?
• If the agent receives a block command while a user is actively logged in, what does it do?
• How does the agent keep its local knowledge of account state in sync without requiring a login to trigger a sync?

Cross-Platform Login Integration

• Windows has Credential Providers. macOS has PAM modules and Directory Services. Linux has PAM. Android and iOS have MDM flows. How do you think about integrating with each while keeping your backend and admin experience unified?
• What is the single API your backend exposes that every platform uses regardless of OS?
• Some platforms let you completely replace the login screen. Others like iOS only let you enforce authentication policies through MDM profiles. How does your system account for platforms where you can't fully control the UI?
• Mobile devices may use biometrics, PIN, or pattern. How does your authentication backend handle this?
• Submission question: What is the single API your backend exposes for device login and what does the request and response look like?

Authentication Backend

• What does your user record look like?
• Walk through every check your backend performs between receiving a login request and returning a result.
• Account blocked, password expired, must change password, device not authorized, too many failed attempts — these all need different responses. How do you handle each?
• How do you make this endpoint secure enough to be called by an agent on a device that is not yet authenticated?

The Offline Problem

• Devices go offline — in basements, on planes, in areas with no signal. What happens when the agent can't reach your backend during a login attempt?
• The agent can cache state locally. How do you use this to allow offline login while still respecting a block applied while the device had no internet?
• How long should the agent's cached credentials be valid?
• How do you store credentials and account state securely on the device across different operating systems?
• Submission question: What is your offline login strategy and how does the agent handle a block applied while the device had no internet?

IT Admin Controls

• An admin clicks Block Account. Walk through exactly what happens — on at least two different device platforms. How fast does each take effect and why might they differ?
• An admin clicks Force Logout on an active session. What does the agent actually do?
• An admin restricts a user to only their assigned devices. What does the agent do when that user tries to log into a different device?
• Submission question: How does blocking an account in the dashboard result in a rejected login — describe every step on at least two different device platforms.

Security Thinking

• What are the most dangerous security vulnerabilities in a centralized authentication system like this and how do you mitigate them?
• What happens if someone removes or disables the agent from their device?
• If your authentication backend goes down, what happens to every employee trying to log in?
• Submission question: What is the hardest part of making this work across multiple operating systems and how would you approach it?
• Submission question: What did you not build and why — what would you prioritize building next?

Background

In enterprises, devices are organized into groups — by department, location, role, or however the admin chooses. Each group can have one or more config templates assigned to it. A config template is a named set of settings — things like maximum upload size, session timeout, theme, feature flags. A single device's actual configuration is never just one template — it's the combined result of every template assigned to its group.

This sounds simple until two things happen at once: an admin updates a template that affects 500 devices, and those same 500 devices are all asking "what's my config right now?" within the same few seconds. Recomputing the merge from scratch for every single request works, but it doesn't scale, and it gets you in trouble the moment two requests for the same device disagree with each other for no good reason. The real problem isn't computing the merge — it's knowing when you can trust a cached answer and when you can't.

You do not need to build any device-side agent for this — assume the device is just calling your API directly to ask "what should my config be?"

What You Need to Build

1. A device belongs to exactly one group
2. A group has one or more config templates assigned to it, each assignment carrying an assignedAt timestamp
3. A device's effective config is every assigned template's key/value settings merged together — when two templates set the same key, the more recently assigned template wins
4. A device can ask the backend "what's my config?" and gets back the merged result plus some identifier of that result's state
5. A device can ask again later with that identifier and get told "nothing changed" cheaply, without the backend redoing the full merge
6. An admin can update a template's values, and every device relying on that template sees the change on its very next request — correctly, not eventually

What We Want to See

State Identity

• What does it mean for two devices, or the same device at two different times, to have "the same" effective config? How do you represent that as something comparable?
• If your backend restarts, or you run two instances behind a load balancer, does your identifier still mean the same thing on both?
• Is your identifier actually tied to the content of the config, or just to "something happened"?
• Submission question: What is your "version" identifier actually built from, and why does it change exactly when the effective config changes — no more, no less?

Avoiding Repeated Work

• A device that asks for its config every 30 seconds with nothing changed should not cost the same work on request #1 and request #100. What's actually different between those two requests?
• Where does the saved work live — and what happens to it when it's no longer trustworthy?
• If you use a cache, what's the key? What invalidates it?
• Submission question: What's actually different, mechanically, between a device's 1st request and its 100th unchanged request? Be specific about where the saved work is and what could make it wrong.

Correctness Under Change

• An admin updates a template at the exact moment a device is mid-request. What does that device get back?
• If a template is updated, which devices need to see a different result on their next call? How do you know your invalidation reaches exactly that set?
• What happens if a device asks for its config, the answer is cached, and then a template that device doesn't even use gets updated? Does anything get unnecessarily recomputed?
• Submission question: Walk through what happens step by step when an admin updates a template: which stored state changes, and which devices are now able to detect that something changed?

Conditional Fetching

• A device that already has the current config shouldn't need the full payload again. What does it send you to prove that, and what do you send back?
• Is checking "are we still in sync" actually cheaper than just doing the merge again?
• Submission question: What is the most likely way your solution could serve stale data without anyone noticing, and how would you catch it?
• Submission question: What did you not build that a production version would need?

What breaks in your solution and when? — A candidate who can clearly describe the weaknesses in their own work is far more valuable than one who cannot see them.

Instructions

Phase 1 requires a written document only — no code. Your document should answer at least one of the questions from the problem you chose, and may include your general thinking, assumptions, and tradeoffs. Accepted formats: .pdf, .docx, .txt, or .md.

What to include in your document

• Which problem you chose (1, 2, 3, or 4)
• Which question(s) you are answering
• Your written answers — clear, structured, and honest about tradeoffs
• Any assumptions you are making
• What you think the hardest part of the problem is