Hedges Outperforming Their Trades
Reported by candidates from Wolverine Trading's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Wolverine Trading put this one in front of candidates in August 2026, and the catch isn't speed, it's the missing rows. A plain join drops every trade with no hedge, and those are exactly the trades where a negative trade PnL could beat a hedge of 0. It's a SQL question on two small tables, so there's no brute force to worry about. It's a LEFT JOIN plus NULL handling. If you blank during the live OA, StealthCoder runs invisibly on your desktop and gives you the query, but you should be able to write this one yourself.
The problem
Two tables describe option trades and their optional hedges. Each row in wolve_trades contains a trade's profit and loss, and a matching row in wolve_hedges contains the hedge profit and loss. Return the trade_id values for trades whose hedge PnL is strictly greater than the trade PnL. If a trade has no hedge row or its hedge_pnl is NULL, use 0 as its hedge PnL. The result must contain one column named Trade_id. Row order does not matter. Tables wolve_trades: trade_id PK (Integer), symbol (Text), trade_qty (Integer), trade_pnl (Integer), option_type (Text) wolve_hedges: trade_id PK (Integer), hedge_pnl (Integer) Constraints wolve_trades.trade_id is unique. For this exercise, assume each trade has at most one matching row in wolve_hedges, identified by the same trade_id. Every hedge row references an existing trade. For this exercise, assume trade_pnl is never NULL, while hedge_pnl may be NULL.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The pattern is a LEFT JOIN from wolve_trades to wolve_hedges on trade_id, then a filter comparing COALESCE(h.hedge_pnl, 0) to t.trade_pnl. Use strictly greater than, not greater than or equal. The common pitfall is an INNER JOIN, which silently removes trades with no hedge row. A trade with trade_pnl of -50 and no hedge should be returned, because 0 is greater than -50. The second pitfall is putting the hedge_pnl condition in the WHERE clause without COALESCE, because comparisons with NULL evaluate to unknown and the row gets dropped. Alias the output column as Trade_id exactly, since the spec names it. No GROUP BY or DISTINCT is needed, because trade_id is unique and each trade has at most one hedge. StealthCoder is your hedge if the syntax slips under pressure in the live OA.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Hedges Outperforming Their Trades cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Wolverine Trading's OA.
Wolverine Trading reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Hedges Outperforming Their Trades FAQ
What's the trick in the Wolverine Trading hedges question?+
Use a LEFT JOIN, not an INNER JOIN, and wrap hedge_pnl in COALESCE(hedge_pnl, 0). Trades with no hedge row or a NULL hedge both count as 0. Then filter where that value is strictly greater than trade_pnl. That's the whole question.
Why does an INNER JOIN give the wrong answer here?+
An INNER JOIN only keeps trades that have a hedge row. Trades with no hedge must be treated as hedge PnL of 0, and any with negative trade_pnl should qualify. Dropping them means missing rows in your output, which fails the hidden test cases.
Do I need GROUP BY or DISTINCT?+
No. trade_id is unique in wolve_trades, and each trade has at most one hedge row. A LEFT JOIN on trade_id can't create duplicates under those constraints, so adding DISTINCT just adds noise. Keep the query simple.
How should I name the output column?+
The spec says one column named Trade_id. Select t.trade_id AS Trade_id. Row order doesn't matter, so skip ORDER BY. Naming mistakes are an easy way to fail a correct query, so match the capitalization given in the problem.
How do I prepare for this in 48 hours?+
Rehearse LEFT JOIN with COALESCE and the difference between filtering in ON versus WHERE. Write this query from scratch twice and test it by hand with three cases: a hedge row, a NULL hedge, and a missing hedge row. That covers nearly everything this question tests.