turno Technical Program Manager Interview: Questions, Experience & Prep (2026)

Turno is an EV commerce platform that helps businesses switch to electric three-wheelers for last-mile delivery. The company has grown quickly in the electric mobility space and currently has 47 open roles, which signals active scaling across product, engineering, and operations.

A Technical Program Manager at Turno sits at the intersection of software, hardware, and business teams. You will drive cross-functional programs in a startup environment, manage ambiguity, and coordinate timelines across vehicle operations, platform engineering, and fleet operator onboarding. This is different from a TPM role at a large tech company: the programs you own directly affect how fleet operators run their businesses, not just internal engineering velocity.

As of July 2026, there are 313 TPM openings tracked across India, with Bangalore leading at 41 openings, followed by Delhi at 14, Pune at 13, Hyderabad at 12, Chennai at 5, and Mumbai at 1. Turno's hiring reflects a broader trend of EV and mobility startups building out their program management function as they scale.

Program and Delivery

1. Walk me through a program you owned end-to-end. How did you track dependencies across multiple engineering and business teams?
2. Turno ships both vehicles and a software platform. How would you manage a program that has hardware and software milestones with different release cadences?
3. Describe a time a critical deadline slipped. What did you do, and what did you learn from it?
4. How do you prioritize competing requests from product, operations, and engineering when resources are tight?

Stakeholder Management

1. Turno works with fleet operators, OEM partners, and internal tech teams. How do you communicate program status to audiences with very different technical backgrounds?
2. Give an example of influencing a team you had no authority over to meet a program goal.
3. How do you handle a situation where two senior stakeholders disagree on scope or priority?

Technical Awareness

1. How comfortable are you reviewing technical designs or architecture diagrams? Walk me through how you would flag a risk in a system design without being the one who built it.
2. Turno's platform involves real-time telemetry from vehicles. What questions would you ask the engineering team when scoping a new telematics feature?

Startup and Growth Context

1. Startups often lack mature processes. How do you introduce structure without slowing teams down?
2. How have you handled a situation where requirements changed significantly mid-program?
3. What metrics would you use to measure the health of a program at a company like Turno, where the product affects both fleet operators and drivers?

Q: Walk me through a program you owned end-to-end. How did you track dependencies across multiple teams?

*Situation:* At my previous company, we were launching a new mobile feature that required changes from three backend teams, a design team, and a third-party payment vendor. The timelines were tight and each team had a different release cycle.

*Task:* I was the sole TPM responsible for getting all five workstreams to a single release date without blocking any one team unnecessarily.

*Action:* I created a shared dependency tracker, ran weekly syncs with each team lead, and caught a two-week delay from the payment vendor four weeks before launch. I worked with the product manager to scope a fallback using an existing payment method so we could still ship on time. I kept stakeholders updated with a short weekly status note rather than scheduling extra meetings.

*Result:* We launched on the planned date with the fallback live. The vendor integration followed three weeks later in a separate release. The product lead said the early risk flag was the reason we avoided a full delay.

---

Q: Give an example of influencing a team you had no authority over to meet a program goal.

*Situation:* I was running a program that depended on the data engineering team completing a pipeline. They were under-resourced and had deprioritised our request.

*Task:* I needed two engineers from their team to commit roughly two weeks of effort, without having any reporting authority over them.

*Action:* I met with the data engineering manager to understand their constraints. I reframed our request in terms of their team's goals, showing that the pipeline would also unblock a reporting feature they had been asked to build. I offered to write the initial data spec so their engineers could start faster. I also aligned both VPs in writing on the priority, which gave the manager the cover to shift resources.

*Result:* Two engineers were assigned within a week. The pipeline was completed a day ahead of schedule, and the data engineering team later reused the spec format I wrote for two other projects.

---

Q: Startups often lack mature processes. How do you introduce structure without slowing teams down?

*Situation:* I joined a fast-growing startup where engineering and product were tracking work across three different tools with no consistent format.

*Task:* I was asked to bring visibility into program status without adding bureaucratic overhead.

*Action:* I observed two sprint cycles before proposing anything. I identified the three pain points teams mentioned most: not knowing who owned a decision, not knowing when something was blocked, and not getting enough notice before a demo. I introduced a single shared weekly update (a Slack post, not a meeting) and a simple RACI for major decisions. I kept everything in tools the teams already used.

*Result:* Within six weeks, the engineering lead told me the number of surprise escalations had dropped noticeably. Avoiding new meetings and new tools kept adoption high.

