Dans quelle mesure est-il important que la syntaxe soit correcte lors d'un entretien? [fermé]

Lorsque vous demandez à un candidat en entrevue d’écrire un programme sur le tableau blanc, attendez-vous du candidat qu’il écrive un code syntaxiquement correct?

J'ai eu deux candidats, l'un d'eux a écrit un programme syntaxiquement correct mais la logique n'était pas à la hauteur, et l'autre avait la logique mieux écrite mais la syntaxe était de la merde.

Je favorise le premier candidat.

Je préférerais à la personne qui était capable de raisonner à travers le problème, de proposer une bonne solution, puis de m'expliquer sa solution. Même si leur logique n’était pas à 100%, s’ils étaient sur la bonne voie et réfléchissaient au problème, posaient les bonnes questions et suivaient le bon chemin, c’était ma gagnante.

Lorsque vous développez du code sur le tas, vous disposez de nombreux outils - IDE, compilateurs, analyses statiques, tests unitaires, tests d'intégration et procédures de test d'acceptation - pour détecter les erreurs de syntaxe et de logique. Si vous écrivez sur un tableau blanc, vous ne disposez pas de ces outils et vous devez commettre des erreurs de syntaxe (en oubliant un nom de méthode, un point-virgule, une accolade), et je peux pardonner.

Ma seule question est la suivante: pourquoi vos candidats écrivent-ils le code réel sur le tableau blanc au lieu de se concentrer sur les algorithmes, les stratégies de conception et la pensée logique? Les langages de programmation changent, pas la résolution de problèmes.

Je favoriserais le second candidat. La logique peut être difficile ( très difficile, parfois) d'obtenir exactement ce qu'il faut. La syntaxe peut être très facile à comprendre lorsque l'IDE, le compilateur et d'autres outils variés vous aident.

Le premier candidat peut ne jamais déclencher une erreur de compilation, mais si son code échoue souvent dans toutes sortes de cas limites bizarres (et moins étranges), son savoir où placer un point-virgule ne vaut plus grand chose.

En fonction des erreurs de syntaxe réelles, je suppose que je préférerais le second candidat , car la vérification de la syntaxe est généralement mieux laissée aux machines .

Des erreurs telles que des points-virgules manquants, l'oubli des crochets fermants ou des virgules dans les listes d'arguments, etc. , toutes les choses que l’on utilise habituellement, mais qui ne sont pas disponibles sur le tableau blanc.

Cependant, il existe des erreurs qui, bien qu’elles ne soient techniquement que des erreurs de syntaxe, font apparaître un malentendu plus profond.

Comme exemple assez artificiel pour faire passer le message: considérons un programmeur python qui préfixe toutes ses variables avec $, ou écrit la boucle for comme for list as item. Techniquement, les deux erreurs sont des erreurs de syntaxe, mais même avec une exposition limitée à python, il faut savoir comment utiliser les caractères légaux et la boucle for. Ce serait une bonne idée que le candidat connaisse php (ou perl?) Et tente de bluffer à propos de ses compétences en python

Je préférerais le second candidat, selon lequel un tableau blanc aurait plus d'impact sur la syntaxe que sur la logique, et que les erreurs de syntaxe sont plus faciles à corriger - l'EDI ou le compilateur peuvent généralement le faire.

J'écris SQL et CSS (les langages les plus simples et les plus basiques que je connaisse) depuis près de 13 ans et je ne me souviens pas toujours de la syntaxe.

Mon ami (également développeur) travaille pour un fonds de couverture, il ne peut jamais se souvenir de la syntaxe d'une instruction insert.

