Quantitative Analyst Interview Preparation Guide

According to Glassdoor data, quantitative analyst interviews average 3–4 rounds and rank among the most technically demanding in finance, with candidates reporting difficulty ratings above 3.5 out of 5 [12].

Key Takeaways

• Quant interviews test three distinct skill layers: stochastic calculus and probability theory, programming fluency (Python/C++), and the ability to translate a portfolio manager's vague question into a tractable mathematical model [6].
• Behavioral questions probe how you handled model failures, deadline-driven deliverables, and cross-desk collaboration — not generic teamwork scenarios. Prepare STAR answers anchored to specific Greeks, P&L attribution, or backtesting results [11].
• Brainteasers and live coding aren't hazing — they're proxies for on-the-job reasoning. Interviewers watch your problem decomposition process, not just the final answer. Narrate your thinking out loud, state assumptions explicitly, and bound your estimates before computing [12].
• Asking sharp questions about the desk's tech stack, model governance process, and alpha research pipeline signals you've done real diligence — and separates you from candidates who only studied textbook Greeks [4].
• Your resume should quantify model impact: Sharpe ratio improvements, VaR reduction percentages, latency benchmarks, or AUM covered. A well-structured resume reinforces every answer you give in the interview [10].

What Behavioral Questions Are Asked in Quantitative Analyst Interviews?

Behavioral questions in quant interviews aren't soft — they're designed to surface how you operate under the specific pressures of a trading floor or research desk. Interviewers want evidence that you've shipped models into production, navigated ambiguity in financial data, and communicated quantitative findings to non-technical stakeholders like portfolio managers or risk officers [12].

1. "Describe a time your model produced unexpected results in production."

What they're probing: Your debugging workflow when a pricing model, risk engine, or signal generator behaves anomalously after deployment — not during backtesting.

What they're evaluating: Systematic root-cause analysis, ability to distinguish data pipeline issues from model specification errors, and judgment about when to pull a model offline versus apply a patch.

STAR framework: Situation — specify the model type (e.g., a mean-reversion signal on equity pairs, a Monte Carlo VaR engine). Task — the anomaly (e.g., P&L attribution showed the model was generating phantom alpha from a look-ahead bias in the data feed). Action — walk through your diagnostic steps: checking input data timestamps, reviewing feature engineering code, running the model against a known-clean historical window. Result — quantify the fix's impact (e.g., "Corrected the timestamp alignment, which eliminated $2.3M in overstated monthly P&L and restored the signal's live Sharpe from 0.4 to 1.1") [11].

2. "Tell me about a time you had to explain a complex quantitative concept to a non-technical audience."

What they're probing: Whether you can translate stochastic volatility surfaces or copula dependencies into language a portfolio manager or compliance officer can act on.

What they're evaluating: Communication precision — do you simplify without distorting? Do you anchor explanations in P&L or risk terms the audience cares about?

STAR framework: Situation — "The head of credit trading asked why our CVA model was repricing a tranche book 15% higher than the previous quarter." Task — explain the model change (e.g., migration from Gaussian copula to a t-copula with fatter tails). Action — built a one-page visual showing tail-dependence differences using historical default clustering data from 2008–2009, framed in terms of additional capital reserve required. Result — "The desk approved the model update within one week instead of the typical six-week review cycle" [11].

3. "Describe a situation where you disagreed with a senior quant or portfolio manager about a modeling approach."

What they're evaluating: Intellectual rigor combined with professional diplomacy. Quant desks value people who defend their methodology with evidence, not deference.

STAR framework: Situation — "A senior researcher insisted on using a GARCH(1,1) model for volatility forecasting on our options book." Task — you believed a regime-switching model better captured the bimodal vol distribution observed in the underlying. Action — ran a parallel backtest over 5 years of daily data, compared log-likelihood scores and out-of-sample forecast errors (RMSE), and presented results in the weekly model review. Result — "The regime-switching model reduced 10-day VaR forecast error by 18%, and the team adopted a blended approach using both models with Bayesian model averaging" [11].

4. "Walk me through a time you worked under extreme time pressure to deliver a quantitative deliverable."

What they're probing: Quant desks operate on trading-floor timelines. Can you triage scope, cut corners intelligently (e.g., use a closed-form approximation instead of full Monte Carlo), and still deliver something the desk can trade on?

