Role-specific interview practice tracks

Suggested practice time: 45 minutes, separate from reading.

Interview principles are shared, but convincing evidence differs by role. This guide identifies evidence types and realistic exercises rather than only listing questions.

1. Software, data, and technical roles

Show correctness, clear reasoning, decision quality, and work under constraints.

Prepare:

• A project with a genuine technical trade-off
• A diagnosed bug or incident
• A quality-versus-speed decision
• Product, design, or operations collaboration
• Code feedback or evidence that changed your view

For live problems, clarify inputs, outputs, edge cases, and constraints. Start simple and correct, then optimize. For system design, cover functional and nonfunctional needs, scale estimates, components, failures, and monitoring.

Exercise: Explain a real feature's architecture, two trade-offs, and one failure mode in 15 minutes.

Software and data need distinct practice. Code correctness, tests, and architecture differ from metric definitions, data quality, analysis, and inference limits. Architecture does not substitute for SQL. Match the announced format; senior roles should also cover scale and organizational decisions.

Practice questions:

• Describe a fault whose root cause differed from the initial hypothesis.
• When did you prefer a simpler solution over a more scalable one?
• How did you preserve quality under time pressure?
• Which technical feedback changed your mind?
• What would fail first at ten times the scale?

2. Product, design, and user research

Go beyond ideal process descriptions. Show judgment under uncertainty:

• How was the actual problem separated from stakeholder requests?
• Where did user and business needs conflict?
• Which option was rejected, and why?
• Which behavior or metric assessed the outcome?
• What proved wrong after launch?

Product exercise: Analyze a falling metric with a hypothesis tree.

Design exercise: Critique a familiar flow after defining user and goal.

Research exercise: Correct a leading question and connect findings to decisions.

Practice questions:

• When did data contradict a key stakeholder?
• Which initial problem framing was wrong, and how did you discover it?
• What did you deliberately not build?
• How did you weigh user and business needs?
• Which assumption failed after release?

3. Sales, marketing, and growth

"Increased sales" alone is insufficient. Explain segment, contribution, baseline, and result cost.

Prepare:

• Needs discovery and hearing "no"
• Objection handling
• A failed experiment
• Budget allocation
• Sales/marketing collaboration
• Funnel quality rather than lead volume alone

In role-play, discover problem, impact, decision-maker, timing, and barriers before pitching. In growth cases, set guardrail metrics so one improvement does not damage another area.

Practice questions:

• Analyze a lost deal.
• When did you turn down an unsuitable customer?
• Which channel grew without producing real value?
• How did you split limited budget between opportunities?
• How do you handle price objections before offering discounts?

4. Support, customer success, and operations

Empathy without resolution, or resolution without communication, is insufficient.

Prepare:

• A dissatisfied customer and respectful boundaries
• Several urgent requests
• Recurring feedback converted into product change
• Documentation or automation
• An operational mistake and prevention

Exercise: Prioritize an outage for a large customer, a manager's simple request, and a recurring multi-user bug. Explain order, communication, and what would change priorities.

Practice questions:

• How did you handle an angry customer who was mistaken?
• Which recurring issue led to process improvement?
• What was your communication sequence during an outage?
• When did you reject a customer request?
• How do you assess response quality and speed together?

5. Management and leadership

Show improved systems, decisions, and people rather than personal execution alone.

Prepare:

• A difficult hiring or performance decision
• Developing a teammate
• Cross-team conflict
• Prioritization with limited resources
• A wrong decision and correction
• A result sustained after your departure

Strong management answers include organizational context, options, criteria, alignment, and second-order effects.

Practice questions:

• Which difficult performance decision did you delay?
• How did you develop someone with a different working style?
• Which decision had unintended negative effects?
• How did you handle conflicting team goals?
• Which system continued without your presence?

Workshops with inputs, outputs, and criteria

All scenarios and data below are hypothetical educational material. Select one matching the advertisement and spend 30–45 minutes solving, presenting, and reviewing it. Examples show one defensible approach, not the only answer. Actual company timing and tool policies take priority.

Software: merging intervals

Input: [9, 11], [10, 12], [13, 14], possibly unsorted. Merge overlapping or touching intervals. Empty input is allowed; reject an interval ending before it starts.

Expected output: Function or pseudocode, tests, and time/memory explanation. The example produces [9, 12] and [13, 14].

Example approach: Validate, sort by start, then compare each interval with the last output. If its start is no greater than the previous end, extend that end to the larger end; otherwise append it. Sorting is typically O(n log n) and worst-case output space O(n); extra sort space depends on implementation.

Criteria: Correct sample output; tests for empty, nested, touching, and invalid input; explanation of merge condition and complexity. Naming the algorithm alone is insufficient. For system design, instead design scale, failures, and trade-offs for a specific need; these are different assessment formats.

Data: rates and inference limits

Input: In one week, using the same user definition, channel A has 1,000 visitors, 200 signups, and 40 purchases; B has 500, 150, and 15. Costs and previous weeks are unavailable. Which channel has lower signup-to-purchase conversion?

Expected output: Rates table, denominator definitions, one limited conclusion, and two follow-up data questions.

Example approach: A is 40/200 = 20%; B is 15/150 = 10%. B is lower for this stage and window. Visitor-to-purchase rates are 4% and 3%. These data do not establish profit, cause, or a change's effect. Check purchase definitions, deduplication, equal conversion windows, and channel costs.

