Know your projects inside out

Quick start

Your résumé, line by line

If the interview is tomorrow

1. 20 minutes — Read the seven résumé claims below. Give each project a 45-second pitch aloud, then say which piece you personally implemented, tested, or debugged.
2. 25 minutes — Draw one borrower prediction, one weather prediction, and one finding creation from input to output. Explain where each can fail.
3. 20 minutes — Practice the three hardest follow-ups with no notes. Explain RiskSight leakage, Pyrograph’s temperature-rule comparison, and Fieldnotes’ client-supplied identity.
4. 15 minutes — Do the mock interview and open only the answers you missed. Rehearse one real debugging or team story with a concrete code change or test.

The sample pitches describe repository behavior. Use “I” for work you can describe from your own experience. For team or AI-assisted work, say what the project does, identify your part, and explain how you checked it. Bring one commit, function, experiment, or issue you can discuss for every project.

The seven lines an interviewer can probe

Three 30-second answers

RiskSight

RiskSight estimates the risk of serious delinquency using borrower records. The core is a NumPy implementation of logistic regression that learns weights from binary cross-entropy, including support for class weighting and regularization. FastAPI and React show the prediction and evaluation. The main evaluation issue I’d discuss is the repository’s preprocessing order. It estimates imputation and scaling statistics before the split, so I’d move those fits onto the training partition.

Pyrograph

Pyrograph is a Jaipur heat-hazard classification prototype. It builds weather and time features, selects an XGBoost classifier on a separate chronological window, and serves it through FastAPI with versioned artifacts. The retrospective evaluation used observed weather. When the project separately tried real three-day-ahead forecast inputs, a simple temperature rule had fewer false alarms and a higher critical success index.

Fieldnotes

Fieldnotes is a small research log for the heatwave project team. React sends requests to an Express API that validates findings and stores them in SQLite. The UI can filter findings by project phase and show role records. The shared PIN is a lightweight gate for a small team. For per-user permissions, I’d have the server derive identity from a verified session.

Three worked follow-ups

RiskSight • Does higher recall prove the custom optimizer is better? The repository compares a balanced scratch model with an unweighted scikit-learn baseline at the same cutoff. The weighted model is encouraged to score positives higher, and both weighting and implementation differ. An apples-to-apples experiment would use identical training-fitted transformations, equivalent weights and regularization, the same evaluation rows, and thresholds chosen on validation. On a loan decision, class weights change training and the threshold changes how a trained score is used. Evaluation script

Pyrograph • Where do the pilot CSI numbers come from? At three days, both systems found two of three positive days, so both have 2 TP and 1 FN. The classifier made 7 false alarms and the temperature rule made 2. The resulting CSI values are 2 ÷ (2 + 7 + 1) = 0.20 and 2 ÷ (2 + 2 + 1) = 0.40. This was 91 days with three positive labels. State that sample size before drawing conclusions. Fixed-lead pilot

Fieldnotes • Why can’t CORS enforce admin permissions? CORS constrains what a browser lets a page read across origins. A direct client can call the API without an Origin header. The role checks use a caller-supplied x-current-user name, so a caller with the shared PIN can claim a different identity. Derive the actor from a verified session on the server, then check the actor’s permissions against the requested record. Express middleware and routes

Your personal contribution worksheet

For each project, fill this out aloud. Keep a GitHub tab open to verify details after your first attempt.

• I personally changed ___ in ___ because ___.
• I checked it by , using input ___ and expecting .
• A teammate, library, or AI tool contributed . I reviewed or tested .
• The hardest bug or trade-off was . The evidence that changed my mind was .
• If I had one more week, my first change would be , because it would improve .

Score each answer from 0 to 2 on accuracy, concrete detail, ownership, and handling a follow-up. A vague claim earns zero on detail. An answer with a specific function, example, or experiment earns two when you can explain how it works.

Study method

How to study with this guide

Purpose: know every project on your résumé well enough to explain it simply, defend its choices, trace a request through its code, and openly name its limitations.

Open a card after saying the answer aloud. Use the recall button to mark cards you can explain from memory. Your browser can remember these marks on this device.

How to use this workbook

For each lesson, do this sequence:

