You are given a DataFrame containing the past **six years of web search logs**. Each row is a single search event with the following columns: | Column | Type | Description | |---|---|---| | `timestamp` | datetime | When the search was issued | | `device_id` | string | Anonymized identifier of the searching device | | `location` | string | Geographic location of the search (e.g., city/region) | | `query` | string | Raw search query text | | `url` | string | The result URL the user clicked | **Task:** design features from this data and build a model that predicts the stock price of a **given company at an arbitrary point in time**. You may also join publicly available historical market data (prices, volumes) for the company. The interviewer will press on every design decision: how you construct features, what model you use, how you avoid overfitting, what you choose as the target, how you handle data drift and variance drift, how you deal with seasonality, and — once you have trained several models based on different hypotheses — how you choose among them. ### Constraints & Assumptions - The log covers **all search traffic for six years**, so it is far too large for in-memory processing; assume you must aggregate before modeling. - A prediction for time $t$ may only use information with timestamps strictly **before** $t$ (no lookahead). - The company is a parameter: the pipeline should work for any publicly traded company, not just one hand-tuned ticker. - Historical price/volume data for the company can be joined; assume standard market hours and trading calendars. - Device IDs are anonymized; you cannot recover user identity, but you can count distinct devices. ### Clarifying Questions to Ask - What is the prediction horizon — nowcasting the price right now, or forecasting over the next hour/day/week? - Is a point estimate of the *price* required, or is predicting *returns* or *direction* acceptable? What metric will the model be judged on? - Should the model produce predictions in real time, or is a daily batch acceptable? - Do we care about one company or a cross-section of many tickers (which changes how we normalize and validate)? - Can we use auxiliary data such as earnings calendars, trading holidays, or news timestamps to contextualize search spikes? ### Part 1 Walk through how you would turn the raw event-level search log into model features for company $X$. Which events are even *relevant* to $X$, what would you extract from each column, and at what time granularity would you aggregate? ```hint Relevance first Before any aggregation you need entity linking: match `query` text and clicked `url` domains to company $X$ (name, ticker, products, executives). Everything downstream depends on this filter, so discuss its precision/recall trade-off. ``` ```hint Make counts comparable Raw search counts trend upward over six years as overall traffic grows. Think about **relative** measures — company share of total search volume, z-scores against a rolling baseline — rather than raw counts. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 2 What exactly is your prediction target, and why? Given that target, what model class do you start with, and why? ```hint The target is a choice Raw price is non-stationary and scale-dependent. Consider forward **log returns** over a fixed horizon aligned with the prediction time, and be ready to justify the horizon. ``` ```hint Start simple With low signal-to-noise financial data, a heavily regularized linear model is a strong, honest baseline; justify any move to gradient-boosted trees or sequence models by out-of-sample evidence, not expressiveness. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 3 Financial data is notoriously noisy. How do you avoid overfitting, and how do you validate the model given that the data is a time series? ```hint Respect time Random k-fold CV leaks future information. Use walk-forward (rolling-origin) validation with a gap/purge between train and test windows to account for overlapping return horizons. ``` ```hint You are your own biggest risk Every feature idea you test on the same history is an implicit hypothesis test. Discuss multiple-testing discipline: held-out final periods, limiting iterations, adjusting expectations for backtest overfitting. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 4 Search behavior, the search platform itself, and market regimes all change over six years. How do you handle data drift, variance drift, and seasonality? ```hint Two different drifts Separate **input drift** (search volume, user mix, logging changes shift feature distributions) from **relationship/variance drift** (market volatility regimes change the target's scale). Each needs its own treatment. ``` ```hint Don't fight seasonality — model it Weekly and annual search cycles (weekends, holidays, earnings seasons) are predictable structure. Either deseasonalize features against a seasonal baseline or add explicit calendar features, and say why you chose one. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### Part 5 You have trained several models, each built on a different hypothesis about how search activity relates to the stock price. How do you decide which one to use — or whether to combine them? ```hint Same yardstick, fresh data Compare all candidates under one frozen walk-forward protocol on data none of them touched during development — and remember that picking the best of $N$ backtests is itself a form of overfitting. ``` #### What This Part Should Cover ```premium-lock What This Part Should Cover ``` ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - Search interest is partly *reactive*: a price move generates news, which generates searches. How would you test whether your features carry predictive information rather than merely reflecting moves that already happened? - How would you demonstrate that the search-derived features add value over a baseline that uses only past price and volume? - If the deployed model's live performance decays after six months, how do you diagnose whether the cause is input drift, a regime change, or backtest overfitting? - How would your feature pipeline and model change if predictions were needed intraday within minutes instead of once per day?