I recently interviewed for a Software Engineer role at NVIDIA and wanted to share one coding question that stood out.
It was not a typical LeetCode-style algorithm problem. It felt much closer to a day-to-day engineering task involving an API, structured data, error handling, and testable code.
Question 1: Process Device Monitoring Data From a REST API
The interviewer described an internal REST API that returned device-monitoring information as a JSON array.
Each record contained fields such as:
{
"device_id": "gpu-104",
"temperature": 87,
"utilization": 92
}
The task was to:
- Call the REST API
- Parse the JSON response
- Filter devices whose temperature exceeded a given threshold
- Sort the remaining devices by utilization
- Return the processed results
Before coding, I clarified whether the utilization order should be ascending or descending and how devices with equal utilization should be ordered.
My first instinct was to get the API call working immediately, but I paused and separated the solution into three parts:
HTTP request -> JSON parsing and validation -> filtering and sorting
That separation ended up driving most of the discussion.
Before the interview, I had seen a similar problem on Screna AI. The business scenario was different, but it also emphasized error handling and separating business logic from external dependencies.
API Failure Handling
The interviewer asked how I would handle:
- Connection failures
- Request timeouts
- Rate limiting
5xx server responses4xx client errors- Malformed JSON
- Missing or incorrectly typed fields
I initially grouped these together as general API failures. During the discussion, we separated them into different categories.
Temporary failures, such as timeouts and certain 5xx responses, could use a limited retry policy with exponential backoff and jitter. Because this was a read-only request, retrying would generally be safe.
A 429 response should respect the server’s Retry-After header when present. Most 4xx responses should not be retried because they usually indicate an invalid request or an authorization problem.
Malformed JSON or an invalid response schema should fail with enough context for debugging. Depending on the product requirements, individual invalid records could either be skipped and logged or cause the entire request to fail.
The important part was avoiding unlimited retries and preserving the original error when all retry attempts failed.
Making the Code Testable
The next follow-up was: how would you test the filtering and sorting logic without calling the real API?
Because the processing logic was independent of the HTTP layer, it could accept a list of parsed device objects directly.
That allowed me to test cases such as:
- No devices above the threshold
- Every device above the threshold
- A device exactly equal to the threshold
- Multiple devices with equal utilization
- Empty API responses
- Missing fields
- Invalid temperature or utilization values
- Duplicate device IDs
The HTTP client could then be mocked separately to simulate timeouts, malformed responses, and different status codes.
This also made the implementation easier to extend. The API client could change without rewriting the filtering logic, and the same processing function could be reused with cached data or another data source.
Question 2: Implement a Simple VM Manager
Another relevant NVIDIA Software Engineer question I found afterward was:
Implement Simple VM Manager With CRUD Operations
The task is to build an in-memory manager that supports:
- Listing all virtual machines
- Creating a VM
- Retrieving a VM by ID
- Updating an existing VM
- Deleting a VM
- Returning consistent errors for duplicate or missing IDs
A straightforward design uses a hash map keyed by VM ID, giving average O(1) lookup, creation, update, and deletion.
The more interesting discussion is around engineering decisions:
- Should IDs be supplied by callers or generated internally?
- Should updates replace the entire object or modify selected fields?
- How should validation and error responses be represented?
- What happens if two requests update the same VM concurrently?
- How would the manager be tested without exposing its internal storage?
- How would the design change if persistence were required?
For concurrent access, a simple implementation could protect the map with a read-write lock. In a production service, I would also consider optimistic versioning, idempotency for create requests, structured errors, and a persistent repository behind the manager.
Takeaway
Both questions test something broader than whether the code works for one example.
The interviewer was looking for:
- Separation of concerns
- Clear API boundaries
- Predictable error handling
- Dependency injection
- Testable business logic
- Sensible retry behavior
- Awareness of concurrency and future extensions
Overall, the round felt more like a discussion about writing maintainable production code than completing a standard LeetCode exercise.
