... voor elk uur dat ik mijn technische verantwoordelijkheden vervul, hoeveel minuten ze denken dat ik zou besteden aan administratieve taken, zoals babysitten, documentatie, niet-technische vergaderingen enz.

Het idee achter uw vraag is redelijk en een idee dat ik in de loop der jaren in veel interviews heb opgenomen. Ik heb nooit slecht gereageerd op de vraag en ook is deze niet slecht ontvangen toen ik hem stelde.

Maar de manier waarop uw uitdrukking uw vraag zou veroorzaken, zou er zeker voor zorgen dat ik slecht zou reageren als ik u zou interviewen voor een technische functie waar u onder meer verantwoordelijk was voor implementaties en documentatie. Je hebt zojuist gezegd dat je die taken niet belangrijk vindt of niet als onderdeel van je technische verantwoordelijkheid beschouwt.

Je hebt me zo ongeveer verteld:

1. Wat je belangrijk vinden en wat ik belangrijk vind, is niet hetzelfde.
2. Als dat is wat u verwacht, pas ik hier niet in de bedrijfscultuur.
3. Misschien doe ik het werk u van mij vragen, maar ik zal het nooit met hetzelfde respect en dezelfde toewijding behandelen als de dingen die ik leuk en opwindend vind.

Zoals ik in mijn opmerkingen zei: hoe je het vraagt is ook belangrijk. En in dit geval zou het hoe ervoor hebben gezorgd dat u überhaupt niet verder kon in het proces.

Gewoon vragen 'Hoeveel tijd wordt besteed aan niet-werkgerelateerde taken?' zou de deur voor u openen om meer gerichte en directe vragen te stellen zonder uw hand op te steken.

Ik vraag altijd "Hoe ziet de gemiddelde dag van de gemiddelde programmeur eruit?" Ik krijg regelmatig grappige reacties, zoals "Wat is een gemiddelde dag?" In die gevallen ga ik dieper in op de details.

Maar hier is de sleutel, denk ik: ik maak altijd duidelijk dat ik verwacht dat er wat tijd zal zijn om niet te programmeren, en daar heb ik geen probleem mee. Als je zegt "voor elk uur dat ik aan het programmeren ben, hoeveel minuten ...", krijg je de indruk dat je een probleem hebt met die minuten, dat je ze kwalijk neemt, dat wat je echt wilt horen "nul" is.

Probeer op grotere schaal te praten en stel andere taken op één lijn met programmeren.

"Welk percentage verwacht ik in een gemiddelde week te besteden aan programmeren, in vergaderingen met andere ontwikkelaars, in vergaderingen met klanten of productmanagers, in samenwerking met een ontwerper, administratieve taken, onderzoek, enz. "

U kunt (en zou) zeker vragen stellen over de ontwikkelingsmethodologie die wordt gebruikt en die u veel zou moeten vertellen over hoeveel overhead u mag verwachten.

In plaats van te vragen hoeveel tijd je zou moeten besteden aan babysit-implementaties, zou je willen vragen naar het buildbeheersysteem. Als de interviewer zegt dat hij een systeem heeft dat automatisch elke dag zonder onderbreking wordt gebouwd en geïmplementeerd in productie, kun je er vrij zeker van zijn dat je niet veel tijd zult besteden aan het omgaan met implementaties. Als de interviewer meer handmatige inspanningen vereist en de inspanningen van mensen in verschillende groepen coördineert, besteed je veel meer tijd aan implementaties.

In plaats van te vragen hoeveel tijd u zou besteden aan het schrijven van documentatie, zou u vragen stellen over de manier waarop de organisatie softwareontwikkeling benadert. Als ze traditionele watervalontwikkeling doen, zou je verwachten dat ontwikkelaars veel meer tijd besteden aan het schrijven van documentatie (en dat er veel meer tijd wordt besteed aan het schrijven van vereisten voor de ontwikkelaars). Als ze een meer agile aanpak hebben, zou je verwachten dat er minder tijd wordt besteed aan het genereren van documentatie (hoewel dat natuurlijk ook betekent dat de vereisten die je krijgt meestal minder gedetailleerd zijn omdat de aanpak ervan uitgaat dat dingen zullen veranderen). / p>

