Interviews techniques. Best practices pour les candidats

Suite à mon expérience avec le monde des SSII parisiennes, j’ai accumulé un certain nombre des idées et de remarques sur les entretiens techniques.

J’ai eu de la chance d’être présent sur les deux côtés des barricades : en tant que candidat cherchant des nouvelles missions et en tant que « conducteur » représentant l’entreprise qui voulait embaucher des spécialistes techniques.

Dans cet article je vais présenter mon expérience en tant que candidat.

Alors, vous êtes un candidat, l'ingénieur en informatique cherchant une nouvelle mission/poste.

Je vais laisser à côté le premier test technique que vous avez éventuellement passé avec le RH. Dans la plupart des cas, ce test est un QCM classique (la syntaxe du langage, possibilité du plateforme, les questions sur les bases de OOP). Ce test est nécessaire pour faire la première « brute » estimation de vos compétences. Ce test permettra d’éviter à l’entreprise de solliciter l’un de ces référents techniques ou architecte pour évaluer le niveau des connaissances de base du candidat.

Tout d’abord, pour réussir l’entretien technique il faut adapter une idée qu’une interview c’est un jeu. Pour vous ce jeu doit avoir 2 objectifs : répondre correctement aux questions et profiter de l’occasion pour parler avec une personne forte techniquement. En effet, les conducteurs des entretiens ce sont des personnes avec un bon niveau technique qui peuvent vous apporter beaucoup d’information nouvelle et intéressante. Notez toutes les questions sur lesquelles vous n’avez pas de réponse, n’hésiter pas à posez des questions à l’interwieur si le contexte est favorable (pas de contraintes de temps, par exemple). Cela montre que vous êtes toujours prêt à apprendre et curieux par rapport aux nouvelles technologies.

Si on vous pose la question et vous ne savez pas exactement la bonne réponse. Pas de panique. Essayez de réfléchir à la voix haute. Faites quelques hypothèses. Peut-être en cours de cette réflexion vous allez trouver la réponse ou la personne en face de vous pourrait vous indiquer la bonne direction. Mais, n’hésitez pas à dire fermement : « Je ne sais pas », si vous ne savez pas du tout où chercher la bonne réponse.
Très souvent on vous posera des questions pièges. Par exemple, « Quelle type de relations entre les objets préférez-vous : héritage ou agrégation/composition ? » Il n’y a pas une seule réponse correcte. Tout dépend du contexte particulier. Vous devez expliquer cela pour chaque type de relation en donnant un exemple.

Lors de vos réponses essayez de montrer votre culture technique, en s’appuyant sur les ouvrages, livres ou blogs des différents experts dans votre domaine.

N’hésitez pas à schématiser vos réponses ou vos réflexions. Les diagrammes UML simples ou juste des carrés avec des cercles suffiront. Les architectes adorent les schémas. :)

Après chaque entretien, faites des rétrospectives. Analysez vous-même vos réponses et le résultat de l’entretien. Notez bien les points que vous ne maîtrisez pas et réfléchissez comment vous pouvez les améliorer. Chaque entretien c'est un miroir qui reflète vos faiblesses. Oui, uniquement, les faiblesses. En informatique, il n y a pas une personne qui sait tout !

PS : L’article a été posté avec le support du café www.lacantochepaname.com, rue Réaumur.

Podcasts pour les développeurs

Si vous êtes passionné par l’informatique et vous êtes prêt de rester « avec l’informatique » en dehors du travail, les podcasts peuvent vous aider à diversifier votre façon de faire la veille technologique. Personnelement, pour moi les podcasts est une meilleure solution pour profiter du temps que je passe en transport en commun.

Je voudrais mentionner dans cet article quelques podcasts informatiques que j’écoute régulièrement.

• http://lescastcodeurs.com/ - un podcast en français sur le monde Java. Les auteurs sont 4 Français très connus dans la communauté Java.
• http://se-radio.net/ - un podcast en anglais sur le génie de logiciel. Je vous le recommande. Très enrichissant. Il y a des interviews avec des personnes remarquables, comme par exemple avec E. Gamma.
• http://www.computer.org/portal/web/computingnow/onarchitecture - architecture de logiciel par le guru d’UML et la programmation orientée objet Grady Booch. (anglais)
• http://radio-t.com/ - pour ceux qui parlent le russe un podcast sur l’IT. Très riche en contenu et avec de l’humour.

