Audcomp Software Engineer Interview Guide

The 60-second brief

Audcomp is described by candidates as a provider of IT and software solutions for small-to-medium-sized businesses, with client offices reported in the range of roughly 50 to 150 users. The Software Engineer role is field-based: you go to client sites, carry out maintenance, diagnose system failures and put in new technical solutions, reporting back to the IT management team. Candidates describe being the main technical person on site, so the job mixes hands-on infrastructure work with client communication.

This guide is for candidates interviewing for the Audcomp Software Engineer position as candidates describe it: a client-facing, travel-heavy role built around IT infrastructure troubleshooting rather than algorithm work. It covers the two reported rounds, the seven reported questions (travel readiness, your reasons for leaving, your fit with small-business IT, and on-site troubleshooting) and a one-week plan for rehearsing them aloud.

Candidates report two rounds, an initial screening call followed by an in-person interview with technical management and leadership, spread over roughly 2 to 4 weeks. The reported questions centre on logistics, work history and troubleshooting method.

Focus areas

• Client-facing support / field engineering
• Customer environment troubleshooting
• Understanding customer requirements

Overview

Candidates describe this loop as accessible and light on formal technical testing, with no algorithm or coding exercise reported. That shifts the preparation. You are not rehearsing data structures; you are preparing a short, credible account of who you are as a field engineer: the environments you have supported, how you diagnose a fault when nobody senior is reachable, and how you explain the result to a non-technical user.

The reported questions fall into three groups. The first covers practical readiness for travel: using your own car for client visits, covering your own fuel for local site visits, and managing several client sites in one week. The second covers your background: why you want to leave your current employer, how your experience maps onto small-to-medium-sized business IT, and your familiarity with the industry solutions the company supports. The third is on-site troubleshooting. Candidates also cite two scenario prompts: fixing a critical system failure at a client site, and managing expectations when a fix takes longer than planned.

The requirements candidates list put troubleshooting experience on IT infrastructure, autonomous field work, strong client communication and a reliable vehicle in the must-have column, with managed service provider or similar client-facing experience as a plus. Build your answers so each one proves one of those items with a specific example: a real site, a real fault, what you did, what you told the client.

Because candidates also report a direct, sometimes informal style and occasional scheduling delays, plan to answer bluntly and concisely. Decide your position on the car and fuel questions before you walk in, and keep a short list of your own questions on mileage, expense reimbursement and any commitments attached to training.

The Audcomp interview process

Candidates report two stages, in this order, over roughly 2 to 4 weeks. The descriptions below cover what is reported and how to prepare for each.

Initial Screening Call

Candidates report an initial call that checks your background and fit for the role. Because the in-person stage follows only after this call, treat it as the point where you establish a clear, short account of your career and your reasons for wanting a field-based client role. A background-and-fit call is where employment-history questions are practised, so have your answer to why you are leaving your current employer ready, and a two-sentence summary of the kinds of environments you have supported. Keep answers direct; the loop is described as straightforward and sometimes informal.

What to demonstrate

• Whether your work history lines up with client-facing IT infrastructure support
• How clearly and concisely you explain your career move and your reasons for it
• Basic readiness for a travel-based role, such as having your own transport

How to prepare

• Write a spoken two-minute career summary that names environments (user counts, infrastructure types) and ends with why a field-based client role is the next step
• Write and rehearse a reason for leaving your current employer that talks about what you want to do next, not what you dislike
• Settle your honest answers on using your own car and covering fuel for local visits so you can reply in one or two sentences
• Ask how the in-person stage is organised and who you will meet

In-Person Interview

Candidates report a face-to-face interview with technical management and leadership. Reports describe a direct style, and note that interviewers may be busy, so the schedule can slip and the structure can be loose. This is where candidates report the reported scenarios about fixing a serious failure on site and about managing client expectations when a fix runs long. Prepare spoken stories built from real incidents, plus a clear account of how you diagnose faults and how you explain them to non-technical staff. Arrive early and be ready to wait.

What to demonstrate

• Your troubleshooting method on client infrastructure and how you explain it
• Communication with non-technical users and with leadership, in person
• Autonomy: working alone on site and knowing when to escalate
• Fit with the travel and logistics demands of visiting several clients in a week

How to prepare

• Prepare two incident stories (a serious on-site failure, and a fix that took longer than promised), each covering the symptom, your diagnostic steps, what you told the client and the outcome
• Write your week-of-travel routine: how you group sites, what you carry, how you handle an urgent call mid-week
• Map your experience to the listed requirements (infrastructure troubleshooting, autonomy, communication, vehicle, optional managed service provider background) and note any gap with how you would close it
• Bring questions on mileage and expense reimbursement and on any commitment attached to training

