Quelles compétences attendriez-vous et apprécieriez-vous chez un ingénieur logiciel junior?
J'ai récemment terminé ma maîtrise ès sciences en génie logiciel et je suis sur le point de commencer ma carrière professionnelle dans quelques semaines. Mon rôle sera celui de développeur junior pour une entreprise qui développe des logiciels en utilisant Java et les technologies connexes (dont Spring et Hibernate). Pour être honnête, je suis vraiment excité par ce qui s'en vient, en particulier parce que je veux développer ma carrière en tant que développeur Java. Je suis également très intéressé à acquérir une expérience dans le domaine. De plus, ce sera ma première expérience de travail en tant que développeur professionnel, donc je je veux vraiment faire de mon mieux dès le début.
Je voudrais savoir quelles compétences et capacités, à la fois techniques et non techniques, seraient les plus appréciées d'un nouveau professionnel (développeur junior) qui pourrait faire partie de votre équipe et dans quelles compétences je devrais me concentrer pour réussir une carrière de logiciel Ingénieur.
Beaucoup d'entre elles sont vraies, peu importe où vous en êtes dans votre carrière, mais peuvent être particulièrement importantes pour quelqu'un qui débute.
- Écoute plus que tu parles. Apprenez de ce que disent les autres.
- Être humble. N'ayez pas peur de partager vos idées, mais ne présumez pas que vous avez raison et que tout le monde a tort. Si vous voyez quelque chose que vous pensez être faux, demandez-le, ne faites pas de déclarations à ce sujet.
- Continue d'apprendre. Les bases de votre éducation sont (devraient être) excellentes, mais vous avez seulement commencé à apprendre la profession. Apprendre en faisant. Je ne pense pas que vous puissiez vraiment apprendre à moins que vous ne pratiquiez réellement ce que vous apprenez.
- Le client sait rarement ce qu'il veut avant de le voir. Habituez-vous à l'évolution de vos besoins. Adoptez un style de développement (si autorisé) qui met les choses devant le client rapidement pour obtenir des commentaires.
- Trouvez des gens qui savent bien travailler avec les clients et demandez-leur de vous guider dans la façon de développer des relations avec eux.
- Écrivez du code robuste et bien testé. Le faire n'est pas le but; le faire correctement est. Si vous êtes bon dans ce domaine, la vitesse viendra avec le temps.
- Travailler dur. N'attendez pas qu'on vous demande de faire quelque chose; chercher ou demander des choses à faire.
- Admettez vos erreurs ou celles de votre équipe. Ne jetez pas les membres de votre équipe sous le bus devant le client, mais soyez honnête lorsque vous rencontrez des problèmes de code.
- Vous pensez peut-être que vos coéquipiers veulent que vous soyez un brillant codeur. Ce serait génial, mais vos coéquipiers veulent vraiment que vous soyez compétent et non un con. Si vous allez être un imbécile, vous feriez mieux d'être brillant.
Voici une liste rapide du haut de ma tête:
- Suivi (terminer ce que vous commencez)
- Honnêteté (dites-moi si vous êtes coincé)
- Curiosité (trouver de meilleures façons de faire les choses)
- Ouverture d'esprit (à la fois à la critique et aux idées qui ne sont pas les vôtres)
- Générosité (partagez ce que vous apprenez; formez la prochaine génération)
Deux choses: la volonté d'apprendre et la capacité d'apprendre.
Motivation. Savez-vous comment vous motiver? Savez-vous quelles tactiques peuvent fonctionner mieux que d'autres? Il s'agit de la conscience de soi que certaines personnes peuvent s'attendre à ce que vous sachiez de toute l'éducation que vous avez faite pour avoir découvert cela de côté.
Compétences de test et de débogage de base. Savez-vous ce qu'est un test unitaire? Connaissez-vous plusieurs façons de déboguer un problème? Il ne s'agit pas de savoir précisément quoi faire dans un environnement, mais plutôt l'idée générale de ce que peuvent être les tests les plus élémentaires et quelles stratégies adopter pour examiner un problème.
Compétences en communication. Êtes-vous précis avec la langue? Comment pouvez-vous passer du technique au non technique? Certes, c'est quelque chose à développer, mais c'est quelque chose à noter et, dans certains cas, à sauver quelqu'un qui pourrait avoir des ennuis en ne comprenant pas les implications de ce qu'il prétend. Comment vous entendez-vous bien avec les gens? Ce n'est pas une exigence stricte, mais si vous pouvez avoir de bonnes relations avec vos collègues, cela peut rendre certains emplois un peu plus faciles à gérer. L'honnêteté et l'intégrité relèvent également de ce groupe de compétences, car en général, il peut y avoir des questions sur la façon dont vous dites ce que vous voulez dire et ce que vous dites. "Office Space" a beaucoup d'exemples de mauvaise communication et bien que le travail soit fictif, il peut y avoir eu de nombreuses scènes qui étaient vraiment proches de la réalité pour certaines personnes en termes de travail dans des environnements de bureau.
Polyvalence. Les nouvelles personnes de l'équipe peuvent assumer un large éventail de responsabilités, de sorte que si vous travaillez dans une petite entreprise, vous devrez peut-être configurer des bases de données, des réseaux, des serveurs Web et d'autres éléments en dehors du développement. Faire un pas pour aider une équipe à respecter un délai serait un autre exemple ici.
La curiosité, l'enthousiasme, établissent une norme élevée pour vous-même, la volonté d'apprendre, prêt à admettre qu'ils ne savent pas, l'intérêt pour ce que fait l'entreprise et comment elle affecte le travail que vous produisez. (Toutes les bonnes qualités même si vous avez 20 ans d'expérience)
De bonnes connaissances techniques sont excellentes, mais vous devez montrer comment appliquer ces connaissances.
Surtout, l'intervieweur doit pouvoir vous voir y travailler en apportant une contribution et en voulant rester. Si vous êtes trop bon, cela peut rebuter certaines personnes plus rapidement qu’en dessous de la moyenne. ;)
Je suis d'accord avec tout ce qui a déjà été dit, mais je tiens à souligner que vous ne devez jamais oublier ces compétences générales (et non techniques) au lieu d'être un expert technique. Vous devriez travailler sur les deux, mais je préfère de loin avoir un intermédiaire qui peut communiquer ce qu'ils savent, puis un maître qui préfère travailler seul.
Aussi, ne passez pas trop de temps avec votre nez dans un livre. Les livres sont bons, excellents même, mais si vous passez la majeure partie de votre temps à lire et moins de votre temps à travailler, vous n'obtiendrez pas la moitié de ces livres.
Pour moi, en tant que développeur junior sans diplôme, ma volonté de travailler dur et de m'améliorer m'a beaucoup aidé dans ma carrière. J'ai également remarqué que le fait de pouvoir faire face à certaines critiques (positives ou non) et de pouvoir en faire le suivi était apprécié par mes supérieurs.
Quant à un nouvel environnement: je conseillerais de suivre le courant pendant la première semaine environ. J'ai fait l'erreur d'essayer trop fort, c'était pas apprécié.
Excellentes réponses à tous. J'ajouterais seulement, d'après mon expérience de vol limitée - vous savez ce qu'ils appellent une licence de pilote?
Une licence pour apprendre.
Beaucoup de bonnes réponses.
Même si je ne travaille pas pour les "gros gars" et que je ne suis pas un gourou, j'ajouterai mes 2 cents.
Soyez gentil avec les gens.
Essayez de socialiser avec vos collègues, passez un peu de votre temps avec certains d'entre eux tous les jours si possible. Allez dîner avec eux de temps en temps, rigolez avec eux.
En d'autres termes, essayez de construire une "communauté" s'il n'y en a pas, ou d'en faire partie si elle existe.
Apprendre à connaître vos collègues vous aidera à vous entendre plus facilement avec eux. De plus, les chances sont bonnes, vous vous amuserez à le faire.
En plus de toutes les bonnes choses soumises par la communauté (ci-dessus), je m'attendrais également à voir des preuves de certaines compétences. Pas la perfection ou les pouvoirs über-geek, mais une bonne connaissance pratique des bases et des concepts de base. Vous avez déjà obtenu le poste (félicitations d'ailleurs!) Donc vous y êtes à peu près.
Mais actualiser vos connaissances et/ou vous familiariser avec les outils, les langages et les technologies utilisés par votre entreprise signifie que vous vous lancerez sur le terrain et créerez une bonne première impression.
Un développeur hypothétique parfait connaîtra les principes fondamentaux de choses telles que
- la langue.
- E/S
- Concepts OO comme l'héritage
- Interfaces d'objets
- accès à la base de données (en particulier en ce qui concerne la façon dont ils le font dans votre nouvelle boutique de code)
- le modèle HTTP
- CSS
- JavaScript/JQuery
- conception de base de données
- SQL et procédures stockées
- le ou les IDE que vous allez utiliser
- cadres pertinents (vous mentionnez Spring)
etc. Il pourra se concentrer sur l'acquisition de nouvelles compétences sans avoir à s'arrêter et à apprendre les bases. Il pourra continuer à poser (poser autant de questions sensées qu'il le souhaite - la plupart des développeurs seniors aimer se faire poser sensibles questions techniques) avec le tarif de routine des formulaires en ligne, des pages d'administration auxquelles de nombreux juniors sont confrontés pendant les premiers mois. Devenir un développeur fiable et junior peut être votre premier test d'initiation en équipe ;-)
Quand je débutais en tant que junior dans l'équipe Web d'une grande entreprise, la majeure partie du travail initial qui m'était assigné était quelque peu sans intérêt mais m'imposait au point où je touchais les livres tous les soirs pour pouvoir comprendre ce que j'allais avoir à faire le lendemain. Je m'en suis sorti, mais c'était cinq ou six mois stressants après le luxe relatif de mon master ;-)
Si vous pouvez faire tous les trucs de base efficacement, vous obtenez des trucs plus intéressants à faire assez rapidement et cela vous aidera bien sûr à faire avancer votre carrière.
Et faisant écho à ce que beaucoup ont dit ci-dessus, le monde des ordinateurs et du code évolue constamment. Vous devrez apprendre de nouvelles choses tous les deux jours. Gardez votre esprit grand ouvert et essayez de voir pourquoi vous vous êtes embarqué dans ce projet en premier lieu - parce que vous <3 le faites. Dans les années à venir, il peut y avoir des moments où cela ne sera pas au premier plan de votre esprit. L'enthousiasme vous aidera à surmonter la plupart des bosses et des obstacles.
Cela dit, mon expérience des douze dernières années suggère que la plupart des juniors ne restent pas dans leur première entreprise pour toujours, alors ne vous attardez pas trop à être "parfait". Faire des erreurs fait partie du processus qui vous mènera du junior à l'endroit où vous voulez vous retrouver. Je fais cela depuis un certain temps maintenant et presque - supprime une base de données de production à peu près au moins deux fois par an.
Bonne chance dans votre carrière.
Passion du travail
Désireux d'en savoir plus & plus & plus ..
honnêteté
cohérence
Excellentes réponses là-bas, si vous suivez tout ce que les gens disent ici, je suis sûr que tout le monde sera bon dans ce qu'il fait,
Je veux juste souligner quelques points.
- Soyez humble, n'ayez pas peur de donner votre opinion, mais une fois qu'une opinion est partagée, ne vous y accrochez pas, soyez prêt à apprendre des autres.
- former des relations avec les membres de votre équipe, les gens autant que nous voulons travailler avec des programmeurs intelligents et bien établis, nous avons toujours besoin de personnes avec qui nous pouvons parler, avoir une relation saine avec les membres de votre équipe vous aidera grandement dans votre carrière.
- Soyez proactif, n'attendez pas qu'on vous donne du travail, trouvez du travail, proposez de nouvelles idées à l'environnement, même si elles ne sont pas acceptées, cela augmentera votre valeur pour l'entreprise.
- Partagez avec d'autres ce que vous apprenez, cela augmentera le niveau de votre compréhension, augmentera votre valeur pour l'entreprise et la communauté.
- Terminez ce que vous commencez, l'engagement est une grande qualité.
- Restez heureux et ne soyez pas déçu lorsque les choses ne se déroulent pas comme prévu, il y aura des hauts et des bas, mais accrochez-vous
Tout le meilleur dans votre travail
Prendre l'initiative. J'ai eu beaucoup de gens qui ne font pas ça du tout et attendent toujours qu'on me dise quoi faire exactement. Si vous voyez quelque chose qui devrait être amélioré, faites-le. Vous avez une idée pour améliorer quelque chose? Avancez-le. Besoin d'une autre compétence pour améliorer quelque chose? Apprend le.
Montre que vous vous souciez de ce que vous faites et que vous souhaitez vous améliorer.
Une compétence que je ne pense pas que beaucoup de programmeurs Jr ont, mais c'est une très bonne, la capacité de créer vos propres outils. Vous pouvez économiser beaucoup de temps et d'efforts avec quelques outils personnalisés bien conçus. Et ils n'ont pas besoin d'être sophistiqués, la plupart des miens sont des scripts Shell à 3 lignes, bien que certains soient beaucoup plus longs.
Mais apprendre à automatiser les choses vous facilitera la vie. (Et impressionnez vos collègues lorsque vous pouvez bien faire les choses)
Pour ne pas vous faire peur du tout, mais une chose que je vais vous mettre en garde contre le fait que dans chaque entreprise dans laquelle j'ai travaillé, ce sont les grandes méthodes de défilement énormes et les objets mal nommés qui vous font redouter d'ouvrir les fichiers source en toute transparence choc et horreur d'un tel gâchis. Les emplacements que vous trouverez généralement dans les gestionnaires d'événements pour les boutons "OK" dans les boîtes de dialogue ou le bouton "Soumettre" sur les pages Web.
Je vous supplie du fond du cœur. S'il vous plaît installer une sonnette d'alarme mentale, que lorsqu'une méthode commence à sembler grande, et en gros, je veux dire plus de 10 lignes environ, pensez à créer une autre méthode ... tant de méthodes plus tard, vous comprendrez à quel point la responsabilité objet que vous développez a.
La prochaine sonnerie d'alarme que je recommanderais, ce sont les 2-3 paramètres maximum d'une méthode. Si vous voyez des méthodes avec environ 10 paramètres d'entrée, dites bonjour à la programmation fonctionnelle dans un langage OO ...
Désolé pour la légère frustration exprimée dans cette réponse, je ne peux pas crier assez combien il est bénéfique d'apprendre à écrire du code propre.
Veuillez vous procurer une copie de Robert. C Martins Clean Code . Lisez-la chaque semaine, sortez-la pour le dîner, dormez avec elle sous votre oreiller, ayez-en une copie dans les toilettes, imprimez quelques pages et collez-les au plafond pour que lorsque vous vous endormez, vous pouvez les lire avant vous vous assoupissez;).
Je vous souhaite le meilleur dans votre carrière. Votre passion à ce stade montre déjà que vous ferez grand.
Le seul conseil que je puisse offrir est de ne jamais cesser d'apprendre. La façon dont ces développeurs de rockstar sont arrivés est de prendre le temps d'apprendre de nouvelles techniques et de nouveaux langages, c'est leur propre temps libre. Bien que ce soit formidable si vous restez là pendant 10 ans, lorsque vous sortirez, vous ne connaîtrez que Java + Spring + Hibernate. C'est pourquoi pendant mon temps libre je regarde la plate-forme .NET, Python, et le code C++ occasionnel pour rester actif. En tant que personne qui travaille sur un MS dans info sec, le temps peut être précieux et il doit être dépensé judicieusement.
La possibilité d'utiliser google. Vraiment.
Non pas que je n'aiderais personne, surtout un collègue junior. Mais il n'y a rien de plus frustrant que d'avoir une personne qui ne fait pas preuve de diligence raisonnable pour résoudre les problèmes, en continu.
Mon conseil à junior soft. ingénieurs est de faire votre diligence raisonnable dans la résolution des problèmes. Utilisez Google, Wikipédia ou stackoverflow avec diligence et méthode lorsque vous ne savez pas quelque chose.
N'attendez pas trop longtemps avant de demander de l'aide à un collègue plus âgé - cela dépend du type d'organisation, cependant. Dans une bonne entreprise où les gens s'entraident, si vous passez plus d'une demi-journée à essayer de trouver une réponse, n'hésitez pas à arrêter vos propres recherches pour demander de l'aide.
Dans d'autres organisations où les gens sont toujours méchants les uns envers les autres, vous devrez peut-être passer quelques jours par vous-même (documenter tout ce que vous avez fait et partout où vous avez fait des recherches) avant de demander de l'aide. Dans de telles entreprises, documenter ce que vous avez fait vous permet de leur montrer que "vous l'avez fait sur Google" car ce sera la première réplique qu'ils vous lanceront.
Mais quoi qu'il en soit, l'essentiel de ce que je rechercherais chez un ingénieur junior est de faire preuve de diligence raisonnable en essayant de résoudre un problème au lieu de s'attendre à recevoir des réponses en permanence. En un mot, montrez-moi que vous pouvez utiliser Google.
(1) Un esprit ouvert. Vous ne voulez pas que quelqu'un qui est institutionnalisé utilise la langue X et l'environnement Y pour chaque projet. Vous voulez quelqu'un qui peut comprendre quand une technologie particulière ne résoudra pas proprement un problème et offrira de bonnes alternatives. En plus de cela, vous voulez quelqu'un qui peut défier la pensée conventionnelle et proposer des solutions qui motivent l'entreprise. Vous pouvez en faire l'expérience vous-même, mais j'ai constaté que les gens s'habituent tellement à un processus qu'ils ne le modifient pas, mais ils se plaignent toujours de la quantité de douleur que cela leur cause. Habituellement, quand j'arrive, je regarde comment améliorer cela et propose des solutions à mon manager. Maintenant, je dirais aussi que le personnel doit être "diplomatique" à propos de ses suggestions :)
(2) Bonnes compétences en modélisation de domaine. C'est un assez gros que j'ai trouvé que certaines personnes négligent. Dans certains des endroits où j'ai travaillé, se renseigner sur l'entreprise, c'est `` se salir les mains '' et les gens évitent les problèmes purement techniques comme l'intégration de vérificateurs d'orthographe dans le contrôle de version, etc. et ils n'investissent pas beaucoup de temps pour améliorer la Entreprise. Être capable de regarder une entreprise et d'en créer des modèles (simplifications) et de communiquer cela à divers publics, qu'ils soient parlés, visuels (UML, SSADM ou autre) ou un peu des deux, vous voulez quelqu'un avec cette mentalité.
Deux livres que je peux recommander sur le sujet sont: The Passionate Programmer et The Pragmatic Programmer . Les deux livres offrent de bons conseils aux programmeurs juniors et seniors.