Most tech Werkstudent interviews are shorter and less procedural than students expect going in. There is usually one round, not five, and it is over inside forty five minutes. That is good news, because it also means there is very little time to recover if you fumble the one question the whole conversation tends to be built around.
What the format actually looks like
Expect thirty to forty five minutes, often over video, sometimes on site. The room is small: the hiring manager, and sometimes one engineer or team member who will actually work with you day to day. There is rarely a panel, a whiteboard coding test, or a second technical round for a Werkstudent-level role. That machinery is mostly reserved for graduate and full-time hiring.
The structure is usually loose rather than scripted: a few minutes on you and your background, a stretch on your experience and your stack, a question or two on logistics, and a short window at the end for your own questions. Few interviewers stick rigidly to a list, but most tech Werkstudent interviews cover the same ground in some order.
The question that decides most interviews
"Walk me through a project you built."
This is the one question almost every tech Werkstudent interview asks in some form, and it is where most students lose the interview without realising it. The typical answer is a description of a university assignment: a group project completed to a brief, graded by a professor, with no decisions the student can actually take credit for and nothing anyone outside the course can go and look at.
That answer tells an interviewer almost nothing. What they actually want to hear is what you chose to do, why you chose it, what went wrong along the way, and what you did about it. Coursework rarely gives you any of those, because the brief, the dataset and the grading criteria were all handed to you.
The fix is not a better story about the same coursework. It is having one real answer ready: a project where you made an actual decision, hit an actual problem, and can point to the result. If a stranger can click a link and see what you built, and better still see it independently graded, the whole question stops being a gamble.
The other questions that recur
Availability and semester planning. How many hours a week can you commit, for how many semesters, and around which exam periods. Know your own calendar before you walk in. Vague answers here read as poor planning, not flexibility.
Basics of the stack they use. Not mastery, just honesty about where you actually stand. Naming a tool you have never touched to sound impressive tends to unravel within one follow up question, and an interviewer who catches it stops trusting the rest of your answers too.
Why this company, specifically. Not "I love your mission." Something that shows you looked at what the team actually does and can say one concrete thing about it.
How to actually prepare
Do not prepare a script. Prepare two short stories you can tell in under two minutes each.
The first is your project story: what you built, one decision you made and why, and one mistake you caught and fixed before it mattered. Interviewers remember the mistake more than the success, because catching your own error is the clearest signal that you can be trusted with something real.
The second is your availability story: hours, timeline, exam periods, stated plainly and without apology.
Practise both out loud, not just in your head. The gap between knowing what you want to say and actually saying it smoothly under a bit of pressure is bigger than most students expect, and thirty seconds of silence at the start of an answer costs more than the content of the answer itself.
An interviewer asks you to walk them through a project you built. What is the strongest thing to lead with?
Before your next interview
Write down your two short stories this week, not the night before your next interview. If your project story is currently a coursework assignment with no link anyone can check, that is the gap to close first. Read what to expect in a German interview more broadly for the etiquette and stages around this core exchange, and check how many hours you are actually allowed to work before you commit to an availability answer you cannot keep.
