Interview Prep · by talent · Computing

Computing DSA — coding, computational thinking, and infocomm: judged on how a candidate reasons through a problem, not how many languages they list.

Computing DSA-Sec admits candidates into schools with a strong software, coding, and infocomm pipeline — distinct from a Robotics DSA, which centres on hardware, sensors, and physical build-and-test. Computing is about the logic that runs on the machine, not the machine itself: writing and debugging code, breaking a hard problem into steps, recognising patterns, and designing an algorithm. Schools assess this through some combination of a written or on-screen computational-thinking task, a hands-on coding or debugging exercise, a walk-through of the candidate's own apps, games, or projects, and an interview. A documented competition record — the National Olympiad in Informatics (NOI), app or game development showcases, or a Capture-the-Flag (CTF) cyber event — strengthens an application, though the headline programming olympiads sit at secondary and JC level, so a P6 candidate's record will usually be app, game, or project work rather than NOI. Selection criteria vary by school — each school sets its own tasks, interviews, and weighting — so confirm each target school's format and whether it offers a computing or infocomm talent area before locking preparation.

What trial coaches actually assess

Computing DSA-Sec assessments are usually run by the school's Computing or Infocomm department head together with a teacher who coaches the coding CCA. Singapore schools do not publish marking rubrics, and criteria differ by school — but the components converge on some combination of a computational-thinking task (often paper-based or on-screen, language-neutral), a hands-on coding or debugging exercise, a walk-through of the candidate's own projects, and an interview. MOE shortlisting draws on primary-school academic results (particularly Mathematics), participation and achievement in coding or infocomm competitions and programmes, and related CCA records, before any task. The six dimensions below are the abilities that computing talent objectively rewards across these formats — they are a synthesis of how coding aptitude and computational thinking are assessed, not any single school's published scoring sheet.

Algorithmic logic — breaking a problem into steps
The highest-signal habit is decomposition: taking a vague, hard problem and breaking it into a clear sequence of steps before touching any code. Assessors give a candidate a puzzle — sort these cards, find the duplicate, get the robot out of the maze — and watch whether they leap to a guess or first lay out the logic. A P6 who can explain a plan in plain steps, spot which case breaks it, and refine it is signalling exactly the reasoning that competitive programming and computer science are built on. Producing working code matters less than showing the logic underneath it.
Programming implementation
Most P6 computing candidates know Scratch or another block language; a meaningful minority can write Python or basic JavaScript. Assessors don't expect production code — they expect clean logic, sensibly named variables, loops and conditions used correctly, and the ability to talk through what each part does. A common task is reading someone else's short program and predicting its output, or extending it by one feature. Coaches watch naming and structure: a variable called "score" beats "x", and a loop beats ten copy-pasted lines.
Computational thinking — patterns and abstraction
Beyond any one language, can the candidate recognise a pattern, generalise it, and ignore the irrelevant detail? Assessors probe this with language-neutral tasks: spot the rule in a sequence, describe how you'd give precise instructions to someone who follows them literally, find the most efficient route. This is the part of the assessment that tuition rarely drills and that separates a child who has memorised syntax from one who actually thinks computationally. It is also the most transferable signal — it predicts how the candidate will handle topics the school hasn't taught yet.
Project portfolio — apps, games, and things built
What has the candidate actually built? A Scratch game, a simple Python tool, a small app or website, a micro:bit project — anything finished enough to demonstrate and talk about. Assessors don't want a list of courses attended; they want one project the candidate owns, can demo, and can explain honestly: what it does, what was hard, what they'd change. A modest project the child can speak about with real ownership beats an ambitious one they clearly had heavy help on.
Debugging resilience
Code rarely works the first time, and how a candidate behaves when it breaks is one of the clearest signals in the whole assessment. A common task hands the candidate a program with a bug and asks them to find it. Assessors watch the method: do they read the error, form a hypothesis, test it, and narrow down — or do they panic and randomly change things? Calm, systematic debugging under a watching adult shows the temperament that long-term computing work demands. Frustration tolerance here matters more than raw speed.
Communication — explaining technical thinking
Can the candidate explain how their code or algorithm works to someone who isn't a programmer — in plain words, without hiding behind jargon? Assessors may ask a candidate to walk through their own project or to describe how they'd solve a problem out loud. The signal is clarity and structure, not vocabulary. Much computing work is collaborative, so the ability to make a non-technical panel genuinely follow a logical idea in ninety seconds demonstrates a maturity that a working program alone never reveals.