STAR framework: Situation — "During the March 2020 vol spike, the risk desk needed an intraday stress-test overlay for our equity derivatives book within 48 hours." Task — build a scenario engine that could reprice 12,000 positions under 5 macro shock scenarios. Action — "I used a delta-gamma-vega approximation rather than full revaluation, parallelized the computation across 8 cores in Python using multiprocessing, and validated against full Monte Carlo on a 500-position subsample." Result — "Delivered the tool in 36 hours; the approximation error was under 2% for 95% of positions, and the desk used it daily for the next three months" [11].

5. "Tell me about a time you identified a flaw in an existing model or process."

What they're evaluating: Proactive risk identification — do you audit inherited code and assumptions, or do you treat existing models as black boxes?

STAR framework: Situation — "I inherited a credit scoring model that used 5-year CDS spreads as a feature." Task — during routine validation, I noticed the feature had a 97% correlation with another input (bond spread), creating severe multicollinearity that inflated coefficient standard errors. Action — applied variance inflation factor (VIF) analysis, removed the redundant feature, and re-estimated the model using elastic net regularization. Result — "Out-of-sample AUC improved from 0.78 to 0.83, and the model's default predictions became significantly more stable across quarterly re-estimations" [11].

6. "Describe a project where you had to acquire a new skill or tool quickly."

What they're evaluating: Learning velocity. Quant roles frequently require picking up new libraries (e.g., migrating from pandas to Polars for performance), new asset classes, or new mathematical frameworks mid-project.

STAR framework: Situation — "Our desk decided to expand into cryptocurrency derivatives, and I had no prior experience with perpetual futures or funding rate mechanics." Task — build a fair-value model for BTC perpetual swaps within three weeks. Action — studied the funding rate arbitrage mechanism, implemented a cost-of-carry model adjusted for exchange-specific funding intervals (8-hour vs. 1-hour), and backtested against 18 months of Binance and Deribit data. Result — "The model identified a persistent 15 bps/day mispricing during high-volatility regimes, which the desk captured for $1.2M in the first quarter" [11].

What Technical Questions Should Quantitative Analysts Prepare For?

Technical rounds in quant interviews test three layers: mathematical foundations (probability, stochastic calculus, linear algebra), programming ability (typically Python or C++), and financial modeling intuition [12]. Expect to solve problems on a whiteboard or in a shared coding environment.

1. "Derive the Black-Scholes PDE from first principles."

What they're testing: Whether you understand the hedging argument — not just the formula. Start with a portfolio of one option and Δ shares of the underlying, apply Itô's lemma to the option price, and show that the portfolio can be made riskless by choosing Δ = ∂V/∂S. Set the portfolio return equal to the risk-free rate and simplify. Interviewers will probe whether you can explain why the drift term μ disappears (risk-neutral pricing) and what assumptions break in practice (discrete hedging, stochastic vol, transaction costs) [6].

2. "You have a covariance matrix that isn't positive semi-definite. How do you fix it, and why does it matter?"

What they're testing: Practical numerical linear algebra. A non-PSD covariance matrix means your portfolio optimizer can produce negative variance — a nonsensical result. Explain at least two remediation approaches: spectral decomposition (eigenvalue clipping — set negative eigenvalues to zero or a small positive ε and reconstruct), or shrinkage toward a structured target like the Ledoit-Wolf estimator. Discuss the tradeoff: clipping preserves eigenvector structure but distorts correlations; shrinkage biases toward the target but guarantees PSD. Mention that this problem frequently arises with short estimation windows relative to the number of assets (e.g., estimating a 500×500 matrix from 252 daily returns) [6].

3. "Implement a Monte Carlo pricer for an Asian option in Python. What variance reduction techniques would you apply?"

What they're testing: Coding fluency and numerical methods knowledge. Write clean, vectorized NumPy code — avoid Python for-loops over paths. For variance reduction, discuss antithetic variates (negate the Brownian increments to create negatively correlated path pairs), control variates (use the geometric Asian option's closed-form solution as a control), and stratified sampling. Interviewers often follow up by asking you to estimate the convergence rate (O(1/√N) for plain MC) and how control variates can improve it [6].

4. "Explain the difference between P and Q measures. When do you use each?"

