AVI-SPL Software Engineer Interview Guide

The 60-second brief

Candidates describe AVI-SPL as a digital workplace services company whose work sits in audiovisual (AV) and unified communications (UC) systems: conference rooms, control centers and communication networks. The Software Engineer role reported here is where software meets that hardware. Candidates describe programming control systems, configuring DSP settings, commissioning installed rooms, and working alongside Design Engineers, Project Managers and field technicians so the software layer of a project goes live.

This guide is for engineers interviewing for the AVI-SPL Software Engineer role, especially candidates whose background is control programming, AV integration or client-facing technical work. It covers the four reported rounds, all eleven reported questions (domain, design and behavioral), the troubleshooting and design scenarios candidates describe, and a plan for rehearsing them out loud.

Candidates report four rounds over about 3-5 weeks: a phone screen, one or more technical interviews, video conferences, and an in-person office visit that depends on the role and location.

Focus areas

• Audio-Visual (AV) Systems
• System Design for Conference Rooms
• Crestron Programming

Overview

The loop candidates describe is built around the point where code meets equipment. The topics they report are control-system programming (Crestron, Extron or similar platforms), signal flow, system integration, DSP configuration, commissioning a new room, and reading project blueprints. Candidates also report that the questions lean toward practical scenarios and away from abstract algorithm puzzles, so your preparation should centre on systems you have built or fixed, not on a LeetCode queue.

The eleven reported questions fall into three groups. Domain questions ask about your DSP knowledge, your familiarity with Crestron products, whether you hold a Crestron programming certification, your design background, and a small markup question about the bold tag versus the strong tag. Design questions ask you to design systems for conference rooms and to identify the components and main goal of a system from a set of project blueprints. Behavioral questions cover your introduction, why you applied, your onsite client support experience, and what you would ask the interviewers.

Reported example scenarios give you concrete drills: diagnosing a communication failure between a touch panel and a processor, explaining your method for commissioning a new conference room, and walking through a board room design from a software and control perspective. For each one, practise a fixed order. Start from requirements or symptoms, move through the signal path and the control path, and finish with how you would verify the result and hand it over.

Candidates also describe regular collaboration with design engineers, project managers and field technicians, plus last-minute interface changes from clients. That makes how you explain a technical choice to a non-technical person part of the preparation. Build a short list of past projects, and for each one be ready to say what you built, what hardware it touched, which alternative you rejected, and why.

The AVI-SPL interview process

Candidates describe the stages below as the usual sequence. The in-person visit depends on the role and location, and the number of technical interviews varies.

Phone Screen

Candidates report that the phone screen is an initial call to establish your baseline experience. It is the first place your self-introduction, your reason for applying and your honest answer on Crestron familiarity and certification come up. Treat it as a short, accurate inventory: which control platforms you have programmed, which hardware you have touched, and where you have worked directly with clients.

What to demonstrate

• Baseline experience across control programming, AV or UC systems and integration work
• Whether your background summary is clear and relevant to a hardware-plus-software role
• Honest self-assessment of certifications and platform familiarity

How to prepare

• Write a present-past-future introduction that names your control platforms, DSP exposure and client-facing work, then practise it aloud until it sounds natural.
• List every platform and device class you have worked with (control processors, touch panels, DSP units, network gear) and mark each as hands-on, supervised or read-only.
• Prepare a one-sentence honest answer on Crestron certification and a plan for how you would close the gap if you lack it.
• Write two reasons for applying that connect your experience to the AV and UC space.

Technical Interviews

Candidates report one or more interviews focused on technical capabilities. The technical areas they describe are control-system programming (Crestron, Extron or similar), signal flow, system integration, and design topics such as requirement gathering, blueprint interpretation and component selection. Prepare to answer from experience, then reason out loud when a scenario is new to you.

What to demonstrate

• Working knowledge of control-system programming and DSP integration
• Ability to trace how audio and video signals move through a system
• Method for troubleshooting communication between separate hardware components
• Ability to turn client requirements into a design and justify component choices