1. Read the explanation once.
2. Hide the answer and say it aloud from memory.
3. Draw the flow on paper.
4. Answer the cards at the end of the lesson.
5. Repeat the cards after one day, three days, seven days, and fourteen days.

Recall levels

Aim for level 3 on every concept before an interview. Level 4 is a bonus.

Your honest project boundary

You are not expected to know every library internals or claim industrial-scale production systems. You are expected to know:

• what you built;
• why you chose it;
• what data/request moves through it;
• what can fail;
• and the first improvement you would make.

RiskSight

RiskSight: credit-risk classification from scratch

Repository: rexyrocks/credit-risk-from-scratch

I.1 The story before the code

One-sentence story

RiskSight predicts whether a borrower is likely to experience serious delinquency, while showing how a logistic-regression classifier can be derived and implemented with NumPy rather than treated as a black box.

Interviewer’s mental model

An interviewer should leave with this picture:

Kaggle borrower rows
        ↓
clean missing values + numerical features
        ↓
custom NumPy logistic regression
        ↓
class weighting + threshold choice
        ↓
metrics / baseline comparison
        ↓
FastAPI prediction service
        ↓
React form and results interface

Speak it in 15 seconds

I built a credit-default classifier from first principles in NumPy, including the weighted loss, gradient descent, and regularisation, then compared it with scikit-learn and exposed both through a FastAPI and React demo.

Speak it in 60 seconds

RiskSight uses the Give Me Some Credit dataset, where the target is whether a borrower has a serious delinquency within two years. The interesting part was not just training a library model: I wrote the logistic-regression mechanics in NumPy—the sigmoid, weighted binary cross-entropy, gradients, gradient descent, L1/L2 regularisation, and thresholded predictions. Since defaults are uncommon, I used balanced class weights and focused on precision, recall, F1, and the confusion matrix rather than accuracy alone. I then compared the custom model to a scikit-learn baseline. For usability, the backend trains or loads cached artefacts and FastAPI exposes prediction and metrics endpoints for a React frontend. The main limitation I would fix first is that scaling occurs before the split in the original preprocessing helper, which leaks test-distribution information; the transformer should instead be fit only on the training partition.

I.2 Dataset and target

The repository uses Kaggle’s Give Me Some Credit data. Its target, SeriousDlqin2yrs, indicates whether a borrower had 90+ days of delinquency within two years. The repository describes roughly 150,000 anonymised records and ten input features, including revolving utilisation, age, debt ratio, monthly income, and late-payment counts.

The central data fact is imbalance: the README reports roughly 6.7% positive/default cases. A model can be highly accurate by predicting every borrower as non-default. That model would be useless for finding defaults.

Recall drill: five sentences, no notes

Say these answers aloud:

1. What is the target?
2. Why is accuracy misleading here?
3. What does a positive label mean operationally?
4. Name three features.
5. What cost might a false negative create for a lender?

Flashcards — data

I.3 Preprocessing, step by step

The core helper is preprocessing.py.

1. load_data(path) reads the CSV through pandas.
2. cleandata(df) drops Unnamed: 0, a CSV index-like column that is not a predictive feature.
3. Missing MonthlyIncome is filled with the median.
4. Missing NumberOfDependents is filled with the mode.
5. scalefeature(X) calculates a mean and standard deviation per feature and applies standardisation: (X - mean) / std.
6. train_test_split permutes row indices with fixed seed 42, then uses 20% for testing.

Why median for income?

Income is commonly skewed: a small number of very large values can pull the mean upward. The median is more resistant to outliers. This is a sensible baseline, but in production you would inspect the missingness itself and perhaps add an income_missing indicator, because missingness can carry information.

Why mode for dependents?

Dependents is count-like and likely has a common most frequent value. Filling with the mode is a simple way to maintain a valid categorical/count value. It is still an assumption, so document it.

Why scaling?

Gradient descent learns weights more reliably when features occupy roughly comparable numerical ranges. Without scaling, a large-range feature can dominate the gradient simply because of its units, not because it is more meaningful.

Important flaw you must own

