Goldman Sachs interview preparation: explain the work behind claims

I would first confirm the period, units and that the operating-cost figure excludes depreciation. EBITDA is 120 − 84 = 36. EBIT is 36 − 6 = 30, assumed operating tax is 30 × 25% = 7.5, and after-tax operating profit is 22.5. Adding back depreciation and subtracting capital expenditure and the working-capital increase gives unlevered free cash flow of 22.5 + 6 − 10 − 8 = 10.5. If working capital instead increases by 14, cash flow falls to 4.5 even though EBITDA is unchanged. I would investigate whether the increase comes from receivables, inventory or payables before describing operating performance as stronger. This is one period of a simplified model, so I would not use it alone to reach a valuation or financing conclusion. The key result is that earnings and cash generation tell different parts of the story.

Make it yours: For banking, explain the bridge and assumptions; for risk, stress cash demands; for operations, reconcile the data feeding the bridge. This is analytical practice, not an investment recommendation.

In a finance class project, our team was about to present a valuation model when I noticed the cash-flow result looked unusually strong. I owned the working-capital schedule. I checked the formulas against our assumptions and found that an increase in receivables had been added to cash rather than subtracted. I corrected the sign, traced the change through all scenarios and asked a teammate to reproduce the bridge independently. We could have left the slide unchanged and mentioned a caveat, but that would have preserved the wrong conclusion. I told the presenter before rehearsal and we replaced the headline with a range. The corrected work changed our recommendation and taught me to validate financial direction, not only whether formulas calculate.

Make it yours: Keep the educational setting clear and prepare the exact sign logic.

During an internship, a daily reconciliation had 38 breaks and a reporting cutoff approaching. I owned the investigation log, not the final release decision. I grouped breaks by cause, traced 24 to reference-data mismatches and sent the supervisor the evidence for correction. I considered prioritizing only the biggest amounts, but that would have missed a recurring source problem. For the remaining items, I recorded the owner, latest evidence and next action rather than marking them resolved. The supervisor approved the documented corrections and carried the unresolved items into the next handoff. We finished with an accurate status report and a clearer queue, which was more useful than a superficially clean total.

Make it yours: A good operations result can be an accurate controlled handoff rather than a claim that every exception disappeared.

In a synthetic receivables project, I was responsible for the stress analysis. The base case showed a comfortable cash buffer, but I noticed the model assumed every customer paid on the same schedule. I grouped customers by concentration and modeled delayed collections for the largest group. I compared that with a uniform-delay scenario and documented why neither was a prediction. The concentrated delay used more cash even when total revenue stayed constant. I presented both cases and identified the input that mattered most: collection timing for the largest accounts. Our team added a concentration sensitivity instead of presenting one favorable base case. I learned to make the uncertainty visible before discussing the result.

Make it yours: Do not turn a classroom scenario into a claim of setting bank limits or preventing a real loss.

For a synthetic transaction service, I owned amount validation. A performance test looked fast, but I found that floating-point handling could change small decimal totals. I built a minimal failing case, proposed decimal-safe representation and added checks for currency and duplicate requests. A teammate wanted to postpone the change until after the demo. I compared the options using correctness and implementation cost, then we agreed to complete the validation first and reduce the demo scope. Thirty-two edge-case tests passed before we returned to throughput work. I learned that a convincing performance number is not useful if the represented amounts are wrong.

Make it yours: Be ready to discuss representation, rounding rules, duplicate handling and what your tests did not establish.