How to prepare

• Draw a signal chain for a conference room from microphones and cameras through a DSP and processor to displays and speakers, and label where gain, routing and control happen.
• Write a fault-isolation sequence for a touch panel that cannot talk to its processor: power, physical link, network settings, addressing, program, then the panel project.
• Prepare a commissioning checklist you could recite: verify against the design, test each source and destination, check control feedback, tune audio, record the final configuration.
• Be ready to discuss the design background and experience question using two concrete projects, including a decision you changed after new constraints appeared.

Video Conferences

Candidates report interviews conducted by video that assess a range of skills. Candidates describe the conversation as honest and open, covering career goals, technical ability and fit with the existing team. Because it is remote, your explanations must work without a whiteboard: say what you would draw, and describe system layouts verbally or share a simple diagram.

What to demonstrate

• Clear verbal explanation of technical decisions to a mixed audience
• Depth when walking through past projects
• Communication and professionalism in a client-facing role

How to prepare

• Test your camera, microphone and screen sharing before the call, and keep a one-page signal-flow or room diagram ready to share.
• Rehearse a two-level explanation of one project: a plain-language version for a client, then a technical version for a peer.
• Prepare a short answer to the bold-text question, covering what the b tag and strong tag mean, how assistive technology treats them, and when CSS is the better tool.
• Prepare your own questions on how projects move between design, project management and field teams.

In-Person Visit

Candidates report that, depending on the role and location, you may visit a local office. This is the stage where face-to-face discussion of your design choices, your onsite client support experience and the questions you ask are most visible. Expect to talk through your work in person, so bring or prepare examples you are allowed to show.

What to demonstrate

• Professional presence in a face-to-face, client-facing setting
• Ability to explain the reasoning behind past design choices
• Fit with a team that mixes designers, project managers and field technicians

How to prepare

• Choose two projects you can discuss in depth and, where your employer permits it, bring non-confidential diagrams, screenshots or code samples.
• Rehearse an onsite support story from first report to handover, including what you told the client at each stage.
• Be ready to sketch a room design on paper or a whiteboard, with a processor, DSP, sources, displays and the control path labelled.
• Bring a short list of questions about methodology, handoffs and onboarding, and drop any that earlier conversations already answered.

Where candidates lose points

Claiming Crestron or Extron fluency you cannot back up, then stalling when asked what you actually programmed

State your real level on each platform (hands-on, supervised, read-only). Prepare one concrete program or interface per platform you claim, and say how you would close any gap.

Describing a DSP as a black box that makes audio work, without naming signal flow, routing, gain staging or tuning

Draw a conference room signal chain and be able to say what the DSP does at each point, how you would test it and what you would check first when audio fails.

Answering the blueprint question by listing every symbol instead of naming components and the main goal of the system

Practise a two-step habit: first state what the system exists to do, then group components by role (sources, processing, control, outputs, network) and flag one likely bottleneck.

Giving a troubleshooting answer that jumps to a guess, such as replacing the panel, rather than a sequence

For the touch panel and processor failure, rehearse the order: power, link, network settings, addressing, program, panel project. Say how each step is verified before moving on.

Telling client-support stories that blame the client or the hardware and never show your decisions or the handover

Use a story with a symptom, a diagnosis order, a client update and a documented fix. Include something you would change next time.

Questions & practice

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

• The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
• How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

1. Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
2. Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
3. Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
4. Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

• The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
• The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

What is your knowledge of DSPs and their integration into complex systems?

Medium · Technical & Domain Knowledge

Approach

