letstransport Frontend Engineer Interview: Questions, Experience & Prep (2026)

LetsTransport is a B2B last-mile logistics platform connecting businesses with trucks and delivery vehicles across Indian cities. Frontend Engineers here build fleet management dashboards, client-facing order portals, and driver interfaces that must work on low-end Android devices over patchy mobile data. As of July 2026, knok jobradar tracked 3 open Frontend Engineer roles at LetsTransport and 405 such roles across India. Bangalore leads with 102 openings, followed by Delhi with 36.

Salary ranges reported in the market for Frontend Engineers (mid-2026):

Candidates report a process that typically includes a recruiter screening call, a React and JavaScript coding round, and a system design or product discussion. The exact format varies by team and seniority.

Questions at logistics-focused startups like LetsTransport tend to blend core React knowledge with real-world product thinking. Candidates report the following types of questions coming up most often.

1. Walk us through a complex UI component you built from scratch. What design and architecture decisions did you make?
2. How would you optimise a React application for slow mobile connections and budget Android devices that LetsTransport's driver users rely on?
3. Real-time fleet tracking is central to LetsTransport. How would you build a live vehicle location map in a web app using WebSockets or server-sent events?
4. Explain the difference between Redux, Zustand, and React Context. When would you choose each for a logistics dashboard?
5. How do you handle API failures in the UI so that drivers and clients see helpful messages rather than a broken screen?
6. Describe how you would build a responsive order-management table with filtering, sorting, and bulk actions for an operations team.
7. Have you contributed to a component library or design system? How did you maintain consistency and allow other engineers to contribute without breaking existing components?
8. How would you implement infinite scroll or cursor-based pagination for a list of thousands of delivery orders without hurting performance?
9. LetsTransport serves both English-speaking clients and regional-language drivers. How would you approach internationalisation in a React app?
10. Describe your approach to accessibility. Have you built forms or flows for users with limited digital experience?
11. Tell us about a time you disagreed with a product decision on the UI. What was your reasoning and what was the outcome?
12. What frontend performance metrics do you track, and how have you measured and improved them in a past project?

Q: How would you optimise a React app for slow connections and low-end devices?

*Situation:* At my previous company, we had a delivery dashboard that drivers opened on their phones over patchy mobile data. Page load was very slow and drivers would often give up before the order list appeared.

*Task:* I was asked to reduce the initial load time and make the app usable on budget Android phones.

*Action:* I audited the bundle with source-map-explorer and found large chart libraries loading on driver-facing pages that had no charts at all. I code-split those with React.lazy and Suspense, replaced heavy PNG images with WebP, added a service worker for offline caching of static assets, and switched from polling to a WebSocket feed to cut unnecessary re-fetches.

*Result:* The app became noticeably faster on the same devices. The support team reported far fewer complaints about the driver app not loading. I cannot share precise metrics, but the product manager confirmed the improvement was clear in driver feedback.

---

Q: Tell us about a time you disagreed with a product decision on the UI.

*Situation:* A product manager wanted a confirmation modal with seven required fields that drivers had to fill before accepting a pickup. Drivers typically do this on the road, in a hurry, on a small screen.

*Task:* I needed to ship the feature on time but felt strongly the UX would hurt adoption and frustrate drivers.

*Action:* I put together a quick walkthrough showing how the flow felt on a small-screen phone with one hand. I proposed keeping only two required fields in the modal and moving the rest to a secondary screen that could be completed later. I backed this with driver interview notes from our UX researcher.

*Result:* The PM agreed to a revised version with three fields. The feature shipped and was well received by the ops team. The exercise also set a norm of involving engineering earlier in flow design.

---

Q: Describe how you built a shared component library for your team.

*Situation:* Our frontend team of five engineers was duplicating button, input, and card components across three internal tools. Every tool looked slightly different and a bug fix in one did not carry over to the others.

*Task:* I volunteered to lead the component library effort alongside my regular feature work.

*Action:* I set up a Storybook instance, defined a token system for colours and spacing using shared CSS variables, and ran a focused sprint to migrate the most-used components. I wrote contribution guidelines so other engineers could add to the library without breaking existing components, and set up visual regression tests with Chromatic.

*Result:* Within two months the three tools looked consistent and new features built on shared components took less time to ship. The library has grown and is now used across the product organisation.

Use STAR (Situation, Task, Action, Result) for behavioural questions and a 'clarify then design' approach for technical or architecture questions.