What they're testing: Foundational understanding of risk-neutral vs. real-world probability. The P (physical) measure reflects actual asset dynamics — you use it for risk management, VaR calculations, and econometric estimation. The Q (risk-neutral) measure is constructed so that discounted asset prices are martingales — you use it for derivatives pricing. The Girsanov theorem provides the change-of-measure mechanism. A strong answer connects this to practice: "When I calibrate a local vol surface to market option prices, I'm working in Q. When I estimate expected shortfall for the risk desk, I'm working in P" [6].

5. "You're given a time series of daily returns. Walk me through how you'd test for stationarity, fit a model, and validate it."

What they're testing: Econometric rigor. Start with the Augmented Dickey-Fuller test (or KPSS as a complement — they have opposite null hypotheses, so using both reduces Type II error). Examine the ACF/PACF plots to identify AR and MA orders. Fit an ARMA-GARCH model if you observe volatility clustering (which you almost always do in financial returns). Validate using out-of-sample forecast evaluation: compare RMSE, check the Ljung-Box test on standardized residuals, and verify that the probability integral transform of residuals is uniform (Rosenblatt transform) [6].

6. "What is the curse of dimensionality, and how does it affect portfolio optimization?"

What they're testing: Whether you understand why Markowitz mean-variance optimization fails in practice with many assets. With n assets, you must estimate n expected returns and n(n+1)/2 covariance parameters. Estimation error grows faster than the number of assets, producing unstable, extreme-weight portfolios. Discuss concrete remedies: factor models (reduce the covariance matrix to k factors where k << n), regularization (L1/L2 penalties on portfolio weights), Black-Litterman (blend prior equilibrium returns with views to stabilize expected return estimates), and resampled efficient frontiers [6].

7. "Write a function that computes the Greeks (delta, gamma, vega) for a European option using finite differences. What step sizes would you choose?"

What they're testing: Numerical differentiation in practice. Central differences (f(x+h) - f(x-h)) / 2h give O(h²) accuracy vs. O(h) for forward differences. For delta, perturb S by h = 0.01 × S (1% of spot). For gamma, use the second-order central difference. The critical follow-up: explain the bias-variance tradeoff in step size — too large introduces truncation error, too small amplifies floating-point rounding error. The optimal h for central differences is approximately ε^(1/3) × S, where ε is machine epsilon (~10⁻¹⁶ for float64), giving h ≈ 10⁻⁵ × S [6].

What Situational Questions Do Quantitative Analyst Interviewers Ask?

Situational questions present hypothetical but realistic desk scenarios. They test whether you can reason through ambiguity, make defensible assumptions, and prioritize correctly under constraints that mirror actual quant workflows [12].

1. "A portfolio manager wants you to build a factor model for a new asset class your desk hasn't traded before. You have 3 years of daily data and 200 candidate features. How do you approach this?"

Approach: Start by acknowledging the data limitation — 750 trading days with 200 features is a severely underdetermined problem. Propose dimensionality reduction first: PCA on the feature set to identify the top 10–15 principal components explaining 90%+ of variance, or use LASSO regression to enforce sparsity. Split data into train (first 2 years) and test (final year) — never use k-fold cross-validation naively on time series due to temporal leakage. Discuss the risk of overfitting explicitly: report in-sample vs. out-of-sample R², and run a permutation test to establish a null distribution for your model's performance. Mention that you'd present the PM with confidence intervals on factor loadings, not point estimates [6].

2. "Your VaR model passed backtesting last quarter but just produced three exceptions in two weeks. The risk committee wants an explanation by end of day. What do you do?"

Approach: Three exceptions in 10 trading days against a 99% VaR implies a ~4.4% empirical exception rate — well above the 1% target. First, check whether the exceptions cluster (consecutive days suggest a regime shift, not random bad luck). Run a Kupiec proportion-of-failures test and a Christoffersen independence test to distinguish between unconditional coverage failure and clustering. Investigate whether the vol model's half-life is too long to capture the current regime — if you're using EWMA with λ=0.94, the effective window is ~30 days, which may be too slow. Present the committee with: (a) the statistical test results, (b) a comparison of your model's vol forecast vs. realized vol over the exception period, and (c) a concrete proposal (e.g., temporarily reducing λ to 0.90 or switching to a GARCH model with faster mean-reversion) [6].

3. "The desk is considering replacing a legacy C++ pricing library with a Python implementation. The PM says Python is too slow. How do you evaluate this?"

