Vad man bör kunna för koncept som junior utvecklare?

Har några intervjuer jag ska gå på om några veckor och jag misstänker att det nuförtiden är efterfrågat av arbetsgivarna att man har koll på de nya hippa sakerna såsom IoT, cloud services, AI, big data och sånt. Fast det är ju egentligen bara koncept i sig, vad ska man exakt veta om dessa saker? Jag har provat att googla på dem, fast det enda jag hittar är tidningsartiklar som beskriver något otydligt kring vad det är på ytan. Det är inget som gör en klokare på något sätt.

Så min fråga är, jag som nyutexaminerad student som vill landa ett jobb som utvecklare. Vad bör jag ha koll på som allmänbildning kring dessa saker? Nu nämnde jag bara några koncept av många, jag känner inte till alla som är trender idag, så det vore snällt om någon kunde berätta om vad för andra koncept man bör ha koll på? Och vad bör man ungefär ha koll på inom varje enskilda koncept?

Blir glad om ni kan hjälpa mig att lista ut det. Själva lärandet och efterforskandet gör jag ju själv, förväntar mig inte att någon ska lära mig det. Bara peka ut vad för koncept som är värda att ha koll på så man ökar sina chanser till jobb. Det finns oväntat lite "vettig" information om det ute, för att vara så populära koncept idag.

Det är väl bra att veta vad det är för något. Det kommer knappast dyka upp på intervjuer om du inte sökt jobb inom just dessa områden. Brukar väl framgå rätt väl vad för tekniska kompetenser som efterfrågas bara av att läsa jobbannonsen och skumma företagets webbplats. Dessutom är det väldigt enkelt att svara på dessa frågor.

Läs hellre på lite om arbetssätt. Kommer nästan ofelbart upp när du får prata med någon utvecklingsansvarig.
"Här på X arbetar vi agilt. Har du någon erfarenhet av detta?"

... sen kommer det obligatoriska med "många bollar i luften" osv. Gör en liten lista och para ihop med egenskaper du ärligt kan säga dig ha. Så har du något i bakfickan.

Vad du bör kunna eller känna till beror på vad du söker för jobb.

Jag jobbar som Java-utvecklare. När vi testar juniora utvecklare så försöker vi se var lägstanivån ligger för det programmeringsspråk vi söker utvecklare till. Vi ger dem några små relativt enkla kodsnuttar och de får beskriva vad koden gör och om de ser förbättringsmöjligheter eller potentiella problem med koden. När vi gör det testet handlar det inte om att sätta dit någon utan att känna av kodförståelse och om man kan det mest grundläggande. Det är förvånansvärt många som säger att de kan ett språk, men att motsatsen visas när vi gör det testet. For-loopar, strängkonkatenering, if-satser etc.

Vi ser gärna att man använt Maven, TDD, Jenkins, Git eller Mercurial, Eclipse/IntelliJ etc., dvs. faktiska verktyg som vi använder i arbetet. Om man sen har erfarenhet från just det vi jobbar med så är det ju mycket positivt, ex. just nu är det Spring Boot. Kommer då en junior med verktygskunskap, kodförståelse och några applikationer skriva med Spring Boot så blir vi väldigt intresserade.
Tänk motsatsen. Den sökande har svårt att förstå enkel Javakod, har aldrig använt Maven eller Git och inte ens hört talas om Spring. Då blir man matt. Startsträckan känns enorm.

Så man får läsa jobbannonserna. Testa att använda de tekniker som beskrivs. Gör i alla fall en Hello World i vad det nu kan vara för teknik. Sätt upp en Jenkins och automatisera lite byggen som byggs med Maven och startas varje gång du pushar till GitHub/BitBucket. Teknikerna är bara exempel från min värld. Dit du söker kan allt vara helt annorlunda.

Det viktigaste av allt är att du är en bra utvecklare för dom är det ont om. Att du lyckats lära dig några verktyg eller tekniker betyder inte att du är en duktig utvecklare. Tyvärr vimlar branschen av en massa odugliga utvecklare för att inkompetenta chefer bara är intresserade och fokuserar på att de behärskar vissa verktyg, framework eller specifikt språk för att få anställning. Är du en driven utvecklare så lär du dig fort en ny teknik eller utvecklingsverktyg.
Däremot är det en helt annan femma att vara en bra utvecklare som kan skriva bra underhållsvänlig. återanvändbar och läsbar kod där det finns en röd tråd genom programmen.
Jag har som konsult vid flertal tillfälle kallats in för att styra upp projekt som har varit "färdiga" till 99%. Detta betyder kort sagt att utvecklarna kört in i väggen och reder inte ut sin egen kod längre. Dessa projekt hamnar till största delen i papperskorgen då det blir billigare att skriva om dem helt. Det intressanta är inte om man får ihop den sista procenten utan det är så skabbig kod att underhållet kommer att vara förödande kostsamt. Har sett läpparna darra på chefer när man berättar att det blir billigare att slänga skräpet för 10-tals miljoner i papperskorgen och skriva om det än att betala mångdubbelt senare för underhållet.
Om du ska anlita en snickare för att bygga ett hus så vill du väl ha en bra snickare som vet hur man bygger ett hus eller hur? Du fokuserar väl inte på om han kan slå i en spik med en viss hammare eller har erfarenhet av en viss skruvmejsel?
Hur som helst, lycka till med ditt jobb.

Övriga utvecklingsfrågor --> Personlig utveckling, studier och arbetsliv
/Moderator