Etched Interview Questions: Performance Reasoning and a Trace Exercise

TL;DR

• Prepare for Etched interview questions by connecting your role to the interaction between chips, systems and inference software, rather than memorising unsourced question lists.
• Use the current Etched opening to choose your depth. Performance analysis, firmware and silicon verification require different project evidence.
• The original trace exercise below shows why adding overlapping operation durations can overstate device busy time and lead to an incorrect performance conclusion.
• Explain what you measured, the competing hypotheses, and which controlled experiment would distinguish them. The examples here are practice, not actual Etched assessments.

What is useful public context for an Etched interview?

Etched’s company site describes inference systems designed across chips, racks, software and manufacturing. Its hiring page emphasizes ownership and things candidates have built. This supports preparing a detailed engineering project discussion; it does not establish a fixed interview sequence.

Job titles can change while a recruiting URL remains the same. For example, a previously indexed performance-profiling opening displayed the title “MTS, Inference Performance Visibility” at the official posting URL when checked on September 14, 2026. Confirm the current responsibilities with recruiting rather than assuming an older search result describes the role exactly.

This guide focuses on software and performance reasoning. An ASIC, physical-design or electrical-engineering candidate should use the relevant opening to add domain-specific preparation. The public pages reviewed did not verify one universal set of Etched interview rounds or questions.

Question 1: why does this profile report more busy time than elapsed time?

Suppose a teaching trace contains these intervals on one device, in milliseconds:

Summing durations gives 16 ms. The observation window lasts 20 ms. But A and B overlap, so the time with at least one tracked operation active is only 12 ms: the interval from 0 to 9, plus the interval from 12 to 15.

For this definition, the busy fraction is 12/20, or 60%. The duration sum divided by the window would be 80%, which answers a different question. Neither number establishes compute saturation, memory pressure or power efficiency.

Ask what the trace events mean before interpreting them. An operation interval might include waiting. Concurrent operations might share a resource, use independent engines or represent nested instrumentation. A timeline alone does not tell you which interpretation is correct.

These numbers are invented for the exercise. They are not Etched hardware measurements or performance claims.

Question 2: can you calculate the union inside a window?

Write a function that clips half-open intervals to a half-open observation window and returns the length of their union. An interval [start, end) includes its start and excludes its end. Equal endpoints represent zero duration. Invalid types and reversed intervals should fail explicitly.

def busy_time(intervals, window_start, window_end):
    def integer(value):
        return type(value) is int

    if not integer(window_start) or not integer(window_end):
        raise ValueError("integer window endpoints required")
    if window_end <= window_start:
        raise ValueError("observation window must have positive length")
    clipped = []
    for start, end in intervals:
        if not integer(start) or not integer(end) or end < start:
            raise ValueError("invalid interval")
        left = max(start, window_start)
        right = min(end, window_end)
        if left < right:
            clipped.append((left, right))
    clipped.sort()
    total = 0
    current = None
    for left, right in clipped:
        if current is None:
            current = (left, right)
        elif left <= current[1]:
            current = (current[0], max(current[1], right))
        else:
            total += current[1] - current[0]
            current = (left, right)
    if current is not None:
        total += current[1] - current[0]
    return total

assert busy_time([(0, 7), (3, 9), (12, 15)], 0, 20) == 12
assert busy_time([(-5, 4), (4, 30)], 0, 20) == 20
assert busy_time([(3, 3), (25, 30)], 0, 20) == 0
assert busy_time([], 0, 20) == 0

The sorting step costs O(n log n), and the clipped list needs O(n) space. Adjacent intervals can be merged because doing so does not change their total length. Duplicate intervals also leave the union unchanged.

The code allows negative interval endpoints because traces may be expressed relative to the beginning of an observation. Clipping is what determines how much contributes to the selected window. That is an intentional contract choice, not an input-validation oversight.

Question 3: how do you know the interval calculation is correct?

Start with empty input, an interval entirely outside the window, an interval spanning both boundaries, nested intervals, duplicates and intervals supplied in reverse order. Test an invalid interval outside the window as well: clipping should not silently excuse malformed source data. To practise calling out edge cases like these in other problems, work through coding interview questions grouped by pattern.

A useful independent oracle for small integer timestamps is to enumerate each unit of time in the window and ask whether any input interval covers it. Compare that count to the optimized result. This is slower for large windows, but its different structure can reveal mistakes in interval merging.

The result must lie between zero and the window length. Reordering input or repeating an existing interval must not change it. Adding a valid interval cannot reduce busy time. Splitting one interval into two adjacent pieces must preserve the result.

Those properties verify the bookkeeping. They still do not prove that the instrumentation accurately represents hardware activity. Keep parser correctness, timestamp accuracy and performance interpretation as separate questions.

Question 4: the trace is correct, so what is the bottleneck?

Imagine an application whose request latency increased after a change. You now know its tracked device busy fraction is lower, not higher. Resist the temptation to announce that the device is faster or underused for one obvious reason.

Possible explanations include delayed input preparation, a smaller batch size, a synchronization change, missing instrumentation or different request lengths. Write two competing hypotheses and identify the additional measurement that would separate them.

For example, if you suspect host-side preparation, record when input preparation starts and finishes and when the device work is submitted. If you suspect synchronization, inspect the gap between submission and execution along with the relevant dependency. These are investigation plans, not claims that a particular profiler exposes those events automatically.

Hold the workload constant before comparing runs. Record the input distribution, software version, configuration, warmup policy and concurrency. Then change one relevant variable and observe whether the expected part of the trace changes. If it does not, revise the hypothesis instead of selecting a more flattering aggregate metric.

Question 5: how would you describe your strongest performance project?

Begin with the user-visible problem and the baseline measurement. Explain the conditions under which the problem occurred, not only the fastest result you observed. Show the observation that led you to focus on a particular component.

Then describe the smallest useful experiment. A strong explanation might say that you reduced copying in one path, preserved a correctness test, and measured the same workload before and after. An incomplete explanation says only that you rewrote a component in a different language and the application became faster.

Discuss the cost of the improvement. Did the change increase memory usage, complicate maintenance or worsen behavior for a different workload? Explain how you selected the tradeoff and what would cause you to reconsider it. The guide to interview storytelling for engineers shows how to name the options you considered and what you would give up with each one. Use real measurements from your work; hypothetical numbers should be labelled as examples.

If your experience is academic or personal, present it honestly. A small experiment with reproducible inputs, clear measurements and a well-explained failure is useful evidence of engineering reasoning. It should not be described as a production deployment.

Questions to confirm before the assessment

Ask which role and team the assessment is calibrated for, whether you will work in an existing codebase, and whether the focus is algorithms, systems, hardware reasoning or a project presentation. Confirm the language, environment, permitted reference material and AI policy.

For a performance-focused conversation, it is reasonable to ask whether you should prepare to interpret traces or explain a prior optimization project. Avoid requesting private assessment questions. The goal is to prepare in the correct area, not obtain the test in advance.

The phone-screen checklist helps organise those questions and a concise introduction. Practise the interval exercise aloud so you can explain the distinction between a correct calculation and a justified engineering conclusion.

Frequently asked questions

No. They are original practice questions based on relevant engineering themes and public company context. No private question bank or candidate experience is claimed.

Not necessarily. Here it means the fraction of the observation window covered by at least one tracked interval. Whether that corresponds to useful computation depends on the meaning and completeness of the events.

It is most relevant to software and performance reasoning. Candidates for other disciplines should prioritize the requirements of their own opening and use the general measurement discussion only where it applies.