Op dezelfde manier kun je vragen hoe ze bugs volgen, hoe ze vereisten volgen, hoe ze testen, hoe ze prioriteit geven aan items, enz. Hoe meer handmatig het proces en hoe meer proces er is, hoe meer tijd je moet besteden verwacht te besteden aan niet-technische taken.

Door over het softwareontwikkelingsproces te praten, laat u over het algemeen zien dat u een betrokken ontwikkelaar bent en maakt u het de interviewer over het algemeen moeilijk om u (opzettelijk of per ongeluk) te misleiden. De meeste mensen hebben niet echt een nauwkeurig idee van waar ze in de loop van een dag eigenlijk tijd aan besteden - veel kleine taken slikken veel grotere delen van de dag op - dus het is moeilijk voor de meeste mensen om nauwkeurig te raden over hoeveel tijd wordt besteed aan het werken aan builds. Dit is dubbel zo wanneer de mensen die het interview afnemen managers zijn die deze taken niet zelf uitvoeren. Managers kunnen gemakkelijk geloven dat een bouwproces relatief soepel verloopt, terwijl het in werkelijkheid een hoop handmatige tussenkomst vereist, simpelweg omdat niemand de inefficiëntie onder hun aandacht brengt. Praten over het proces van het ontwikkelen van software is echter meestal veel eenvoudiger omdat het veel transparanter is. Het is onwaarschijnlijk dat een manager bijvoorbeeld niet op de hoogte is van de dagelijkse stand-upvergadering als het team dat gebruikt of dat de manager niet in het algemeen zou kunnen beschrijven hoe releases worden gepland en geïmplementeerd.

Als het niet aan te raden is om het rechtstreeks te vragen, hoe zou je die informatie dan kunnen extraheren op een manier die vooroordelen jegens mij zou opleveren en mijn kansen om aangenomen te worden verkleint.

Alle softwareontwikkelaars zullen deze taken moeten uitvoeren. Sorry, maar je zult werk moeten doen dat niet codeert /

Dat gezegd hebbende, kun je dingen vragen als:

• "Wat is je aanpak om een ​​hogere maar nieuwe architectuur te ontwikkelen? " Dit geeft inzicht in hoeveel brainstorm- / planningsbijeenkomsten u zult hebben.
• "Hoe wordt de bestaande code onderhouden?" Dit geeft aan welke documentatie wordt aangemaakt als onderdeel van het proces, en het is gemakkelijk om hierover te vragen.
• "Wat is het proces voor het implementeren van nieuwe code / revisies?" Krijgt de betrokkenheid van de ontwikkelaar bij dit proces ..
• "Hoe betrokken zijn softwareontwikkelaars bij het onderzoeken van klantbehoeften en het ontwikkelen van specificaties?" Inzicht in hoeveel tijd u zult besteden aan scope, brainstormen over functies, enz.
• "Hoe volgt u softwarefouten / functies die moeten worden ontwikkeld?" Helpt bij het geven van inzicht in het bijhouden van documentatie / problemen.
• "Wat is je minst favoriete onderdeel van je werk?" Wanneer het aan andere ontwikkelaars wordt gevraagd, kan het ongelooflijk inzichtelijk zijn, omdat dit vaak het minst favoriete onderdeel is van ontwikkelaars.

Deze vragen, in een combinatie gesteld, zullen je heel duidelijk een antwoord op je vraag geven . Merk ook op dat hoewel de meeste van deze vragen specifiek zijn voor software, het algemene idee van toepassing is op bijna alle banen - maar in plaats van software / code vervangt u gewoon het product waaraan u werkt (marketingmateriaal, widgets, enz.) In de vragen.

In wezen zou ik graag willen weten: voor elk uur dat ik mijn technische verantwoordelijkheden vervul, hoeveel minuten ze denken dat ik zou besteden aan administratieve taken, zoals babysitten, documentatie, niet-technische vergaderingen enz. .

Ik zou waarschijnlijk eerst vragen of het bedrijf al dan niet formele processen heeft die dit soort boekhouding mogelijk maken. Als de organisatie een start-up is, dan is er misschien wel een cowboymentaliteit waarbij dit soort tracking gewoon niet wordt gedaan en daardoor krijg je een potentieel lege blik.

