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

Intangles is a fleet intelligence and vehicle telematics company that processes real-time sensor data from thousands of vehicles to help fleet operators cut costs and reduce downtime. As of mid-2026, intangles has 26 open roles listed on job sites, reflecting active hiring across its data and product teams.

The Data Analyst role sits at the intersection of IoT data pipelines, SQL-heavy analytics, and business reporting for fleet clients. Candidates typically go through two to three rounds covering a technical screen, a hands-on SQL or Python exercise, and a final discussion with the hiring manager. The process is known for being practical: candidates report that questions focus on real fleet data scenarios rather than abstract puzzles.

To do well, you need comfort with large and often messy sensor datasets, the ability to build dashboards non-technical fleet managers can act on, and the skill to translate a data finding into a plain business recommendation.

1. Write a SQL query to find the top 5 vehicles by average fuel consumption over the last 30 days from a trips table.
2. How would you detect anomalies in GPS location data for a fleet of trucks?
3. You are given a dataset with missing odometer readings. How do you decide whether to impute or drop the records?
4. A fleet client says their vehicles are breaking down more often than expected. Walk us through how you would analyse the maintenance data to find the root cause.
5. How would you build a dashboard in Power BI or Tableau to show real-time fleet utilisation to a client's operations manager?
6. Explain the difference between a window function and a GROUP BY in SQL. Give an example where a window function is the better choice.
7. How do you handle duplicate records in a large IoT events table where the same device sends repeated signals?
8. A product manager asks: 'Is our predictive maintenance model actually saving money for clients?' How do you structure the analysis?
9. Describe a time you had to clean and standardise data from multiple sources with different formats.
10. How would you calculate churn for a fleet client, and which leading indicators would you track to predict it early?
11. What is the difference between precision and recall? When would you prefer higher recall in a vehicle fault detection model?
12. How do you explain a complex data finding to a non-technical audience, such as a fleet operations supervisor?

Q: How would you detect anomalies in GPS location data for a fleet of trucks?

*Situation:* At my previous role, we received GPS pings every 30 seconds from hundreds of delivery vehicles. Occasionally a device would send coordinates that placed a truck far outside its expected route or implied an impossible speed.

*Task:* I needed to build a lightweight anomaly detection layer before the data reached our reporting dashboards, so operations managers were not seeing false alerts.

*Action:* I calculated the maximum physically possible speed between two consecutive GPS points using the Haversine formula. Any jump that implied a speed no vehicle could realistically achieve was flagged as a bad ping. I also used a rolling median of the last few pings to catch stationary devices that suddenly reported a large location jump. I wrote this logic in Python and added it as a step in our ETL pipeline.

*Result:* Operations managers stopped raising tickets about phantom location errors, and the dashboard data became reliable enough for the client to act on without manual checking.

---

Q: A fleet client says their vehicles are breaking down more often than expected. Walk us through how you would analyse the maintenance data.

*Situation:* Imagine a fleet client contacts the account team saying they are seeing more unplanned breakdowns in the last quarter compared to the same period the previous year.

*Task:* My job would be to find whether the increase is real, which vehicle types or routes are most affected, and whether early warning signals exist in the sensor data.

*Action:* I would start by pulling maintenance event logs and joining them with vehicle metadata and trip history in SQL. I would compare breakdown frequency by vehicle age, make, and route type. Then I would look at engine temperature, battery voltage, and fault code data in the weeks before each breakdown to find patterns. If a pattern appeared, I would build a threshold-based alert in the dashboard so the client team could act before a vehicle failed.

*Result:* This kind of analysis turns a reactive complaint into a proactive monitoring workflow. Clients who have implemented predictive maintenance alerts, as publicly reported in fleet industry case studies, have reduced unplanned downtime meaningfully over time.

---

Q: Describe a time you had to clean and standardise data from multiple sources with different formats.

*Situation:* In a previous project, I was consolidating fuel transaction data from three fuel card providers. Each used a different date format, different column names for the same field (vehicle ID, asset number, unit code), and one provider included tax in the amount while the others did not.