Approach: Profile the existing C++ library to establish latency benchmarks — what's the per-trade pricing time, and what's the throughput requirement? For many quant applications (end-of-day risk, overnight batch pricing), Python with NumPy/SciPy is fast enough because the bottleneck is I/O, not computation. For latency-sensitive applications (real-time options market-making), propose a hybrid: Python for research and prototyping, with critical hot paths in C++ called via pybind11 or ctypes. Quantify the developer productivity gain — if the Python implementation takes 2 weeks vs. 8 weeks in C++, and the latency difference is 5ms vs. 0.5ms on a desk that trades hourly, the business case for Python is strong. Present a decision matrix with columns for latency, development time, maintainability, and hiring pipeline (Python quants are far more abundant than C++ quants) [6].

4. "A colleague's model shows a strategy with a backtest Sharpe ratio of 3.5. They want to go live. What questions do you ask?"

Approach: A Sharpe of 3.5 in a backtest is almost certainly too good to be true. Probe for: look-ahead bias (are features computed using data that wouldn't have been available at trade time?), survivorship bias (does the universe include delisted securities?), transaction cost assumptions (are they using mid-price fills on illiquid instruments?), and data snooping (how many strategy variants were tested before arriving at this one?). Ask for the deflated Sharpe ratio — Harvey and Liu's framework adjusts for multiple testing. Request out-of-sample performance on a held-out period the researcher hasn't seen. If the strategy trades infrequently, check whether the Sharpe is inflated by stale pricing (Getmansky-Lo-Makarov smoothing bias) [6].

What Do Interviewers Look For in Quantitative Analyst Candidates?

Quant hiring committees typically evaluate candidates across four axes, often with explicit scorecards [12]:

Mathematical maturity: Not just knowing formulas, but understanding derivations, assumptions, and failure modes. Can you explain why geometric Brownian motion is a poor model for equity returns (fat tails, volatility clustering, leverage effect) and what you'd use instead? Interviewers distinguish between candidates who memorized Itô's lemma and those who can apply it to a novel SDE on the spot [3].

Programming as a tool, not a parlor trick: Production quant code must be readable, testable, and performant. Interviewers look for vectorized NumPy over nested loops, proper use of version control, and awareness of numerical stability issues (e.g., computing log-likelihoods in log-space to avoid underflow). Mentioning unit tests for pricing functions or CI/CD pipelines for model deployment signals production readiness [3].

Financial intuition: The ability to sanity-check quantitative outputs against market reality. If your model says a 1-month ATM vol for SPX is 5%, you should immediately recognize that's far too low (historical average is closer to 15–18%). This intuition comes from watching markets, not just reading textbooks [6].

Red flags that sink candidates: Inability to state assumptions behind a model. Treating all data as IID without checking. Writing code that works but is unreadable. Claiming expertise in a technique (e.g., "I used machine learning") but being unable to explain the loss function, regularization method, or why that approach was appropriate for the problem [12].

What separates top candidates: They connect every technical answer back to a business outcome — not "I implemented PCA" but "I reduced the covariance matrix from 500 to 12 factors, which cut the optimizer's runtime from 4 hours to 8 minutes and allowed the PM to rebalance intraday instead of overnight" [3].

How Should a Quantitative Analyst Use the STAR Method?

The STAR method (Situation, Task, Action, Result) works for quant interviews when you anchor each element in quantitative specifics — model names, metrics, asset classes, and dollar or basis-point impacts [11].

Example 1: Model Validation Under Regulatory Pressure

Situation: "Our desk's interest rate swap pricing model was flagged during an internal model review for failing the Fed's CCAR stress test benchmarks. The model underestimated potential losses on a $40B notional swap book under the severely adverse scenario by 22%."

Task: "I was assigned to identify the source of the discrepancy and remediate the model within the 90-day regulatory window."

Action: "I traced the issue to our yield curve construction methodology — we were using cubic spline interpolation on par rates, which produced unrealistic forward rate oscillations in the 7–10 year tenor bucket under stress. I replaced it with monotone convex interpolation (Hagan-West method), which preserved no-arbitrage constraints. I then re-ran the stress scenarios, validated against the Fed's published benchmark losses, and documented the methodology change in a 30-page model risk report for the validation team."

Result: "The remediated model's stress losses fell within 3% of the Fed benchmark (vs. 22% previously). The model passed the next CCAR cycle, avoiding a potential capital surcharge of $180M. The monotone convex method was subsequently adopted as the firm-wide standard for curve construction" [11].

Example 2: Alpha Research and Signal Development

Situation: "Our systematic equity desk's primary momentum signal had decayed from a live information coefficient (IC) of 0.05 to 0.02 over 18 months, reducing the strategy's annualized alpha from 3.2% to 1.1% on a $2B AUM book."

Task: "I was tasked with diagnosing the signal decay and either rehabilitating the existing signal or developing a replacement."

Action: "I decomposed the signal's IC into sector, factor, and idiosyncratic components using a Barra-style risk model. The analysis revealed that the momentum signal's alpha had been almost entirely absorbed by crowding — the signal's correlation with hedge fund positioning data (13F filings) had risen from 0.15 to 0.62. I developed an orthogonalized momentum signal that residualized out the crowded component using principal component regression on the positioning data. I backtested the new signal over 10 years with proper walk-forward optimization (12-month training, 3-month test windows)."

Result: "The orthogonalized signal restored the live IC to 0.045 within two quarters. The strategy's annualized alpha recovered to 2.8%, generating approximately $56M in incremental P&L over the first year. The approach was extended to three other signals on the desk" [11].

Example 3: Infrastructure and Performance Optimization

Situation: "Our end-of-day risk calculation for a 50,000-position multi-asset portfolio was taking 6.5 hours, frequently failing to complete before the 6 AM reporting deadline."

Task: "Reduce runtime to under 2 hours without sacrificing accuracy."

Action: "I profiled the codebase and found that 80% of runtime was consumed by full revaluation of exotic structured products using single-threaded C++ Monte Carlo. I implemented three changes: (1) replaced full MC with a Longstaff-Schwartz regression-based approximation for American-style exotics, reducing per-position pricing time by 70%; (2) parallelized the remaining MC paths using OpenMP across 16 cores; (3) cached intermediate results (discount factors, vol surfaces) that were being redundantly recomputed for each position."

Result: "Total runtime dropped from 6.5 hours to 1 hour 40 minutes. The approximation error was under 50 bps for 98% of positions (validated against full MC on a weekly basis). The risk team gained a 4-hour buffer before the reporting deadline, eliminating the missed-deadline incidents that had occurred 3 times in the prior quarter" [11].

What Questions Should a Quantitative Analyst Ask the Interviewer?

The questions you ask reveal whether you've actually worked on a quant desk or just studied for one. These questions demonstrate domain fluency and help you evaluate whether the role matches your skills [4] [5]:

1. "What's the current tech stack for model development and deployment? Are models prototyped in Python/R and then rewritten in C++, or do you deploy Python directly to production?" — This tells you whether you'll spend 30% of your time on C++ translation work or can focus on research.

2. "How does the model validation process work here? Is there an independent model risk team, or do quants validate each other's work?" — Reveals the firm's model governance maturity. Shops without independent validation often have weaker risk controls.

3. "What's the typical ratio of research time to production support? How much of a quant's week is spent maintaining existing models vs. developing new ones?" — On some desks, "quant" means "model maintenance engineer." This question surfaces that reality before you accept.

4. "How is alpha attribution performed, and how does quant research feed into portfolio construction decisions?" — Shows you understand the full signal-to-portfolio pipeline, not just the modeling step.

5. "What data vendors and alternative data sources does the desk currently use, and are there plans to expand?" — Signals your awareness that data quality and coverage often matter more than model sophistication.

6. "Can you describe a recent model that didn't work as expected in production and how the team handled it?" — This is a culture question disguised as a technical one. The answer reveals how the desk handles failure — blame vs. learning.

7. "What's the desk's approach to model interpretability vs. predictive performance? Are there constraints on using black-box ML models?" — Directly relevant if you're joining a desk that faces regulatory scrutiny (banking book) vs. one with more freedom (prop trading) [5].

Key Takeaways

Quant interviews are multi-layered evaluations that test mathematical depth, programming fluency, financial intuition, and communication ability simultaneously. Prepare by solving problems out loud — the narration matters as much as the solution. For behavioral rounds, build a library of 8–10 STAR stories anchored in specific models, metrics, and dollar impacts; generic answers about "working well in teams" won't survive a quant hiring committee [11] [12].

Practice live coding in Python with a focus on vectorized NumPy operations, numerical methods (Monte Carlo, finite differences, optimization), and clean code structure. Review your stochastic calculus fundamentals — Itô's lemma, Girsanov's theorem, and the Feynman-Kac connection appear in nearly every technical round [6].

Build your resume to reflect the same specificity your interview answers require — quantified model impacts, named methodologies, and production-scale metrics. Resume Geni's resume builder can help you structure your quant experience with the precision hiring managers expect.

Frequently Asked Questions

How long should I expect the quant interview process to take from first screen to offer?

Most quant hiring pipelines span 4–8 weeks and include 3–5 rounds: an initial phone screen (often a probability brainteaser or quick coding problem), a technical phone interview focused on stochastic calculus or statistics, a take-home coding assignment (typically 4–8 hours), and a final "superday" with 3–5 back-to-back interviews covering technicals, behavioral, and culture fit [12]. Some hedge funds compress this into 2 weeks; large banks may take 10+ weeks due to compliance approvals.

How important are certifications like CQF or FRM for quant interviews?

Certifications like the Certificate in Quantitative Finance (CQF) or Financial Risk Manager (FRM) can supplement your profile but rarely substitute for a strong quantitative degree (PhD in math, physics, CS, or financial engineering). Most hiring managers weight published research, competition results (Kaggle, quantitative finance competitions), and demonstrable project work above certifications. The FRM is more valued in risk quant roles at banks; the CQF signals self-directed learning for career switchers [7].

Do quant interviews differ between buy-side and sell-side?

Significantly. Sell-side (bank) quant interviews emphasize derivatives pricing theory, PDE methods, and model validation frameworks — you'll face more Black-Scholes derivations and Greeks calculations. Buy-side (hedge fund) interviews focus on statistical modeling, signal research, and portfolio construction — expect questions about information coefficients, factor models, and strategy backtesting methodology. Prop trading firms often add real-time mental math and probability puzzles to test speed under pressure [12].

Should I prepare differently for a risk quant vs. a desk quant interview?

Yes. Risk quant interviews emphasize VaR methodologies (historical simulation vs. parametric vs. Monte Carlo), stress testing frameworks (CCAR/DFAST for US banks), model validation techniques, and regulatory capital calculations (Basel III/IV). Desk quant (front-office) interviews focus on pricing models, calibration techniques (e.g., calibrating a Heston model to a vol surface), hedging strategies, and P&L explanation. The programming expectations also differ: risk quants often work more with SQL and large-scale data pipelines, while desk quants need faster numerical computing skills [6] [12].

What programming languages should I focus on for quant interviews?

Python is the baseline expectation for nearly all quant roles — specifically NumPy, pandas, SciPy, and scikit-learn [4]. C++ remains critical for low-latency trading desks and derivatives pricing libraries (particularly at banks with legacy infrastructure). R appears occasionally in econometric and statistical research roles. SQL proficiency is assumed but rarely tested in depth. For competitive differentiation, familiarity with GPU computing (CUDA/PyTorch for Monte Carlo acceleration) or Rust (emerging in some fintech quant shops) can set you apart [5].

How should I handle a brainteaser I can't solve during the interview?

Quant brainteasers (e.g., "What's the expected number of coin flips to get two heads in a row?") test your problem-decomposition process, not just your answer. State your approach explicitly: define the state space, set up the recurrence relation, and solve. If you're stuck, verbalize where you're blocked — "I can set up the states but I'm not seeing how to solve this system of equations" — because interviewers often provide hints to candidates who demonstrate structured thinking. Silence is the worst response; a partially correct approach with clear reasoning scores far better than a guess [12].

What math topics appear most frequently in quant interviews?

Based on candidate reports, the highest-frequency topics are: probability theory (conditional expectation, Bayes' theorem, Markov chains), stochastic calculus (Itô's lemma, geometric Brownian motion, martingale theory), linear algebra (eigendecomposition, PCA, matrix calculus), statistics (hypothesis testing, maximum likelihood estimation, time series analysis), and numerical methods (Monte Carlo simulation, finite differences, optimization algorithms). Combinatorics and brainteaser-style probability puzzles appear in nearly every first-round screen [12] [6].