spoton Data Analyst Interview: Questions, Experience & Prep (2026)

SpotOn is a logistics and supply chain technology company that relies heavily on data to optimise last-mile delivery, fleet routing, and client SLA performance. With 105 open roles currently active, data analysts here work at the intersection of operations, product, and business intelligence. The interview process typically spans two to four rounds: an initial screening call, a SQL or analytics skills assessment, and a business case or managerial discussion. Candidates report the exact structure varies by team, so ask your recruiter what to expect before your first call.

Salary bands for Data Analyst roles broadly follow market levels. Publicly reported figures on Glassdoor suggest entry-level analysts (0-2 years) can expect 5-10 LPA, while lead-level roles reach 28-45+ LPA. Actual offers depend on your city, the specific team, and your negotiation.

1. Walk me through how you would build a delivery performance dashboard for ops managers who are not technical.
2. A key delivery metric drops sharply overnight. How do you investigate the root cause?
3. Write a SQL query to find the top 5 delivery hubs by average delivery time in the last 30 days.
4. How would you define and measure 'on-time delivery' when different clients have different SLA windows?
5. Describe a time you found an insight in data that changed a business decision.
6. How do you handle missing or inconsistent GPS timestamps in trip data?
7. A product manager wants to know whether a new routing algorithm improved delivery time. How do you design the analysis?
8. What SQL or Python approach would you use to detect anomalies in daily shipment volumes?
9. How would you segment SpotOn's client base to prioritise retention efforts?
10. Explain a complex analysis you did to someone outside your team. How did you make it understandable?
11. You have trip, driver, and order tables in the database. Write a query to compute each driver's on-time delivery rate for the current month.
12. If two metrics are moving in opposite directions (say, deliveries per day is up but customer complaints are also rising), how do you report that to leadership?

Q: A key delivery metric drops sharply overnight. How do you investigate?

*Situation:* At my previous role, our next-day delivery completion rate fell noticeably on a Monday morning.

*Task:* I needed to identify whether the drop was a data pipeline issue, an ops issue, or a reporting error, and communicate findings to the ops head quickly.

*Action:* I first checked whether the ETL job had run correctly, then segmented the drop by city, hub, and vehicle type. I found the problem was concentrated in one hub where a batch of trips had not been geo-tagged due to a GPS sync failure.

*Result:* The ops team re-processed the affected trips, the metric corrected itself, and I added an automated alert for GPS data completeness so the same gap would surface within minutes next time.

---

Q: How would you define and measure 'on-time delivery' when clients have different SLA windows?

*Situation:* At an earlier company, every enterprise client had a different promised delivery window, making a single on-time metric meaningless across the portfolio.

*Task:* My manager asked me to create a fair OTD metric that worked across all client contracts without losing per-client visibility.

*Action:* I built a client-level SLA reference table and joined it to the trips table, flagging each delivery as on-time or late relative to that client's contracted window. I then created both a global weighted OTD rate and a per-client breakdown for the business review.

*Result:* The new metric surfaced two clients whose SLAs were consistently missed and had not been flagged by the old blanket calculation. The ops team used this to adjust driver allocation for those zones.

---

Q: Describe a time your analysis changed a business decision.

*Situation:* The ops team at my previous company was planning to add a third shift at a regional hub based on a general sense that demand was rising in that zone.

*Task:* I was asked to validate whether the investment actually made sense before headcount was approved.

*Action:* I pulled three months of trip data for that hub, broke it down by hour and day of week, and overlaid it with existing shift schedules. The data showed peak demand was concentrated in a short window already covered by current shifts, and a full third shift would mostly sit idle.

*Result:* The team held off on the third shift, re-timed two existing drivers to cover the true peak, and achieved the same throughput improvement at a fraction of the cost.

For SQL and technical questions: State your approach before writing code. Mention edge cases (nulls, duplicates, timezone mismatches in trip timestamps) out loud. SpotOn's data involves geolocation and time-series, so candidates report interviewers appreciate when you flag data quality assumptions before diving into the query.