Where candidates lose points

Hesitating or hedging on the questions about using your own car and covering fuel for local visits

The requirements candidates list include a reliable vehicle, and these questions are reported directly. Decide your position before the interview and answer in one or two sentences. Afterwards, ask how mileage and expense reimbursement work so there are no surprises.

Answering the question about travelling to several client sites in a week with a trait ("I am very organised") instead of a routine

Describe how you group sites, what you carry, how you confirm access, and how you handle an urgent call mid-week. Use one real week as the example.

Answering why you are leaving your current employer by criticising them

Give one concrete reason that points toward this role, such as wanting client-facing field work, and keep it short. Rehearse it aloud until it takes under a minute to say.

Jumping to a fix when asked about on-site troubleshooting, or listing tools instead of a sequence

Walk through the order you work in: ask what changed and who is affected, reproduce or observe the fault, check the simple and cheap causes first, make one change at a time, confirm with the user and write it up. Add when you escalate.

Telling only large-organisation stories that never show you working alone with a client

Pick stories in which you made the decision on site with no senior person to ask, and which end with what you told a non-technical user. Describe the user count and the environment so the fit with small-business IT is obvious.

Questions & practice

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?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Are you willing to use your own car for client visits?

Medium · Operational and Logistical Readiness

Approach

1. Answer the question directly first (yes, yes with conditions, or no), then give the conditions. A vague answer to a yes/no logistics question reads as a hidden no.
2. Back the yes with evidence. Name the vehicle you would use, say whether it is reliable enough for daily site visits, and mention any earlier job where you drove between customer sites.
3. Before you commit, check whether your car insurance covers business use. Many personal policies cover commuting but not driving between client sites, and an uncovered accident on a client trip is your cost.
4. Ask how mileage is reimbursed (a per-mile rate, a flat allowance or nothing), and whether you would carry client equipment or spare hardware in the car. Both change what yes actually costs you.
5. If you have a real constraint, such as a shared car or no car on certain days, say so plainly and offer a workaround. Raising it at the screen is better than discovering it after the offer.

Follow-up

• What would you do if your car broke down on the way to a client appointment?
• How far from your home are you willing to travel for a same-day visit?
• Does your insurance cover business use, or would you need to change your policy?

Are you prepared to cover your own fuel costs for local client site visits?

Medium · Operational and Logistical Readiness

Approach

1. Keep two things apart: whether you are willing to do it, and the terms. Something like "I can cover local trips; I'd like to understand how mileage beyond that is handled" answers the question without refusing anything.
2. Work out the real cost before the interview: weekly cost = weekly miles / fuel economy x fuel price. For example, 300 miles a week at 30 mpg and $3.50 a gallon is 10 gallons, about $35 a week or roughly $1,800 a year.
3. Ask where "local" ends: whether there is a distance or a list of sites past which fuel or mileage is reimbursed, and how claims are logged and paid.
4. Build any uncovered running cost (fuel, extra wear, higher insurance) into the salary you ask for, and negotiate it at the offer stage rather than turning down the role during screening.
5. Mention how you would track it: a mileage log or app that records each site visit, so any expense claim or tax record can be checked later.

Follow-up

• How would you keep track of mileage and expenses across several client visits a week?
• At what point would the travel cost make this role unworkable for you?
• If fuel is not reimbursed, how does that change your salary expectations?

Why are you looking to leave your current place of employment?

Medium · Experience and Industry Knowledge

Approach

1. Give one factual sentence about why you are leaving (limited scope, no client contact, a contract ending, a layoff), then spend the rest of the answer on why this role is the next step.
2. Look forward. Tie the move to what this role is described as offering: client-facing work across different small and mid-sized business environments, on-site troubleshooting, and working on your own.
3. Do not criticise your current employer or manager. If the real reason is a bad situation, describe what was missing, not who was at fault.
4. Keep it consistent with your CV and your screening-call answer. If you were laid off or your contract ended, say so plainly, because an evasive answer here raises more questions than the fact itself.
5. Finish with something concrete you want to do in this role, such as owning a set of client sites end to end, so the answer ends on what you would bring.

Follow-up

• What would your current employer have to change for you to stay?
• What would make you want to leave this role in a year?
• How does a travel-heavy, client-facing role fit what you want to do next?

Can you describe your familiarity with the industry solutions we currently support?

