Freight Tiger · Software Engineer
Updated · 2026-10-02

Freight Tiger Software Engineer
Interview Guide

THE 60-SECOND BRIEF

As a Software Engineer at Freight Tiger, you are tasked with building the digital backbone of India’s fragmented logistics landscape. Your work directly impacts how goods move across the country, optimizing complex supply chain networks through innovative software solutions. You will be responsible for developing scalable backend services and data-driven systems that bring transparency and efficiency to a historically manual industry. This role is critical because the platform handles high-stakes logistical data that requires precision, reliability, and speed. You will collaborate with cross-functional teams to translate operational challenges into technical architecture. Whether you are optimizing routing algorithms or improving database performance, your contributions are the engine that keeps Freight Tiger competitive in a fast-evolving market.

This guide is scoped to a Software Engineer candidate at Freight Tiger.

Freight Tiger candidates report 2 rounds over 2-4 weeks. The stages below are what candidates describe, not a published process.

Data Structures & Algorithms (DSA)SQLBackend Development

19 min read

Browse Software Engineer questions

See the practice prompts

19Practice promptsAcross five skill areas

As a Software Engineer at Freight Tiger, you are tasked with building the digital backbone of India’s fragmented logistics landscape. Your work directly impacts how goods move across the country, optimizing complex supply chain networks through innovative software solutions. You will be responsible for developing scalable backend services and data-driven systems that bring transparency and efficiency to a historically manual industry. This role is critical because the platform handles high-stakes logistical data that requires precision, reliability, and speed. You will collaborate with cross-functional teams to translate operational challenges into technical architecture. Whether you are optimizing routing algorithms or improving database performance, your contributions are the engine that keeps Freight Tiger competitive in a fast-evolving market. ##### Tip While the interview process is straightforward in its technical requirements, success at Freight Tiger requires demonstrating that you can apply your skills to real-world logistics problems rather than just memorizing textbook solutions.

01

Technical Screening

reported

Initial assessment of technical capabilities focusing on core engineering fundamentals.

What to demonstrate

  • Initial assessment of technical capabilities focusing on core engineering fundamentals
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Answer aloud and timed: Explain the time complexity of your solution for a given array manipulation problem.
  • Answer aloud and timed: How would you optimize a search operation in a large dataset?
Freight Tiger Software Engineer candidate reports ↗
02

Managerial Assessment

reported

Evaluation of fit for the team and discussion of past projects in context of relevant technologies.

What to demonstrate

  • Evaluation of fit for the team and discussion of past projects in context of relevant technologies
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Answer aloud and timed: Write a function to solve a specific string manipulation challenge.
  • Answer aloud and timed: What are the trade-offs between using a HashMap and a TreeMap in this scenario?
Freight Tiger Software Engineer candidate reports ↗

PracHub editorial advice for the preparation topics above.

01

Master the basics

Do not overlook fundamental SQL concepts. Many candidates focus heavily on algorithms and neglect the database skills that are critical for this role.

02

Be vocal

If you are given a take-home assignment or a live coding problem, document your assumptions and explain your logic. This helps the interviewer understand your thought process even if you run out of time.

03

Prepare for the Managerial Round

Use this time to demonstrate your soft skills and your ability to work within a team. Be ready to discuss your past projects and how you handled technical conflicts or deadlines.

04

Review your resume

Be prepared to answer questions about every bullet point on your resume. If you list a project, be ready to dive deep into the architecture and the challenges you faced.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

16 technical prompts0 include a worked solution

Explain the time complexity of your solution for a given array manipulation problem.

medium
Technical and DSA Proficiency

Explain the time complexity of your solution for a given array manipulation problem.

Approach
  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.
Follow-up
  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

How would you optimize a search operation in a large dataset?

medium
Technical and DSA Proficiency

How would you optimize a search operation in a large dataset?

Approach
  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.
Follow-up
  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Track a rolling failure rate per destination for circuit decisions

easy
sliding windowring buffercircuit 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?