The current pipeline imputes missing values and standardises X before creating train/test sets. The income median, dependents mode, means, and standard deviations include the test rows. The test distribution therefore influences the training transformation. Repair the pipeline in this order.

split raw rows first
fit imputer and scaler only on training X
transform training X with training statistics
transform test X with the same training statistics
save those statistics for incoming API requests

Do not be embarrassed by this answer. Detecting and repairing leakage is exactly the kind of judgment an ML interviewer wants to hear.

Whiteboard exercise R-A

On paper, write pseudo-code for a leakage-free preprocessing flow. Include fit and transform separately. Then answer: “Why must the deployed API use the training mean and standard deviation?”

Flashcards — preprocessing

I.4 Logistic regression without library shortcuts

The custom class is named logisitic_regressionScratch in logistic_regression.py. Notice the spelling typo; do not hide it if someone points it out. Say it is preserved in imports for compatibility and you would rename it with tests/refactoring in a cleanup pass.

The model

For a row of features x, the model computes:

z = x · w + b
p = sigmoid(z) = 1 / (1 + e^-z)

• w is a vector of learned feature weights.
• b is the intercept/bias.
• p is a score between zero and one.

The prediction method makes a class label with:

prediction = 1 when p >= threshold; otherwise 0

Binary cross-entropy

The code calculates a weighted binary cross-entropy loss. Conceptually, the loss rewards a high predicted probability for the true label and penalises confidence in the wrong label.

loss = -[y log(p) + (1-y) log(1-p)]

The negative sign ensures a good prediction yields a small loss rather than a large negative number.

Gradient

For logistic regression, the core residual is p - y. The code multiplies it by sample weight, then obtains:

dw = (1/m) Xᵀ (weighted residual)
db = average(weighted residual)

Then it updates:

w = w - learning_rate × dw
b = b - learning_rate × db

Mini-exercise R-B: trace one update

Assume one feature, one row: x = 2, y = 1, current w = 0, b = 0, learning rate 0.1, and sample weight 1.

1. Compute z.
2. Compute sigmoid(z).
3. Compute residual p - y.
4. Compute dw and db.
5. Compute the updated w and b.

Check: z=0, p=0.5, residual=-0.5, dw=-1, db=-0.5, so updated w=0.1, b=0.05.

Flashcards — model mechanics

I.5 Class weights and regularisation

Balanced class weights

In fit, when class_weight='balanced', the code calculates:

w_positive = n_samples / (2 × number of positives)
w_negative = n_samples / (2 × number of negatives)

Because positives are less frequent, each positive usually receives a larger weight. The loss and gradient give those mistakes greater importance.

This is not magic. It intentionally changes the classifier’s trade-off. Recall may rise, but precision can fall because more cases get marked risky.

L1 versus L2

The implementation adds the regularisation term to dw, not db; it leaves the bias unregularised.

Mini-exercise R-C: choose a tool

For each case, choose a likely first response and explain why:

1. Defaults are rare and recall is near zero.
2. Coefficients are very large and unstable across samples.
3. You want a sparse, easier-to-interpret linear model.
4. False negatives cost much more than false positives.

Suggested answers: class weighting/threshold adjustment; L2; L1; a cost-aware threshold plus possibly class weighting.

Flashcards — imbalance and regularisation

I.6 Evaluation and threshold choice

evaluate.py manually calculates confusion-matrix components:

                 Actual positive   Actual negative
Predicted positive       TP                FP
Predicted negative       FN                TN

Then it derives:

precision = TP / (TP + FP)
recall    = TP / (TP + FN)
F1        = 2 × precision × recall / (precision + recall)
accuracy  = (TP + TN) / all rows

The script sweeps thresholds from 0.1 to 0.9. It applies an illustrative monetary model: correct loan to a good customer earns interest, while a loan to a defaulter loses principal. Treat it as a teaching exercise, not an actual bank policy.

How to defend your choice of a metric

I would not select a threshold by F1 alone. The appropriate threshold depends on what a missed default, wrongly declined borrower, review capacity, fairness constraints, and probability calibration mean in the intended workflow. F1 is useful as a balance of precision and recall, but it does not encode the business cost directly.

Mini-exercise R-D: answer from a confusion matrix