For behavioural questions: Open with context in one or two sentences (Situation). State what *you* were personally responsible for, not what the team was asked to do (Task). Spend most of your answer on what you specifically did (Action). Close with a concrete outcome, even if qualitative (Result). Avoid vague endings like 'it went well' or 'the team was happy.'

For technical or design questions: Start by clarifying scope. Ask whether the solution is mobile-first or desktop-first, what the expected data volume is, and whether offline support is needed. These are directly relevant to LetsTransport's product context. Then walk through your thinking out loud. Interviewers typically care more about your reasoning and trade-off awareness than about landing on one specific answer.

For performance questions: Lead with 'measure before optimising.' Name the diagnostic tool you would use first (Lighthouse, Chrome DevTools, source-map-explorer) before listing solutions. This signals engineering maturity rather than pattern-matching.

For conflict or feedback questions: Focus on how you communicated, not on how you were right. Frame the other person charitably. Interviewers want evidence that you can work constructively with a PM or designer even when you disagree.

LetsTransport is a product-led logistics company where Frontend Engineers work closely with operations and product teams. Based on publicly available information and what candidates report from similar-stage Indian startups, interviewers typically look for these qualities.

Product empathy over pure coding skill. The primary users are truck drivers and logistics coordinators, not tech-savvy consumers. Engineers who can articulate why UX decisions matter for non-technical, often first-time smartphone users tend to stand out from candidates who focus only on technical correctness.

React depth with real trade-offs. You are expected to know hooks, state management, and rendering performance well. More importantly, you should explain why you would choose one approach over another in a given context, not just define terms from documentation.

Comfort with operational constraints. Low-bandwidth environments, budget devices, and real-time data updates are recurring themes at logistics companies. Answers that acknowledge these constraints and propose suited solutions are valued above generic best-practice answers.

Ownership and self-direction. LetsTransport is a fast-moving startup. Candidates who show examples of identifying problems on their own, proposing solutions, and following through without being directed tend to do well.

Clear communication. Interviewers want to see you think out loud, ask clarifying questions before diving in, and explain your reasoning in plain language. Silent coding without narration is a common reason candidates do not move forward.

Structure your preparation in phases, moving from core technical skills to company-specific research.

Phase 1: Core React and JavaScript
Review React hooks (useState, useEffect, useCallback, useMemo, useRef) and understand when each one prevents unnecessary re-renders. Practise building small components from scratch rather than only reading documentation. Review JavaScript async patterns, closures, and event delegation.

Phase 2: Performance and real-time patterns
Practise profiling a React app using Chrome DevTools and Lighthouse. Review code-splitting with React.lazy, image optimisation, and service worker basics. Study WebSockets and server-sent events for real-time use cases, which are directly relevant to fleet tracking at LetsTransport.

Phase 3: Company and product research
Use LetsTransport's website and any publicly available product content to understand their core user flows: the driver app, the client dashboard, and the operations portal. Think about the frontend challenges behind each screen and be ready to discuss them. Prepare genuine questions about the team's tech stack and the problems they are currently solving.

Phase 4: Behavioural preparation
Map several work experiences to the STAR format. Choose examples that show ownership, conflict resolution, and measurable improvement. Rehearse them out loud so you do not ramble during the actual interview.

While you prepare, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so new openings at LetsTransport and similar companies do not slip past you.

Jumping into code before clarifying the problem. Many candidates start coding immediately when given a broad question like 'build a tracking screen.' Spending a minute asking about user type, device target, data volume, and offline requirements shows product maturity and is specifically valued at a logistics company like LetsTransport.

Generic React answers without context. Saying 'I use Redux for state management' without explaining when or why sounds like every other candidate. Relate your answer to real scenarios, ideally from products with high data volume or operational complexity similar to LetsTransport's.

Listing performance fixes without explaining the symptom. Naming optimisations like lazy loading and memoisation without connecting each to a specific problem signals you are reciting a checklist. Always start with 'the symptom was X, so I used Y because...'

Underestimating behavioural rounds. Startups at LetsTransport's stage care about ownership and culture fit. Candidates who prepare only technical topics often stumble on questions about conflict, feedback, or failure. Prepare at least two stories where things did not go as planned and you had to adapt.

Vague results in STAR answers. Ending with 'the team was happy' or 'the project was a success' is weak. Even qualitative outcomes such as fewer support tickets, faster driver onboarding, or a design system adopted across the product team are far more convincing.

Not preparing any questions for the interviewer. Interviewers typically leave time for your questions. Candidates who have nothing to ask signal low interest in the role. Prepare genuine questions about the team's current frontend challenges, the deployment workflow, or how product and engineering collaborate on driver-facing features.