For metric or case questions: Use a 'Define, Segment, Diagnose' structure. First define the metric precisely: what counts as a delivery and what the time window is. Then segment by a logical dimension such as city, hub, vehicle type, or time of day. Then diagnose by ruling out data issues before jumping to operational causes.

For behavioural questions: Use STAR (Situation, Task, Action, Result) and keep the 'Situation' brief. Interviewers at ops-heavy companies like SpotOn typically want detail on the 'Action', especially decisions you made with incomplete or ambiguous data.

For stakeholder or communication questions: Lead with the audience. Explain that you adapt the level of detail based on whether the listener is technical or operational. Mention a specific format you have used, such as a one-page summary, a live dashboard, or a regular email digest to city managers.

SpotOn's analytics teams sit close to operations, so interviewers are looking for analysts who can move fast and communicate clearly to non-technical stakeholders, not just people who can write clean SQL.

Domain curiosity. Candidates who have read about logistics metrics (OTIF, first-attempt delivery rate, cost per delivery) stand out. You do not need a logistics background, but showing you have thought about how data drives operational decisions signals genuine interest in the business.

Structured thinking under ambiguity. Interviewers typically give open-ended prompts on purpose. They want to see you ask clarifying questions, state your assumptions, and work through a problem step by step rather than jumping straight to a conclusion.

Ownership mindset. Because analysts here often work directly with city ops managers or product teams, interviewers look for candidates who have followed an analysis all the way to an outcome, not just handed off a report and moved on.

Practical SQL and Python skills. Candidates report the technical round focuses on window functions, joins across multiple tables, and writing queries that are readable and efficient. Python questions, if asked, tend to centre on pandas and basic data cleaning rather than machine learning.

Week 1: Domain and SQL foundations
Read publicly available material on last-mile logistics metrics: on-time delivery, SLA adherence, first-attempt delivery rate, and cost per delivery. Practice SQL with datasets that have a time dimension and a location dimension. Focus on window functions (ROW_NUMBER, LAG, LEAD, running totals) and multi-table joins, since SpotOn's operational data is structured around trips, drivers, and orders.

Week 2: Case and communication practice
Pick two or three past projects and structure them as STAR stories. Practise explaining a technical finding to a non-technical listener in under two minutes. If you have built dashboards, be ready to walk through the design decisions you made and why you chose that format over another.

Week 3: Company-specific prep
Review SpotOn's publicly available blog posts, press coverage, and LinkedIn updates for context on their operations or product direction. Think about which metrics their ops teams would care about most and prepare one or two questions or ideas you would explore if you joined. This kind of specific prep consistently impresses interviewers across analytics roles.

For finding the right opening in the first place, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR on your behalf, so you can focus your prep time on the interview itself.

Jumping to analysis before defining the metric. Many candidates start writing SQL or describing an approach before clarifying what the metric actually measures. Interviewers at data-driven ops companies notice this pattern immediately.

Ignoring data quality. In logistics, GPS failures, late uploads, and timezone errors are common. Candidates who treat all data as clean look inexperienced. Mentioning data validation as a first step shows practical awareness of how messy operational data really is.

Vague STAR answers. Saying 'my analysis improved efficiency' without a concrete action or outcome does not land well. Be specific about what you did and what changed as a direct result, even if the numbers are approximate.

Over-engineering solutions. A question about identifying delivery outliers does not require a machine learning model. Candidates who default to complex solutions when a simple query or pivot would do are often flagged as impractical for an ops-oriented team.

Not asking questions. Interviewers typically expect candidates to ask one or two clarifying questions during case rounds. Not asking suggests either overconfidence or disengagement with the problem.

Ignoring the audience. If a question asks how you would present findings to a city ops manager, answering with a technical dashboard description misses the point. Always frame your answer around the stated stakeholder and their actual decision.