Criteria: Correct numerators and denominators; counts distinguished from percentages; no causal claim from association; purchase lag and data quality discussed. For SQL roles, derive the same output from events and show joins do not multiply users.

Product: funnel decline and experiment selection

Input: Of 1,000 people seeing the start page, 400 begin and 100 finish. Improve completion with one week's capacity; the cause is unknown.

Expected output: Two hypotheses, an investigation, and an experiment with success and guardrail metrics.

Example approach: Start rate is 40%; completion among starters is 25%. Verify event definitions and device segments before building. Form errors and unclear document requirements are hypotheses. If evidence points to the form, test clearer errors; measure valid completions with incorrect-data submissions and support requests as guardrails.

Criteria: Correct stage calculation; hypotheses separate from facts; evidence-based prioritization; duration, comparison method, and sample limits defined. The largest drop does not prove the cause.

Design: improving a constrained flow

Input: A three-step form shows errors only after final submission, without identifying the field. Server validation must remain; one day is available for an initial design.

Expected output: Before/after frames, error state, and a user-test plan. Attractive visuals alone are insufficient.

Example approach: Add an error summary linked to fields and field-level messages, preserve correct inputs, and specify keyboard navigation and error announcements. Observe several users finding and correcting errors and record failed attempts.

Criteria: Clear user and problem; success, error, and recovery states; accessibility built into decisions; findings limited to the sample rather than generalized to guaranteed product-wide improvement.

Research: correcting a leading question

Input: A stakeholder wants to ask, "Do you like our new, easy feature?" to decide whether to build it.

Expected output: Neutral question, follow-up, and consent-based evidence recording.

Example approach: "The last time you did this task, where did you start and where did you stop?" Then: "Can you show that step with an example?" Separate observed behavior, quotes, and researcher interpretation. Obtain recording consent and avoid unnecessary information.

Criteria: Remove leading adjectives; examine actual experience instead of hypothetical liking; connect findings to decisions; do not portray a small sample as conclusive for all users.

Sales: price objection without immediate discount

Input: A customer says, "Too expensive." Budget, problem cost, and decision-maker are unknown, and you cannot authorize discounts.

Expected output: Two-minute opening, three discovery questions, and an agreed next step.

Example approach: "What alternative or budget are you comparing this with?" Ask about the current problem's cost and decision-makers. If need and fit are confirmed, propose reviewing a narrower scope. Promise neither discounts nor guaranteed outcomes.

Criteria: Hear and restate the objection; gather information before pitching; respect authority and limits; next step has an owner and time. Pressuring an unsuitable customer to buy earns no credit.

Marketing and growth: budget allocation

Input: A spends 10 million toman for 50 leads and 10 customers. B spends the same for 100 leads and five customers. Measurement windows match; retention and margin are unknown.

Expected output: Cost per lead/customer, a test-budget recommendation, and conditions that change it.

Example approach: A costs 200,000 toman per lead and one million per customer; B costs 100,000 and two million. A acquires customers more cheaply in this limited sample. Test gradual increases rather than transferring the whole budget immediately. Examine customer quality, attribution, retention, and channel capacity.

Criteria: Correct arithmetic; lead volume distinguished from customer value; no assumption that returns remain constant at scale; spending ceiling and experiment stopping rule defined.

Support, success, and operations: crisis prioritization

Input: Payments fail for several customers, a manager wants a nonurgent report, and a user asks a settings question. Financial failures are possible, but outage scope is unknown.

Expected output: Action order, stakeholder messages, and update timing. Customer size alone must not decide priority.

Example approach: Establish scope and financial risk, then escalate through the incident process to a technical owner. Tell users investigation is underway and give a next-update time, without an unconfirmed resolution promise. Reschedule the report with an explanation and route the settings question to guidance or a colleague. Security evidence changes severity and escalation.

Criteria: Impact, urgency, and risk drive priority; clear incident ownership; no sensitive disclosures; regular communication and reprioritization criteria; one prevention action after resolution.

Management: performance and capacity

Input: A teammate missed two deliveries. Causes are unknown, prior expectations were vague, and the project deadline is near.

Expected output: Private conversation plan, immediate capacity decision, and two-week follow-up criteria.

Example approach: Review the two deliveries and effects without personality labels. Ask for their perspective and blockers, agree outputs and dates in writing, and specify support. Adjust scope or workload for the immediate deadline. Track progress at clear checkpoints over two weeks. Follow organizational performance policy without guessing personal causes.

Criteria: Clear expectations, evidence, and support; urgency does not replace fairness; confidentiality maintained; team effects and next decision date considered.

Create a workshop for another role

Extract these from the advertisement:

Use this for finance, HR, content, legal, education, procurement, or other work.

Specialist readiness criteria

• At least one exercise matching the actual format
• Three stories about this role's decisions
• Two common trade-offs explained
• Success metrics and gaming risks understood
• Problems and effects demonstrated beyond naming tools

Record input, output, and evidence in your own file. Fluent explanation does not compensate for incorrect output. Reuse the workshop with timing and probes in the full mock interview. These exercises review readiness; they do not replace learning the profession or the employer's specific criteria.

Related guides

• Portfolios, cases, and take-home work
• Full mock interview and feedback