Hoe weerleg je effectief een "heksenjacht" als deze?

Het is geen "heksenjacht".

Je moet het vanuit hun perspectief zien.

Je hebt programmeerervaring, je hebt toegang tot Google en Stack Overflow, en je bent erg slim, maar dat zijn ook zoveel andere Baanjagers. Ze hebben ook programmeerervaring, toegang tot Google en Stack Overflow, enz. Met andere woorden: je moet je onderscheiden van die andere werkzoekenden.

En ik ben bang dat verbaal judo niet is waar je je momenteel op moet concentreren.

Als je een baan wilt met C # (in plaats van JavaScript), moet je een klein project bouwen in C #. Als je een baan met Java wilt, moet je een project in Java doen.

En hoewel ja, iemand kan je inhuren om een ​​compleet andere taal te gebruiken dan je gewend bent, maar dat gebeurt. Als je echt je kansen op het vinden van een baan in een bepaald gebied wilt vergroten, moet je bereid zijn te bewijzen dat je bereid en in staat bent om een ​​nieuw project aan te nemen en het in de betreffende taal te doen (dat ben je niet volledig bekend in nog).

En er is geen beter bewijs daarvan dan een speelgoedproject waar je momenteel aan werkt.

Het speelgoedproject kan dan gebruikt worden als startpunt voor een discussie. Het hebben van een project om over te praten, is eigenlijk een geweldige manier om het gesprek te sturen naar iets dat je weet. Zonder dat kan de interviewer gewoon domme algemene vragen stellen die hij / zij van internet heeft gekopieerd en die per definitie moeilijk te beantwoorden zijn.

Je solliciteert in wezen naar een C # -baan en je hebt het alleen op de universiteit gebruikt.

Je zegt dan dat je met andere talen hebt gewerkt en weet hoe je moet programmeren.

Ik ben geen C # -persoon, maar een Java-persoon, en het Java-ecosysteem en de best practices zijn zo groot dat hoewel de taal zelf vrij klein is, het niet zomaar iets is dat je op je eerste dag oppikt . Zelfs met internet en hulp en zo.

Dit is waarschijnlijk ook het geval voor C #, en de senior ontwikkelaar weet dit , en jij niet !

Dat is een rode vlag daar, en ook een grote.

Ik zou wat meer ervaring opdoen met C # en wat goed gepolijste voorbeeldprojecten op bijv. Github voor de wereld om te zien of ik jou was.

RE: fietsen

Programmeren is als fietsen

snel fietsen bestaat uit twee elementen :

• de vaardigheden
• de fitheid

In jouw geval lijkt het erop dat je niet in staat was om fitness aan te tonen.

Stel je voor dat je een manager bent van de plaatselijke fietsclub en je zoekt een nieuwe rijder om je team te versterken. Zou je een renner in dienst nemen die al 2 jaar niet heeft getraind?

In veel gevallen willen fietsclubs die gericht zijn op prestaties een fietser die in topconditie is op het moment van aanwerving, zodat ze kunnen vermijd de kosten om de rijder op te leiden.

Re: computers begrijpen

Weten hoe te programmeren vereist een begrip van hoe computers werken, hoe ze "denken". Als je de ene taal kent, is het niet moeilijk om een ​​andere te leren.

Kosten van bijscholing

Het maakt niet uit of het moeilijk of gemakkelijk is. Het gaat erom hoe lang het duurt voordat je productief bent en als je de taal / technologieën niet kent, kan dit maanden duren.

Oplossing

Ik stel voor om open te gaan bronproject.

Met openbare commits kun je gemakkelijk je bijdragen laten zien (die je vaardigheden laten zien) en wordt het gat van 2 jaar irrelevant.

Bedoel niet om u in elkaar te slaan, maar uw weergave van programmeerkennis is naïef.

Syntaxis is eenvoudig. Syntaxis opzoeken is eenvoudig. Wat moeilijk te weten is, is wat je moet opzoeken.

Wanneer zou je een taak in plaats van een discussie gebruiken? LINQ bestaat al een paar jaar, maar ik wed dat het er niet was toen je op de universiteit zat. Wanneer zou u EF versus SQLLINQ versus ruwe TSQL gebruiken? Heb je de berichtenwachtrij gebruikt?