1. Define the DSP's job in a meeting room before naming any product: it takes mic and line inputs, sets gain staging, runs acoustic echo cancellation, noise reduction and an automatic mixer, then routes through a matrix to the codec, the amplifiers and any recording feed.
2. Explain echo cancellation correctly: each canceller needs the far-end audio as its reference, meaning the signal actually sent to the room speakers. A wrong reference, or speakers fed from a different path, is a common reason the far end hears its own voice.
3. On the control side, I treat the DSP as a networked device with a text or binary protocol over IP or RS-232. I keep one connection object that reconnects with backoff, frames replies by their delimiter and maps named controls (mute, level, preset) to commands, so the UI never sends raw strings.
4. Keep state in sync. I subscribe to or poll mute and level values so the touch panel shows changes made elsewhere, such as a hardware mute button or the DSP's own software. After a reconnect or a DSP reboot I re-query everything instead of trusting cached values.
5. Name the edge cases: a volume slider that floods the device (rate-limit, or send only the latest value), a preset that changes routing during a live call, and what the room should do when the control link drops.

Follow-up

• Far-end participants hear an echo of themselves. How do you work out whether the cause is the echo-cancellation reference, gain staging or speaker placement?
• Where does the DSP sit relative to the video codec, and which of the two should do echo cancellation?
• How do you keep a volume slider responsive without overrunning the DSP's command interface?

Are you familiar with Crestron products?

Medium · Technical & Domain Knowledge

Approach

1. Answer the literal question first and rate your own familiarity honestly. Say which Crestron hardware you have handled (control processors, touch panels, keypads, switchers) and whether you programmed it, configured it or only used it.
2. Show that you understand the control model. A touch-panel press reaches the processor as a join (digital, analog or serial). Program logic turns it into a device command over IP, RS-232 or IR, and device feedback drives the button states on the panel.
3. Walk one concrete example from start to finish. For a 'start presentation' button: power the display, wait for warm-up, select the input, unmute program audio, and show the button as active only after the display confirms.
4. If most of your hands-on time is with Extron or another control platform, map it explicitly. The event-driven logic, device drivers and feedback loops carry over; the platform-specific part is the tooling and the file formats.
5. Name failure modes you have dealt with: a display that ignores commands while warming up, a dropped IP session to a device, and a panel that has lost its connection to the processor.

Follow-up

• How would you diagnose a touch panel whose buttons do nothing while the processor appears to be running?
• How do you keep panel feedback correct when someone changes the input with the display's own remote?
• What would you need from a device's control protocol document before you write a driver for it?

Are you a certified Crestron programmer?

Medium · Technical & Domain Knowledge

Approach

1. Give a direct yes or no in the first sentence. If yes, name the certification level you hold and when you earned it. If no, say what training you have done toward it and where you are on that path.
2. Back the answer with the program you know best: the room type, the devices it controlled, how you split it into a module per device, and how you tested it before commissioning.
3. If you are not certified, offer evidence that transfers: state-machine or event-driven code, serial and TCP device protocols you have implemented, UI work for panels or embedded screens, and any Extron or other control-platform credential you hold.
4. Be precise about your own role. Writing a control program from scratch, modifying an existing one and loading a vendor-supplied file are different levels of experience, so say which of these you have done.

Follow-up

• Walk me through how you structured the last control program you wrote.
• How would you write a driver for a device that has no existing module?
• How do you test a control program before you are on site with the hardware?

What is your design background and experience?

Medium · Technical & Domain Knowledge

Approach

1. Settle which kind of design is meant, or cover both briefly: software design (architecture, interfaces, UI) and AV system design (room layout, signal flow, equipment selection). Questions reported for this role include room design and reading blueprints, so have an AV example ready.
2. Tell one project as requirement, constraints, options considered, decision and result. For example: why a room needed a separate DSP instead of the codec's built-in audio, or why I cut a touch-panel UI down to three modes.
3. Name the artifacts you produced, such as signal-flow diagrams, rack elevations, UI layouts, device control lists and test plans. They show that installers and programmers could build from your design.
4. Explain the reasoning behind one trade-off in cost, reliability or usability, and say what you would do differently now.

Follow-up

• Which design decision on that project turned out wrong, and how did you find out?
• How did you turn a client's description of how they meet into a list of requirements?
• How did you keep the design documents and the as-built system in step when changes came late?

