[Attel Malagate]

Citation :

Publié par Ariakah

Le Code Titre, c'est ça TP-01280 si c'est bien le chiffre que tu souhaites avoir

Par contre, je ne suis jamais allé sur ce site. C'est ma conseillère Pôle Emploi qui m'a conseillé cette formation et j'y suis allé sans trop d'espoir d'être pris vu mon âge et ma grosse période à vide pour des raisons personnelles

Et le Greta ne t'as jamais donné ça ?
https://www.banque.di.afpa.fr/Espace...1280m03&type=t

Bon.
Je veux pas te faire peur. Mais si le Greta ne t'as jamais parlé de jury, du dossier professionnel à remplir et tout.
Rapproche toi d'eux, et demande des renseignements.

Parce que j'ai déjà aidé quelqu'un à remplir un dossier pro.
Et c'est pas de la tarte.

[Neirdan]

Mdr, en tant que juré, le dossier professionnel, on ne l'ouvre que lorsqu'on a un doute sur les capacités du candidat.
Ce qu'il lui faut, c'est le RC du titre, pour savoir comment son examen va se dérouler.

[Attel Malagate]

Citation :

Publié par Neirdan

Mdr, en tant que juré, le dossier professionnel, on ne l'ouvre que lorsqu'on a un doute sur les capacités du candidat.
Ce qu'il lui faut, c'est le RC du titre, pour savoir comment son examen va se dérouler.

C'est l'attitude commune à tous les jury en France ou juste le tien et de quelques uns de tes confrères ?
C'est de l'ordre du possible de tomber sur un jury qui regarde attentivement le DP ou pas?

En tout cas, il semble bien qu'il a un DP à rendre + un projet d'entreprise avec passage devant un jury pendant 1h30 pour prétendre décrocher son Titre pro.

[Neirdan]

Si c'est un titre équivalent bac +2:

30 ou 35 minutes de présentation
suivi directement de
35 ou 40 minutes de d'entretien (questions) technique du jury

Echange entre les membres du jury (2 a 3mn)

15 minutes d'entretien final sur la posture professionnelle

Délibération du jury (là ça peut varier).

C'est l'attitude que j'ai pu constater chez tous les membres du jury avec qui j'ai soit été juré, soit le formateur.
Il y a aussi un dossier ECF (examen en cours de formation), pareil, on n'y prête pas trop d'attention, sauf si gros doute lors de l'entretien technique.

J'ai eu un candidat qui nous a pondu en 15 minutes une fonction d'addition qui donnait ça :

public void function addition (int a, int b) {
int a = 8;
int b= 5;
int c = a + b;
return c;
}

Autant dire qu'on a regardé son DP et son ECF avec attention.

[La Hutt Finale]

Mon examen ca a été "ouhlala covid, controle continu kthx bye restez chez vous".

[Gratiano]

Citation :

Publié par Trisch

Hu, comment ça pas de déclaration de variables en JS ? Pas de controle de type ? :X

Code:

const mastring = 'hello'

if (typeof mastring === 'string') { 
    console.log('im-a-string') 
}

va donner quoi selon toi ? ( tu noteras le const, et le === qui fait un controle également sur le datatype)

Je veux bien que pour un dev qui n'a fait que du langage typé (strict), passer en JS est perturbant (moi le premier), mais de là à dire qu'il n'y a pas de declartion de variable, ou de possibilité de controler/type..... teudieu, on est dans le dev, donc on se doit d'etre strict aussi dans ce que l'on affirme !

JS est "autant typé" que le php, et ça n'a pas empéché ce dernier de dominer le dev web pendant des années.

C'est ce que je dis, il n'est pas typé strict. Tu es obligé de le coder et vu que je fais ce boulot, je vois peu voire pas de personnes le faire donc niveau maintenabilité, c'est zéro.
Le même problème existe en php. La théorie, c'est bien mais la pratique montre tout autre chose.

Fais cela en java, la pré compile t'envoie chier direct et tu compiles pas point. C'est pour cela que je préfère bosser en java avec des framework java qui te permettent bien des choses tout en évitant ce genre de trucs. Après c'est un choix.

Comme tu le dis, on est dans le dev et donc on voit de tout et surtout du n'importe quoi. Tous les devs ne sont pas bons et tu peux voir des horreurs ensuite. Donc m'en remettre à un langage permissif, très peu pour moi. C'est pour cela que je n'aime pas l'évolution actuelle car dans un voire deux ans, ceux qui devront maintenir ça s'arracheront les cheveux et ceux qui auront codé ces horreurs ne seront plus là. C'est aussi ça le dev.

[Ghalleinne]

Y'a quand même Typescript qui est quand même pas mal présent (ne serait ce que parce qu'Angular l'impose) et qui permet de retrouver un typage plus rigoureux.

On retrouve la même chose que sur Java ou C#, si tu as fais de la merde dans le typage, ça sort des erreurs aussi sec.

Perso, avec ma petite expérience, ça semble tout à fait régler les problèmes de variable mal typée du Javascript.