Ik codeer C # de afgelopen 10 jaar fulltime en ik ken niet alle functies. 4 jaar geleden was ik fulltime ASP.NET. Ik ben niet op de hoogte van de nieuwe dingen. Het zou me een maand kosten om op 1/2 snelheid te komen en 4-6 maanden om volledig op de hoogte te zijn van de nieuwe dingen. Werkgevers eisen de nieuwe dingen, omdat consumenten de nieuwe dingen eisen. De consument weet misschien niet wat asyc is, maar hij weet wanneer de gebruikersinterface vastloopt.

Ik stel voor dat je de houding laat varen en op de hoogte bent van de nieuwste functies.

De belangrijkste manier om interviewers te overtuigen dat u na een pauze niet bent vergeten hoe u uw werk moet doen, is door hen te laten zien . Maak een vrijetijdsproject, ontwikkel het van begin tot eind en geef ze de bron en / of links naar waar het wordt gehost. "Je bent bang dat ik ben vergeten hoe ik moet coderen? Nou, hier is wat code die ik vorige week heb geschreven!"

Een grotere zorg is de schijnbare aanname dat programmeren iets is dat je een keer en nooit meer moet leren , de rest is slechts detail. Met name de suggestie dat het voor u triviaal zou zijn om C # op te halen, omdat u JavaScript kent, is een rode vlag. Om te beginnen is het verschil tussen sterk getypeerde en zwak getypeerde talen enorm! Als je JS kent, zou je dan code kunnen schrijven die is gecompileerd in C #? Misschien wel, zeker met de hulp van een IDE. Maar zou het idiomatisch zijn, correct gebruik maken van het (enorme) .NET Framework, efficiënt gebruik maken van de GC, parallel draaien waar nodig, enz.? Ik heb twijfels.

Om een ​​voorbeeld te geven uit mijn ervaring, toen ik C # leerde kennen nadat ik eerder voornamelijk in C en C ++ werkte (alle syntactisch vergelijkbare talen), zou ik schatten dat het me twee of drie jaar om een ​​vergelijkbaar expertiseniveau te bereiken. Heeft deze toekomstige werkgever twee of drie jaar te wachten? Misschien niet.

Het is waar dat begrijpende werkgevers zullen weten dat goede ontwikkelaars uiteindelijk nieuwe talen kunnen leren. Het is ook waar dat goede werkgevers hun personeel zullen opleiden in plaats van te wachten tot een ander bedrijf het voor hen doet. Maar het is ook waar dat hoe eerder een nieuwe werknemer volledig productief kan worden, hoe beter, wat de werkgever betreft. Het is mogelijk dat hun zorgen niet zozeer gaan over uw aangeboren codeertalent als wel over uw huidige vaardigheden en relevante kennis. Hoe ouder die dingen zijn, hoe langer het duurt voordat je op de hoogte bent, en totdat dat gebeurt, ontvang je een salaris zonder (veel) bij te dragen. Op die manier bekeken, is het volkomen begrijpelijk dat een werkgever bedenkingen heeft. Om die bedenkingen te overwinnen, laat ze zien dat je weet wat ze nodig hebben om te weten. Terwijl u aan een project voor dat doel werkt, kunt u zich zelfs realiseren dat het niet zo gemakkelijk is om van het ene naar het andere over te schakelen als u lijkt te denken.

Ervan uitgaande dat zowel je C # -ervaring bijna aan het begin was van de 15 jaar waarover je praat (aangezien je vermeldt dat het op de universiteit was), als dat ze specifiek aan het werk waren voor een C # -positie, suggereerden ze niet echt dat je "vergeten" het werk - meer dat je het nooit echt had gedaan. C # en het .NET Framework van ~ 15 jaar geleden is een heel ander dier dan wat je nu hebt. Zo erg zelfs dat de universiteitservaring bijna waardeloos zou zijn.

Ja, je ervaring met het werken in andere talen zou je een niet onaanzienlijke voorsprong geven bij het leren ervan, maar de realiteit is dat je een behoorlijk steile leercurve voor de eerste paar maanden in ieder geval en als een bedrijf iemand inhuurt die ervaring heeft met een bepaalde taal / technische stack, dan is dat meestal omdat ze iemand nodig hebben die zogezegd een vliegende start kan maken en meteen productief kan zijn, niet in x maanden tijd.