To make a word bold in code, would you prefer using <b></b> or <strong></strong> and why?

Medium · Technical & Domain Knowledge

Approach

1. Lead with semantics. In HTML5, <strong> marks content of strong importance, seriousness or urgency. <b> draws attention to text without implying extra importance, such as keywords or product names in running text.
2. Both render bold by default, so the choice is about meaning, not appearance. For bold that is purely visual, such as a label or a heading style, I set font-weight in CSS on a class instead of using either tag.
3. Correct a common myth. Most screen readers do not change voice or announce <strong> by default, so I choose <strong> for meaning and maintainability, not because it guarantees a spoken difference.
4. Give the short answer and the parallel case: I use <strong> when the word matters to the meaning (a warning, a required step) and <b> for stylistic emphasis. <em> versus <i> follows the same rule for emphasis and italics.

Follow-up

• When would you use <em> instead of <i>?
• If a design system needs bold labels everywhere, would you change the markup or the CSS, and why?
• What does nesting one <strong> element inside another mean?

Can you design systems for conference rooms?

Medium · Problem-Solving & System Design

Approach

1. Start with requirements: room size and seating, the use cases (local presentation, video calls, hybrid meetings), the content sources and calling platform the room must support, and who will run it without help.
2. Lay out the signal flow. Sources and the codec feed a switcher that drives the displays. Microphones feed a DSP for echo cancellation and mixing, which then feeds the codec and the amplified speakers. The camera goes to the codec, and a control processor and touch panel sit on the network.
3. Write the control software as a small state machine of room modes (off, presentation, call). It needs one-touch start, power sequencing that waits for display warm-up, a shutdown that resets volume and routing, and an auto-off on a timeout or on room occupancy.
4. Plan for failure and support. Poll every device for online status, report faults to a monitoring system, and keep a manual path (display remote, local input) for when the processor is down. Put AV devices on their own VLAN with the ports and PoE budget they need.
5. Weigh a standard room template reused across a site (easier to support, faster to deploy) against custom design per room. Cover edge cases such as divisible rooms, which must merge audio routing and control when the partition opens.

Follow-up

• How would the design change for a divisible room that is sometimes one space and sometimes two?
• How would you monitor hundreds of these rooms and find a broken one before the next meeting starts?
• The codec reboots in the middle of a call. What should the touch panel and the rest of the room do?

Given a set of project blueprints, can you identify the components in the system and explain the main goal of

Medium · Problem-Solving & System Design

Given a set of project blueprints, can you identify the components in the system and explain the main goal of the system?

Approach

1. Read the drawing set in order: title block and revision, drawing index, legend of symbols and abbreviations, then the general notes. Device symbols mean nothing until the legend defines them.
2. Separate the sheet types. Floor plans show device and floor-box locations. Reflected ceiling plans show ceiling mics, speakers and projectors. Elevations show display and camera heights. Signal-flow diagrams and rack elevations show how the equipment connects.
3. Identify each component by its function along the signal path: sources and inputs; switching and processing (switcher, DSP, codec, control processor); outputs (displays, speakers); and the control and network links between them. Note each connection type, such as HDMI, network, RS-232 or analog audio.
4. State the system's main goal in one sentence based on what the components imply, for example a hybrid meeting room with ceiling audio and two displays. Support it with the two or three connections that prove it.
5. Point out gaps and conflicts as you find them: a device on the floor plan that is missing from the signal-flow diagram, no echo-cancellation reference path, one network switch that every device depends on, or no power at a display location.

Follow-up

• Where is the single point of failure in this system, and how would you remove it?
• Which control path would you use for each device on these drawings, and why?
• What would you ask the design engineer before you start programming from these drawings?

One customer endpoint stalls deliveries to every other destination

Medium · bulkhead · timeouts · saturation

The egress service delivers about 1.5k webhooks/second across 40,000 destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. Throughput falls to 300/second, queue depth climbs, and p99 delivery latency for unaffected destinations goes from 200 ms to minutes, while the error rate barely moves. One tenant holds 900 destination rows whose URLs share a hostname that now answers in 9.5 seconds. Explain the mechanism with the arithmetic, then give the containment in the order you would apply it.