STAR for behavioural questions (Situation, Task, Action, Result): Most TPM interviews at companies like Turno will include three to four behavioural questions. Keep your Situation and Task brief (two to three sentences together), spend the most time on Action, and close with a concrete Result. If you do not have a hard number, describe what specifically changed rather than claiming vague success.

Simplified prioritisation framework for scoping questions: If asked how you would prioritise a program or feature, structure your answer as: clarify the goal, identify who is affected, list the constraints (time, resources, dependencies), propose two or three options, and recommend one with clear reasoning. This shows structured thinking without overcomplicating a straightforward question.

Risk framing for technical questions: When asked about technical risks, use this pattern: 'Here is what I understand the system does, here is the assumption I am questioning, here is how I would validate it, and here is the fallback if the assumption is wrong.' This shows technical curiosity without overclaiming expertise you may not have.

Startup framing for process questions: Turno is a growth-stage company. When answering about process or structure, frame your answer around speed and reversibility: 'I would start small, check if it is working, and expand only if the team finds it useful.' Answers that sound designed for a large enterprise tend to land poorly in this context.

Turno interviewers are typically looking for a specific mix of qualities in a TPM, based on what candidates report from interviews at similar EV and mobility startups.

Comfort with ambiguity. Turno operates in a space where hardware timelines, regulatory changes, and market conditions shift frequently. Interviewers want to see that you have navigated unclear requirements before and that you have a method for creating clarity rather than waiting for someone to hand it to you.

Cross-functional credibility. The role involves working with vehicle operations teams, software engineers, and business partners. You should be able to show that you have built trust with non-technical stakeholders and that engineers see you as useful rather than as overhead.

Bias for outcomes, not process. Candidates who describe implementing a process for its own sake tend to not do well. What works better: describing how a specific intervention you made changed a measurable outcome, even if you cannot attach a precise number to it.

Some technical grounding. You do not need to be a former software engineer, but you should be comfortable reading a system diagram, asking meaningful questions in a tech review, and identifying risks in a technical plan. Questions about telematics, API integrations, or data pipelines are fair game given Turno's product.

Phase 1: Understand Turno's business

Read everything publicly available about Turno's platform, fleet management tools, and operator-facing features. Understand what makes their EV offering different from competitors. Think about what programs a TPM there would actually own: onboarding new fleet operators, launching new vehicle models, or scaling the charging and service network.

Phase 2: Build your story bank

Write out eight to ten stories from your past experience using the STAR format. Make sure you have at least one story covering each of: a program that was delayed, a stakeholder conflict you resolved, a time you influenced without authority, and a time you introduced process in a fast-moving team. Map each story to the questions in this guide before the interview so you are not searching for examples under pressure.

Phase 3: Practice out loud and sharpen technical basics

Practice answering questions out loud, not just in your head. Time yourself: a strong STAR answer should take two to three minutes. Review the basics of how telemetry or IoT data flows through a system, since Turno's vehicles generate real-time data. You do not need to be an expert, but you should be able to ask smart questions about data latency, storage, and alerting.

Candidates report that Turno's process typically includes an initial HR screening, one or two functional interviews, and a final round that may include a case study or live scenario. Prepare a short program pitch: describe a program you would run at Turno in your first few months, in three to five minutes.

Treating it like a large-enterprise TPM interview. Answers that reference elaborate OKR tracking frameworks, six-sigma processes, or multi-quarter roadmap ceremonies often land poorly at a company like Turno. Ground your answers in what works in a fast-moving, growth-stage environment.

Vague results. Saying 'the project was successful' without explaining what success looked like is a red flag. If you do not have a hard metric, be specific in other ways: 'We shipped on time, the team flagged fewer blockers the next quarter, and the customer success team reported fewer escalations.' Specific observations beat vague claims every time.

Not asking about the actual programs. Many candidates forget to ask what programs the TPM would own in the first few months. This question signals that you think in terms of real work, not job titles, and it gives you useful information for the rest of the conversation.

Overclaiming technical depth. If you are not an engineer, do not pretend to be. Interviewers at technical companies respect 'I would ask the engineering lead to walk me through the architecture and flag anything that looks risky based on my experience' far more than an incorrect technical claim.

Ignoring the EV and logistics context. Generic TPM answers that could apply to any software company miss the point at Turno. Tie your answers to fleet operations, hardware-software integration, or operator experience wherever you can.