Je continue à échouer sur une partie de l'entretien, des suggestions? [fermé]

J'ai donc quelques logiciels / sites dans mon portefeuille. Ils font de l'argent mais pas beaucoup.

J'ai donc décidé d'acquérir une expérience professionnelle, en postulant principalement à des postes de développement junior Java / PHP.

Le problème est que je réponds correctement à toutes les questions techniques et que nous programmons de faire un "test" de codage, la phase finale de l'entretien. Je ne peux jamais me détendre et trop réfléchir et finir par faire le test très lentement. OU parfois je viens de frapper un bloc et j'ai du mal à penser debout.

Je ne comprends pas cela parce que d'autres choses que j'avais écrites résolvaient des problèmes beaucoup plus complexes alors que le "Test" est en fait brutalement simple comme écrire et tester le palindrome.

D'autres fois, ils me donneront un test logique avec les flux vers les opérations mathématiques et encore une fois, je ne serai pas en mesure de le faire dans le temps imparti.

Je sais que je peux écrire des logiciels / sites Web vendables qui peuvent générer de petits revenus et trouver des moyens de résoudre les problèmes, mais j'ai beaucoup de difficulté avec des tests de codage simples lors des entretiens.

Aucune suggestion?

Continuez à assister aux entrevues. Vous finirez par trouver un endroit qui posera des questions plus adaptées à vos points forts. Vous serez également mieux et plus à l'aise avec les entretiens, ce qui ne peut que vous aider. Considérez-le comme un jeu, car c'est vraiment ce que c'est. Continuez à jouer et vous finirez par gagner.

C'est très courant. La plupart des programmeurs sont capables de programmer efficacement lorsqu'ils sont dans leur zone de confort. Par exemple, je ne peux travailler que sur Ubuntu, avec vim, si je n'ai pas cet espace de travail, je n'aurai pas envie de programmer. J'ai également besoin , dans une certaine mesure, de Google pour la recherche.

Je suis sûr que vous avez développé une zone de confort pour la programmation. Je recommanderais de vous habituer à l'environnement où quelqu'un est derrière vous en attendant que son code soit terminé. La meilleure façon de s'y habituer est de continuer à aller interviewer.

Vous pourriez penser que cela n'a pas beaucoup d'impact, et cela pourrait ne pas l'être. Mais pour certains d'entre nous, programmer avec ou sans musique, en utilisant un IDE ou un simple éditeur de texte, en utilisant une chaise en bois ou assis sur un canapé, une pièce sombre ou une pièce lumineuse ... font une énorme différence dans notre développement la vitesse.

Notez qu'une fois que vous avez obtenu le poste, vous pouvez généralement créer votre propre zone de confort dans l'espace de bureau qu'ils vous offrent.

EDIT : Cette question me rappelle à un vendeur, me demandant comment me sentir à l'aise et mieux à froid. La meilleure réponse est de continuer à faire des appels à froid et de réfléchir à chaque appel. Après un moment, le vendeur améliore ses compétences et son confort. Je pense que le programmeur n'est pas différent lors des entretiens, après tout, le point principal est de se vendre à l'intervieweur

Ceci est juste ma suggestion, pourquoi ne pas essayer d'être entrepreneur. Il pourrait y avoir de nombreuses personnes confrontées au même problème. Si vous pouvez écrire des sites Web pour de petits revenus, vous pouvez certainement en gagner beaucoup.