Approach

1. Look at saturation before errors. A flat error rate with collapsing throughput says nothing is failing, things are waiting, so the first signal to pull is in-flight request count or pool wait time rather than the error counter. This is the distinction that decides the whole investigation.
2. Group in-flight work by resolved host, not by destination id. The cap is keyed per destination row, so 900 rows sharing one hostname buy 3,600 concurrent slots against a single host, each held for 9.5 seconds. The bulkhead was never a bulkhead for that host, and grouping by the wrong dimension is why the dashboard looked healthy.
3. Do the arithmetic in both directions. Required concurrency is arrival rate times latency, so 1.5k/second at 200 ms needs about 300 in flight, which is entirely consumed by 3,600 slow slots; conversely whatever concurrency is left sustains rate equals concurrency divided by 9.5 seconds, which is the 300/second you are seeing. Matching both numbers is what promotes this from a plausible story to the mechanism.
4. Explain why the circuit breaker never helped. It opens on consecutive failures, and a 9.5-second response inside a 10-second timeout is a success. Slow is not failing, so an error-rate breaker cannot see this; you need a slow-call ratio, a deadline propagated from the caller's remaining budget, or a concurrency limiter.

Follow-up

• The host recovers to 80 ms. How long does the queue take to drain, and what does the drain do to the recovered host?
• Where should the 10-second timeout number actually come from?

Suggested practice checklist

The plan starts with the reported rounds and your own inventory, builds the domain and design skills the reported questions test, adds troubleshooting practice, then moves to behavioral rehearsal and a full mock loop.

Day 1 — Map the loop and inventory your experience

• Write the four reported rounds in order and mark which of them you can answer from direct experience today.
• List every control platform, DSP unit, touch panel, network device and client environment you have worked with, tagged hands-on, supervised or read-only.
• Write your honest answer on Crestron familiarity and certification, with your plan to fill gaps.

Deliverable: A one-page round map and a tagged inventory of platforms and projects, plus a written answer on certification.

Day 2 — DSP and signal flow

• Draw an audio and video signal chain for a conference room and label sources, DSP, processor, displays, speakers and the control path.
• Write a short answer on what a DSP does in the chain (mixing, gain, equalisation, routing) and how you would tune it after install.
• Say the DSP answer aloud to a friend who is not an AV person and check that it holds up.

Deliverable: A labelled signal-flow diagram and a spoken answer on DSP integration.

Day 3 — Crestron, Extron and the certification question

• Write what you know of Crestron products: processors, touch panels, programming workflow and how a project is loaded and tested.
• Repeat the same for Extron or any similar platform you have used.
• Write a truthful answer on certification: your status, what you have learned on the job and when you would complete the credential.
• Write the one-paragraph answer on the b tag versus the strong tag.

Deliverable: A platform cheat sheet, a certification answer and a written markup answer.

Day 4 — Troubleshooting and commissioning

• Write a fault-isolation sequence for a touch panel that cannot reach its processor, with a verification step for each stage.
• Write your commissioning method for a new room, from checking the design to final tests and handover.

Deliverable: A diagnostic sequence, a commissioning checklist and a written solution to the practice drill.

Day 5 — Conference room and blueprint design

• Design a board room from a software and control perspective: requirements, components, control interface, network and failure handling.
• Take any real or sample drawing, name the components and state the system's main goal in one sentence.
• Prepare your design background answer using two projects and one decision you changed under constraints.

Deliverable: A written room design, an annotated blueprint reading and a design background answer.

Day 6 — Behavioral stories and your own questions

• Write and rehearse the present-past-future introduction.
• Write the reasons you applied, each tied to something you have done.
• Write an onsite client support story with symptom, diagnosis order, client update and handover.
• Write five questions to ask and rank them.

Deliverable: Four spoken answers and a ranked question list.