Ik sprak met een recruiter over een andere open positie hier in de stad. Hij zinspeelde op het idee dat zijn cliënt het misschien niet leuk vindt dat ik al een tijdje niet meer professioneel met webontwikkeling heb gewerkt.

Als het om een ​​full-stack of front-end-gebaseerde rol ging dan kan ik zien wat de recruiter bedoelde - in het bijzonder de JavaScript-frameworks bewegen erg snel en dit kan hen aangaan. Om die angst tegen te gaan, is de beste aanpak om kennis te tonen van hoe het ontwikkelingslandschap in die tussenliggende tijd is veranderd.

Leg aan recruiters / interviewers uit dat u begrijpt dat de branche snel evolueert, maar dat u de veranderingen in uw persoonlijke tijd bijhoudt (ervan uitgaande dat u - zo niet, neem dan een weekend of twee en maak het waar) en dat u denkt dat u onmiddellijk productief kunt zijn als u een nieuwe functie start. Als je de tijd hebt, zou je idealiter enkele codevoorbeelden kunnen produceren in de frameworks, enz. Die zijn vrijgegeven sinds je de branche hebt verlaten en deze publiceren op GitHub of iets dergelijks om een ​​back-up van je claims te maken.

Sommige werkgevers kan nog steeds aarzelen bij het idee, maar de meest redelijke zouden het moeten begrijpen.

Het probleem is niet de lange pauze.

Je vergelijkt een:

• meestal statisch
• gecompileerd
• sterk getypeerd
• klasse-gebaseerd