Je realiseert je wel dat "babysitten implementaties "en" documentatie "kunnen vanuit managementperspectief als technisch worden beschouwd, maar niet van collega-ontwikkelaars, toch? Er zijn hier communicatieproblemen en je moet hier voorzichtig zijn met je vocabulaire.

U moet voorbeelden vragen om te zien hoe gedetailleerd de documentatievereisten zijn en deze te vergelijken met andere functies die u heeft gehad. Hoeveel "tijd" u eraan moet besteden, wordt bepaald door uw schrijfvaardigheid.

Het is belangrijker om hun perceptie te peilen over de hoeveelheid tijd die ontwikkelaars momenteel in dit gebied doorbrengen. Vinden ze dat het moet worden verbeterd? Staan ze open voor het vinden van tools om het proces meer geautomatiseerd te maken?

Elke programmeur schrijft liever code dan zo ongeveer iets anders. Ze snappen het. Wat ze niet willen, is iemand die er zo'n afkeer van heeft dat het misschien moeilijk is om mee te werken en onwillig om het vuile werk op te knappen. Concentreer u meer op het vinden van hun managementstijl om te zien of ze openstaan ​​voor verbeteringen op dit gebied.

Ik zou zeggen dat het gepast is om deze vraag over de rol te stellen.

Het interview is een tweerichtingsproces, een proces waarbij het bedrijf leert over jou, je vaardigheden en of ze denken dat je bij het team past. De tweede is dat u informatie verkrijgt over het werk dat u verwacht te doen en de omgeving (zowel fysiek als digitaal) waarin u wordt geacht te werken.

Veel mensen stellen voor om een ​​dergelijke vraag te stellen, wat zou duiden op de interviewer dat 'je alleen wilt doen wat je wilt' en al het andere is een extra gewicht in je dagelijkse strijd.

Ik ben het eens en oneens, je geeft deze indruk aan sommige interviewers, maar tegelijkertijd Als u op zoek bent naar een baan met een lage bureaucratische voetafdruk, dan heeft u het recht om hier rekening mee te houden in uw besluitvormingsproces.

Aan het eind van de dag zijn er veel ongepaste vragen om te stellen. Ik denk niet dat dit er een van is, aangezien je geluk een grote factor is in je productiviteit bij een baan. Wees voorzichtig dat HOE je dit vraagt ​​van echt belang is.

Als je het als een gedoe, een dagelijkse strijd of een extra gewicht ziet, dan wordt je waarschijnlijk in een negatief daglicht gesteld.

Het draait allemaal om positiviteit, je wilt de indruk wekken dat je ZULT je best doen, dat je met het bedrijf ZULT werken en niet ertegen!

Zoals anderen al zeiden, zou ik de woorden "organisatorische bureaucratische voetafdruk" overslaan. Het klinkt hip en slim, maar het kan gemakkelijk overkomen als hatelijk. De managers die u interviewen, zouden heel goed degenen kunnen zijn die verantwoordelijk zijn voor de "organisatorische bureaucratische voetafdruk" en zij deden wat dan ook (mogelijk vreselijke) bureaucratie om een ​​reden die ze waardevol vonden om ieders tijd te rechtvaardigen. Ze zijn misschien zelfs trots op dit werk en zien het als een echte meerwaarde voor het bedrijf, dus als je het allemaal samenvat als bureaucratie (die op zich al een negatieve bijklank heeft), zal je waarschijnlijk geen voorstanders winnen. Collega individuele bijdragers vinden het misschien een leuke en slimme uitdrukking - we hebben zeker allemaal moeten stilstaan ​​in een stapel administratieve rompslomp die groot genoeg was om een ​​voetafdruk te zijn gemaakt door de afschuwelijke sneeuwman, maar als je de sneeuwpop bent, zul je misschien niet vinden het is grappig.

