Implement a thread-safe periodic job scheduler
Company: Nuro
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: hard
Interview Round: Onsite
# Implement a thread-safe periodic job scheduler
## Problem: Periodic Job Scheduler (Concurrency)
Implement a small in-process **job scheduler** that can run **periodic tasks** (functions/callbacks) at a target frequency.
### Requirements
1. You must support scheduling tasks specified as a function/callback.
2. Each task is **periodic**, e.g. `50 Hz` (50 times per second). You must convert frequency to a period (time interval).
3. Expose two thread-safe APIs:
- `schedule(taskFn, frequencyHz) -> jobId`
- `cancel(jobId) -> void`
4. The implementation must be **runnable** (not just a dry run):
- There is at least **one dedicated worker thread** responsible for executing the tasks.
- Another thread may call `schedule()` and `cancel()` concurrently while the worker is running.
### Behavioral expectations / assumptions (state clearly in your implementation)
- Use a **monotonic clock** for timing.
- Multiple jobs may be scheduled at once.
- If a job is cancelled, it should not run again after cancellation takes effect.
- Define what happens if a task execution takes longer than its period (e.g., skip missed ticks vs. run immediately to “catch up”).
### What to provide
- The scheduler data structures and synchronization strategy.
- The worker thread loop logic (sleep/wake strategy).
- How cancellation is handled safely under concurrency.
### Constraints & Assumptions
- Preserve the scope, facts, inputs, and requested outputs from the prompt above.
- If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
- Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
### Clarifying Questions to Ask
- Clarify language/runtime assumptions and the level of depth expected.
- Use examples to connect definitions to practical engineering decisions.
- Call out pitfalls, trade-offs, and common misconceptions.
### What a Strong Answer Covers
- Accurate definitions and comparisons with concrete examples.
- Complexity, lifecycle, safety, or operational implications where relevant.
- Trade-offs that explain when one approach is preferable to another.
- Common failure modes and how to avoid them.
### Follow-up Questions
- How would you debug a production issue related to this topic?
- What trade-off would change in a high-throughput service?
- Which misconception do candidates often have here?
Quick Answer: Implement a thread-safe periodic job scheduler evaluates engineering fundamentals, trade-offs, examples, pitfalls, and operational implications in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.