Medium · Experience and Industry Knowledge

Approach

1. Before the interview, find out which industries Audcomp's clients are in and which systems the role supports, from the job posting, the company website or by asking at the screen. Then prepare a map from each of those systems to your own experience.
2. Organise your experience by layer so it is easy to follow: endpoints and OS, identity and email (for example a directory service and a hosted email tenant), networking (DHCP, DNS, VPN, firewall), backup and restore, and any line-of-business applications you have supported.
3. Give scope for each one: how many users or sites, whether you administered it or only used it, and one concrete task you did with it, such as a migration, a restore or a permission cleanup.
4. Be honest about gaps and show how you would close them. For example: "I haven't run that product, but I administered a similar one; before a site visit I'd read the vendor docs and test in a trial or lab tenant."
5. Relate your scope to the environments the role describes, client sites of roughly 50 to 150 users, and say which of your experience matches that size.

Follow-up

• Which system have you supported most deeply, and what failed most often in it?
• How would you learn a line-of-business application you have never seen before your first visit to that client?
• How do you document a client environment so another engineer can support it after you?

What is your approach to troubleshooting issues when you are on-site at a client location?

Medium · Experience and Industry Knowledge

Approach

1. Start by defining the scope: who is affected, since when, and what changed (updates, new hardware, a password change, a moved cable). One user versus the whole office already separates an endpoint fault from shared infrastructure.
2. Isolate one layer at a time, from the bottom up: link and cabling, then IP configuration (a Windows 169.254.x.x address means DHCP failed), then name resolution with nslookup, then reachability with ping or traceroute, then the service or application, then authentication. If it works by IP but not by name, the problem is DNS.
3. Collect evidence before changing anything: event logs, recent updates and the user's exact error. Change one thing at a time and write down each step, so you can roll back and so the fix can be explained afterwards.
4. Restore service first and find the root cause second. Agree a workaround with the client if needed, set a time limit on diagnosis, and escalate with a written handover (symptoms, what you ruled out, current state) once the problem is beyond what you can fix on site.
5. Keep the client informed in plain language (what is affected, what you are trying next, when they will hear from you), confirm the fix with the affected users before you leave, and record the cause and fix in the ticket.

Follow-up

• The whole office has lost internet access but one PC still works. Where do you start?
• When do you stop troubleshooting on site and escalate, and what do you hand over?
• How do you confirm the fix has held after you leave the client's office?

Suggested practice checklist

The plan follows the reported loop: logistics and fit questions first, then background and experience, then on-site troubleshooting, then a full spoken run. Each day ends with something written that you can reread before the call.

Day 1 — Map the loop and settle your answers on travel costs

• Write down the two reported rounds, a screening call and an in-person interview with technical management and leadership, and mark which part of each you feel least ready for
• Decide your honest position on using your own car for client visits and on covering fuel for local visits, then write a one-sentence answer to each
• Write three questions to ask about mileage, expense reimbursement and travel expectations

Deliverable: A one-page loop map, two one-sentence answers (car and fuel) and three written questions on travel and expenses.

Day 2 — Build your multi-site week

• Write a sample week with three client sites in different areas, showing the order, the buffer for urgent calls and what you resolve remotely beforehand
• Write a visit-kit checklist (hardware, cables, spare parts, credentials, documentation) and a pre-visit confirmation message
• Record yourself answering how you handle travelling to multiple client sites in one week using a real week as the example

Deliverable: A sample weekly schedule, a kit checklist, a confirmation message template and one recorded answer.

Day 3 — Prepare your reason for leaving and your career summary

• Write three versions of your reason for leaving, then keep the one that points toward field-based client work and drop any that criticise your employer
• Write a two-minute career summary that names environments, user counts and infrastructure you have supported
• Practise both aloud until the answers are short and direct

Deliverable: One final reason-for-leaving answer and a written two-minute career summary, each rehearsed aloud.

Day 4 — Map your experience to small-business IT

• List the requirements candidates report (infrastructure troubleshooting, autonomy, client communication, vehicle, optional managed service provider background) and write one example from your history for each
• Write one story in situation, action, result form where you were the only technical person responsible, ending on the outcome for the users
• Write what you know of the industry solutions the company supports and where you would need to learn, and name one concrete gap with a plan to close it

Deliverable: A requirements-to-evidence table, one written story, and a short note on the industry solutions you know and the gap you will close.

Day 5 — Rehearse on-site troubleshooting and the two reported scenarios

