Dataford
Interview QuestionsInterview GuidesExperiencesCoaching
New
Pricing
Get started
Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
Experiences
Practice
Mock InterviewsTimed interview simulations with feedbackCoaching1:1 coaching with people at your target companiesSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Build my plan

Lower-Latency Real-Time Optimization

HardCoding00:00
Practice interviewer
In session
5 left
00:00

Your question is Lower-Latency Real-Time Optimization. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

You're a robotics engineer at Pickle Robot working on the gripper controller for a trailer-unloading arm. The function below runs inside the hard real-time control loop at 1kHz, computing a grip force adjustment from the current joint state. Under load testing it mostly hits its 1ms budget, but every so often a single control cycle takes several milliseconds, long enough to miss the deadline and cause a visible jerk in the gripper.

#include <vector>
#include <mutex>
#include <iostream>

struct JointState {
    double positions[7];
    double velocities[7];
    double torques[7];
};

struct GripperConfig {
    double gain;
};

std::mutex g_configMutex;
GripperConfig g_config;

std::vector<double> computeGripAdjustment(JointState state, double targetForce) {
    std::vector<double> adjustment;

    std::lock_guard<std::mutex> lock(g_configMutex);

    for (int i = 0; i < 7; i++) {
        double error = targetForce - state.torques[i];
        adjustment.push_back(error * g_config.gain);
    }

    std::cout << "grip error computed" << std::endl;

    return adjustment;
}

Explain exactly why this occasionally misses its 1ms real-time budget, and how you'd rework it to keep the worst case bounded, not just the average case.