Suppose TP=80, FP=120, FN=20, TN=780.

1. Calculate precision.
2. Calculate recall.
3. Calculate F1 approximately.
4. Would accuracy alone make the model look better or worse than it is?

Check: precision = 0.40; recall = 0.80; F1 ≈ 0.533; accuracy = 0.86, which can look deceptively strong despite many false positives.

Flashcards — evaluation

I.7 API and frontend: trace one request

The FastAPI backend lives in backend/main.py. At startup it:

1. locates project files from its own path;
2. loads and cleans the training data;
3. trains both the NumPy and scikit-learn models;
4. creates threshold-sweep data;
5. stores models, scaling statistics, test data, and sweep outputs in backend/cache/models.joblib.

Important contracts:

• POST /predict: receives a borrower profile in the known feature order and returns results from both models.
• GET /metrics: returns comparison and threshold-sweep information.
• GET /health: returns a liveness check.
• backend/schemas.py: Pydantic request/response contracts keep API data predictable.

The React app uses frontend/src/api.js for HTTP calls. PredictionForm collects values, ResultsPanel displays a response, and ModelPerformance renders evaluation/threshold information.

Request tracing drill R-E

Close this document and draw the route for a user pressing “Predict.” Include every component from browser form to response display. Reopen this only after you have drawn it.

Debugging scenarios

Scenario 1: The frontend gets a CORS error.
Talk through allowed origins in FastAPI’s CORS middleware, the frontend URL, and the backend URL; do not jump straight to disabling CORS broadly.

Scenario 2: An API prediction looks different from notebook results.
First verify feature order, imputation, training-vs-inference scaling statistics, model version, and threshold. These are more likely than “FastAPI changed the model.”

Scenario 3: Server restart takes too long.
Inspect whether the joblib cache exists and is valid. A robust version should also track dataset/model-code versions so stale caches cannot silently serve incompatible data.

Flashcards — delivery

I.8 RiskSight mock interview

Answer each aloud in under 90 seconds. Record yourself on the second attempt.

1. Explain RiskSight to a non-technical recruiter.
2. Derive the path from Xw+b to a yes/no decision.
3. Why did you use class weights rather than oversampling?
4. What information leaks in the current preprocessing code?
5. A product manager says, “Make recall 100%.” What do you ask before changing the threshold?
6. What would you add for a production review?

Production-minded answer: stratified, leakage-free splits; train-only transforms in a pipeline; calibrated probabilities; fairness and drift evaluation; robust numerical clipping; data/model versioning; authentication/audit logging; monitoring; human review rules; and clear non-automated-decision safeguards.

Pyrograph

Pyrograph: heatwave classification prototype

Repository: rexyrocks/pyrograph

II.1 The story before the code

One-sentence story

Pyrograph is a Jaipur-specific prototype that classifies daily heatwave conditions with XGBoost, then serves a versioned, integrity-checked model through a typed FastAPI API.

The crucial wording rule

Call the reported evaluation retrospective classification. Its inputs were observed daily weather. The separate forecast-input pilot used archived forecasts and found that a temperature rule scored higher on CSI at leads of three to five days.

60-second explanation

Pyrograph is an extreme-heat classification prototype. I defined a fixed climatology reference for 2015–2018, used 2019–2021 for training, selected a model on 2022, and evaluated the chosen XGBoost model on 2023–2024. The model consumes observed weather, temperature lags, a temperature-departure feature, and cyclic calendar features. The API validates input ranges with Pydantic and loads the model only after checking a manifest, SHA-256 hashes, and the exact feature order, so a model cannot accidentally be combined with the wrong climatology reference. It supports individual and chronological batch predictions. Severity and persistence are explicit post-processing rules, not hidden inside the classifier. That retrospective test used observed weather. A separate forecast-input pilot found the temperature rule ahead of the classifier on CSI at leads of three to five days.

II.2 Time split and evaluation evidence

The checked evaluation.json contains this experiment design:

The selected model is XGBoost, selected using CSI (Critical Success Index), with F1 then name only as deterministic tie-breakers. Its committed retrospective test metrics are precision 0.8333, recall 0.8491, F1 0.8411, and CSI 0.7258.

