Target Software Engineer Interview Questions
Software engineers at Target write the logic that lets a store act as a shop, a pickup point and a small shipping centre in the same building. Prepare to design out loud how orders are grouped for picking, how a parcel gets the right box, how a ready time is promised, and how returns come back through the store, with clear stories about scope and shared code. What to show here: practical design that saves steps for team members and waiting for guests. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Target hires, in its own words, and its questions for every job →
1. Tell me about a time you wrote code that served two groups with different needs, such as customers on an app and staff on a work tool, and how you stopped one from hurting the other.
- Describe the shared code and the two groups.
- Explain where their needs pulled apart.
- Show the design choice you made.
- Share the result and what you would do again.
“I worked on an order details module used by the customer app and by a staff tool. The app team wanted fewer fields for speed. Staff needed every field, including storage notes. The first plan was one response with flags for each screen, and it became a mess of conditions. I proposed a shared core that both used, with a thin layer on top for each group, owned by that group. A change for the app could no longer break the staff tool. It took longer at the start, but after that your result.”
Weak answers build for the louder group and let the other find out when something breaks.
2. Describe a time you found out late that a feature would not be ready before a seasonal code freeze. What did you do with the time left?
- Describe the feature and the freeze date.
- Explain how you realised it would not fit.
- Show what you proposed and to whom.
- Share what shipped and the lesson.
“We were building a new way to split large orders into several parcels, and a code freeze was set before the busy season. Ten days before, testing showed wrong splits for heavy items. I told my lead the same afternoon. I proposed shipping only the part that was solid, splitting by item count, behind a switch that was off by default, and leaving weight rules for after the season. We turned it on for a few locations and watched. The result was your result. I learned to test the hardest case first, not last.”
Weak answers push untested work in just before the freeze, or keep the bad news to themselves until the last day.
3. A store has many online orders to pick this hour. Design how you would group them so a team member collects items for several orders in one walk through the store.
- Model the store as zones with a walking order.
- Group orders by due time and by zones they touch.
- Limit each batch by what a cart can carry.
- Keep items for different orders apart and handle items not found.
“I would model the store as zones in a walking order, not as exact positions. Orders due soonest are picked first, so I sort by due time and take a window of orders. Within that window I group orders that share zones, up to what one cart can hold. Chilled and frozen items go in a late batch so they stay cold. The pick list is sorted by zone order, and each item is tagged with the bag it belongs to. If an item is not found, only that line is flagged and the walk continues. A simple greedy grouping is good enough.”
Weak answers pick one order at a time, or try to compute a perfect route and miss the pickup deadlines.
4. A guest starts a return in the app and hands the item to a team member at the store or at the car. Design that flow from the first tap to the refund.
- Define the states from requested to refunded.
- Decide what the guest shows and what the team member scans.
- Trigger the refund once, on a confirmed handover.
- Cover wrong item, damaged item and no-show.
“The return has clear states: requested, approved, handed over, checked and refunded. In the app the guest picks the order line and a reason, and gets a code. At handover the team member scans the code and then the item, so the system knows the right item came back. That scan triggers the refund, with the return id as a key so a retry cannot refund twice. If the item is wrong or damaged, the team member chooses a reason and the return goes to review. Returns that are never handed over expire after a set period.”
Weak answers refund at the first tap before any item is handed over, or have no protection against a double refund.
5. A store is about to ship an order with a lamp, two cushions and a mug. How would your code choose the box, or boxes, to pack them in?
- Gather size, weight and fragility for each item.
- Name the problem and why an exact answer is costly.
- Use a simple rule such as largest item first.
- Add limits and give the packer a way to override.
“This is a form of bin packing, which is too slow to solve exactly for every order. So I would use a rule that is quick and usually good. Sort items from largest to smallest, then place each in the first box where it fits by volume and weight, allowing some room for padding. Fragile items like the mug get extra space and are not placed under heavy items. The code compares one larger box with two smaller ones on shipping cost. Item sizes in the data are often wrong, so the packer can override the choice, and that feedback is recorded.”
Weak answers add up volumes and pick the box with that volume, ignoring shape, weight and fragile items.
6. When a guest places a pickup order, the app promises a time it will be ready. How would you calculate that promise so it is quick but rarely broken?
- List the inputs: order size, orders already waiting, staff on shift, store hours.
- Start with a simple estimate from past data.
- Add a safety margin that grows with uncertainty.
- Compare promises with real times and adjust.
“I would start from what the store can do: how many orders are already waiting and how many team members are picking this hour. From past data I can estimate picking time for an order of this size in this store. The promise is that estimate plus a margin, and the margin grows when the store is busy or the order has items that are often hard to find. I would rather promise a slightly later time and beat it. Every order then gives feedback, promised against actual, so the estimate for each store improves over time.”
Weak answers promise one fixed time for every store and every order, whatever is happening in the building.
7. Why do you want to write software that turns a store into a pickup point and a shipping centre as well as a shop, and why Target?
- Say what you enjoy about this kind of problem.
- Tie it to stores with several jobs.
- Link it to your own work.
- Say what you want to learn.
“I enjoy problems where software meets physical limits. A box has a size, a cart holds only so much, and a team member can walk only so fast. At Target the store near a guest's home does the work a distant warehouse might do elsewhere, which makes the logic richer: the same shelf serves a guest in the aisle and an order for a guest far away. I have worked on your project, where rules met real limits, and that was my favourite part. I want to learn how these systems are tested against a real store day.”
Weak answers speak about coding in general and show no curiosity about how a store works.
8. A store closed early because of a storm, but online orders kept being sent to it for shipping all afternoon. What should have stopped this, and what do you do now?
- Stop new orders reaching the closed store.
- Move or reschedule the orders already sent there.
- Tell guests whose delivery time changed.
- Fix the gap so a closure stops orders at once.
“Right now I would mark the store as unable to ship, so nothing new is sent there. Then I would list the orders already assigned, send them to other stores or the warehouse where stock allows, and let guests know if their delivery date has moved. After that I would look at the design. Order assignment probably read the store's planned hours, not its real state. I would add a status that store leaders or operations can change in one step, and have assignment check it every time. I would also add an alert when a store accepts orders but picks none.”
Weak answers only fix the data for this one store, or leave guests to discover the delay themselves.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.