Why Good ML Engineer Candidates Still Get Rejected

CANDIDATE A  (illustrative example)
Modelling: strong, explained boosting and tuning well
SQL:       needed hints for a LEFT JOIN with a date window
Design:    could not say where features come from at
           prediction time
Manager:   wants to work on 'cutting-edge research'
Decision:  no hire for this applied role

Nothing here says the candidate is weak. Every line says
the candidate is not ready for THIS job yet.

CANDIDATE A, after focused practice  (illustrative)
Modelling: strong
SQL:       wrote the label query with a point-in-time
           join on their own
Design:    proposed nightly batch scores in a table,
           same feature code for training and serving
Manager:   'I enjoy shipping models people use, and I
           want to learn your deployment stack'
Decision:  hire

-- Churn training set, PostgreSQL syntax
-- snapshot: 2026-01-01, features from 60 days before,
-- label = no order in the 30 days after
WITH base AS (
  SELECT customer_id, DATE '2026-01-01' AS snapshot_date
  FROM customers
  WHERE signup_date < DATE '2026-01-01'
),
features AS (
  SELECT b.customer_id,
         COUNT(o.order_id)          AS orders_60d,
         COALESCE(SUM(o.amount), 0) AS spend_60d,
         MAX(o.order_date)          AS last_order_date
  FROM base b
  LEFT JOIN orders o
    ON o.customer_id = b.customer_id
   AND o.order_date >= b.snapshot_date - INTERVAL '60 days'
   AND o.order_date <  b.snapshot_date
  GROUP BY b.customer_id
),
labels AS (
  SELECT b.customer_id,
         CASE WHEN COUNT(o.order_id) = 0 THEN 1 ELSE 0 END AS churned
  FROM base b
  LEFT JOIN orders o
    ON o.customer_id = b.customer_id
   AND o.order_date >= b.snapshot_date
   AND o.order_date <  b.snapshot_date + INTERVAL '30 days'
  GROUP BY b.customer_id
)
SELECT f.*, l.churned
FROM features f
JOIN labels l USING (customer_id);

"I fix a snapshot date. Everything the model may know comes
from before that date, here the last 60 days of orders.
The label comes only from the 30 days after it.

I start from the full customer list with LEFT JOINs, so
customers with zero orders stay in the data. Those are often
exactly the churners.

To get more examples, I repeat this for several snapshot
dates and stack the results, then split by snapshot date."

# One function used by BOTH the training job and the API.
from datetime import date

def build_features(orders_60d: int, spend_60d: float,
                   last_order: date, today: date) -> dict:
    days_since = (today - last_order).days if last_order else 999
    return {
        "orders_60d": orders_60d,
        "avg_order_value": spend_60d / orders_60d if orders_60d else 0.0,
        "days_since_last_order": days_since,
    }

# Training job: build_features(...) for each row of the SQL output
# API:          build_features(...) from the live database values
print(build_features(3, 1500.0, date(2025, 12, 20), date(2026, 1, 1)))

Q: Classify incoming support tickets into five teams.

"I would start with TF-IDF features and logistic regression.
It trains in seconds, is easy to explain, and gives a baseline.

If accuracy on the hard classes is not good enough, I would
try a small pretrained text model and compare on the same
validation set. I would only move up if the gain justifies
the extra latency, cost and maintenance.

For tickets the model is unsure about, I would route them to
a human queue instead of guessing."

Rate yourself 1 (weak) to 5 (strong):

__ I can write a point-in-time training query in SQL
__ I can explain LEFT JOIN vs INNER JOIN effects on rows
__ I can describe batch vs online serving for my project
__ I can explain training-serving skew with an example
__ I always propose a baseline before a complex model
__ I can state the running cost or latency of my design
__ I know whether the role is applied or research

Anything below 4: that is your practice for this week.

Use any orders/customers dataset in SQLite or PostgreSQL.

1. Count orders per customer in the 60 days before a date.
2. Same, but keep customers with zero orders.
3. Label customers with no order in the next 30 days.
4. Build features + label for three snapshot dates
   and UNION ALL them.
5. Find the share of churners per signup month.
6. Explain out loud why each date filter sits in the ON clause.

JOB DESCRIPTION KEYWORDS        MY MATCHING STORY
------------------------------  ---------------------------
Deploy / productionise          ____________________________
Data pipelines / SQL            ____________________________
Monitoring / retraining         ____________________________
Stakeholders / business         ____________________________
Research / experiments          ____________________________

Lead with the stories that match the top two rows of
the job description, not the ones you like most.