Why the three time windows?

• Training teaches model parameters.
• Selection chooses a model/hyperparameter approach without touching the final test period.
• Test estimates how the chosen approach handles later unseen rows.

A random row split would risk training on future weather patterns while evaluating on earlier rows, producing an unrealistically easy task.

CSI in depth

CSI = TP / (TP + FP + FN)

It excludes true negatives. In rare-event detection, there can be many ordinary days; counting them can make a mediocre event detector look good. CSI focuses on hits, false alarms, and missed events.

Flashcards — evaluation

II.3 Inputs and feature engineering

PredictionInput in backend/main.py contains:

• date;
• daily temperatures: tmax, tmin, tmean;
• humidity, maximum wind, pressure, solar radiation, cloud cover;
• lagged maximum temperature for the prior three days;
• lagged minimum temperature for the prior three days;
• optional previous-day heatwave result.

The backend creates additional features:

1. temperature departure: tmax - climatology normal;
2. day-of-year sine: sin(angle);
3. day-of-year cosine: cos(angle).

Together, the serving manifest expects 17 features.

Why sine and cosine instead of day 1 to 365?

December 31 and January 1 are adjacent in the seasonal cycle but numerically far apart as 365 and 1. Sine/cosine turn the calendar into a circle, so nearby dates remain nearby in feature space.

Why lag features?

Heat events often persist. Recent maximum and minimum temperature values communicate short-term thermal buildup that one day alone may miss. But they only work operationally if those prior observations are actually available at serving time.

Mini-exercise P-A: count the features

Without looking at the list, reconstruct why the model has 17 inputs. Then say which three are engineered inside the service.

Check: 14 supplied weather/lag inputs plus departure, sine, and cosine.

Flashcards — features

II.4 Safe serving and artefact integrity

The most sophisticated implementation story in this project is backend/serving.py.

The model bundle contains:

artifacts/jaipur-fixed-v2/
  manifest.json
  model.json
  reference.json
  evaluation.json

At startup, load_runtime:

1. rejects a mixture of separate model/features/climatology environment overrides;
2. chooses one bundle directory;
3. reads the manifest;
4. checks supported schema version and expected 2015–2018 reference period;
5. computes SHA-256 for model, reference, and evaluation artefacts and compares them with the manifest;
6. loads XGBoost;
7. verifies the model’s feature names exactly match the manifest’s 17-feature order;
8. places the loaded runtime objects on FastAPI’s app.state.

Explain why this matters

An ML system is not only model.json. A prediction depends on a model, feature contract, reference climatology, and evaluation context. If someone changes one independently, the service might still return a number but that number can be invalid. The single checked bundle reduces this “silent mismatch” risk.

Mini-exercise P-B: failure mode

Imagine model A is trained with a 2015–2018 reference but someone deploys it with a reference file from a different period. Name two possible outcomes and explain why neither is acceptable.

Answer direction: feature values change in a way the model was never trained on; score distributions/threshold meaning can change; results may look plausible but be wrong. Failing startup is safer.

Flashcards — serving

II.5 Prediction, severity, persistence, and batches

The model itself returns an XGBoost score. The API converts it to a positive classification at 0.5:

prediction = 1 when probability >= 0.5

Then it applies domain logic:

• severe: positive prediction and tmax >= p98 for that calendar day;
• persistence met: the prior day is also heatwave-positive;
• alert triggered: mirrors persistence status in this response.

The important distinction:

ML model predicts a binary condition
             ↓
explicit post-processing turns it into severity/persistence/alert metadata

For POST /predict/batch, records must have strictly increasing dates. Consecutive days can derive the previous-day heatwave state from the last computed response. A gap clears that automatic continuity; the result becomes unknown unless explicitly supplied.

Mini-exercise P-C: reason about a batch

You send three records: 1 May positive, 2 May positive, 4 May positive. What is persistence for each if no first-record prior state is supplied?

Check: 1 May: unknown/None; 2 May: true because it follows a positive previous day; 4 May: unknown/None because there is a date gap.

Flashcards — inference logic

II.6 The separate risk/planning index

backend/risk.py does not estimate mortality probability. Its own code calls it a transparent planning index and returns mortality_probability: None.