taal (C #) naar een

• dynamisch
• geïnterpreteerd
• zwak getypt
• op prototypen gebaseerd

taal (Javascript).

En je denkt dat ze onderling uitwisselbaar zijn omdat ze hebben een vergelijkbare syntaxis. Als ik de interviewer was, zou dit meer dan genoeg informatie zijn om de discussie meteen te stoppen.

Misschien wil je dat punt zelf aanpakken voordat ze het doen, en het stuur overnemen terwijl je uitlegt dat de pauze niet echt een nadeel is. Probeer ze b.v. "Je bent een senior ontwikkelaar, je weet dat het niet gaat om het onthouden van syntaxis, maar om te weten wat je niet weet"
Je zou ook willen aantonen dat je weet wat er nieuw is en wat goed werkt met hun programmeerstapel . bijv. "Terwijl ik in mijn pauze zat, heb ik het nieuws en de trends van taal X en framework Y gevolgd, ik kan gemakkelijk iets bouwen volgens de 2018-normen"

U moet zich realiseren dat de hoofdprogrammeur waarschijnlijk een punt heeft. Ik zou niet toestaan ​​dat iemand die zichzelf beschrijft zoals jij dat doet (JavaScript-achtergrond, talen categoriseren zoals jij dat doet) een grote en kritische OOP-codebase sluit zonder dat je een aantal serieuze vragen beantwoordt.

Voor mij is het zo iets heel anders als je codeert in een op prototypen gebaseerde taal of een op klassen gebaseerde taal. Ik ben zelf bedreven in veel talen, hoewel deze allemaal op klassen zijn gebaseerd (zelfs als ik geen fundamenteel probleem heb om de ene boven de andere te bevoordelen), ik weet dat mijn zwakte ligt in het gebruik van op prototypen gebaseerde talen - en of ik zou solliciteren voor een baan hierin is het duidelijk dat ik de technische persoon die mij interviewt ervan moet overtuigen dat ik weet wat er aan de hand is.

Wat je normaal gesproken in een dergelijke situatie zou moeten laten zien, is de poging om op te helderen wat er ontbreekt van uw vaardigheden, inclusief het accepteren dat u misschien niet de technisch meest bekwame persoon voor de baan bent, maar de meest professionele met de wil om te leren en te doen wat nodig is.

Programmeren is een vaardigheid, talen zijn slechts hulpmiddelen. Het beste tegenargument zou zijn. "Als je een bekwame automonteur had, zou je dan aan zijn vaardigheid twijfelen omdat hij recent geen oliefiltersleutel had gebruikt?"

De vaardigheid is belangrijker dan het gereedschap.

Ik begrijp volledig waar je vandaan komt. Ik ben een software-engineer die begon als een hobbyist en ik had een geweldige tijd om recruiters en HR-afdelingen te overtuigen om me mijn eerste kans te geven. Het klinkt alsof de barrières waar je tegenaan loopt nadat je een tijdje geen ontwikkelwerk hebt gedaan vrij gelijkaardig zijn. Met dat in gedachten, mijn advies:

Ik heb opleiding en werkervaring in IT, met name in webontwikkeling. Ik programmeer en schrijf al 15 jaar markup. Ik heb professioneel gewerkt als webontwikkelaar en heb die vaardigheden in mijn persoonlijke leven gebruikt.

Wat ik ga zeggen klinkt misschien raar of oppervlakkig, maar het is geboren in mijn ervaring tijdens mijn afgelopen tien jaar in het personeelsbestand. Ik heb gemerkt dat bedrijven die hun ontwikkelaars omschrijven als "IT" en die items als "schrijfopmaak" in hun functiebeschrijvingen plaatsen, over het algemeen meer traditionele, minder flexibele operaties zijn. IT is ook vaak een kostenpost binnen een niet-technische organisatie, terwijl ontwikkeling meestal is "waar de magie gebeurt" in een op technologie gericht bedrijf. Omdat ik aan beide kanten van die kloof heb gestaan ​​(vier jaar in QA / programmeren in een IT-rol, de rest in niet-IT-programmering), zou ik je aanmoedigen om indien mogelijk naar de laatste soort rol te streven. In mijn anekdotische ervaring geeft IT veel meer om de certificeringen die je hebt en hoe goed je bent op papier (heb je bijvoorbeeld hiaten in de baan?), Terwijl softwarewinkels veel meer lijken te geven om 'kun je dit oplossen whiteboard-probleem / programmeeropdracht mee naar huis nemen "waarvan ik denk dat het in uw voordeel zou werken. Dit is enigszins raak van de rest van het antwoord, maar het is nog steeds het overwegen waard!

Ik heb de afgelopen 2 jaar een pauze genomen van de IT-industrie omdat ik gewoon een pauze nodig had. Ik ben onlangs begonnen met proberen weer aan het werk te gaan.

Het helpt om iets te laten zien of een verhaal te vertellen over je pauze. Als de doorbraak was: "Ik was net opgebrand bij het programmeren", begrijp ik dat helemaal, maar je wilt er een positieve draai aan geven als het in interviews naar voren komt. Het zou leuk zijn om gewoon duidelijk te kunnen zijn in uw redenen hiervoor, maar ik denk dat een beetje persoonlijke marketing hier uw kansen zou vergroten. Heb je de afgelopen twee jaar de kans gehad om aan iets interessants te werken, of te reizen, of misschien een niet-programmeer-passie te volgen?

Eind vorig jaar vond de CEO van een lokaal bedrijf me op LinkedIn en spoorde me aan om te solliciteren. Ik ontmoette de CEO en de hoofdprogrammeur via de telefoon. De hoofdprogrammeur liet het klinken alsof ik geen schijn van kans had, omdat ik sinds mijn studie geen specifieke programmeertaal (C #) had gebruikt.

Als je ook vrije tijd hebt genomen softwareprojecten, zou het goed zijn om dat nu weer op te pakken in plaats van nadat u weer aan het werk bent. Toen ik de sprong van hobbyist naar professional probeerde te maken, leverden zijprojecten het bewijs om het vertrouwen van personeelsmanagers te versterken dat ik niet zomaar zou crashen en verbranden op de eerste dag.

Hier is een voorbeeld Ik creëerde (veel later) terwijl ik probeerde een nieuwe taal te leren (Rust). Het is een amateuristische Tetris, geschreven in een taal die ik niet beheerste. Zelfs gezien het feit dat het minder dan professioneel is, heeft het kunnen wijzen op werk dat ik met succes heb afgerond in een taal die nieuw voor me was, me geholpen mijn eigen zaak te verdedigen. Als u uw C # -vaardigheid aantoont in een bijproject, zou het risico van de aanwerving vanuit het perspectief van het bedrijf afnemen.

Hoewel ik een beetje beledigd was door deze neerbuigende opmerking, reageerde ik niet en liet het maar gebeuren . Maar ik wilde hem echt op zijn plaats zetten. Programmeren is als fietsen of je schoenen strikken. Het is niet iets dat u gewoon "vergeet" te doen.

Ik leef hier met je mee. Toch vertonen de synchrone request / response-apps die ik in 2012 bovenop Django aan het bouwen was, heel weinig gelijkenis met de apps met één pagina die mensen tegenwoordig bouwen bovenop generieke Rest API's. Er is zoveel logica naar de frontend verplaatst. Je weet nog steeds hoe je moet rijden met het wielvoertuig dat je hebt leren rijden, maar de kinderen rijden tegenwoordig op eenwielers. U hoeft niet de nieuwste en beste te gebruiken om nuttige interfaces te bouwen, maar ik heb gemerkt dat wervingsverzoeken een voorkeur hebben voor nieuwere frameworks. Je moet er op zijn minst vertrouwd mee zijn, zodat je goed beredeneerde argumenten kunt maken voor wanneer ze wel of niet geschikt zijn.

Elke goede programmeur kan op talloze bronnen en documentatie vertrouwen als hij een commando of een methode. Als je een taal kent, is het niet moeilijk om een ​​andere taal op te halen.

Waar en niet waar. Ik heb banen gehad waarbij ik code heb bijgedragen in Java en C #, maar Python is mijn brood en boter en ik kan vol vertrouwen zeggen dat hoewel ik de taken heb volbracht die ik in die andere talen moest volbrengen, ik dat deed zonder vertrouwd te zijn met taalidioom en mijn code had zeker "een accent" dat me weggaf als niet-moedertaalspreker.

Snel vooruit naar vandaag, ik sprak met een recruiter over een andere openstaande positie. Hij zinspeelde op het idee dat zijn cliënt het misschien niet leuk vindt dat ik al een tijdje niet professioneel met webontwikkeling heb gewerkt. Dat laat ik ook zo, maar ik ga nog steeds proberen voor de functie.

Hoe ga ik zo om met werkgevers of recruiters? Is het de moeite waard om zo'n "heksenjacht" te weerleggen?

Door extra goed te zijn! Je beleeft geen heksenjacht; u ervaart de twijfels van mensen die niet bekend zijn met uw werk en uw capaciteiten. Dit wordt versterkt omdat goed presteren in je huidige functie wordt gezien als een sterk bewijs van competentie (zoals ik ontdekte toen ik probeerde een baan als hobbyist te krijgen zonder dat trackrecord). Het is verbazingwekkend hoeveel dit soort bewijs ertoe doet; in 2011 kon ik niemand betalen om me voor hen te laten programmeren, maar na een jaar ervaring met de functietitelprogrammeur (waarin ik zelfs geen erg goede programmeur was), begon ik recruiters wekelijks of zelfs dagelijks te bereiken. / p>

Je moet interviewers een warm en vaag gevoel geven over je vermogen om de taak te volbrengen die ze nodig hebben. U kunt dit doen door uw vaardigheden op te frissen, uw interviewtechniek aan te scherpen en hen werk te laten zien dat u onlangs heeft gedaan. Als je de laatste tijd nog niet hebt gewerkt, is dit een goed moment om in een bijproject te springen dat je programmeervaardigheden zal afstoffen EN je een voltooid project geeft dat je met interviewers kunt bespreken.

Mijn beste advies hier is: show, don't tell.

Als ze zeggen alsof je bent vergeten wat je moet doen, antwoord dan met toegepaste kennis. Laat zien dat je ervaring hebt.

Schrijf in je vrije tijd een app of twee, zet een deel van je werk online en neem het op in begeleidende brieven enz. Zodat ze je werk kunnen zien. Sterker nog, laat de code open voor weergave op GitHub of een vergelijkbare service.

Ook een korte opmerking uit mijn eigen persoonlijke ervaring. Recruiters zullen een scatter-shot-benadering gebruiken om zoveel mogelijk potentiële kandidaten te matchen tot de posities die ze proberen te vervullen. Dit was erg frustrerend voor mij toen ik op zoek was naar een instappositie en 300 mijl werd gestuurd om te solliciteren voor een functie waarvan het salaris hoger is dan ik nu ben, 8 jaar later, en verdiende.

I vond uiteindelijk werk toen een van deze recruiters heel direct besloot het contact te verbreken omdat ik geen van de ongepaste banen kreeg waarvoor hij me naar voren had geschoven.

Ik googlede banen bij Rails (mijn belangrijkste medium), en stuurde speculatieve e-mails, evenals het beantwoorden van vacatures. Ik merkte dat de baan zelf vanaf het begin heel eerlijk was over mijn functie, in tegenstelling tot werken via een professionele recruiter.

Om een ​​lang verhaal kort te maken: als het pad van rekruteringsagenten niet werkt, probeer het dan op een andere manier.

In mijn ervaring als interviewer en geïnterviewde heb je een beetje pech gehad. Het kan veel bedrijven niet schelen of hun nieuwe werknemer de taal of het framework du jour kent die ze toevallig gebruiken bij hun huidige project.

IT is tenslotte een snel veranderend veld, wat vandaag het nieuwste en coolste is, zal morgen oude, knapperige legacy-code zijn. Wat ik wil als ik iemand interview, is om erachter te komen of ze goede basisprincipes van CS hebben en gemakkelijk nieuwe dingen kunnen oppikken, of het nu gaat om talen, frameworks of programmeerstijlen.

Dat, motivatie en interesse in programmeren (coole projecten op github? werken aan een open source-project ernaast? wat vind je van de laatste ontwikkelingen in je favoriete taal? ..) zijn veel meer belangrijker dan of je C # kent.

Dat houdt zo ongeveer in wat voor soort antwoord ik een interviewer in die situatie zou geven: nee, ik ken C # nu niet, maar ik ben gemotiveerd om ervoor te kiezen en ik heb veel meer geldige vaardigheden die ik aan het bedrijf kan inbrengen dan een specifieke syntaxis kennen.

Ga er allereerst niet vanuit dat een ‘agressieve’ vraag van een interviewer betekent dat ze een negatief beeld van je hebben. Ze proberen misschien gewoon te zien hoe u reageert op een beetje druk.

Ten tweede zijn er mensen in deze branche die echt geloven dat u 10 jaar ervaring moet hebben met alle technologieën die u gaat gebruiken op een nieuw project, en begrijpen totaal niet dat goede programmeurs voortdurend nieuwe trucs leren en dat ze echt iemand willen die goed is in het leren van nieuwe vaardigheden. Gebruik het interview als een kans om ze te vertellen dat ze het bij het verkeerde eind hebben: vertel ze hoeveel nieuwe talen en technologieën je onder de knie hebt in je carrière. Als dat werkt, heb je te maken met een werkgever die goed is om voor te werken; als dat niet het geval is, ben je er het beste uit.

Enkele uitstekende antwoorden hier suggereren het OP om een ​​speelgoedproject te maken. Ik zou hem aanraden om nog een stap verder te gaan en te proberen wat werk te krijgen als freelance webontwikkelaar. Er zijn tal van webontwikkelingstaken op de freelancer-website. Als hij daar eenmaal een paar projecten heeft gedaan, kan hij zijn freelance profiel linken aan linkedin.

Twee dingen:

De mening van een recruiter is niet erg nuttig, ze zijn niet de rekruteringsmanager en hebben geen zeggenschap over de uiteindelijke beslissing. De opmerking van uw recruiter was onprofessioneel, maar gebruikelijk omdat het gewoon mensen zijn zoals ieder ander. Ze rekenen er ook op dat je een baan krijgt in ruil voor je tijd, dus dat is misschien gewoon een manier waarop ze niet met je willen werken. Hoe dan ook, ga verder, er zijn veel recruiters en zoals ik al zei, ze doen het voor het geld om je niet te helpen.

In jouw situatie raad ik aan om direct te solliciteren, mogelijk met een begeleidende brief met vermelding van enkele van je kwalificaties, maar hier is waar je tegenaan loopt:

Als ik twee programmeurs kan inhuren en beiden het probleem kunnen oplossen, waar de een recente ervaring heeft en de ander niet, welke denk je dat het het sneller zal oplossen (binnen budget)?