Nous nous retrouvons tous les deux sur W3CSchools , je suppose que nous devrions être gênés (il a un diplôme et j'ai un doctorat).

Cependant, pour être honnête, je pense que nos priorités sont correctes. La syntaxe n'est pas une compétence importante.

Quelques réflexions sur les erreurs de syntaxe ... Je me demandais si vous aviez expliqué clairement à la fois que la syntaxe devait être correcte. Parfois, les gens supposent que le pseudo-code est correct.

De plus, si quelqu'un revendique des années d'expérience dans une langue et ne peut pas corriger la syntaxe de base, vous devez en douter.

Les erreurs de syntaxe peuvent varier. Par conséquent, si quelqu'un oublie un nom de méthode, c'est OK (pour moi), mais si quelqu'un ne sait pas comment faire référence à une méthode dans une classe (notation par points) ou ne connaît pas un principe de base comme la syntaxe d'un classe simple, alors les chances sont cette personne n'a pas utilisé la langue pendant une longue période.

Pour le gars qui n'a pas obtenu la syntaxe correcte, pensez-vous que ses erreurs auraient pu être facilement corrigées avec l'éditeur de langage approprié? si c'est le cas, je vote pour lui.

Je suppose que ce que je pense ici est que les erreurs de syntaxe sont acceptables dans les limites.

Un assistant programmeur junior ou même un outil logiciel pourrait peut-être trouver et corriger une syntaxe incorrecte si la logique est bonne. Mauvaise logique ... toute solution est beaucoup moins assurée. Tous les programmeurs vont se tromper. Je choisirais celui qui a des problèmes, il est plus facile à repérer et à réparer.

À moins que le problème ne soit subtil et que la plupart des questions de l'entretien ne le soient pas, le premier candidat est disqualifié. Il est beaucoup plus facile d'apprendre la syntaxe d'une langue que la conception d'algorithmes. J'engagerai un programmeur avec une expérience de travail réussie dans plusieurs langues, même s'il n'a aucune expérience de ma technologie actuelle. Ce n'est pas la meilleure stratégie si j'ai besoin de faire quelque chose aujourd'hui, mais si j'ai besoin de beaucoup de choses au cours des douze prochains mois, je choisirai toujours des compétences générales plutôt qu'une expérience spécifique.

La vérification de la syntaxe est à quoi sert un compilateur. Un compilateur ne peut pas améliorer votre logique, mais il peut vous dire comment corriger votre syntaxe. Cela signifie que pour tout travail dans lequel vous écrivez du code à l'aide d'un compilateur, la logique est intrinsèquement beaucoup plus utile que d'être syntaxiquement correcte.

Les entrevues sont toujours des situations délicates - vous pouvez le dire parce que lorsque vous sortez, vous pensez immédiatement à tout ce que vous auriez dû dire, ou à la bonne réponse aux questions et aux choses que vous vouliez leur poser mais que vous avez oubliées. Donc, étant donné cela, attendre un code parfaitement écrit sans erreur de syntaxe devient irréaliste.

De plus, vos attentes en matière de code parfait (sur un tableau blanc!) Peuvent ne pas correspondre aux intervieweurs - par exemple, lors d’une interview à laquelle j’ai assisté, il m’a été demandé d’écrire un cours, ce que j’ai fait, uniquement pour que l’enquêteur me tire dessus dans un constructeur de copie. Alors j’en ai écrit un qui ne faisait que mettre a = b, mais c’était suffisant pour le satisfaire. Mes attentes concernant le problème ne nécessitant pas de copieur, je les ai laissées de côté, car elles n'étaient pas liées au problème à résoudre - je ne m'attendais pas à devoir écrire du code entièrement conforme, en compilant le code (selon ses normes de codage cachées), simplement afficher ma compréhension de la solution. (Ce même intervieweur n'a pas aimé ma solution non plus, ce n'était pas comment il l'aurait fait alors évidemment je me suis trompé, soupir).

Si vous voulez du code de travail d'une personne interrogée, donnez-leur un compilateur. Alors ne vous plaignez pas quand ils vous facturent :)

Allez donc pour la personne qui sait ce qu’il fait, pas pour celle qui peut assimiler les mots mais qui n’en comprend pas le sens.

Au cours d’une interview, l’interviewer s'intéresse davantage à votre

1. Approche du problème
2. Compétence utilisée pour résoudre le problème et la
3. Temps pris pour donner efficacement une solution adéquate

La syntaxe n'a certes pas beaucoup d'importance, mais elle occupe une place prépondérante dans la résolution d'un problème. Vous pouvez vous attendre à des erreurs de syntaxe importantes qui ne peuvent pas convaincre l'intervieweur.

La logique et la syntaxe appropriées combinées peuvent faire l'affaire dans une interview.

Une erreur mineure ou mineure ne vous coûtera jamais très cher si la logique suffit.

En plus, il existe peut-être des IDE disponibles qui pourraient facilement rendre la syntaxe de n'importe quelle forme. Mais utiliser quelle méthode où et quand et surtout POURQUOI ne serait connu que par un type possédant la logique et la connaissance du sujet.

J'espère et vous prie de fournir quelque chose de plus qu'un tableau blanc ou un bloc-notes pour écrire le code.

J'irais avec le deuxième candidat. ..

Certaines personnes veulent de grands développeurs Java, de grands développeurs C #, de grands développeurs C ++, etc. Si tel est votre cas, utilisez A et plus de puissance. Si je ne peux pas raisonner pour résoudre le problème, comment pouvez-vous vous attendre à ce qu’ils raisonnent et résolvent vos problèmes commerciaux?

D'autres personnes veulent simplement d'excellents développeurs capables de travailler dans n'importe quelle langue. Ils pensent / modèlent le problème et le mettent en œuvre dans n'importe quelle langue. Si vous décidez soudainement que .NET est nul et que vous passez à Java ou inversement, ce sont les développeurs qui refusent de se lancer ou refusent d'apprendre. De même, si vous avez un type de package d'automatisation / de calcul qui dispose d'un langage propriétaire et que vous avez besoin d'automatiser certaines tâches, ce sont les types de développeurs qui peuvent le faire. Exemple concret ... Je devais trouver un langage de script propriétaire personnalisé pour un progiciel de cartographie afin d'extraire des codes postaux pour des régions dessinées personnalisées pour un ancien employeur. Un autre exemple ... Mon employeur actuel a un système de gestion de propriété propriétaire qui contient un langage personnalisé pour la rédaction de rapports ... Dans tous les cas,

Sur le tableau blanc également, il y a une pression supplémentaire / nervosité afin que personne ne soit à son meilleur. De plus, je doute fortement qu'en codant, vous obteniez un résultat parfait à chaque fois. Je suspecte que vous compiliez ou que vous couriez juste et trouviez des erreurs. De plus, cela dépend de la langue. C est suffisamment petit pour que vous puissiez probablement mémoriser la plupart des bibliothèques de langage / noyau (bien que je n’en ait pas besoin). Java / C # a des bibliothèques si volumineuses (avec des changements si fréquents) qu'il est hors de question de les mémoriser.

Le fait de connaître plusieurs langues peut également jouer contre vous. C # et Java interfèrent l'un avec l'autre avec moi. Mais connaître plusieurs langues peut également élargir votre perspective, en particulier si vous connaissez un langage de script et un langage fonctionnel en plus de C # / Java.

Pourtant, si les deux candidats résolvent le problème avec une logique correcte, le type avec une syntaxe correcte a probablement un avantage. Si on résout le problème et on ne le fait pas, alors personnellement, j'irais avec le gars qui peut résoudre le problème.

Néanmoins, si quelqu'un prétend être un expert en Java et ne peut pas déclarer un tableau d'utilisation, une instruction if ou une boucle while, ils pourraient mentir. Mais je comprendrai peut-être si quelqu'un est un expert de Java mais a beaucoup travaillé sur C # récemment et essaie de faire une carte ou quelque chose comme ça…. .Length ou string.length () / string.Length / string.length au lieu de string.length () ... Des choses mineures que je pardonnerais. Ou s'ils oublient l'ordre des arguments d'un appel de bibliothèque. Ou une typo / demi-colon ici ou là ....

Je n'en prendrai aucun.

Une bonne syntaxe est inutile si le programmeur n'est pas bon en résolution de problèmes. Et une mauvaise syntaxe pour une langue donnée signifie que le candidat ne se sent pas à l'aise avec cette langue en particulier, peut-être par manque d'expérience directe.

Quoi qu'il en soit, la logique est beaucoup plus importante que la syntaxe.

Comme toujours, cela dépend. Si les erreurs de syntaxe sont relativement mineures, je les ignorerais. Si elles sont incroyablement gigantesques, je ferais attention à elles et essaierais de déduire pourquoi elles sont là.

Je pense que les erreurs de logique sont pires que les erreurs de syntaxe, ces dernières pouvant presque toujours être interceptées mécaniquement, les premières moins (dépend, dans une certaine mesure, de la langue dans laquelle vous écrivez, certaines classes d’erreurs de logique sont interceptées par des caractères suffisamment avancés. inférence et vérification).

Cela dépendra certainement du poste pour lequel l'entretien est proposé, et probablement aussi de la langue.

Travailler sur C ++, avoir un gars qui bégaie sur la syntaxe est effrayant. C ++ est plein de coins sombres, les pièges reposent pratiquement partout. Un bégaiement de la syntaxe signifie une mauvaise exposition au langage et les débutants en C ++ font beaucoup d'erreurs (pour ne pas dire que d'autres ne le font pas de temps en temps).

Pour répondre à votre question, alors:

• si je dois pourvoir un poste de développeur simple, je prendrais celui qui maîtrise bien la syntaxe C ++. Il ne brillera pas, mais ne devrait pas provoquer trop de catastrophes.
• si je dois pourvoir un poste de développeur principal, je ne prendrais pas non plus. Un développeur principal est censé avoir à la fois de l'expérience et de la logique.

Il n'y a qu'une mise en garde: les gens reconnaissent leur manque d'expérience. Idéalement, les gens devraient coder dans la langue de leur choix ou un pseudo-code s'ils le préfèrent (étudiants par exemple).

Histoire vraie, j'oublie toujours la syntaxe des événements C # lorsque je dois les écrire à la main. Cela arrive parfois dans les interviews. Je n'ai pas le problème quand je code avec un clavier.

Choisissez le gars qui peut coder, pas celui qui ne peut pas mais peut se rappeler de la syntaxe.

Quand j'écris du code sur du papier / tableau blanc, même pour un entretien d'embauche, je saute une grande partie de la syntaxe. Je n'utilise pas de points-virgules, je modifie les appels de méthode, etc. Je suis plus susceptible d'écrire une phrase expliquant 4 lignes de code vraiment basique que le code lui-même. Vraiment, j’utilise un pseudo-code php-like, et parle de ce que je fais, et note des commentaires rapides pour expliquer des choses que je passe sous silence (qui, en théorie, n’ont rien d’important pour la programme)

Mon objectif lors du codage dans une interview est de montrer comment je résous le problème, et non de dicter quelque chose qu'une dactylographe pourrait entrer dans le Bloc-notes et avoir couru.

Longue histoire courte: je pense que vous devriez considérer pourquoi le premier programmeur avait une syntaxe de merde. Il pouvait très bien le savoir, mais le considérait comme non pertinent pour l'entretien et préférait se concentrer sur les aspects difficiles de ce travail (logique et résolution de problèmes).

La personne qui ne peut pas répondre logiquement à la réponse n’est pas qualifiée. Il y a trop de personnes dans notre secteur qui produisent un code de déchets conforme mais ne faisant pas ce qu'il devrait faire ou ne gèrent pas les erreurs ou les cas critiques.

La deuxième personne peut être ou ne pas être non qualifiée selon le type et le nombre d'erreurs et la difficulté de ce que vous vous attendez à écrire. En termes SQL (le langage dans lequel j'écris), la personne qui ne parvient pas à mémoriser la syntaxe d'une jointure explicite n'est pas qualifiée pour un travail nécessitant l'interrogation d'une base de données - pas d'exception; celui qui ne peut pas se rappeler comment obtenir un CTE récusif (mais qui sait qu'ils existent et essaie de l'utiliser) ne l'est pas. En d'autres termes, je m'attendrais à ce que la syntaxe soit plus correcte pour le code de base que vous écrivez tout le temps, mais pas pour les opérations effectuées occasionnellement et non pour la syntaxe complexe.

Si j’envisageais une personne que je connaissais qui possédait d’excellentes qualifications dans un domaine connexe mais ne connaissait que très peu de ma langue, je pardonnerais probablement davantage les erreurs de syntaxe. Je préférerais embaucher un excellent développeur Oracle plutôt qu'un médiocre développeur SQl Server pour un travail SQL Server (bien entendu, une personne de premier plan pour SQL Server serait préférable) et je ne m'attendrais pas à ce que cette personne connaisse la syntaxe de SQL Server si elle peut me montrer comment faites-le dans Oracle. Même chose avec les personnes Java et C #, la personne qui possède d’excellentes compétences en résolution de problèmes est supérieure à celle qui possède d’excellentes compétences linguistiques, mais celle qui les maîtrise toutes les deux gagne à chaque fois (elles sont parfois difficiles à trouver).