Building a project you can still defend

The interview that ends it

You submit a project. The interviewer opens it and says: ”Walk me through this function. Why a left join here rather than an inner one?”

If a model wrote it and you accepted it, you will not know. There is no recovery from that moment, and it is not because anybody objects to the tool: it is because the entire purpose of the artefact was to show how you think, and it now shows how something else thinks.

The rule that survives contact

Anything you would be asked about in an interview, you type yourself.

That is a small set, and it is not the whole project. Concretely:

• Type yourself: the schema and the joins, the metric definitions, the evaluation, the decisions about missing data, anything you will describe as a judgement.
• Delegate happily: boilerplate, argument parsing, the matplotlib incantation for a second axis, a regular expression, a Dockerfile skeleton, converting a script into a module, writing the docstrings.
• Delegate and then read carefully: anything that touches correctness, because of the next section.

The dividing line is not difficulty. It is whether a reviewer would ask why.

Silently wrong is the real risk

Generated data code fails in a particular way: it runs, produces plausible output, and is wrong. Three examples that recur:

• df.groupby('region') drops rows where region is null, because dropna=True is the default. Your totals are quietly short and nothing errors.
• A join that should be one-to-many is written as one-to-one, so rows multiply and every sum is inflated. The code is fine; the arithmetic is not.
• A deprecated argument from a version two years old, which either warns or silently changes behaviour.

The defence is not vigilance, which fails. It is a check that runs: assert the row count after a join, assert that totals reconcile to a number you computed by hand on ten rows, print the null counts before and after. Twenty lines of assertions catch all three of the above and cost less time than finding one of them the hard way.

Learning while using it

There is a real tension here and it deserves a straight answer rather than a slogan.

Reading a correct solution feels like learning and mostly is not. What encodes a skill is the effort of producing something and being wrong. An assistant removes exactly that effort, which is why it can make you faster this month and no better in six.

The practical compromise that works:

1. Attempt first, then compare. Write your version, however clumsy, then ask for a critique. You keep the productive struggle and still get the correction.
2. Never move on from code you do not understand. When something appears that you cannot explain, stop and ask what each part does until you can. This is the single habit that separates people who learn with an assistant from people who do not.
3. Keep a decisions file. DECISIONS.md, one line per choice: what you did, what you rejected, why. Written as you go, it takes seconds; reconstructed later, it is fiction. It is also, conveniently, the raw material for the case-study page.
4. Delete and rewrite one component from memory at the end. If you cannot, you did not learn it, and now you know that before an interviewer does.

Disclosure

Say what you used. A line in the README (“Used an assistant for boilerplate and plotting; the schema design, join logic and evaluation are mine”) costs nothing, is increasingly expected, and pre-empts the suspicion.

Nobody competent will reject you for using the tools their team uses daily. They will reject you for not being able to explain your own submission, and those are different failures with different fixes.

The limitation

The evidence on assistants and learning is unsettled. Studies find real productivity gains on well-specified tasks and weaker or negative effects on retention and on debugging unfamiliar code, and the picture differs sharply between novices and experienced developers. Anybody telling you confidently that assistants either destroy learning or do not affect it is ahead of the evidence.

What is not in dispute is the interview: you will be asked to explain your work by somebody who is good at telling. Build so that you can.