Inputs include heatwave probability, severe/persistence flags, and aggregate shares for older adults, young children, outdoor workers, informal housing, and social deprivation.

It computes:

overall index = 70% heat hazard + 30% vulnerability score

Then it selects a Low/Moderate/High/Severe band, surfaces three largest contributing factors, and returns suggested municipal actions.

Why separate it from the ML model?

The classifier was trained on weather-related heatwave labels. The planning index combines that hazard signal with policy assumptions about vulnerability. It has value as explainable decision support, but it has not been fitted or validated on mortality outcomes. Keeping it separate makes that boundary visible.

Flashcards — risk index

II.7 Limitations drill

Memorise this exact, mature answer:

The committed test is a retrospective classification evaluation using realised weather, not archived forecasts issued before the target day. Its inputs and lags may not all be operationally available at a real decision cutoff, probabilities are uncalibrated, the work is single-location, and the test period had earlier inspection. Before claiming forecasting performance, I would run a time-stamped backtest using historical forecast issuance data, compare simple operational baselines, calibrate if probabilities drive actions, and validate across separate periods and locations.

Flashcards — limitations

II.8 Pyrograph mock interview

1. Explain fixed climatology in plain English.
2. Why is CSI appropriate for this kind of evaluation?
3. Trace a /predict request from JSON to result.
4. How does the service keep model/reference versions consistent?
5. Which part is ML and which part is policy/rule logic?
6. What must change before a city could use this operationally?

Fieldnotes

Fieldnotes: shared research log

Repository: rexyrocks/the-log

III.1 The story before the code

One-sentence story

Fieldnotes is a small shared research workspace where a team can store, filter, and organise findings by phase, using a React/Vite frontend, Express API, and SQLite persistence.

60-second explanation

Fieldnotes is the collaboration layer around a research project. The browser UI is React and Vite; it gets its API base URL from VITE_API_URL. The Express backend creates the SQLite schema at startup and stores findings with a constrained phase, contributor, title, body, tags, and timestamp, plus a simple roles table. The API validates fields and phase names, uses parameterised SQL, converts tags between JSON storage and arrays in responses, and returns appropriate HTTP errors. I chose SQLite for simple, portable persistence in a small project and enabled WAL mode for better read/write behaviour. For Railway deployment, the database path is environment-configured and a mounted volume prevents data loss across container redeploys. The shared access PIN is only lightweight gating; I would replace it with real server-side authentication before describing it as secure.

III.2 Data model and startup

backend/server.js starts by reading environment variables:

PORT
DATABASE_PATH
ACCESS_PIN
FRONTEND_URL

It ensures the database directory exists, opens better-sqlite3, enables WAL (write-ahead logging), then creates two tables if they do not already exist.

findings

roles

Why WAL?

WAL keeps writes in a separate log before checkpointing them back into the main database. For a small application, it generally lets readers proceed more smoothly while a write occurs. It does not turn SQLite into a distributed, unlimited-concurrency database.

Flashcards — data model

III.3 REST API: route by route

Health

GET /health returns { ok: true }. It is useful for deployment platforms and basic checks: “is the process listening and able to answer?” It is not a full database-integrity or dependency-health probe.

Findings

GET /api/findings?phase=scoping

• trims query input;
• validates the phase against a seven-value Set;
• chooses either a phase-filtered or all-findings prepared statement;
• sorts newest first by timestamp and ID;
• parses stored tag JSON before returning rows.

POST /api/findings

• receives phase, contributor, title, body, and optional tags;
• checks the phase and required text fields;
• turns tags into JSON;
• inserts with placeholders;
• selects and returns the created record with HTTP 201.

DELETE /api/findings/:id

• validates the numeric ID and a current-user header;
• loads the finding;
• allows deletion only for its author or a role whose lane includes “admin”;
• deletes or returns appropriate 400/403/404 errors.

Roles

GET /api/roles returns the role list.

POST /api/roles inserts a new role or updates one if a valid ID exists in the payload. Once roles exist, it checks whether the supplied current user is an admin before allowing role creation/update.

