Tutoring CS for Bilingual Students

I have tutored introductory programming and data structures at San José State University since August 2024, and a large share of that has been with students who are learning the material and the language of instruction at the same time. I am also a co-author on a peer-reviewed poster abstract at the ACM SIGCSE Technical Symposium 2026 on bilingual coding for inclusive computer science learning (DOI 10.1145/3770761.3777339), where I am listed seventh in the author order. The study behind it involved 60 bilingual participants — 40 novice and 20 experienced programmers.

What follows is about running a tutoring session, not about that study's results. Where the two touch, I have tried to be careful about which is which.

The first diagnostic: is it the concept or the sentence?

The single most useful habit I have picked up is refusing to treat a hesitant English explanation as evidence of a shaky concept. They correlate weakly and they get confused constantly, including by the student themselves.

Three moves separate them, and any one of them takes about ninety seconds.

Ask for a trace, not a definition. "What does a while loop do?" is a vocabulary question in disguise. "Here are three lines and i starts at 0 — what is i after this runs, and how many times did the body execute?" is a concept question. A student can answer the second one with numbers.
Let them answer in whichever language is faster. If a student explains the idea fluently in Arabic, or Spanish, or Vietnamese, and then stalls translating it, the concept is intact and the bottleneck is translation. That is a completely different intervention.
Ask them to point. "Show me the line where the value changes." Pointing has no vocabulary requirement at all and it localises the misunderstanding to a specific line rather than a general topic.

Getting this wrong is expensive in a way that is easy to miss. A student misdiagnosed as not understanding recursion gets re-taught recursion, which is boring and slightly insulting, and the actual gap — that they had never seen the word "invoke" — survives the entire session.

Keywords are symbols before they are words

Programming languages are built almost entirely out of English words, and that is an accident of history rather than a design requirement. For a student who reads English slowly, every keyword is doing double duty: it is a token the compiler recognises, and it is a word they are also trying to parse.

The move that helps is to explicitly relieve the second duty. Treat while, return, void and static as symbols to recognise, in the same way + is a symbol. Nobody learns arithmetic by learning to pronounce "plus". I will sometimes write the keyword and its meaning side by side once, in the student's stronger language, and then never translate it again — the goal is recognition speed, not vocabulary.

Two keywords deserve special care because their English meaning actively misleads:

static does not mean "unchanging" in the everyday sense, and a student reasoning from the English word will get it wrong in a specific, predictable way.
return suggests giving something back to where it came from, which is close enough to be dangerous and far enough to cause errors about control flow.

Error messages are the hardest text in the course

Compiler and interpreter errors are dense, idiomatic, technical English, often with a syntax of their own. They are the most frequent English a beginner reads and the least forgiving.

What works is teaching the shape of a message rather than its wording. Every Python traceback, for example, has the same four parts: where it happened, the call path that got there, the exception type, and the message. I have students read them in a fixed order — file and line first, exception type second, prose last — because the prose is the part that requires the most English and usually carries the least information.

Building a personal error glossary is worth the twenty minutes it costs. Five or six entries covers most of a first semester: NullPointerException, IndexError, TypeError, SyntaxError, "cannot find symbol". Each one gets the student's own one-line description in their own language, plus the two most common causes. This is not a workaround for weak English. It is what experienced engineers do too; they have just internalised it.

Session mechanics that make a measurable difference

Slow down, do not simplify. Reducing content is patronising and unhelpful. Increasing the pause after a question is neither. Three to five seconds of silence feels unbearably long to the tutor and is roughly the amount of processing time a second-language listener needs.
Write while you speak. Anything said only aloud is available once. Anything written is available for the rest of the hour, and reading is usually a student's strongest channel.
Prefer the concrete noun. "The thing at position 3" beats "the element at index 3" the first time. Introduce the technical term immediately afterwards, because the student needs it for the exam — but land the idea first.
Never ask "does that make sense?" It has one socially acceptable answer. Ask them to predict the output of a variation instead.
Give the vocabulary for asking questions in class. "Can you say that again more slowly?" and "Which line are you on?" are worth rehearsing. A student who has a sentence ready will use it; a student composing one under pressure will stay silent.

What the research supports, and what it does not

I want to be precise here, because it would be easy to overstate.

The published abstract reports pre-to-post improvements across the 60 participants in programming confidence, computing identity, enjoyment and motivation, with novices gaining more than experienced programmers. The direct bilingual-versus-English comparison was not statistically significant, and the abstract reports no percentage figures at all. Anyone who quotes you a percentage improvement from it is quoting something that is not in the document.

So the honest summary is narrow: there is directional evidence that language-aware instruction helps how beginners feel about programming, which matters because confidence is a substantial part of whether someone enrols in the second course. There is not evidence, from this work, that it produces better code. Treat the practices above as craft informed by research, not as research findings.

The thing worth carrying

Separate the logic from the language, and stop letting one stand in for the other. Once you are asking a student to trace, point and predict rather than define and explain, you find out what they actually know within the first few minutes of a session — and most of the time it is more than either of you expected.