Notes and pet project code: teach Copilot to answer about your experience

Questions about experience come up in every interview, and generic words don't answer them. The Sobes bank has, for example, "Do you manage to learn on your own at home? Do you have pet projects?" and "What do you do in your free time? What pet projects do you have?". A follow-up always comes next: why that database, how auth works, what you would redo.

The Copilot context knows your role, stack, and resume, but the resume in it is short: text over 5,000 characters gets cut. The details that separate your answer from any other candidate's sit deeper: in project stories, numbers, and the reasons behind decisions. That's what notes, code upload, and ready-made documentation are for. The assistant doesn't invent experience that isn't in your materials, so the more facts they hold, the more specific the answers.

How Copilot finds what it needs

When the interviewer asks a question, Copilot searches your notes for fragments similar to that question and adds them to the hint. A few rules worth knowing before you start writing:

• Search works both by meaning and by words. The note title and section headings strongly affect whether a fragment is found.
• At most three fragments go into an answer, and at most two from a single note.
• The query is built from the current question and a couple of phrases before it. Text from screenshots doesn't go into the search.
• The assistant uses a note as your way of putting the topic, it doesn't read it out word for word.

Hence the main principle: one topic per note and clear headings. A long file called "Everything about my experience" works worse than ten notes with titles like "Kafka migration in the payments service".

What to write in notes

Three kinds of material pay off best.

Project stories. The situation, the task, what you personally did, the result. These are the raw material for questions about your most challenging task, conflicts, and mistakes. The notes library has a template for these stories ("About me (STAR)") and a separate "Pet project" template.

Numbers. Load, data volume, response time before and after, team size, timelines. They are the hardest thing to recall in an interview, and the thing the interviewer remembers.

Architecture decisions. What you chose, what the alternatives were, and why you settled on it. "And why not X?" comes up almost every time.

An example of a note that gets found well:

# Task queue in the notification service: why RabbitMQ and not Kafka
 
## Context
The service sends pushes and emails, up to 2M messages a day, with peaks after marketing campaigns.
 
## What we chose and why
RabbitMQ: we needed priorities and delayed delivery, and had no need to keep an event history.
We considered Kafka and dropped it: a team of three, nobody to maintain a cluster.
 
## Result
Peak delivery delay went from 40 minutes down to 3. No lost messages in a year.
 
## What I'd do differently
Move retries into a separate queue from day one.

The headings repeat the words the interviewer will use in the question. The numbers are in the text, not in your head.

For standard questions with a prepared answer, the "Questions and answers" format is convenient: the note is made of cards, and a card is always passed in whole. The format is picked when you create the note and can't be changed later. To have a card found by differently worded questions, fill in "Other phrasings".

If the project is under NDA, put an already anonymized version into notes. How to build one is covered in How to talk about an NDA project in an interview.

Folders, the search flag, and indexing status

Copilot searches notes that have "Use in RAG" turned on. New notes have it on. Turn it off for anything unrelated to your current job search: old course notes and other people's cheat sheets will get in the way of your stories. The notes panel in the overlay (Ctrl/Cmd + N) shows excluded notes too, it's your personal cheat sheet.

Notes with the flag on show an indexing status. Until a note is in the index, it can't be found by meaning, only by words.

Check the result before the meeting, not during it. The "What Copilot finds" button opens a field where you type a question the way an interviewer would ask it, for example "tell me about your experience with Kafka". In return you see the fragments that would go into the hint. If the right note wasn't found, renaming it or adding a heading with the question's key words usually helps.

Pet project code

"Upload test project" puts code into your notes, and Copilot answers questions about it: how a module works, where permissions are checked, why the structure is what it is.

• The limit is 50 files and 400 KB. .env files, node_modules, builds, and .git are skipped automatically.
• If the project doesn't fit, the app marks the essentials itself: README and manifests, entry points and routes. Tests and generated files go to the end of the list. You can adjust the selection by hand.
• Files containing something that looks like keys or passwords are unchecked on upload. If you upload such a file anyway, the values are replaced with [REDACTED] and end up neither in the note nor in answers.
• The project is stored as a single note. You can't edit it by hand, you refresh it by uploading the project again.

At most two fragments from one note go into an answer, so ask about the project specifically: name the module, file, or function. And add a regular note next to it using the "Pet project" template, describing the architecture and decisions. The code answers "how is it built", the note answers "why".

Upload only your own code. Work repositories, proprietary code, and anything you can't show to third parties don't belong in notes.

PDFs and files

File upload accepts .md, .mdx, .txt, and .pdf, and each file becomes a separate note. A scan with no text layer is recognized by a neural network. If a PDF has some pages as text and some as scans, the scanned pages aren't recognized, so mixed documents are better split.

A hundred-page course summary as one note searches poorly. Break it up by topic before uploading.

Ready-made documentation

You don't have to summarize technology theory yourself. The notes section has a "Documentation" button: a catalog of ready-made documentation for PostgreSQL, Spring, React, and other technologies. You add what you need with "Install", up to 20 per account.

Documentation works as a reference supplement on top of your notes: at most two pieces from it go into an answer, and the answer doesn't wait for it if the search runs long. Your stories stay first.

Narrowing search for a specific meeting

When you create a meeting, the "Notes for Copilot" button (folder icon) limits search to the folders you pick, and you can change that later on the meeting page. The same place controls which documentation takes part in this meeting. With nothing selected, search covers all notes with the flag on.

This helps when materials shouldn't mix. Say you have two versions of your story, one for backend and one for fullstack: put them in separate folders and pick one for the meeting.

How it shows in the answer

Under the assistant's answer there's "Sources": the note and documentation fragments the model received. A documentation piece is marked with a book icon. The model may not have used a fragment, but the sources tell you whether the thing you were counting on was found.

If you need the assistant to look up something specific, ask directly: "find in my notes what the load on the notification service was". It will then run a separate search.

What to do today

Half an hour for a first pass:

1. Write three notes using the template above: two decisions from your latest project and one story about a hard task.
2. Upload your pet project code and add a note with its architecture.
3. Install documentation for two or three technologies from the job description.
4. Open "What Copilot finds" and ask five questions you expect in the interview. Rename whatever wasn't found.

Right before the meeting, all that's left is picking the folders and going through the ten-minute pre-call checklist. Role, level, and answer style are configured separately, in the context.