PUT /api/roles/:id validates the positive ID, loads the row, uses existing values for omitted fields, validates the final values, then updates it.

Flashcards — API

III.4 Browser application and state

The React app defines seven display labels and matching API slugs. For example, “Scoping & Data Recon” maps to scoping and “Dataset + ML Model” maps to ml-model.

The application keeps separate state for:

• selected tab and active phase;
• findings for a selected view and all findings for overall statistics;
• roles/team;
• loading and error state for findings and team data;
• the add-finding form;
• search string, mobile navigation, and quick-reference panel;
• selected user and PIN gate state.

Keeping loading/error state explicitly makes a disconnected backend visible rather than showing a silently empty application.

The frontend reads:

const API_URL = import.meta.env.VITE_API_URL || 'http://localhost:3000'

That enables a local default while allowing a deployed frontend to target its deployed backend.

Request lifecycle exercise F-A

Trace “Add finding” on paper:

click Add finding
→ React opens composer state
→ user fills title/body/tags
→ submit handler validates at UI level
→ fetch POST with JSON
→ Express validates again
→ SQLite insert
→ JSON 201 response
→ React appends/refreshes state and renders the card

Add error branches: bad phase, missing field, offline backend, invalid PIN, and server error.

Flashcards — React/client

III.5 CORS, lightweight access control, and the security boundary

The Express server configures CORS with a comma-separated FRONTEND_URL allowlist. It permits requests without a browser origin. An empty allowlist or a wildcard permits any origin. With a configured list, the server compares the origin to the listed entries.

If ACCESS_PIN is configured, middleware permits only /health and /api/team-names without the PIN. Other routes require an x-access-pin header equal to the configured value.

This is enough to demonstrate how middleware and environment configuration work. It is not strong production authentication:

• the PIN is shared, not tied to an identity;
• the frontend persists it in localStorage;
• a user name is supplied by the client in x-current-user;
• a caller can impersonate another displayed name;
• no session expiry, password hashing, rate limiting, or audit trail exists.

What “fix it” would actually mean

real user identity provider or local accounts
→ server-validated session/token
→ HttpOnly secure cookies where applicable
→ users/roles stored with immutable IDs
→ server derives actor identity from session
→ authorisation checks use that server identity
→ rate limiting, logs, secure secrets, tests

Flashcards — security

III.6 Deployment and persistence

The project README describes a Railway backend and separately deployed frontend. A key deployment concern is SQLite durability.

Container filesystems are often ephemeral: a rebuild/redeploy can discard local files. The deployment recipe uses a Railway volume mounted at /data, then configures:

DATABASE_PATH=/data/fieldnotes.db

The important sentence is conditional: the file persists while the same volume remains attached. It is not backup, replication, or a guarantee against accidental deletion.

Deployment exercise F-B

Explain the difference among:

1. an environment variable;
2. a container filesystem;
3. a mounted persistent volume;
4. a backup.

If you can explain all four clearly, you can handle most intern-level deployment questions.

Flashcards — deployment

III.7 Scaling and improvements

If the team grows from 5 people to 500

Say this:

SQLite was the right simplicity trade-off for a small shared tool, but for multi-instance deployment, higher write concurrency, mature access control, and richer reporting, I would migrate to Postgres. I would introduce migrations, indexes based on observed queries, a real identity model, and API/integration tests before optimising the frontend.

Suggested incremental improvements

1. Move route validation into a schema library such as Zod/Joi or carefully written validators.
2. Split App.jsx into page, findings, team, and authentication components/hooks.
3. Add backend route tests using a temporary database.
4. Make role checks server-derived from a real session.
5. Add database migrations and indexes if data grows.
6. Add pagination/search server-side when findings become numerous.

Fieldnotes mock interview

1. Why was SQLite suitable here?
2. What does WAL change, and what does it not change?
3. Trace a POST finding request and its validation.
4. How do parameterised queries help?
5. What happens if the frontend is deployed but VITE_API_URL is wrong?
6. Why is the PIN approach not strong auth, and how would you replace it?

Cross-project mastery

Cross-project mastery

IV.1 The project map

RiskSight
  strongest proof: ML fundamentals + evaluation thinking
  strongest risk: data leakage / overclaiming business value