Si vous connaissez des autres podcasts intéressants, vous pouvez les rajouter dans les commentaires de cet article.

TeamCity - Intégration continue (IC)

La suite des articles sur l’industrialisation de développement.

Cet article est consacré au serveur d’intégration continue TeamCity. Ca fait déjà presque 2 ans que j’utilise ce serveur. Très stable, facile à mettre en place et facile à utiliser.

Quelques liens utiles:

1. Télécharger TeamCity: ici
2. Documentation et video tour des fonctionnalités : ici
3. Blog de TeamCity : ici

Cet outil est développé par JetBrains, un éditeur de logiciel très connu dans le monde Java pour son IDE Intellij Idea et dans le monde .NET pour son plugin Resharper.

Ecran principal de TeamCity donne une image instantanée des états des différents builds qui sont présents sur le serveur :

Pour utiliser TeamCity (ou n’importe quel autre serveur d’intégration continue) vous aurez besoin de deux choses : le système de contrôle des versions (CVS, SVN, et à partir de la version 5.0 TeamCity supporte Git et Mercurial– les vcs distribués très à la mode en ce moment) et un outil des builds automatiques (Ant, Maven, MsBuild, etc).

Une particularité de l’architecture TeamCity est l’utilisation des agents – machines physiques qui se sont regroupés ensemble pour permettre l’exécution de plusieurs builds en même temps. Cette fonctionnalité est disponible uniquement dans la version payante.

TeamCity supporte 2 plateformes Java et .NET. Cet argument peut être très intéressants car TeamCity permet dans ce cas là de capitaliser les connaissances sur le processus d’intégration continue pour différents projets. Les meilleures pratiques et astuces du monde d’IC de Java peuvent être réutilisées pour .NET et vice versa.

La fonctionnalité très utile pour les chefs de projets et responsables techniques de projets. Les différentes statistiques sur la santé du processus d’intégration(combien des builds « cassés », les tests unitaires qui provoquent plus d’erreurs, nombre des test unitaires, le temps de « fixage » des bugs, etc ). Les stats montrent l’évolution du projet dans différents contextes : les moments critiques (où il y avait plus d’erreur), la réactivité de l’équipe pour corriger les erreurs, etc.

Mac in our life

Chez Mozilla, on programme avec le Mac :

Pour comprendre pourquoi Google c’est génial, regarder dans quelles conditions travaillent ces « pauvres gars » :

Plus de photos de Google à Stockholm, Sweden, ici.

La puissance de VmWare in action sur mon portable MacBook Pro - Mac Leopard Snow, Windows XP et Ubuntu sont ensemble:

Industrialisation de développement de logiciel (.NET)

Dans cet article je voudrais présenter mon expérience dans l’industrialisation de développement de logiciel. Je vais me concentrer sur les aspects purement techniques.

Je pense que l’automatisation est l’une des caractéristiques principales de l’industrialisation. La première chose à automatiser est un processus de build de votre logiciel. Le strict minimum d’un build automatique :

1. Compilation des sources
2. Packaging (création des *.dll, *.exe ou archive Web, par exemple)

Aujourd’hui, les bons projets rajoutent encore quelques étapes supplémentaires pour assurer la qualité :

1. Tout d’abord, la récupération de la version du système de gestion de version (CVS, SVN, Git, etc).
2. 2 étapes décrit précédemment
3. Lancement des tests automatisés (NUnit+DbUnit.NET)
4. Génération de la documentation (Doxygen - générateur avancé de la documentation technique à partir du code source, les langages supportés - C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C# )
5. Génération des métriques sur le code (FxCop - signale des problèmes (règle de nommage, performance, architecture(design), sécurité, etc) dans le code, NCover - détermine la couverture du code par les tests, NDepend - analyse les dépendances).
6. Déploiement pour l’équipe de QA si nécessaires.
7. Envoie des notifications à l’équipe de développement sur les résultats des builds (mail, SMS, feed RSS, etc).

Dans le monde .NET, nous avons outil MSBuild (équivalent de Ant en Java) qui permet de faire ces builds. L’exemple du script MsBuild pour compiler une classe C#:

MsBuild contient un certain nombre de tâches (target) prédéfinis. Toutes les 7 étapes que j’ai listé peuvent être réalisées facilement avec les targets standards de MsBuild.

Dans le prochain article je décrirai le serveur d’intégration continue TeamCity qui s’intègre dans la politique d’industrialisation des grands projets.

Audit des logiciels

Je me prépare à l’audit externe de quelques applications lundi prochain.

Pour ceux qui cela intéresse il y a la norme ISO 9126 consacrée à l’évaluation de la qualité de logiciel. Pour plus de détails : http://en.wikipedia.org/wiki/ISO_9126

Une représentation très compréhensive en français est ici.

Parmi les logiciels qui permettent de sortir certaines métriques sur le code, je peux vous recommander :

1. Source Monitor. Support de plusieurs langages: Java, C++, C#, C, Delphi, Visual Basic et même HTML. Un outil puissant, facile à utiliser et à installer. OpenSource. http://www.campwoodsw.com/sourcemonitor.html.
   Merci à Aurélien qui m'a montré cet outil.
2. Metrics pour Eclipse. Que pour le monde Java. Un plagin très sympathique et puissant qui s’intègre à Eclipse et qui calcule les métriques à la volée. http://metrics.sourceforge.net/

Cet audit semble être très intéressant. On devra évaluer une dizaine de l’application pendant quelques heures. J’espère ce sera très enrichissant !

Bon, c’était mon dernier post pour ce week-end ;)

