Level 1
Explain the whole process of building , then finish XSLM yourself over . Choose one example and explain your design and reasons out loud.
Who can apply
Open to applicants aged 10 and over.
Screen-sharing interview
Share your entire screen through SONUB video, then carry out the tasks.
Level 1 interview task — build XSLM
- The examiner asks how is built — the environment, the and project structure, the , the , , text generation, the , XChat and publishing. The candidate answers right away, in their own words.
- After answering, the candidate finishes XSLM themselves over . They type and run the source, save the trained , start the Runner and get their own trained model to answer in XChat — and that ends the exam.
Type and run everything yourself, without handing it to an outside or another person. The examiner may ask what an output or a line of means while you work.
Common to every level
Example interview question: an AI that guesses the next word
Examiner Build an that guesses the next word while a student types study notes. Explain, step by step, how you would make it and how you would check that it works.
Answer in these four steps. Each step shows what to say, with a short example.
-
1. Goal
Say what the AI does and for whom — what goes in and what comes out. Example: “When a student types ‘machine’, it suggests ‘learning’.”
-
2. Data
Say what it learns from, how much, and what you keep aside for testing. Example: “2,000 sentences from my own notes — 80% to learn from, 20% kept for testing.”
-
3. How it works
Say how it works inside and what you build it with. Example: “A counts which word comes after which and suggests the most frequent next word.”
-
4. Check
Say how you know it works: one number you measure and one limit. Example: “On the test sentences, I count how often the real next word is among the top three suggestions. It looks only one word back, so long sentences go wrong.”
The examiner may change the topic — for example, a filter for spam messages or a lunch-menu recommender — but you answer in the same four steps. Higher levels explain each step in more detail, and the interview also has other questions and tasks for each level.
What to learn
- Explain every step of building in your own words — from preparing to the , , , text generation, , XChat and publishing.
- Type and run the XSLM source yourself over , all the way to chatting in XChat with the you trained.
- Check the output (, generated text, responses) and, when stuck, read the and fix it.
How you are marked
- Did the candidate explain how to build XSLM in order, fluently and in their own words?
- Did the candidate finish XSLM over screen sharing and get their own trained model to answer in XChat?
- Did the candidate check the output and explain how they fixed errors?
Practice interview questions
These 20 questions are examples of what the examiner may ask in the interview. Do not try to hit a single correct word — explain your answer out loud. Open each one to see a sample explanation and a follow-up question. They are not official exam questions.
Overall flow, environment and data
-
1
Examiner Explain what is and the whole order of building it, from preparing to chatting in XChat.
Show a sample explanation
Sample explanation XSLM (Extra Small Language Model) is a tiny you build from scratch on SONUB to learn how is developed. The order is: check the environment → folder, settings.json and data (prepare.py) → (tokenizer.py) → (engine.py, model.py) → and checkpoints (train.py) → text generation (generate.py) → (runner.py) → the XChat chat screen (xchat.py) → publishing on (export.py). It is finished when the you trained are saved, loaded again and used in XChat.
Follow-up question Why can you say XSLM is finished even if its answers are odd?
-
2
Examiner Explain why building needs no pip install, no , no and no .
Show a sample explanation
Sample explanation The on /ai/build is 32bit running in the with , and 3 is already installed. The source uses only the Python and never imports , so nothing has to be installed with pip. You train the yourself from scratch and call no outside , so no API key is needed. The computing runs on the the browser emulates.
Follow-up question What do you need to run the same source on your own computer?
-
3
Examiner Explain the folder structure of the project and the values in settings.json.
Show a sample explanation
Sample explanation All work happens in ~/xslm. holds the raw text (raw.txt), the , the and the ; checkpoints holds the trained (model.json); the sources sit right in the project folder. settings.json holds values such as width ( size), (how many tokens the sees at once), merges (number of merges), steps ( repeats), (how much to change at once), seed and .
Follow-up question What happens if you change settings.json while continuing training?
-
4
Examiner Explain the format of the (raw.txt) and how prepare.py handles it.
Show a sample explanation
Sample explanation raw.txt has one question–answer pair per line in the form "Q: … | A: …". prepare.py reads it as , drops blank and duplicate lines, and checks that there are at least five different lines, all in the right form. Then it sets aside one line in every five for validation and saves /train.txt and data/val.txt (the default data gives 12 for training and 3 for validation).
Follow-up question If you add one question–answer pair of your own, which file do you rebuild first?
-
5
Examiner Explain why the is split into training and validation sets, and why it is split by question–answer pair before turning it into .
Show a sample explanation
Sample explanation is text the never trains on, so it shows whether the model handles new text instead of just memorising. If you cut anywhere after turning text into tokens, the same example can land on both sides, so the split is done by question–answer pair first. That keeps the honest.
Follow-up question If the validation data is also used for training, what can the validation loss no longer tell you?
Tokenizer and model
-
6
Examiner Explain why a is needed and how 's character-based learns its vocabulary.
Show a sample explanation
Sample explanation A computes only numbers, not letters, so the tokenizer gives every piece of text a number. Character-based BPE starts with single characters and, as many times as merges in settings.json says, joins the most frequent pair of neighbouring pieces into a new piece. The order of the merges becomes the rules, saved in /tokenizer.json.
Follow-up question If you raise merges, how do the count of the same text and the vocabulary size change?
-
7
Examiner Explain what encode and decode are, what roundtrip: OK checks, and what happens to a character never seen before.
Show a sample explanation
Sample explanation encode turns the text into numbers one character at a time, then applies the learned merge rules in the same order to get a list of numbers; decode turns the numbers back into pieces and joins them. roundtrip: OK means the whole training text was turned into numbers and back into exactly the original. A new character is not learned — it becomes piece number 0, �.
Follow-up question If you retrain the , why can't you keep using the you already trained?
-
8
Examiner Explain what the and the position are and why they are added together.
Show a sample explanation
Sample explanation The embedding is a table that looks up a number vector (of length width) by number. The same token also needs to know which place it is in, so a , learned separately for each place, is added. Both tables start as random values and change during .
Follow-up question Why does the position vector table have as many rows as ?
-
9
Examiner Explain Query, Key and Value in , and the .
Show a sample explanation
Sample explanation Query is what the current place is looking for, Key is the of each earlier place, and Value is the information to take. Query and Key give a relevance score, turns the scores into , and the Values are mixed in that proportion. The causal mask lets each place see only itself and earlier places, so it cannot peek at the answer when predicting the next .
Follow-up question Why must the scores at earlier places not change when tokens are added later?
-
10
Examiner Explain what Value and backward in engine.py do, and the layers after (, and the ).
Show a sample explanation
Sample explanation A Value holds one number, its effect on the (grad) and a record of the for each operation. backward walks the backwards and adds up gradients, so the effect of a used several times is summed too. The MLP widens the to twice the width and narrows it again, residual connections add a layer's input to its output so no information is lost, and the output layer (head) gives a next-token score for every word in the vocabulary.
Follow-up question What decides the 's number of , and how do you count it?
Training and text generation
-
11
Examiner Explain what learns to do and the .
Show a sample explanation
Sample explanation The goal is to predict the next . If the tokens are [a, b, c], the answer for input [a, b] is [b, c]. Cross-entropy loss is the of the given to the correct token, so it gets smaller the more probability the correct token gets. A small does not guarantee the tells the truth.
Follow-up question For a model that gives every token the same probability, how is the loss related to the vocabulary size?
-
12
Examiner Explain, in order, what happens in one training step in train.py.
Show a sample explanation
Sample explanation It picks a random stretch of +1 from the , clears every 's grad to 0, computes the and gets the gradients with backward. If the total size of the gradients is over 1 it is scaled down to 1 (clipping), and × is subtracted from each weight (). Then it saves the checkpoint and prints step and loss.
Follow-up question What happens if grad is not cleared to 0?
-
13
Examiner Explain what a checkpoint stores and what is checked when training resumes.
Show a sample explanation
Sample explanation checkpoints/model.json stores the settings, the , a of the (), the , the step and the random state. It is written to a first and swapped in with , so if saving stops halfway the previous checkpoint survives. On the next run it checks that the settings, tokenizer and data are unchanged — if not it refuses on purpose, and if so it continues from the saved step.
Follow-up question Why is it risky to change the data and keep training from the old checkpoint?
-
14
Examiner Explain how you check that is going well — how to read the training and the .
Show a sample explanation
Sample explanation train.py prints the validation loss before and after training, and step and loss at every step. Each step picks a different stretch, so loss goes up and down. Do not judge by one number — compare the trend and the validation loss before and after training. If only the training loss falls while the validation loss rises, suspect .
Follow-up question How does the loss move if is far too large?
-
15
Examiner Explain how generate.py writes text and what , and seed do.
Show a sample explanation
Sample explanation It reads the checkpoint to rebuild the , then repeats: feed in the last , get the next-token scores, pick one and append it. temperature 0 picks the highest score, and a larger temperature spreads the more evenly. top_k keeps only the top k candidates, and 0 keeps them all. The same checkpoint, question, seed and settings give the same text.
Follow-up question Does more randomness make an under-trained model answer better?
Runner, XChat and publishing
-
16
Examiner Explain what the (runner.py) is, which it opens, and how you check it.
Show a sample explanation
Sample explanation The Runner is a classroom that reads the checkpoint once, takes requests and calls generate. On (loopback) at the in settings.json, returns {"status": "ok"} and /generate returns text made from the in the . Start it in the background, call /health and /generate with , and check that a bad request such as empty JSON gets 400 instead of crashing the server.
Follow-up question Why must the Runner be restarted after you train again?
-
17
Examiner Explain what XChat (xchat.py) does and the flow from XChat to the to the .
Show a sample explanation
Sample explanation XChat is only the chat screen — it never loads the itself. It reads a question, wraps it in the format (Q: … A:), sends it to the Runner's /generate as a and shows the text it gets back. The Runner writes that text with the saved weights. If the Runner is off, XChat shows a connection error instead of a fake answer.
Follow-up question Why does XChat add "Q:" and "A:" to the question before sending it?
-
18
Examiner Explain how you publish the finished on and which files you upload.
Show a sample explanation
Sample explanation export.py gathers the (model.safetensors), settings (config.json), (tokenizer.json) and the run sources into the hub folder, and reads them back to check nothing changed. Write the (), create a Public on Hugging Face, and with a Write run install → push. It is published when a git clone in another folder, followed by python3 export.py --restore . and python3 generate.py, gives the same answer.
Follow-up question If git push is rejected because of files, what did you skip?
-
19
Examiner Explain what the format is and what goes into the .
Show a sample explanation
Sample explanation safetensors is a file with a header (names, shapes, positions) in front, followed by the numbers written one after another as 4-byte values. It holds no runnable , so it is safe to read. The model card says what the is, lists the files, how to run it, the , the and its limits (it is for learning, so its answers are mostly random).
Follow-up question What do you do with the Access Token once everything is uploaded?
-
20
Examiner Explain how you would show, when you finish yourself in the interview, that your own trained is really answering.
Show a sample explanation
Sample explanation Run prepare.py → tokenizer.py (roundtrip: OK) → the engine.py check and the model.py shape check → train.py (, step, , , checkpoints/model.json) → generate.py → runner.py (, /generate) → xchat.py in order and show each output. Finally ask a question in XChat and show the answer coming back; then show that turning the off gives a connection error and turning it on brings the chat back. That makes it clear the answer comes from your checkpoint, not from a fixed sentence.
Follow-up question If the answers come out strange, what would you check first?