My 7 tips for successfully getting through a school admissions panel

It has now been more than two years since I have regularly served as a juror for coding schools across France (mainly Tours, Nantes and Paris for now) for the DWWM and CDA professional certifications.

I very often find myself giving the same advice to students for their oral defense, so I decided to gather, once and for all, all this advice into a single blog post:

#1 - Don't be afraid of the jurors

We regularly come across students who shake, lose their composure, get their words mixed up and who are on the verge of self-sabotage because of the stress caused by presenting in front of a jury.

Remember that jurors are only there to validate the skills you present to them based on the framework they've been entrusted with, and nothing else! Their job is not to scare you, put you down or point fingers at you—quite the opposite.

I have yet to meet a juror whose goal wasn't to help students improve!

#2 - Proofread your report and have others proofread it too

Even after proofreading, one or two typos may slip through here and there, but leaving a mistake in every line or paragraph really gives the impression that the student didn't put enough care into their report, and can sometimes even make reading and conveying information difficult!

Ideally, have at least two other people proofread it in addition to yourself.

#3 - Number your slides

It's a small detail, but it matters! When you present your slides, if one of the jurors has a question, they have to wait until the end of your presentation, and if the question is about a specific slide, they won't be able to note down its exact location.

On your end, when you need to go back to it, you'll spend 5 minutes trying to find it, which will kill the pace of the defense!

Numbering your slides will help both the juror and yourself—two birds, one stone!

#4 - Take readable code screenshots

We (almost) all love using our code editor in dark mode, but taking screenshots of your code directly from your editor is not at all suitable, neither for your report nor for your slides!

• Too much ink is used and the print quality is often not great
• The projector's contrast makes the code unreadable

Instead of taking a screenshot of your editor, go for a specialized tool as I present in the article above, and choose a light theme!

#5 - Add hidden slides

Hidden slides are slides available at the end of your presentation, after the thank-you slide, which allow you to positively surprise the jury, but also help you during your presentation.

Here are some examples of hidden slides that can be useful:

• Anticipate questions on a point you didn't cover during your presentation due to lack of time
• Help you answer complex questions (security, for example)
• Show diagrams or code that would have made the initial presentation too heavy
• ...

When you get to the topic in question, boom, you pull out your hidden slide and it's usually a very pleasant surprise!

#6 - Know how to say "I don't know"

I've seen several times students justify choosing a particular technology because it's "faster" or because it's "better than the rest," without really understanding how the tool in question works internally or its actual performance.

Don't be afraid to say "I don't know," or "we made this choice because it seemed like the best option, without knowing all the alternatives"! Or better yet, pull out the benchmark for the technology you're using, and then you can say "because it's faster"!

You're a student, you're not even a junior developer yet, you're allowed not to know many things.

The most important thing is to show that you want to learn what you don't yet know!

#7 - Don't blame others

Even as a student, you should maintain a professional attitude, so saying "it's a classmate's fault" or "it's because the instructor..." or even blaming the school won't get you anywhere.

You can point out where something went wrong, without blaming a specific person or entity.

The purpose of a developer is to solve problems, so you can take ownership of the fact that you encountered a problem (organization, knowledge transfer, etc.), that you didn't find a solution, and explain what you could have done afterward to solve it!