[Gratiano]

@Ghalleinne: Je ne me suis pas trop penché sur Angular mais si ce genre de chose existe, c'est très bien.

[derioss]

Il n'y a pas aussi de language meilleur que d'autre, il y a le bon language en fonction du job et des compétences de ton équipe.

Il y a tout un tas de process permettant d'éviter des horreurs, que ce soit un language typé ou pas, mm des languages fortement typé tel que java ou python, le legacy cela existe.

Le premier truc que tu te dis, c'est un manque de compétence, c'est un piège souvent, il faut situer le contexte (année de dev, contrainte archi etc..) et se poser les bonnes questions, cela évite des surprises comme de refactor un pan de code et que ca pète à l'autre bout.

De toutefacon, il faut être humble et respecté le code de tes collègues et tes collègues, on fait tous de la merde à tout les niveaux, et d'ailleurs les premiers années, quand tu regardera ce que tu a coder il y a quelques mois, tu dira putain j'ai vraiment fait de la merde...(c'est un bon signe ca).


Pour ta recherche de stage, essaye des gens de bonnes "intentions" comme le CNRS ou autre, les tpe/pme, tu a fais du php, tu pourras toujours trouver à faire de l'intégration wordpress en stage.

Ensuite, tu a énormément d’activités sur linkedin, sinon non, les gas cherchent pas le mouton à 5 pattes car il est cher.
Les annonces faut également savoir les lires, si tu vois anglais B2 c'est un prérequis, si tu vois bac +5 c'est souvent un souhait..

Mm issue dans la reconversion, au bout de un deux ans d'xp les offres pleuvent sans que tu les cherches vraiment, cela dépend aussi des opportunités de tes premiers postes mais également de ta curiosité pour le secteur qui se voit rapidement en entretien ou sur un C.V.

Après, les framework, oui et non, c'est pas grave si tu a pas vu le dernier truc à la mode, tu es débutant, tu ne sais pas coder, tu n'es pas autonome, tu ne connais pas les process, ce que tu vend c'est ton envie et rapidité de progression.

Ta plein de MOOC à faire pour te sensibiliser et prouver ton intérêt pour le métier, cela te mettra le pied à l'étrier en prouvant que tu n'est pas la parce que tu a vu la lumière.

Car la première barrière niveau recrutement chez les gas en reconversion, c'est bon le gas est la pourquoi ? pour le plein emploi et prendre la thune, ou parce qu'il aime ca.
Et c'est ca qui conditionnera ta rapidité de prise de poste, car les 2/3 premières années c'est assez violent la courbe de progression, sachant qu'un débutant les 6 premiers il coute cher à l'entreprise.


C'est pour ca d'ailleurs que si tu à le choix vise toujours la compétences jamais le salaires, ni les conditions, si tu peux te le permettre, tu perdra un peu au début, mais tu fera rapidement un x2 en salaire voir un x3 à moyen long terme si tu a commencé bas.



Pour moi, apprendre ce que c'est les test unitaire, git, les workflows et globalement comment on fait de la "qualité de code", te sensibilisera plus que de foncer tête baisser dans un framework.
Savoir taper quelques commandes linux, c'est pas du luxe en stack php également.
Coté base de données mysql et une nosql, pas de devenir un cador mais au moins passer 30/40 H sur un MOOC afin de comprendre comment ca marche.
Savoir démarrer un container docker ou un vm te fera également gagné du temps, la tu est aussi a 30/40H.

Et pitié git, ca ne s'apprend pas avec un IDE, cela s'apprend en ligne de commande et après tu passe à l'IDE.

En gros, si ta formation te forme pas sur cette techno, c'est pas un problème, tu va la chercher tout seul la compétence, et c'est de toutefacon, ce qu'on te demande en entreprise.

[Doudou Spuiii]

Citation :

Publié par Ariakah

Justement on m'a conseillé de récupérer les bases sur Openclassroom et de poursuivre ses connaissances sur CodInGame

En fait, ce qui va pas mal compter aussi, c'est comment tu te démerdes en entretien et comment t'arrives à broder.
Si t'as pas d'xp mais que t'arrive à tchatcher un peu lors de ton entretien et que t'as l'air de savoir où tu vas, même si au fond tu doutes, t'auras plus de chances que la brute nerd premier de promo qui va bredouiller en regardant ses pieds face au recruteur.

Bon après, le soucis quand tu sais tchatcher mais que tu maitrises pas, c'est quand tu dois vraiment bosser une fois que t'as eu le job, mais bon, faut prendre un problème après l'autre

[Gardien]

Citation :

Publié par Gratiano

C'est ce que je dis, il n'est pas typé strict. Tu es obligé de le coder et vu que je fais ce boulot, je vois peu voire pas de personnes le faire donc niveau maintenabilité, c'est zéro.
Le même problème existe en php. La théorie, c'est bien mais la pratique montre tout autre chose.

Ce genre de souci sont réglé de façon simple avec du Code review... Par un mec expérimenté et qui va identifier ces soucis.

Après, sans code review... Quelques soit le langages, tu peux avoir des horreurs....

[Gratiano]

Citation :

Publié par Gardien

Ce genre de souci sont réglé de façon simple avec du Code review... Par un mec expérimenté et qui va identifier ces soucis.

Après, sans code review... Quelques soit le langages, tu peux avoir des horreurs....

Je suis bien d'accord avec toi mais bien souvent dans de petites équipes, le code review passe à la trappe pour plein de raisons et oui après c'est l'horreur.

[derioss]

Du coup, c'est un souci de management pas de language.

[La Hutt Finale]

Citation :

Publié par derioss

Du coup, c'est un souci de management pas de language.

Langage. We are in France, we speak french.

[Gratiano]

Citation :

Publié par derioss

Du coup, c'est un souci de management pas de language.

Oui et non, c'est surtout un souci de coût et de délai comme d'habitude. Et puis @Gardien l'explique bien, tu as aussi des dev inexpérimenté sans encadrement et sans règle de codage et là c'est la foire.

Je n'ai vu que du code review que sur des gros projets avec plusieurs prestataires. Quand c'était un petit projet (comprendre 5-6 personnes max), le code review passait systématiquement à la poubelle...

[derioss]

Ouaip je vous bien le trucs.

Alors les bonnes pratiques = pertes de temps.

Mm c'est quoi agile ? Tu sais le truc avec les sprint et qui permet de mesurer l évolution de la productivité globale de une équipe afin d avoir des retours si les process mis en place sont utile ou non, de planifier etc..

Ah cool, bon ça on garde, on va s en servir pour enchaîner les sprint et mettre la pression aux devs.
Et on va mettre des chef de projet/scrum master de partout afin de bien surveiller tout ça.

[Gratiano]

@derioss: Voilà c'est ça

[La Hutt Finale]

Citation :

Publié par derioss

Mm c'est quoi agile ?

On a pas trouvé mieux pour vendre des formations qui servent à rien.

[N° 44 636]

dams ma boite on a de l'agile ET des code review. C'est pas incompatible, faut juste penser sur le long terme.
Je rejoins qd meme Gratiano (je marque ce jour d'une pierre blanche) sur le typage. On utilise python pour le back, on type ca avec Pydantic + Mypy. Le front on type ca avec Typescript.
Ca évite tellement d'erreurs.

[Gratiano]

Citation :

Publié par N° 44 636

Je rejoins qd meme Gratiano (je marque ce jour d'une pierre blanche) sur le typage.

Comme quoi tout est possible.

[Mordreck]

Citation :

Publié par Gardien

Ce genre de souci sont réglé de façon simple avec du Code review... Par un mec expérimenté et qui va identifier ces soucis.

Après, sans code review... Quelques soit le langages, tu peux avoir des horreurs....

Meme avec du code review cela va reposer sur les bonnes intentions contrairement a une contrainte forte du langage, qui s'assure que certaines mauvaise pratique ne puisse pas se faire (par exemple, utilisation de type heterogene au sein de la meme variable, declaration de variable globale au sein d'un scope local, etc...)

[Manael]

Citation :

Publié par Gratiano

Oui et non, c'est surtout un souci de coût et de délai comme d'habitude. Et puis @Gardien l'explique bien, tu as aussi des dev inexpérimenté sans encadrement et sans règle de codage et là c'est la foire.

Je n'ai vu que du code review que sur des gros projets avec plusieurs prestataires. Quand c'était un petit projet (comprendre 5-6 personnes max), le code review passait systématiquement à la poubelle...

De mon côté, petit ou gros projet, le code review et la qualité de code c'est systématique : les outils de nos jours simplifient ces process, entre les merge review de gitlab, l'utilisation de phabricator pour ceux qui sont sous svn, les analyses qualité de Sonarqube, c'est très facile de s'assurer que les choses soient faites proprement.

[Gratiano]

@Manael: C'est toujours facile quand la volonté est là. Quand elle n'est pas là, et bien tu arrives à des situations très compliquées.

[Ariakah]

Citation :

Publié par Doudou Spuiii

En fait, ce qui va pas mal compter aussi, c'est comment tu te démerdes en entretien et comment t'arrives à broder.
Si t'as pas d'xp mais que t'arrive à tchatcher un peu lors de ton entretien et que t'as l'air de savoir où tu vas, même si au fond tu doutes, t'auras plus de chances que la brute nerd premier de promo qui va bredouiller en regardant ses pieds face au recruteur.

Bon après, le soucis quand tu sais tchatcher mais que tu maitrises pas, c'est quand tu dois vraiment bosser une fois que t'as eu le job, mais bon, faut prendre un problème après l'autre

Je vais essayer même si je ne me sens pas trop à l'aise à cet exercice

Par contre je n'ose plus suivre entièrement vos réponses car je suis totalement largué dans ce que vous dites. Excusez moi d'avance