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
ExperiencesCoaching
New
Practice
Mock InterviewsTimed interview simulations with feedbackSuccess 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
Get started
Virtual Functions Output and Fixes
00:00
5 left

Virtual Functions Output and Fixes

HardPython

Problem

At Zoox, sensor fusion code manages a fleet of onboard sensors through a shared base class. Below is a simplified version of that hierarchy, along with the code that exercises it in main.

#include <iostream>
using namespace std;

class Sensor {
public:
    Sensor(string name) : name_(name) {}
    void describe() { cout << "Sensor: " << name_ << endl; }
    virtual double readRange() { return 0.0; }
    ~Sensor() { cout << "Destroying " << name_ << endl; }
protected:
    string name_;
};

class Lidar : public Sensor {
public:
    Lidar() : Sensor("Lidar") {}
    double readRange() override { return 120.5; }
    int* buffer = new int[1024];
    ~Lidar() { delete[] buffer; cout << "Destroying Lidar buffer" << endl; }
};

class Camera : public Sensor {
public:
    Camera() : Sensor("Camera") {}
    double readRange() override { return 80.0; }
};

class StereoCamera : public Camera, public Sensor {
public:
    StereoCamera() : Camera(), Sensor("StereoCamera") {}
};

void printRange(Sensor s) {
    cout << s.readRange() << endl;
}

int main() {
    Sensor* fleet[2];
    fleet[0] = new Lidar();
    fleet[1] = new Camera();

    for (int i = 0; i < 2; i++) {
        fleet[0]->describe();
        cout << fleet[i]->readRange() << endl;
    }

    Lidar lidar;
    printRange(lidar);

    for (int i = 0; i < 2; i++) {
        delete fleet[i];
    }

    return 0;
}

Write out, line by line, exactly what this program prints when it runs, and explain why. Then say what you would change about the class design and why each change matters.

Because deletion through Sensor* has undefined behavior, distinguish guaranteed output from behavior that cannot be specified portably.

Constraints

  • request is a string
  • Supported requests are trace, explanation, design, unique_ptr<Sensor> owning Lidar, and StereoCamera with duplicated Sensor inheritance
  • For any other request, return the complete analysis object
  • The C++ program's output after delete fleet[0] is not portably deterministic because the operation has undefined behavior

Function Signature

def analyze_sensor_program(request):
Interviewer

Your question is Virtual Functions Output and Fixes. Start with the requirements in the Question tab.

Run and submit as often as you like. When you're ready, talk me through your approach or go straight to the code.

You need to log in / sign up to run or submit.
Code
Sign up free to run your codeLog inLn 2
Run your code to see test output here.