Built from the rounds and topics Freight Tiger candidates report.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the Freight Tiger loop
  • Write out the reported sequence: Technical Screening, Managerial Assessment.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 2 reported rounds, with the weakest marked.

02Work Data Structures & Algorithms (DSA)
  • Spend the session on Data Structures & Algorithms (DSA), which Freight Tiger candidates report being tested on.
  • Write one worked example in Data Structures & Algorithms (DSA) and time yourself on it.

Deliverable: One timed worked example in Data Structures & Algorithms (DSA).

03Work SQL
  • Spend the session on SQL, which Freight Tiger candidates report being tested on.
  • Write one worked example in SQL and time yourself on it.

Deliverable: One timed worked example in SQL.

04Work Backend Development
  • Spend the session on Backend Development, which Freight Tiger candidates report being tested on.
  • Write one worked example in Backend Development and time yourself on it.

Deliverable: One timed worked example in Backend Development.

05Answer out loud: Technical and DSA Proficiency
  • Answer aloud, timed: Explain the time complexity of your solution for a given array manipulation problem.
  • Answer aloud, timed: How would you optimize a search operation in a large dataset?

Deliverable: Spoken answers to 2 reported Technical and DSA Proficiency question(s), under time.

06Answer out loud: SQL and Database Management
  • Answer aloud, timed: Write a query to perform a complex join across three tables.
  • Answer aloud, timed: Explain the difference between inner, left, and full outer joins with a real-world example.

Deliverable: Spoken answers to 2 reported SQL and Database Management question(s), under time.

07Answer out loud: Backend Architecture
  • Answer aloud, timed: How would you design a RESTful API for a logistics tracking service?
  • Answer aloud, timed: What are the key components of a microservices architecture?

Deliverable: Spoken answers to 2 reported Backend Architecture question(s), under time.

Expand any day for tasks and deliverables. Your progress is saved on this device.

Behavioural rounds judge the decision you made and what it cost.

How do you handle edge cases when implementing a sorting algorithm?

medium
Technical and DSA Proficiency

How do you handle edge cases when implementing a sorting algorithm?

Approach
  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.
Follow-up
  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Tell callers you do not own that their integration breaks

medium
deprecationcompatibilitystakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach
  1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
  2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
  3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
  4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
Follow-up
  • How would you detect a consumer that reads the field only during a monthly export?
  • One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?

Reverse your own decision and price the reversal

medium
reversibilitymeasurementmigrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach
  1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
  2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
  3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
  4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.
Follow-up
  • What in that decision was irreversible, and did you know it was irreversible when you made it?
  • How did you tell the people who had already built on top of the original decision?
  • 01

    How do you handle edge cases when implementing a sorting algorithm?

  • 02

    A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

  • 03

    Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

PracHub preparation framework ↗
How long should I prepare for the interviews?

Given the focus on core computer science and SQL, a solid 2-3 weeks of focused practice on coding challenges and database query optimization is typically sufficient.

Freight Tiger Software Engineer candidate reports ↗
What is the biggest differentiator for successful candidates?

The ability to explain the "why" behind your code. Successful candidates don't just solve the problem; they explain why their chosen approach is the most efficient given the constraints.

Freight Tiger Software Engineer candidate reports ↗
Is the culture collaborative?

Yes, the engineering culture is built around solving complex logistical problems as a team. You will be expected to engage in technical discussions and contribute to the broader design of the system.

Freight Tiger Software Engineer candidate reports ↗
What if I don't have experience with logistics?

While domain experience is a plus, it is not a requirement. Focus on demonstrating your technical foundation and your ability to learn the business logic quickly.

Freight Tiger Software Engineer candidate reports ↗
What topics does Freight Tiger test in interviews?

Freight Tiger interviews most often cover Problem Solving, Data Structures & Algorithms (DSA), Engineering Management, API Automation Assignment, and SQL. The exact emphasis depends on the specific role you apply for.

Freight Tiger Software Engineer candidate reports ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.