• Write your troubleshooting sequence as numbered steps, from asking what changed to confirming with the user and writing it up, and mark the point where you escalate
• Prepare the reported scenario about fixing a serious system failure at a client site: symptom, steps, communication, result
• Prepare the reported scenario about managing expectations when a fix takes longer than anticipated, including exactly what you tell the client and when

Deliverable: A numbered troubleshooting sequence and two written incident stories, one per reported scenario.

Day 6 — Autonomy, pushback and talking to leadership

• Write two examples of working alone at a client or internal site, including a time you escalated and why
• Look up the kinds of small-to-medium-sized businesses you have served and write how your experience reads for them

Deliverable: Two written autonomy examples, one practised pushback story and a short note framing your experience for small-business clients.

Day 7 — Full spoken run and final questions

• Answer all seven reported questions aloud in sequence, then the two reported scenarios, and cut every answer that runs long
• Review the answers for consistency, especially travel, car and fuel answers against your multi-site week
• Finalise your questions on mileage, reimbursement, training commitments and how the in-person stage runs

Deliverable: A recorded full run with a list of answers to tighten, plus your final questions to ask.

Field engineer behavioral preparation

Candidates report that this loop leans on your experience, your readiness for field work and your handling of clients rather than on coding. Each prompt below needs a real example with your own decisions in it: the environment, what you did on site, what you told the client and what happened. Rehearse until each answer is short and direct.

1. Describe a time you had to fix a critical system failure while on-site at a client location.
2. How do you manage client expectations when a fix takes longer than anticipated?
3. Why are you looking to leave your current place of employment?
4. Tell me about a time you worked independently with a client and had to decide when to escalate.

How do you handle the logistical demands of traveling to multiple client sites in a single week?

Medium · Operational and Logistical Readiness

Approach

1. Lead with the mechanism rather than a trait. Say how you build a week: group client sites by area so the route is a loop rather than a series of round trips, place visits that have a fixed time (a maintenance window, a staff changeover) first, and leave open blocks for unplanned faults.
2. Describe your per-visit preparation: confirm access and the on-site contact the day before, read the ticket or visit history, and load the kit (laptop, cables and adapters, spare parts, remote-access credentials, a charged phone) so a forgotten item does not cost a second trip.
3. Show how you cut travel. Name what you resolve by remote session before leaving, and what truly needs hands on site, so a short fix does not consume a half day on the road.
4. Back it with one real week in numbers: how many sites, roughly what distance, what went wrong, and how you re-sequenced when a visit overran or an urgent call arrived, telling the next client early rather than arriving late.
5. Close on record-keeping: log time and mileage per site, write a handoff note after each visit and send the client a short summary. Keep your answer consistent with what you said about using your own vehicle and covering fuel.

Follow-up

• A client reports an outage while you are mid-visit at another site. What do you do in the next ten minutes?
• How do you track mileage and expenses so reimbursement is straightforward?
• What do you do when a visit overruns and the next client is already waiting?

How does your experience align with the challenges faced by small-to-medium-sized business IT environments?

Medium · Experience and Industry Knowledge

Approach

1. Anchor the answer on concrete features of small-business environments: a modest user count, few or no dedicated IT staff on site, a mix of older and newer hardware, and line-of-business software that the office cannot do without. Say which of these you have supported and how many users were involved.
2. Tell one short story where you were the person responsible, in the shape situation, your action, result: the environment, the fault or project, the decision you made and what changed for the users. Spend most of the time on your reasoning and what you did, not on the tool names.
3. Match the story to the requirements candidates list: troubleshooting infrastructure, working alone, explaining things to non-technical people. If you have managed service provider or similar client-facing experience, say so; if you do not, bridge with the closest equivalent such as internal IT for a similar-sized organisation or freelance client work.
4. Name one gap honestly and say how you would close it quickly, for example an unfamiliar line-of-business application: you would ask for admin documentation, shadow a colleague on one visit and keep a runbook of what you learn.
5. Avoid ending on a list of technologies. End on the outcome for the client: downtime avoided, a stable setup handed over, a request understood correctly the first time.

Follow-up

• Tell me about a time you were the only technical person present and something you had never seen before broke.
• How would you approach a client site running software you do not know?
• Which part of a small-business setup are you least experienced in, and what would you do about it?

Argue against a design, lose, and commit anyway

Medium · disagreement · service boundaries · decision records

Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

Approach

1. State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
2. Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
3. Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
4. Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.

Follow-up

• What threshold on that alert would have proved you right, and did anyone ever look at it?
• If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?