Position-specific focus

Competitive programming

For candidates whose strength is algorithmic problem-solving under time pressure — the profile that maps onto the National Olympiad in Informatics (NOI) pathway in the upper school. The signal is speed and rigour in turning a problem into a correct, efficient algorithm, usually in Python or C++. Note that NOI itself is a secondary-school and JC competition, so a P6 candidate's record here will be informal — strong performance on coding-puzzle platforms or junior contests — and that is entirely normal; assessors look for the reasoning, not a medal a P6 couldn't yet have won.

App & game development

The most common P6 computing profile: a candidate who builds things people can use — a Scratch or Unity game, a simple mobile or web app, an interactive tool. The signal here is finishing something, iterating on it, and being able to demo and explain it with ownership. Adjudicators look for evidence of real iteration (version two fixed what version one got wrong) over a single polished-looking demo, and for genuine understanding of the code rather than a template the child assembled with heavy adult help.

Computational thinking

For candidates whose strength is the underlying reasoning rather than any one tool or language — decomposition, pattern recognition, abstraction, and precise step-by-step logic. This profile suits the child who is strong at Math and logic puzzles and picks up new coding concepts fast, even without a long portfolio. Adjudicators value this highly because it is the most transferable signal: it predicts how the candidate will cope with the school's curriculum, including topics and languages they have not yet met.

Infocomm projects

For candidates drawn to the applied infocomm side — using technology to solve a real problem, basic cybersecurity (Capture-the-Flag style puzzles), data, or digital media projects. This maps onto the Infocomm Club and applied-technology tracks many schools run. Adjudicators look for a candidate who has actually done something with a purpose behind it — a tool that solved a problem they noticed, a CTF puzzle they cracked — rather than one who only voices general interest in technology.

These are emphases, not rigid streams. Most strong P6 computing candidates straddle two — a game-builder whose real strength is the algorithmic thinking underneath, or a computational-thinking child who happens to have built an infocomm project. Schools do not expect a Sec 1 candidate to commit to a single track; the focus areas exist to help families recognise which of their child's strengths to put forward most clearly.

Sample interview questions

Q1
"Why computing, and not robotics?"
Subtext:

STEM-leaning families often apply to both. The panel wants to know the candidate understands the difference, not just that they like technology.
Approach:

Distinguish the two honestly. Robotics centres on hardware — sensors, motors, physical build-and-test. Computing centres on the logic and code that runs on the machine. Say which actually pulls you and why.
Template
"I've built robots, but the part I lost track of time on was always the code — figuring out why the line-follower drifted, not wiring the sensor. With robotics the hardware limits what I can try; with pure code I can build a whole game or tool with just a laptop. The logic is the part I actually enjoy, so computing is the honest fit."
Q2
"Walk us through something you've built."
Subtext:

The panel wants method, iteration, and genuine ownership — not a list of courses or a demo the child clearly didn't write.
Approach:

Pick one project. What it does, what was hard, what broke, what you changed. Spend most of the time on the hard part and the fix, not the features.
Template
"I made a Scratch game where you dodge falling blocks. The first version let the player walk through walls — my collision check only looked at the centre, not the edges. I fixed it by checking all four corners. That bug taught me more than the rest of the game; now I test edge cases first."
Q3
"Here's a short program. What will it print — and there's a bug, can you find it?"
Subtext:

Tests reading code and systematic debugging directly — the method matters more than getting it instantly.
Approach:

Trace it line by line out loud. State what each step does, predict the output, then locate the bug and explain why it's wrong before fixing it.
Template
"Let me trace it. The loop counts up, but it starts at 1 and stops before the last item — so it skips the final element. That's an off-by-one error. I'd change the start to 0, or the condition to include the last index, and run it again to check."
Q4
"Explain how one of your programs works to someone who can't code."
Subtext:

Tests technical communication — clarity and structure over jargon.
Approach:

Pick something you genuinely understand. Use one everyday analogy. Check yourself: would a parent who's never coded follow it?
Template
"A loop is like telling someone "keep stamping passports until the queue is empty" instead of writing out the same instruction a hundred times. My game uses one to move every falling block down a step, over and over, so I write the rule once and the computer repeats it."
Q5
"You're given a problem you don't immediately know how to solve. What do you do?"
Subtext:

Computational thinking under uncertainty. The panel wants a method, not 'I'd search it up' or 'I'd ask the teacher.'
Approach:

Describe decomposition: break it into smaller parts, solve the easy part first, try a small case, look for a pattern. Show you have a process when you're stuck.
Template
"I start small. If the problem is for a hundred things, I try it for two or three on paper first and look for a pattern. I break it into parts and solve the part I do understand, then build out. Usually the small case shows me the rule for the big one."
Q6
"What coding or tech have you explored on your own, outside class?"
Subtext:

Self-direction and genuine interest. Generic answers ('I watch coding videos') fail; one specific thing chased on the child's own initiative succeeds.
Approach:

Name one specific thing you taught yourself or kept tinkering with, and what you made or learned from it.
Template
"Nobody taught me Python, but I wanted my Scratch ideas to run faster, so I followed free tutorials and rewrote my dice game in it. I got stuck on random numbers for days before it clicked. Now I prototype small tools in Python whenever an idea won't fit in Scratch."
Q7
"If our school and another both offer you a computing place, how would you choose?"
Subtext:

Tests honesty under pressure and whether the family has researched this school's actual computing or infocomm pipeline.
Approach:

Don't dodge. Name one specific thing about this school's computing or infocomm program and commit to a reason.
Template
"Honestly, your school — your students compete in the National Olympiad in Informatics every year and your Infocomm CCA runs an app-building showcase. That competitive coding track is exactly what I want to push myself on, so I'd choose here even if the other called first."

Schools that offer this talent via DSA

Hwa Chong Institution (Secondary)
Computing / Infocomm, IP
Computing and Infocomm listed among HCI's DSA talent areas, covering computational thinking, coding, and algorithmic problem-solving through the six-year Integrated Programme. As a SAP school, HCI weights bilingual (Chinese-English) capability and Chinese cultural engagement alongside technical merit. Confirm the current-year talent-area list and selection format in HCI's DSA brief.
St. Joseph's Institution (Secondary)
Computing / Coding, DSA-Sec
Listed among schools offering a coding / computing DSA talent area. Confirm the current-year talent-area list, task format, and weighting directly with the school's DSA brief.
Ngee Ann Secondary School
Computing / Coding, DSA-Sec
Listed among schools offering a coding / computing DSA talent area. Confirm the current-year talent-area list and selection format directly with the school.
Commonwealth Secondary School
Computing / Infocomm, DSA-Sec
Offers DSA in computing- and infocomm-related talent areas, with an applied and project-based orientation. Welcomes candidates with a documented coding or app/game project record. Confirm the current-year talent-area list with the school.
Bukit View Secondary School
Computing / Coding, DSA-Sec
Listed among schools offering a coding / computing DSA talent area. Confirm the current-year talent-area list and selection format directly with the school.
Methodist Girls' School (Secondary)
Computing / Infocomm, IP
Computing-related talent areas sit within MGS's IP, which leads to the IB Diploma in senior years. Confirm whether a computing or infocomm talent area is offered in the current year, along with the selection format, in the school's DSA brief.
Serangoon Secondary School
Computing / Infocomm, DSA-Sec
Confirm with the school whether a computing or infocomm talent area is offered in the current DSA year — talent-area lists change annually and not every school runs a computing track each year. Request the task format and weighting before preparing.
Yuan Ching Secondary School
Computing / Infocomm, DSA-Sec
Confirm with the school whether a computing or infocomm talent area is offered in the current DSA year. Where offered, request the task format and weighting directly before preparing.
St. Patrick's School
Computing / Coding, DSA-Sec
Confirm with the school whether a coding or computing talent area is offered in the current DSA year. Where offered, request the task format and weighting directly before preparing.