Pyrograph
  strongest proof: time-aware ML + robust model-serving contract
  strongest risk: presenting retrospective classification as forecasting

Fieldnotes
  strongest proof: end-to-end web/API/database engineering
  strongest risk: describing lightweight PIN gating as secure auth

IV.2 Cross-project flashcards

IV.3 Explain it at three levels

Practice every project for three audiences.

IV.4 Answer templates

“What was the hardest part?”

The hardest part was not the initial code; it was defining a contract that stays correct across steps. In RiskSight that is keeping preprocessing identical in training and inference. In Pyrograph it is keeping the model, climatology, and feature order compatible. In Fieldnotes it is making persistence and the browser/API boundary explicit. I learned to look for hidden assumptions at those boundaries.

“What did you personally do?”

I implemented and integrated the code represented in the repository: [name the exact module/function], then I verified it by [metric/test/request path]. I would be careful not to claim external users, operational deployment, or outcomes that I did not independently measure.

“What would you do with two more weeks?”

First I would close the correctness risk: [leakage-free pipeline / forecast-time backtest / real authentication]. Then I would add focused automated tests around the critical request/data flow. Only after that would I work on extra UI or features.

Mock interviews

Active-recall exam bank

Do these without notes. Mark each answer green (complete), yellow (partial), or red (could not recall). Revisit every red card tomorrow.

Rapid round: 30 questions

1. Define logistic regression in one sentence.
2. Why does sigmoid appear in logistic regression?
3. What does a 0.5 threshold do?
4. Explain precision versus recall using lending.
5. What is class weighting?
6. What exact preprocessing leakage exists in RiskSight?
7. How would you save correct preprocessing for an API?
8. What does L1 encourage that L2 does not?
9. Why is a hypothetical profit table not a business policy?
10. What is a chronological split?
11. Why is it appropriate for Pyrograph?
12. What is CSI and why might it help with rare events?
13. What is a fixed climatology reference?
14. Name the three engineered Pyrograph feature types added by the API.
15. What is the model-bundle manifest protecting against?
16. Why validate feature order?
17. What turns a positive Pyrograph classification into “severe”?
18. What creates a persistence signal?
19. Why is realised weather not forecast validation?
20. Why is Pyrograph’s planning index not mortality probability?
21. Why choose SQLite for Fieldnotes?
22. What does WAL do?
23. How do prepared SQL statements help?
24. Why validate API input on the server?
25. What does VITE_API_URL do?
26. What does CORS do—and not do?
27. Why is a shared PIN not strong auth?
28. Why is a mounted volume useful to SQLite?
29. What first change would you make for each project?
30. Give your 30-second pitch for each project.

Mini whiteboard tasks

1. Draw RiskSight’s training and inference paths. Circle the point at which leakage must be prevented.
2. From memory, derive precision, recall, and CSI from TP/FP/FN/TN.
3. Draw Pyrograph’s bundle-validation path and label the three checked artefacts.
4. Draw a three-day /predict/batch sequence and explain date-gap behaviour.
5. Draw Fieldnotes’ React → Express → SQLite request path for one new finding.
6. Redesign Fieldnotes auth in six boxes, ending with a server-side authorisation check.

Code reading tasks

Open each file in GitHub and annotate it yourself.

• RiskSight: logistic_regression.py. Put a comment beside every line that changes w or b.
• RiskSight: preprocessing.py. Mark each transformation as “fit”, “transform”, or “both,” then explain why the current design leaks.
• Pyrograph: backend/serving.py. List each startup condition that can fail and what bad deployment it prevents.
• Pyrograph: backend/main.py. Find where the 17 feature values are put in the manifest-prescribed order.
• Fieldnotes: backend/server.js. For each route, list input, validation, database action, and status code.
• Fieldnotes: frontend/src/App.jsx. Find where the API base URL is read and where error state changes the visible UI.

14-day plan

14-day recall calendar

Keep sessions short and active. Stop rereading when you can retrieve.

Final check

Final pre-interview rule

Start with the problem and your contribution. Then give the data or request flow, one design decision, one result with its measurement context, and one limitation. End by naming the first thing you would change.