Vous avez déjà identifié quel est votre problème - résoudre les problèmes sous pression (ei quand quelqu'un vous regarde). Est-ce parce que vous manquez de confiance ou que vous n'avez pas assez d'expérience ou que vous craquez sous la pression?

Aller à beaucoup d'entretiens pour acquérir de l'expérience et de la pratique peut être une bonne idée mais peut également produire des contre-effets. Les échecs constants dans les entretiens peuvent ébranler encore plus votre confiance, alors soyez prudent.

Je vous suggère d'essayer la programmation par les pairs afin que vous puissiez vous sentir à l'aise pour résoudre les problèmes lorsque quelqu'un vous regarde. Essayez également de comprendre ce qui vous empêche d'être efficace sous pression (est-ce le stress des tests eux-mêmes, le stress de travailler sous surveillance étroite, le stress de travailler dans un délai spécifique, etc.).

Il semble que vous vous étouffiez sous pression. Puisque vous devez faire les exemples chronométrés dans le cadre du processus d'entrevue, vous devrez apprendre à surmonter cela. Il s'agit de gérer la peur, pas de programmer des compétences.

Une option serait de vous entraîner à écrire des exemples de problèmes et de vous chronométrer. Une fois que vous savez que vous pouvez les faire en moins de dix minutes, vous pouvez craindre d'être moins chronométré.

Une autre option serait de trouver une technique pour calmer votre peur, et l'utiliser pour vous désengorger. L'apprentissage d'une technique de méditation pourrait vous aider. Ou mémorisez la litanie contre la peur (de Dune .) Apprenez une sorte d'astuce pour éliminer votre réaction de peur.

Je suis assez surpris que personne ne l'ait encore demandé, mais comment abordez-vous les tâches de programmation ?

Si vous sautez simplement dans le code, il y a de fortes chances que vous vous perdiez et finissiez par faire des erreurs simples et que vous vous laissiez troubler. Prendre une étape à la fois:

1. Rassemblez les exigences : qu'est-ce que votre enquêteur demande exactement? Assurez-vous qu'il n'y a aucune question en suspens avant le codage. Par exemple, si vous êtes confronté à la vieille question "isPalindrome", posez des questions comme "et si la chaîne a des caractères spéciaux?" ou "les chaînes de longueur impaire telles que 'ada' comptent-elles comme des palindromes?". Vous devez savoir comment clarifier les exigences avant de concevoir un algorithme.
2. Concevez votre algorithme : décomposez-le en sections logiques si cela est logique. Parlez-en .. Écrivez peut-être un pseudocode si vous faites du tableau blanc. Guidez votre intervieweur à travers vos étapes. Essayez de le parcourir avec quelques entrées différentes (valides et non valides) pour vous assurer d'obtenir les résultats souhaités.
3. Maintenant, commencez à coder : à ce stade, vous devriez être très confiant dans ce que vous êtes sur le point d'écrire. Essentiellement, vous devriez simplement parcourir les motions dans la langue que vous connaissez. À ce stade, peu importe s'il y a des erreurs de syntaxe, car les enquêteurs qui en valent la peine pardonneront à ceux qui participent à une session de tableau blanc (si vous disposez d'un PC / IDE pour résoudre le problème, c'est une autre histoire).

Vraiment, quand on s'attaque à des problèmes de codage, un enquêteur ne recherche pas tellement un bon code. C'est plutôt pour voir comment on aborde un problème donné. Plonger directement dans le code est une mauvaise chose, point final.

Vous constaterez également que lorsque vous parlez du problème (collecte et conception des exigences), vous serez un peu plus à l'aise et moins susceptibles de faire des erreurs idiotes pendant la partie codage.

Projet Euler

Il me semble que vous échouez au test fizzbuz . Des algorithmes simples et insensibles qui ne servent généralement à rien d'autre que d'identifier si vous comprenez les concepts de base de la programmation.

Rafraîchissez vos bases

Ce que je recommanderais, c'est de rafraîchir vos bases.

http://projecteuler.net/

Inscrivez-vous et commencez à pratiquer, vous constaterez qu'en parcourant ces exemples, vous aurez une meilleure compréhension des concepts de programmation de base. Je pense que vous y trouverez une question palindrome avec des séquences de fibonacci et d'autres concepts mathématiques (son familier).

Demandez des commentaires pendant ou après l'entrevue. Qu'ont-ils aimé? Qu'est-ce qu'ils n'ont pas aimé? Vous pourriez être surpris des réponses.

Différentes personnes recherchent des choses différentes, bien sûr, mais la façon dont vous essayez de résoudre un problème est généralement plus importante que d'écrire une solution 100% correcte. Vous vous inquiétez peut-être de toutes les mauvaises choses.

La meilleure façon de s'améliorer est de pratiquer. Essayez d'écrire une liste de problèmes courts. Ensuite, pour chaque élément de la liste, écrivez un petit programme qui résout le problème. Commencez avec des problèmes très faciles, comme FizzBuzz , et augmentez la difficulté au fur et à mesure. Pouvez-vous résoudre les problèmes que vous avez vus lors des entretiens précédents? Trouver la plus grande sous-chaîne que deux chaînes ont en commun? Calculer la décomposition en facteurs premiers de n!?

L'idée n'est pas d'apprendre la solution à tous les problèmes que vous pourriez rencontrer, mais de vous entraîner à écrire rapidement de petits programmes, mais aussi de découvrir où sont vos points faibles afin de vous améliorer. De nombreux problèmes sont faciles à résoudre avec la bonne structure de données, mais difficiles autrement, alors assurez-vous d'avoir une base solide dans les structures de données.

Entraînez-vous et trouvez quelqu'un pour vous guider à travers les rudiments de la procédure à suivre. Cela peut prendre une poignée d'essais, mais il pourrait être surprenant de savoir ce qui est découvert si vous pouvez obtenir des commentaires et de la pratique à ce sujet. Un recruteur m'a expliqué comment gérer un problème de tableau blanc une fois, ce qui semble être similaire à votre problème ici.

Je ne suggère pas de mémoriser les réponses autant que d'avoir un schéma de ce qu'il faut faire face à un tel problème et comment le résoudre. À quoi cela ressemble-t-il? Avez-vous vu des problèmes similaires? Que pourraient apporter certaines approches simples en termes d'algorithme? C'est du moins ma suggestion.

Il est assez fréquent que les développeurs de logiciels échouent lorsqu'on leur demande de passer un test de codage ou d'écrire un petit morceau de code lors de l'entretien. Comme quelqu'un l'a déjà mentionné, c'est parce que la plupart d'entre nous ne peuvent coder que lorsque nous sommes dans notre "zone de confort" et assis dans une petite pièce, entourés de 2 à 5 enquêteurs n'ajoute pas vraiment beaucoup de confort.

La réponse est triple:

• pratiquez et pratiquez plus. essayez pendant un mois de faire 30 à 40 minutes de programmation avec un papier et un stylo et vous serez surpris de voir à quel point cela deviendrait facile. Pendant la pratique - essayez le genre de tâches de programmation que vous attendez des sessions de codage d'interview - par exemple, implémentez un singleton, inversez une chaîne, etc. C'est encore plus facile avec "lire ce morceau de code indésirable et trouver ce qui ne va pas "- essayez d'imprimer et d'analyser ces impressions pendant deux semaines et vous améliorerez considérablement cette compétence.

• apprenez à contrôler votre peur. si vous pensez que le test est trop dur et que vous ne pouvez en terminer que 20% - faites-le 20%, ne vous inquiétez pas pour le reste. Il se peut que le test soit déraisonnablement grand pour le temps imparti pour le faire (par exemple, les gars en entrevue sont censés vous donner 20 minutes pour le terminer, mais ils doivent conclure l'interview en 5 minutes en raison d'une explosion de la production, etc.) . Il est également possible que d'autres candidats n'aient réussi à passer le test de 10%, donc en ayant terminé 20%, vous serez toujours en avance sur les autres candidats.

• Lorsque vous écrivez un code lors d'un entretien, ne vous embêtez pas à le rendre parfait lors d'un premier passage. il suffit d'implémenter un "chemin heureux aka le scénario le plus courant en premier" et de prendre la peine de gérer les erreurs plus tard. si vous manquez de temps - ajoutez simplement une note rapide au bas de la feuille décrivant - ce que vous auriez fait pour améliorer le code si vous aviez eu plus de temps.

[dois courir, modifiera / améliorera ma réponse plus tard]

Comme beaucoup de gens l'ont déjà dit, la pratique est l'une des choses les plus importantes. Si vous avez déjà fait un problème similaire, vous pourrez trouver la solution rapidement.

Si vous avez du mal à trouver des problèmes à résoudre vous-même, essayez d'utiliser la recherche Google pour programmer des questions d'entrevue pour votre langue ou votre choix.

Vous pouvez également vous procurer des livres conçus pour enseigner des cours de CS de niveau inférieur. La plupart de ces livres sont remplis de tâches de programmation qui sont petites et peuvent être faites rapidement à la maison. Ils peuvent être utilisés pour la pratique.

Je suis également très mauvais aux tests et je l'ai toujours été. Je ne pouvais pas pour la vie de moi comprendre pourquoi un cours de programmation m'a donné des tests à faire avec un crayon et du papier. Je n'y suis jamais devenu bon. Cependant, j'ai expliqué aux intervieweurs que j'avais ce problème et que je le savais. J'ai également réussi à interviewer des entreprises qui ne m'ont pas donné de tests stupides.

Ma suggestion est de dire à l'entreprise avant de passer l'entretien que vous ne ferez pas ce type de test, mais vous êtes plutôt content de X. (Trouvez une alternative qui a du sens et vous vous sentez à l'aise.) Pour ma part, je leur ai proposé de leur envoyer du code, et une fois, j'ai suggéré qu'ils me donnent un programme simple à écrire, et je l'apporterai avec moi au entretien dans 3 jours.

Selon l'endroit où vous cherchez à obtenir un emploi, cela peut ou non fonctionner pour vous.