Open school finder

Parent-as-coach checklist

Lead time — when the task is still weeks out

Help your child finish and document one project as a single artefact: what it does, the hardest part, what broke, what they changed. One project they can demo and explain with real ownership outweighs a list of coding courses on the application form, and it becomes the thing they talk about at interview.
Drill computational thinking, not syntax. Hand your child unplugged logic puzzles — give precise instructions to someone who follows them literally, find the rule in a sequence, plan the most efficient route. This is the part schools test that most coding tuition skips.
Practise reading and debugging code, not just writing it. Show your child a short program with a bug and have them trace it line by line and find the error. Schools test calm, systematic debugging far more than they test how fast a child can type fresh code.
Confirm two things directly with each target school: that it offers a computing or infocomm talent area this year (the lists change annually), and what the selection task looks like. Then run a mock interview using the questions above, especially "Why computing, not robotics?" and the school-choice question.

Tapering — final week

Stop learning new languages or frameworks. Cancel any last-minute coding bootcamp — final-week load rarely helps and usually adds nerves. The task rewards reasoning your child already has, not syntax crammed this week.
Rehearse the one-project walk-through until it lands in about 90 seconds — smooth, with the hard-part-and-fix at the centre. Make sure the project actually runs on the device they'll bring, and have a backup (screenshots or a recording) in case it won't load.
Confirm logistics in writing: time, venue, attire, whether to bring a laptop or the school provides machines, and which language(s) the coding task expects. Email the teacher-in-charge if anything is ambiguous — the email itself signals an attentive family.
One practice explanation to a non-coder. Have your child explain how a program works to an adult who can't code (a neighbour, a relative). Explaining technical logic under unfamiliar eyes is exactly what freezes kids on the day — force the awkwardness early.

Day of the task

Eat about 90 minutes before — protein, not sugar. Debugging and a computational-thinking task reward steady, patient thinking; a sugar crash mid-task is visible to a panel.
Bring the project on a charged device, plus a charger and a backup (screenshots or a short recording). Tech fails on the day; a child who shrugs and shows the backup looks more capable than one whose demo crashes and panics.
Drop off, don't hover. Greet the teacher-in-charge, leave. Over-involved parents are visible and the child absorbs the cost.
No post-mortem in the car. One question only: "What's one thing you'd do differently?" Anything else waits 24 hours. Replaying a bug they couldn't fix during the wait only corrodes the next task.

If the runway is short

If you came to this page late — application in, task coming up, no clear plan — there are still real moves. Don't try to learn a new language this week; the task rewards reasoning, not fresh syntax, and a crammed framework won't hold under pressure. Instead, take the most genuine thing your child has ever built — a Scratch game, a small Python tool, even a half-finished app — and turn it into a tight 90-second walk-through: what it does, the hardest part, what broke, what they changed. Rehearse it five or six times until it's smooth and specific. Then drill the two skills schools test that tuition skips: tracing and debugging a short program with a bug in it, and unplugged computational-thinking puzzles (find the rule, give literal instructions, plan the efficient route). Those moves buy composure and sharpen the logic your child already has. Some families bring in a private coding coach at this stage; a good one can stabilise nerves and tighten the explanation, but no coach manufactures, in three sessions, the algorithmic instinct that months of building and debugging build. Treat it as triage, not a fix.

Get notified when this page goes deeper

We send one short email when this talent page gets a meaningful update — new questions, school changes, parent reports.

Subscribe to parent list

All interview prep