A model only sees the columns you hand it. Feature engineering is the work of turning raw facts about the user, the thing being scored, the moment of the request, and past interactions into those columns. Picture a food-delivery app that serves about 2M orders a day from 180k restaurants. When a customer places an order, a model predicts whether it will arrive more than 10 minutes after the promised time, which happens to about 12% of orders. A "likely late" score pads the estimated time of arrival (ETA) the customer sees and gets a courier assigned earlier.

What the model knows about that order, and in what form, decides how good that score can be. Hand-built features help most with tabular models like this one, and even there they have limits: a tree model needs no rescaling, a pretrained text embedding replaces hand-picked keywords when meaning matters, and a feature that needs an always-on streaming job but barely moves accuracy is usually not worth keeping.

In a machine learning (ML) system design round, "What features would you use, and how would you represent them?" comes right after framing and data, and it usually takes 5-10 minutes. Mid-level candidates are expected to name concrete features and sensible encodings. Senior candidates are expected to handle brand-new restaurants and customers on purpose, show how they would prove a feature helps, and notice when a feature looks too good to be true. A bare list of features with no representation and no way to judge them is a common down-level signal.

We will use the late-delivery model throughout. You will come away able to propose, encode, and defend a feature set for any new prompt, whether it is late delivery, fraud, or click prediction. How those features get computed and served in production is the next section of this course.