Devoxx is the biggest conference for developers in France. It takes place yearly in Paris, lasts 3 whole days and gathers more tham 3200 people. More than 170 conferences are presented (under different formats: keynotes, universities, quickies, hands-on-labs and conferences) around very diverse themes (web, UX, Java, big data, cloud...).
In addition to being the year that marked its great return after a period of significant pandemic, the conference of passionate developers celebrated its 10th anniversary this year!
Warning: Devoxx France being a French conference, most of the content are only available in French.
It would have been a shame to write an article without speaking about my experience as a speaker, wouldn't it? 😄
I had the honnor to be selected to present two talks; a first one about the state managements in React, and another one about MJML email templates.
I'll publish other articles soon to share about the process of CFP submission and my experience as a speaker.
Speakerine: Amélie Benoit
Sources on Github (slides + code): https://github.com/abenoit/react-states
Résumé: Que nos applications soient legacy ou complètement nouvelles, la question du stockage et de la gestion des données est une constante. Il existe aujourd'hui de nombreuses façon de gérer ce state, mais peu de guidelines fortes.
Avec des exemples de code, nous verrons ensemble trois acteurs majeurs de la gestion du state en React aujourd'hui: de la solution native à Recoil en passant par Redux-toolkit.
Speakerine: Amélie Benoit
Sources sur Github (slides + code): https://github.com/abenoit/email-templates
Résumé: Vous êtes la personne qui s'est portée volontaire pour écrire les templates HTML pour la prochaine campagne d'email de votre entreprise. Mais qui dit HTML, dit interprétation de rendu. Votre expérience avec Internet Explorer vous avait déjà laissé quelques traces, et votre instinct vous dit - à raison - de vous méfier tout autant des client mails qui liront votre template...
Un ami vous a parlé de MJML, un framework spécialement dédié à la création d'emails responsive. Technologie qui vous est inconnue, vous vous lancez pour trouver la meilleure solution - de l'écriture à la validation - de vos templates d'emails.
As always, keynotes open our mind about the ecosystem and its repercussions. 6 keynotes spread over 2 days, as many topics presented I've summed up in the skechnotes below. Pour Devoxx France's 10 year anniversary, the organizers wondered: what will our ecosystem look like in the next 10 years? This is under this theme of sustainability and future of tech that the keynote were all about.
I am not going to make a list of ALL the conferences presented at Devoxx France (there are way too many of them for such a small article!). All the videos are published online if you would like to watch them. Here is a palmares of the conferences I had the chance to attend to and that I liked the most!
As a front-end developer, it was more out of curiosity that I sat down for a 3 hour conference about hexagonal architecture (I've already played with DDD but I can't say that I'm a fluent back-end dev). In the end, all the concepts were naturally and clerly brought with concrete example; I did not see the time passed, I laughed and had a very nive moment.
Through a story of legacy code to bring back to life, the speakers provide solutions to help re-work on code that no one masters (legacy, side effects, no / few tests, cross dependencies ...).
Speakers:
Résumé: Votre backend n'a même pas 3 ans et pourtant, il n’est pas en forme. Il devient difficile d’y ajouter de nouvelles fonctionnalités, de maintenir et/ou de refactorer l’existant. Le code est intolérant à la montée de versions de librairies, pouvant lui causer une régressionnite fonctionnelle aiguë. Les tests deviennent douloureux à l’écriture.
Les précédents choix techniques ont comme effet secondaire de limiter ou verrouiller l’évolution du logiciel, à un point où il devient tentant de repartir de zéro. Votre backend commence lentement à pourrir, son architecture s’étant sclérosée.
Mais savez-vous qu’il existe différents types de complexité logicielle ? Et que bien les identifier en les séparant avec un pattern d’architecture adapté, peut améliorer la pérennité de nos applications ? Et tout ça, quels que soient les frameworks que vous utilisez ?
Dans cette opération à code ouvert sous forme d’un mob-programming intéractif, venez découvrir comment redonner un coup de jeune à votre backend à bout de souffle en le faisant migrer vers de l’Architecture Hexagonale.
My favorite talk of Devoxx France 2022! Marcu gives explanations about minorities feelings within the tech ecosystem, along with some keys to help them to be included better.
Speaker: Marcy Ericka Charollois
Résumé: Les femmes sont sous-représentées dans le domaine du numérique. Elles représentent à ce jour uniquement 30% des salariés, tous métiers confondus.
Que s´est-il passé dans ce secteur professionnel pourtant dominé par la gente feminine lors de sa génèse ? Les femmes ne se sentiraient-elles plus ou pas à leurs places ?
Pourtant, les femmes communiquent. Hélas, bien souvent, on ne les écoute pas. Résultat ? Migration vers des métiers corollaires, brown-out, désincarnation dans l'équipe, démission, création de la FemTech et de safe places comme lieux d'expression communautaire.
Alors, si vous voulez favoriser la mixité et que vous avez saisi que la cause des femmes dans la tech est une brèche pour résoudre, en plus, la problématique de la diversité et de l'inclusion, venez découvrir comment améliorer vos pratiques !
Marcy Ericka Charollois : Auteure en social tech, content strategist, fondatrice de Merci Marcy et The Safe Place. Ancienne rédactrice en cheffe de WeLoveDevs pendant 2 ans. J'y étais la première femme embauchée. Oui, en plus de ça, j’étais la première femme racisée et LGBTQIA+.
Je me rends vite compte que peu de personnes comme moi sont représentées dans la tech. J'ai alors choisi de prendre une plume plus engagée pour valoriser la diversité en brisant le ciment des faux-semblants des valeurs d'entreprise.
Je milite afin de créer une cohésion véritable au sein des équipes, en leur permettant d'incarner une culture d'inclusion authentique au delà du bullshit.
We probably all have already had mob-programming sessions in our companies; this has become a recurring practice for those developers at Ouest France. Return on their experience and share of the attention points for a mob-programming that works!
Speakers:
Résumé: Shérif, le manager, est en colère. Il vient de surprendre toute l’équipe de développement autour d’une même machine. Rendez-vous compte ! Après des comparaisons douteuses avec la DDE, il les a bien sermonnés et leur a ordonné de retourner à leur poste de travail immédiatement, un peu de sérieux ! Avec Shérif, la bamboche, c’est terminé !
Malheureusement, des Shérif, il en existe encore beaucoup dans les open-spaces de nos DSI. Partager un ordinateur entre plusieurs développeurs, mais pourquoi donc ?
Le MOB programming est une pratique s’appuyant sur le Lean et sur Extreme Programming qui consiste à réaliser une tâche, qu’elle soit technique ou non, à plusieurs. Les groomings, planifications et autres réunions de conception, ne serait-ce pas déjà des MOBs ?
De mythe à réalité, nous vous proposons de faire un retour d’expérience du MOB programming dans une équipe produit chez Ouest-France. Nous vous offrirons deux points de vue, celui du lead, présent depuis le début du projet (5 ans) et celui d’un développeur qui a rejoint l’équipe début 2021.
The pyramid of tests, we all know about it. Jonathan explains why he came into questioning all of those principles, what wasn't working, and what is important to keep in mind when we write tests in our application.
Speaker: Jonathan Boccara
Résumé: Tester son code c'est facile à dire, mais écrire des tests utiles dans du code en entreprise, c'est pas toujours facile à faire.
En théorie les tests doivent nous aider, pourtant: - Le code ne se prête pas toujours aux tests unitaires, - On se retrouve parfois à refactorer les tests quand on refactore le code, - La pyramide des tests est souvent inversée, - Certains tests sont toujours verts, sauf quand ils sont rouges pour de mauvaises raisons, - On a beau tester le code, on a toujours des bugs, - Etc.
La meilleure façon d'éviter ces problèmes est d'avoir les clefs pour choisir le bon test à écrire (ou à ne pas écrire!) en fonction du code à tester.
Le but de cette présentation est de vous rendre autonome sur votre stratégie de tests, en vous présentant les tenants et aboutissants des différents types de test et du testing en général.
En particulier vous verrez: - pourquoi la pyramide des tests est contre-productive - quand écrire des tests unitaires et quand ne surtout pas en écrire, - comment rédiger des tests robustes et clairs - les différentes abstractions que l'on peut tester
Venez prendre du recul sur le testing et faites les bons choix dans vos tests!
Once again, I stepped out of my comfort zone by assisting a conference on a tool I do not master: Kubernetes. And it was in a very accessible way and with a background of good mood that Aurélie and Gaëlle explained to us why writing a Kubernetes plugin is interesting according to need, and they even wrote one live!
Speakerines:
Résumé: Kubernetes est assez complexe comme cela … mais savez vous qu’il est possible de rajouter des fonctionnalités à notre orchestrateur préféré grâce aux plugins et à un petit outil : Krew ?
Nous verrons dans ce talk, qu’en quelques minutes il est possible de créer un plugin à Kubernetes permettant de rendre plus user-friendly nos pods (selon la thématique saisonnière ^^). Mais ce n’est pas tout ! Le but est aussi de le partager aux autres et pour cela, Krew est “The place to be”. A la fin de ce talk vous aurez toutes les billes en main afin de pouvoir réaliser & partager votre propre plugin.
One of my favorite conference, during which I have discovered the public speaking skills of Julien Topçu (for the second time actually, as he was also presenting the conference about hegaxonal architecture). Julien brings us in a scripted universe about explanations and evolutions that brought us with today's implementation of OAuth 2, through allegories that help us to understand terms and concepts that can be complex. Clear (even limpid) and fun, don't miss watching this conference to better understand what is hidden behind this authorization mechanism!
Speaker: Julien Topçu
Résumé: Il est très difficile aujourd'hui de déployer une application sur le web sans se frotter à OAuth2. Conçu pour mieux protéger les utilisateurs et les utilisatrices, ce standard de délégation d'autorisation s'est totalement imposé dans l'industrie.
Cependant, n'avez-vous pas pleuré en essayant de comprendre les concepts de OAuth2 ? On ne va pas se mentir, entre les différents rôles et la multitude de flows qui le constituent, il y a vraiment de quoi se perdre et sa complexité en décourage plus d'un ! Et pourtant, on ne peut pas s'en passer, donc on y va et généralement c'est douloureux…
Mais ne vous inquiétez pas, que vous ayez un profil tech ou non, ce talk va vous permettre d'enfin comprendre les méandres de OAuth simplement, dont la nouvelle version 2.1, en s'appuyant sur des analogies de la vie courante !
When joining a company, the salary is important but it shouldn't be the only things to look at. For example with startups, employees are offered other advantages - with sometimes scarny acronyms. Damien explains clearly and in a simple manner what they correspond to, and why it could be interesting to take them into account!
There is a calculation mistake in this sketchnote, I haven't fixed it yet.
Speaker: Damien Pacaud
Résumé: De plus en plus d entreprises proposent, en complément de la rémunération, des « packages d’équity ».
C’est un cercle vertueux qui démarre en Europe et il peut être utile de prendre ces éléments en compte lorsque vous cherchez votre nouvel emploi.
Bien souvent, les développeurs en France considèrent peu ces éléments de rémunération et n'y prêtent pas beaucoup d'attention.
Ce talk a pour but de démystifier le monde bizarre des BSPCE, AGA, RSU, Warrants et autres Stock options.
Benoît explains very clearly what DataClasses are in Python, a new feature also appearing in Java 17 under the name of Records. They are useful in a large number of cases (especially on a DDD-based back-end).
Speaker: Benoît Prioux
Résumé: Les Records sont l’une des nouveautés les plus attendues avec la sortie de Java 17. Des concepts similaires ont déjà été introduits dans d’autres langages: data class en Kotlin, @dataclass en Python, case class en Scala.
Pattern assez simple de premier abord, les records vont devenir un véritable indispensable de votre boite à outils de développeur.
Après un tour d’horizon des implémentations dans les différents langages, je vous propose de vous partager différents cas d’utilisations pour du pattern matching, du DDD et même pour des monoids 😱.
Of course, there are still plenty of amazing content I haven't talked about and that is available to watch on Devoxx France's YouTube channel.
This year, once again, I spent an incredible moment at Devoxx France. 3 days, intense but with so many people I met and so fulfilling! I did not speak about the BoFs (Birth of Feather) where a small group of people can share about various topics (hello Duchess France!), the concert, the wine & cheese event, the closing keynote provided by the cast-codeurs... Maybe the opportunity to write a second article!
]]>The conference lasts one whole day, during which 3 cinema rooms have been re-organized to receive speakers and participants. Comfortable seats, giant screen... It was quite an incredible experience!
I was incredibly surprised by all the efforts the organization team put into:
Huge shoutout to the whole team for this crazy organization!
I had the honnor to be selected to present a talks about state management in React.
I'll publish other articles soon to share about the process of CFP submission and my experience as a speaker.
Please note how tiny I look in front of this huge screen
Speaker: Amélie Benoit
Sources sur Github (slides + code): https://github.com/abenoit/react-states
Résumé: Que nos applications soient legacy ou complètement nouvelles, la question du stockage et de la gestion des données est une constante. Il existe aujourd'hui de nombreuses façon de gérer ce state, mais peu de guidelines fortes.
Avec des exemples de code, nous verrons ensemble trois acteurs majeurs de la gestion du state en React aujourd'hui: de la solution native à Recoil en passant par Redux-toolkit.
Speaker: Nicolas Karasiewicz
Nicolas is a conscience awakener and explained to us, with a lot of humor and self-mockery, how important accessibility is. That a disabled customer remains a full-fledged customer and there are now a lot of tools and processes at our disposal to help anyone navigate a website.
Je ne vais pas faire un résumé de toutes les conférences, mais seulement de celles auxquelles j'ai pu assister et faire un compte rendu. Toutes les vidéos sont disponibles en ligne si vous souhaitez les visualiser !
Speaker: Alexandra White
Talk en anglais présenté par Alexandra, et qui nous explique pourquoi et comment écrire des documentations efficientes pour nos projets. Amené avec beaucoup d'humour et de légèreté, elle nous donne ici des clés pour nous aider dans ce process qui nous est parfois pénible et pourtant si important.
Speaker: François Delbrayelle
François goes through GDPR principles, by whom and why these rules were introduced. He gives tips for integrating these principles into our projects on a daily basis, in order to ensure that we do not deviate from them.
Speaker: Loriane Buffet
I really enjoyed Loriane's talk on accessibility. In particular when she dismantles the benefits induced for valid people people and/or projects. A talk that puts things in their place, gives keys to bad practices and explains that making your site accessible ultimately concerns all professions.
Obviously, there are still plenty of incredible conferences to discover in replay on the GDG Lille YouTube channel. I am thinking in particular of the conference in Florence Chabanois about recruiting women, or even the one from Rose Mazari about digital sovereignty.
For my first time there, I absolutely loved my experience at DevFest Lille. Excellent atmosphere, strong values, warm welcome, and the most interesting conferences. I felt truly honored to be one of the presenters, as everyone were relevant and interesting in their presentation. I hope to have the opportunity to renew this adventure!
]]>Applying for a job in tech usually comes with its set of technical tests. Live coding, deep dive, MCQ... each type of interview has its own set of advantages and disadvantages.
I've had both hats, but now I'm more of the interviewer. I wanted to share here the advice that can help you if you are going to have tech challenges to pass.
That does not mean that by following these tips, you will necessarily succeed in your interview!
I'm going to provide you keys to having a clearer, cleaner and more organized approach, which are qualities generally sought after by the people who will interview you. Obviously, the technical level and other qualities expected depend on the company and the position you are applying for. In any case, these tips are essential elements that can only work in your favor. Or even potentially play against you if they are not or not well presented.
We start this series with tips for the offline coding challenge! I am talking about this exercise with more or less precise instructions that you are given to work at home in a given time.
⚠️ I am a front-end developer and give advice rather focused on a JS / TS test, but most of them are applicable whatever the language and the type of challenge.
As with any interview, your goal should always remain the same: to make the person in front want to work with you.
In the case of an offline technical test, you won't get direct interactions - the second objective will then be to make the person who will review your project want to read your code, and arouse their curiosity.
It may seem like an extremely basic advice, but it is nevertheless the most important. Read the instructions, make sure you understand them. In any doubt, do not hesitate reach out to the contacts who sent you the coding challenge to ask for clarification.
If the instructions are long or complex, you can also reformulate them on your side, in the form of a TODO list for example. It is also important at this stage to define the primary and secondary elements.
Instructions: Create an application that displays a form with a text field and a "search" button. When you click on "search", display a list of items from the list [given to you via API or JSON file].
The instructions are super vague, sometimes on purpose. But the absolutely essential elements in this application are:
Et THAT'S IT !
Of course, it's then up to you to add some bonuses - which by definition should only come after the core elements are implemented:
Only once the instructions are clear and understood, and you have determined the main elements, you can begin to think of coding. Advantages of processing like this:
You start, and by definition, you will make your first technical and architectural choices, which brings me to the second point: keep it as simple as possible.
Even if you're passionate about the challenge you've been sent, you probably don't want or have the time to spend a lot of time on it. And no one [with common sense] can blame you for that. You have the right to choose such library or framework because you are comfortable with it to go faster. Or choose a more naive or simple implementation because it suffices for this project.
The technical test doesn't have to be a steroid-boosted application because you want to show the full extent of your knowledge. Rather choose to apply them intelligently and simply, according to the need for the application (this advice is also valid for any project). Whatever the tech you decide to go with, just remember to mention it in the documentation section - see below.
Example: I know Redux like the back of my hand. The application asks me to display a list of items; do I really need Redux for such use case?
The goal is to create code that induces the least possible cognitive load for the reviewer. One way to help is to have consistent code: always the same spacings, import organization, variable naming convention...
There are a multitude of tools that help us on keeping our code consistent and easy to read. I simply name ESLint and Prettier, which respectively take only a few minutes to install.
In the same idea, impose yourself a convention (or according to the instructions) to name your functions, components and variables: camel case / snake case? Filenames starting with a capital letter? File hierarchy? ...
Not so much a matter of consistency, but try to keep the code as easy to read as possible. A third person will pass behind you and will try to understand what you have coded. There are simple ways to get your code a smoother read:
If you feel the need to add a comment in your code to help understand a particular element, do not hesitate to do so. However, it can sometimes be a code smell indicating that your code could be written differently or refactored - but it can sometimes provide value and clarification.
API tokens or keys or any other secrets you may need should never be committed or present in clear in your code. Use environment variables, and potentially a library to access them (example: dotenv).
Overall, this is good practice for any application you might write.
In a perfect world, we have time to write tests: unit first, integration if possible and ideally a small end-to-end test. But - like in real life - it's time consuming. If you are running out of time and you haven't written your application in TDD (which is rarely the case for front-end), try if possible to add at least some unit / integrations tests on the main component of your application, or on the central logic. This will support the fact that you still know how to do it and have a concrete example to show.
And if you don't know how to do it or don't have the time, then write it in the "Possible improvements" section in your report (see documentation section below). Do not hesitate to indicate the scenarios you would have tested and which library you could have used - and why.
As in any project, it is better not to push all your code at once. Even if messages aren't perfect, your branch commits should reflect the iterative implementation of your application.
Example:
- init app
- create search form
- API call to search for the items
- list all the items
- loading state
- ...
To go further on the types of commits, there are now commit conventions on which you can base yourself on, for example Conventional commits.
During a live interview we can easily speak our mind; but when you are alone with your exercise, it's often something we forget to do (even in the professional world, even the most seasoned): explain, document.
Code alone is not enough to describe your intentions, choices and thoughts.
When you submit your technical test, documentation can guide the person who reads your challenge through your approach.
At the base of your project, create a README.md if it does not already exist and describe your journey.
As the basis, describe how to launch your application! Help the reviewer and save them time. It is also a good practice on any project to indicate how to launch the application as well as the tests if there are any
# Install dependencies
npm install
# Start application: this will run the app in the development mode.
# Open http://localhost:3000 to view it in the browser.
npm start
# Run unit tests
npm run test
PS: also remember to test these commands one last time before returning the project (yes it's a real life experience).
The technical choices made by a candidate during his challenge do not matter that much, as long as they are able to explain why they made them. Without explanation, it is difficult to say if the candidate went for it because it was what they knew or if it was out of conviction that it was the best choice for this use case. And even if the explanations can lead to questions, the technical choices and the explanations associated with them can then be challenged in the rest of the process.
Example 1: The application had a form and a button, which led me to create a very simple form validation in vanilla JS. However, on a production application that would need to grow, we can think of integrating a library such as [form validation lib of your choice].
Example 2: In order to deliver a pleasant user experience and to save time, I used [name of the UI library of your choice]. This library is quite light and offers the components I needed to easily compose the interface of the application.
The explanations can relate to the language (why Typescript?), the libraries / frameworks used, the way you have architected the code, the state management you have (or not) used...
All your choices come from decisions and experience. This process of explaining everything can only enlighten the person who will read your challenge and help to know you.
You have implemented the essential elements of the challenge but you have spent all your time quota. Everything is going to be alright! Describe the elements that you did not have time to implement.
If you ever feel like you have implemented everything - stay humble, no code nor app is ever perfect. Look for improvements, missing points, technical or in terms of feature. It is extremely important to stay objective about your work. And if you still can't find what to say, you can always add notes on how the application could evolve in case we ask to scale (addition of features or people to work on it, mass user support , accessibility, optimizations...)
Example 1 - tech improvement: I didn't have time to implement unit tests for all components. As for [this component that you were able to test], the idea would be to continue this process for all the other components of the application.
Example 2 - the product improvement: the API returned me other properties which would have been interesting to show to the users like [name a property]. Moreover, it is possible to add a filter/sort/pagination function which would improve the user experience the returned list is sometimes very large.
This section may seem trivial, but it can save you if you just haven't had time to do everything. No need sweep dust under the carpet, the people who will read your challenge won't be fooled; take the lead, explain everything, and this will allow you to defend yourself during a potential debriefing interview.
When you are finally finished, I can only encourage you to step out of your body, and put yourself in the place of a third person. Review everything, the README, the code on Github (or whatever the platform). This will allow you to identify points for improvement - which you will either have time to correct or add as an area for improvement in the README!
Also check that
I realize while writing this article that all of this advice can seem like a lot of mental work. Just keep in mind that your test doesn't have to be perfect. Also that:
I hope this was useful, good luck in your next interview! I'll continue this series with an article about live coding challenges.
]]>Applying for a job in tech usually comes with its set of technical tests. Live coding, deep dive, MCQ... each type of interview has its own set of advantages and disadvantages.
I've had both hats, but now I'm more of the interviewer. I wanted to share here the advice that can help you if you are going to have tech challenges to pass.
That does not mean that by following these tips, you will necessarily succeed in your interview!
I'm going to provide you keys to having a clearer, cleaner and more organized approach, which are qualities generally sought after by the people who will interview you. Obviously, the technical level and other qualities expected depend on the company and the position you are applying for. In any case, these tips are essential elements that can only work in your favor. Or even potentially play against you if they are not or not well presented.
The goal is to solve one (or more) tech exercises live in front of one or several people. This kind of test is difficult and particularly dreaded because we find ourselves naked in front of one or more strangers who judge us in real time, which leaves little room for error. Anyway, that's what we say to ourselves.
As with any interview, the goal must always remain the same: make the person in front of you want to work with you.. But this time it goes both ways; it is also necessary that the people in front of you make you want to work with them - finding yourself in front of a pretentious *** probably remove all desire to join their company!
My tip is then to approach this interview as an exchange, a discussion or even as a mob-programming session. It may be your future colleagues that you meet for the first time. These people in front are not mere spectators, they are here to accompany you, answer your questions, unblock you if necessary.
As with any interview, it is best to do your research beforehand and prepare questions. In addition to giving context, it allows you to have questions to ask at the end of the interview. You can then search conferences, technical blogs, publications... It is not only important to show your interest in the company, but also and above all to show that you are planning.
Regarding the technical part, the process is sometimes communicated in advance, which then makes it relatively easy to know what to work on. If not, several possibilities and resources:
It seems extremely basic as advice, but it is nevertheless the most important. Read the instructions, make sure you understand them. and LISTEN. If there is any doubt about an instruction, ask questions. It is better to repeat than to be wide of the mark. A smarter way to make sure that you have understood correctly (or precisely that you are not sure you understand) is to reformulate the exercise in your own words, and ask if this is what is expected.
The most common syndrome I've noticed among developers is over-engineering.
"Super easy, I know how to do it, so let's go for a nested double reduce!"
Expectation VS Reality: We forget the return, the parameters are in the wrong direction, we initialized the function badly and we made a typo for each word.
With stress, it's actually super hard to output code to an editor you're probably not familiar with - probably without auto-completion, and with people watching and you think are judging every typo. Even when we are used to it. Even when you're a senior!
Overall, and especially when stressed, #1 tip: ITERATE.
Example: start with a first `for` loop, mutated variables here and there. Then extract into a function. Then use a `.map` instead (or why not a `reduce` if you really feel like it). etc
And the secret that isn't one - tip #2 TALK.
Super important to avoid isolating yourself in your exercise and to make your intention understood by the people in front. They will be able to understand, help or challenge you. You give yourself a chance to argue your choices while showing that you are objective about your code.
Example: "Here I'm going with a naive approach to start with, it's not ideal performance-wise, but I'll come back to it later."
And if the result is not as expected, de-dramatize. The interviewers know that it is a stressful exercise and that no one is in possession of all their means.
On D-Day, whether you've been preparing for weeks or not at all, you're usually hyper-stressed (except superhuman people, of which I'll never be one).
Stress is actually pretty good in small doses. It allows you to be concentrated, to try to surpass yourself during the exercise. But it is essential not to be overwhelmed. Several techniques exist:
It is difficult to know our reactions given a situation before being actually confronted with it. In a stressful situation in front of people, do I tend to block / make jokes / talk too much...?
It is often after several interviews that we get to know oneself other better, through what we feel but also through the feedback that we can receive (or ask to receive) after the interview.
Ask questions by bouncing on the test or remarks of the speakers; "are you using a /lib/archi/process?etc convention". This shows that you care and can give you insight into how the teams are working.
If possible, practice speaking while coding. We rarely have this need on a daily basis, so it's quite unnatural and probably destabilizing at first. At least raise your head between a few lines of code to explain what you're trying to do. Ask for help if you are stuck.
The important thing is to keep in touch with the interviewers. Yes it's a technical test but the fact remains that an important part of the success of this challenge is attributed to communication and feeling because it is an essential component in our daily life (even for the devs yes).
This is the perfect time to say what you thought of the test and your performance. The ideal is to provide suggestions for improvements to the rendered code, whether technical, functional, from a QA point of view, performance, etc.
No code is perfect (and certainly not code from a live coding challenge). Tip #3: stay objective and humble!
Live coding challenges are difficult and stressful, it's normal to feel that way. The interviewers - our future colleagues? - are here to help us and put us at ease. Count on them, but help them by keeping communication open all the time.
]]>Composed of two words: Sketch and Note, the Sketchnote is nothing but a drawing, a visual representation of a note-taking containing both drawings and text. It's a graphic facilitation technique, often used by agile coaches (who happen to be the ones who initially trained me).
Today there are many training resources, and it does not require any particular skill. One might believe that it requires knowing how to draw or write correctly. It is in fact an extremely accessible technique!
If you know how to write, draw squares / rectangles / circles / triangles, you will know how to make a sketchnote!
Our brain does not work in a linear fashion. Sketchnotes, in addition to being visually more attractive, offer a more opened and free organization of information, and sometimes more representative of what we are trying to transcribe.
The visual representation of a concept captures the reader's attention more effectively than a block of text would. The primary interests are the attraction and retention of information.
To transcribe the information in visual form, our brain naturally does all the work of appropriating the information; we capture the information, understand it, synthesize it, and then find a personal and visual way to place it in a sketchnote. It facilitates the memorization of information.
It's also a great way to work on your creativity (calling all notebook doodlers!), and a real pleasure to create. It is also with more pleasure and ease that we will reread notes written in the form of a sketchnote!
For all these reasons, sketchnote is a great way to learn - and if I ever had to take lessons again, I know this would be my new way to take notes!
Finally, a sketchnote is a representation of the important concepts among the information that the one captures. Two people reading or listening to the same thing will never produce the same sketchnote, and probably will not transcribe 100% the same information!
Sharing your sketchnotes is totally optional but can be a motivational source for you to refine your research and your work. This helps to share information effectively and the people who read it will also retain the information better!
For simple notes (announcement, event, specific information), readers will remember better. For more complete or complex notes, and it allows people who will read to understand the information more easily, with less cognitive load.
Simply: To absolutely everything!
As mentioned above, it is an extraordinary way to learn and retain information, so perfect for revision sheets for example. I use this technique to take notes during technical conferences (usually live), or to express concepts (recently on design patterns).
But in fact, we could also use it to make summaries of books, films, speeches, and why not even cooking recipes!
So get your pens! You don't need a lot of materials to get started:
It also works with a digital tablet with a drawing application.
Let's see the basic elements of a Sketchnote. For each of the categories mentioned, do not hesitate to reproduce the examples and to create your own library of the elements that you like in order to use them more regularly.
Icons and emojis are an integral part of our lives now! And it is only natural that we can (must!) use them in a sketchnote. In addition to capturing attention, they convey meaning.
There are a multitude of pictograms that you can use and which are easy to draw because they are based on basic geometric shapes.
Characters are also great sources of icons to use and easy to draw. Moreover, a happy or sad character also instinctively leads readers to be more responsive.
Calendar | Goal | Group | Time | Warning |
---|---|---|---|---|
Images alone are not enough to convey information. Adding text is essential to provide sufficient context to complete the information. Combining a pictogram and text adds context for example!
Text translation: Combine with text to provide context.
Ideally, the text should be as readable as possible. A simple way to achieve this is to use capital letters, tightly packed together.
Once sufficiently comfortable, it is possible to use special fonts; a world of infinite possibilities then opens up to you!
Text translation: Capitalized, regular and well tight. Large, Font, Handwritten, Underligned, Bold (not to be abused!)
In a sketchnote, we try to arrange the information effectively. In the case of a list, we can then use a variety of bullet points. No rule to follow, choose the ones you like or that make sense in your context!
Sometimes essential to bring from one idea / block to another, or to define a reading flow, the arrows are faithful allies to any budding sketchnoter.
No we're not talking about Kubernetes here, sorry 😂
They make it possible to group information that is related to each other. It is simply a matter of categorizing and putting this information into boxes.
Again, lots of container possibilities! You can also choose to frame a main title to highlight it.
Choosing one, two or three main colors per sketchnote is ideal because they allow you to add a visually pleasing touch and emphasize important elements.
The colors are placed on fonts, containers, arrows or pictograms for example.
Shadows help to give volume to elements and make them stand out. They can be gray or colored, internal or external.
This is the part that I find the most difficult to apprehend. The white sheet on which we know what we want to write but we don't know how to place the blocks in relation to each other. This exercise is even more complex when taking notes in live.
If you already know how the information is structured, you can start directly or define areas in pencil. For example in the case of an idea around which gravitates information, a mindmap works well. If, on the other hand, the plan is composed of 3 parts, you can already mentally divide the sheet into 3 vertical or horizontal zones.
If you don't know the outline or information to write in advance, here's how I go about it in a conference
Probably not the first exercise I would recommend for beginners, but definitely challenging and interesting, taking notes live is difficult but rewarding. I am easily distracted, and this allows me to focus on the entirety of a talk or a meeting.
Here is an example of a live note taking of a 3 hour conference given by Jordan Nourry, Adrien Joly and Julien Topçu at Devoxx France 2022 (Video of the conference)
On the training side, I first had an initiation with agile coaches who explained to me the basics explained in the previous section.
There are also books by Mike Rohde (founder of the concept of sketchnotes) which are excellent resources to start or improve your knowledge.
Although it may seem daunting from afar, GO FOR IT! It's an exceptional and fun way to take notes, retain information and share it effectively.
Make your dictionary of pictograms, fonts, containers, try things and above all, have fun!
]]>We use so many tools, frameworks, we read so much code on a daily basis... I wanted to take a moment to go back to the basics of what I learnt at school and that I met here and there in my daily life. In order to better understand. To improve my thinking in the face of problems.
I was very surprised to see that the sketchnotes posted on Twitter had received some enthusiasm; I do them with pleasure on my free time and each like, each message is a reward that I did not expect. It also came with passionate and instructive debates, especially on the Singleton pattern.
All the sketchnotes on the design patterns I make are and will be added to this article.
Most sketchnote content is based on https://refactoring.guru
5 basic principles OOP #SOLID that we sometimes find in some of the patterns mentioned next!
Turns out these principles are newer than I originally thought 😇
The series of design patterns in sketchnote begins with the Singleton. Widely used in front-end frameworks, but not always good practice when it comes to implementing it in our code.
Some debates on Twitter about if it's a good practice to use this pattern: https://twitter.com/AmelieBenoit33/status/1570313646605234177 - I'll summarize it soon!
It reminds me of the character builder I played with in The Sims or some RPGs (weeks spent on Baldur's Gate, my childhood ❤️)
I often use this pattern to build datasets in unit tests - not always with a Director though.
Similar to a subscription system (magazine, newspaper, YouTube channel, etc.) where the publisher calls a subscriber method when an event occurs.
Widely used in frontend in various contexts!
Simple to set up, it allows customers to consume APIs or data in a uniform way.
]]>