*Task:* I had to produce a single clean table the finance team could use for monthly reconciliation.

*Action:* I wrote a Python script using pandas that applied a schema mapping for each provider, normalised all dates to ISO format, stripped the tax component using the applicable rate, and flagged any records where the vehicle ID could not be matched to the master fleet list. I documented each transformation step so the process could be audited later.

*Result:* The reconciliation that previously took the finance team a full day of manual work ran in a few minutes. The script was later reused for two additional provider integrations.

STAR for behavioural questions (Situation, Task, Action, Result): Keep the Situation and Task brief. Spend most of your time on Action and Result. For data roles, include specific tools, SQL logic, or Python libraries where relevant. Interviewers remember answers that name real techniques over vague descriptions.

Problem-solving framework for case questions: Clarify the business question first. Identify the data you would need. Describe how you would explore it (distributions, joins, aggregations). Explain how you would validate your finding. End by stating how you would present it to a non-technical stakeholder. This structure shows analytical thinking and business sense at the same time.

SQL question structure: Restate the table structure or assumptions before writing code. Build the query step by step: filter, join, aggregate, then window function if needed. Call out edge cases like NULLs or duplicate rows at the end. Interviewers at companies like intangles care as much about how you handle dirty data as whether your syntax compiles.

Based on what candidates report from intangles interviews, the panel is looking for four things.

Practical SQL depth. You should be comfortable writing multi-table joins, window functions, and CTEs without looking them up. Questions are typically framed around real fleet data scenarios, not textbook examples.

Data intuition. Can you spot a data quality problem before it reaches a dashboard? Interviewers want analysts who think about what can go wrong in a pipeline, not just how to query a clean table.

Business communication. Intangles sells to fleet operations teams, not data engineers. They want analysts who can translate a finding into a plain recommendation a fleet manager will act on, not a statistics lecture.

Python familiarity. You do not need to be a machine learning engineer, but comfort with pandas, basic exploratory data analysis, and writing reusable scripts is expected at mid and senior levels.

Give yourself two to three weeks of focused preparation.

Week 1: SQL and data fundamentals. Practise window functions (RANK, ROW_NUMBER, LAG/LEAD), multi-table joins, and aggregation queries. Use a free SQL practice platform with realistic datasets. Write at least five queries a day and make sure each one handles NULLs correctly.

Week 2: Python and case practice. Review pandas for data cleaning, groupby operations, and handling missing values. Study a publicly available fleet or IoT dataset on Kaggle to practise exploratory data analysis. Prepare a clear walkthrough of a past project using the STAR structure.

Week 3: Company and role context. Read about fleet telematics and how intangles describes its platform. Understand common metrics in fleet management: utilisation, uptime, and fuel efficiency. Prepare a handful of questions for the interviewer about the team's current data stack and the biggest analytical challenges they are solving.

On the day, think aloud during technical questions so the interviewer can follow your reasoning, even if you do not arrive at the perfect answer immediately.

If you want to stay on top of new openings while you prepare, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you.

Writing SQL without handling NULLs. A common mistake is writing GROUP BY or JOIN queries that silently drop or miscount NULL values. Always mention how you handle NULLs, even if the interviewer does not ask.

Giving generic answers to domain-specific questions. If asked about anomaly detection in vehicle data, a generic statistics answer sounds hollow. Tie your answer to the domain: GPS coordinates, sensor drift, device connectivity gaps.

Skipping the business context. Interviewers at intangles connect data work to client outcomes. If you only describe technical steps and never say what decision the analysis supports, the answer falls flat.

Preparing only for technical questions. Candidates report that the final round often includes a discussion about how you have handled ambiguous briefs, disagreements with stakeholders, or projects that did not go as planned. Prepare at least two such stories.

Not asking questions. Arriving with no questions about the role or the team signals low interest. Prepare thoughtful questions about the data infrastructure, team size, or how the analyst role works alongside product and engineering.