Day 7 — Full mock loop

• Run a mock phone screen using the introduction, the reason for applying and the experience questions.
• Run a mock technical session: DSP, platform familiarity, the touch panel failure and the room design.
• Review each answer for unsupported claims and rewrite any that you could not defend.

Deliverable: A mock-loop recording or notes, with a corrected list of weak answers.

Client-facing and experience questions

Candidates describe the conversation as honest and open, covering your career goals, your technical ability and how you would fit the team. The role is client-facing and works with designers, project managers and field technicians, so prepare stories that show decisions you made, how you communicated them, and what you changed afterwards.

1. Describe a time a client changed requirements late in a project and how you adapted.
2. Describe a time you had to explain a technical fault to a non-technical person.

Tell us about yourself.

Medium · Behavioral & Situational

Approach

1. Structure the answer as present, past, future: what you do now, the two or three experiences that led there, and what you want from a role that mixes code with hardware.
2. Choose evidence that matches the stack candidates report for this role: control programming, DSP configuration, commissioning, network setup or client-facing work. Name the systems and your own part in them.
3. Include one concrete outcome, such as a room you commissioned or an interface you rebuilt after a client changed their mind, and say what you personally decided.
4. End with a bridge sentence into why this role so the next question has an opening. The mistake that sinks it is a chronological CV recital, or a software-only story that never touches hardware.

Follow-up

• Which project on your CV should we discuss first, and why that one?
• Which part of that work did you do yourself, and which with a team?
• Where do you want to be strongest after a year in this role?

What about AVI-SPL made you apply to this position?

Medium · Behavioral & Situational

Approach

1. Give two or three specific reasons you could defend, and tie each to your own history: the AV and UC focus, the mix of programming with commissioning, working with design engineers and project managers.
2. Read the role requirements candidates describe and mention the platforms listed (Crestron, Extron, DSP tuning, network configuration), saying which you have used.
3. Structure it as what you have been doing, what pulled you toward this kind of work, and what this role lets you do next.
4. Avoid generic praise, repeating the company's slogans, or leading with pay or commute. If you are early in your career, say what you have already built or studied in AV and what you want to learn.

Follow-up

• What other roles are you considering, and how does this one compare?
• Which part of this role do you expect to be hardest at first?
• What would make you leave a role like this?

What is your experience with onsite client support?

Medium · Behavioral & Situational

Approach

1. Pick one onsite or in-person support story where you made the decisions. Name the site type, the symptom the client reported and what was at stake for them that day.
2. Narrate the diagnosis from outside in: power, physical connection, network and addressing, control processor and program, then the signal path. Say you changed one thing at a time and how you confirmed each result.
3. Show client handling: how you described status to a non-technical person mid-fault, how you set expectations, and how you responded to a last-minute change request.
4. Close with handover: what you documented, what you changed to prevent a repeat, and what you learned. If you have no onsite work, use the nearest equivalent (help desk escalation, field deployment, customer demo) and say so plainly. Blaming the client or the hardware sinks the story.

Follow-up

• What would you have done if the fault could not be reproduced on site?
• Tell me about a time a client asked for a change late in a project.
• How did you decide what to escalate, and to whom?

What kind of questions do you have for us?

Medium · Behavioral & Situational

Approach

1. Prepare four or five questions before the call and pick the ones that fit who you are speaking with. Draw on topics candidates describe: project methodology, handoffs between designers, project managers and field technicians, and how commissioning is signed off.
2. Ask something that shows you thought about the work: how a control program change is handled after a client sees the finished room, how code is versioned and shared across sites, or which control platforms the team uses most.
3. Include a growth question, such as how new engineers learn the hardware side, because the reported tips encourage candidates to show willingness to learn.
4. Cross off questions the conversation has already answered and keep a spare. The mistakes are having none, asking what the careers page answers, or opening with pay.

Follow-up

• Which of those questions matters most to your decision, and why?
• What would you want to hear that would make you decline an offer?