Het klinkt alsof uw grootste zorgen zijn in de tijd die wordt besteed aan dingen die ik op het niveau van individuele bijdragers 'risicobeperking' zou noemen. Bijeenkomsten, documentatie en verificatie van de implementatie zijn allemaal bedoeld om de fouten te verminderen die optreden tussen andere leden van het project wanneer mensen niet duidelijk communiceren over een belangrijk deel van het werk.

Ik vind best veel van de antwoorden van andere posters hier, en ik vind het vreselijk om deze vele goede voorbeelden te herhalen, dus ik zal er alleen op wijzen dat er een paar basisstrategieën zijn:

• Dag in het leven-vragen - ga in detail in op de taken die u verwacht te doen en wat de verdeling van het werk is op een bepaalde dag, week, fase kan zijn. Praat over processen, praat over specifieke aandachtsgebieden van het project, praat over teamdynamiek, praat over tools en processen die ze gebruiken om hoofdwerk, herhaalbaar werk sneller te maken.

• Waar geven we het meest om Vragen - verschillende branches hebben verschillende drijfveren. Overheid, defensie en gezondheidszorg hebben vaak een zeer sterke drijfveer voor kwaliteit - u zult veel tijd besteden aan het documenteren van code zodat iemand anders deze kan onderhouden zonder de boel te verknoeien, veel tijd om te testen en te controleren of alles werkt, veel tijd om ervoor te zorgen dat dat specificaties duidelijk zijn en implementaties naar behoren worden uitgevoerd. In een levenskritisch systeem is niet verknoeien belangrijker dan een extra functie laten uitvoeren. In e-commerce, sociale media en andere producten in een zeer concurrerende feature-ruimte, is het snel iets op de markt krijgen. Er is kwaliteitsborging, maar als het erop aankomt, zullen ze het op de markt brengen, zelfs als er iets kleins (zoals documentatie) niet wordt gedaan. Vraag dus wat de prioriteiten van het bedrijf zijn en hoe ze aansluiten bij de manier waarop u als ontwikkelaar aan het werk zou gaan.

• Bedrijfscultuurvragen - is het een dictatuur? Een consensuscultuur? een kleine groep Illuminati die het bedrijf runnen? Hoe worden beslissingen genomen, hoe worden problemen opgelost, waarom en wanneer heb je formele vergaderingen? Hoe de organisatie plannen maakt om vooruit te komen en obstakels te overwinnen, zal een grote invloed hebben op het aantal bijeenkomsten en de productiviteit van die bijeenkomsten.

Ik zou eigenlijk bij elk interview een combinatie van alle drie vragen, en dan zou ik kiezen en kiezen op basis van de interviewer - zowel zijn persoonlijke stijl als zijn plaats in de organisatie zouden factoren zijn. Managers zijn waarschijnlijk in staat om de "waar geven we om" -vragen het duidelijkst en beknopt te beantwoorden. Individuele bijdragers zijn wellicht het meest nauwkeurig bij de "dag in het leven" -vragen. Vaak vind ik dat de HR-vertegenwoordiger beter is dan je zou denken bij de "bedrijfscultuur" -vragen, omdat ze het team van buitenaf naar binnen zien kijken. Maar dat betekent niet dat je het doelwit van je vragen strikt moet beperken. Het kan bijvoorbeeld ZEER veel vertellen als de individuele bijdrager en de manager het niet erg eens zijn over een van deze vragen - met name het 'waar we om geven' - als het team aan de ene kant werkt en het management ziet een andere die je zoekt. bij een team dat misschien op weg is naar een noodlanding om andere redenen dan Death by Paperwork.

In de loop van de tijd heb ik door met anderen in mijn branche te praten, een idee ontwikkeld over waar mijn favoriete banen in de rijk van "organisatorische bureaucratische voetafdrukken" - ik hou toevallig van hoge risico's, hoge complexiteit, hoge kosten, hoge bureaucratische overheaduitdagingen ... maar ik realiseer me ook hoeveel sneller mijn collega's in andere industrieën bewegen ... na verloop van tijd, mijn Het algemene gevoel was dat concurrenten in een branche in de meeste gevallen op dezelfde manier zullen opereren - dus als ik weet hoe de ene werkt, kan ik bepaalde generalisaties maken over de volgende en vrij snel op de details ingaan.