Web Developer Toolbar

Pour ceux qui travaillent beaucoup avec des technologies Web (HTML, CSS, JavaScript). Un addon magique pour FireFox qui facilite grandement le déboguage et l’analyse de pages web.
Les fonctionnalités que j’utilise le plus souvent sont les suivantes :
1. Affichage des erreurs JavaScript (les messages d’erreurs sont très parlants, ce que n’est pas le cas chez IE).
2. Désactivation rapide de tous les JavaScript sur la page (avez-vous testé comment se comportent vos pages sana JavaScrip activé ?)
3. «Display form details » - affiche les détails sur les inputs (noms, id), valeurs des attributs action des balises form


Installation facile à partir de : https://addons.mozilla.org/en-US/firefox/addon/60

Des espaces à la fin des noms. Version Windows et Linux

Bonjour,

Est-ce que vous savez que les règles du nommage des fichiers sont très dépendantes du système d’exploitation. Voilà un exemple qui m’a coûté quelques jours d’investigation pour un projet sur lequel je travaille.

Sous Windows le nom du fichier ne peut pas contenir des espaces à la fin! Pour Windows les fichies :
1. ‘toto.txt’
2. ‘toto.txt ’ (un espace à la fin)
3. ‘toto.txt ‘ (deux espaces à la fin)
sont identiques et seront représentez par UN SEUL fichier sur votre disque ! Windows va tronquer les espaces à la fin.

Dans les OS comme Linux RedHat ce n’est pas le cas. Pour ce système, ces trois fichiers sont les fichiers différents. Donc, pour Linux l’espace à la fin du nom de fichier est tout à fait légitime.

Cette différence subtile m’a coûté 2 jours pour réussir à reproduire une anomalie. Vu que notre plateforme de développement est sous Windows et les serveurs de production sont sous Linux, je ne pouvais pas avoir le même comportement de l'application que nos clients.

Conclusion. La reproduction des anomalies, les tests de régression, les tests unitaires doivent être exécutés dans l’environnement le plus proche possible de votre environnement de production. C’est une règle de-facto de développement que je n’ai pas respecté. Mais, l’anomalie est reproduite et sera corrigé et moi, j’ai appris quelque-chose de nouveau et c’est ça qui compte !

Vos commentaires

Bonjour,
J'ai activé la possibilité d'écrire des commentaires par des anonymes.
Désormais vous pouvez laisser vos commentaires sans avoir besoin de posséder un compte chez blogger.com.

La matrice de compétence d'un programmeur

J'ai lu un message sur le forum de RSDN.ru (Russian Software Developer Network) et j'ai tombé sur cette matrice de compétence (en anglais) :

http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm

C'est un document très bien structuré et qui rassemble toutes les domaines dont les connaissances sont primordiales pour un ingénieur en informatique.

Si vous faites des interviews techniques, cela pourra vous bien aider - vous l'imprimez ce document et lors d'un interview vous l'utilisez comme un plan.

A la fin de l'entretien vous devez avoir parcouru avec le candidat toutes les rubriques de cette matrice.

L’image ci-dessus représente l’exemple de la matrice rempli après l’interview.

Il est conseillé de conserver ce document afin d’avoir une source d’information plus ou moins formelle à partir de laquelle la décision sera prise.