Esistono attualmente test attitudinali moderni, standardizzati per l'ingegneria del software? [chiuso]

sfondo

Sono un ingegnere del software di lavoro che sta cercando un nuovo contratto per il prossimo anno. Nella mia ricerca, sto sopportando diverse assurde interviste tecniche come indicato da questa popolare domanda che ho posto oggi .

Anche se le domande che mi venivano poste non fossero quasi sempre assurde, sarei comunque stanco di rispondere più volte per varie opportunità contrattuali.

Quindi questo mi ha fatto pensare che avere un esame standardizzato che i professionisti del software di lavoro potessero sostenere avrebbe fornito una scorecard comune che potrebbe essere referenziata dagli intervistatori al posto di assurde domande di intervista tecnica (ovvero nerd hazing).

Domanda

Esiste un test attitudinale di ingegneria del software standardizzato (SEAT ??) disponibile per i professionisti che lavorano?

Se non esiste un esame del genere, quali domande o argomenti dovrebbero essere coperti?

Un pensiero in più

Per favore, tieni presente, se suggerisci una domanda o un argomento, di concentrarti su domande o argomenti che sarebbero rilevanti per le pratiche di sviluppo contemporanee e bisogni realistici nella forza lavoro in quanto questo sarebbe il punto di un test attitudinale standard. In altre parole, niente domande sull'attraversamento del clown .

Dai un'occhiata a Codility .

È un test di programmazione online che supporta un numero di lingue diverse. Le domande sono ben definite e non eccessivamente complesse sebbene richiedano un po 'di pensiero, oltre a buone tecniche di programmazione (difensiva) - non solo devi scrivere una soluzione di lavoro corretta ma testeranno cose come le condizioni dei bordi e l'overflow dei numeri interi .

Non ho idea di quanto bene sia l'autocertificazione, ma due recenti domande di lavoro hanno utilizzato quel sito come parte del processo di selezione.

I test attitudinali hanno lo scopo di misurare la struttura innata di qualcuno per un determinato argomento, non quanto già sai di un argomento. Non penso sia quello che stai cercando. Invece, sembra che tu voglia un modo standard per dimostrare ciò che sai in modo da non dover sopportare le domande tecniche durante un'intervista (o almeno puoi evitare quelle sciocche).

Buone notizie: ci sono molti modi in cui puoi dimostrare ciò che sai. Gli strumenti a tua disposizione includono:

• curriculum: un curriculum ben scritto può fare molto per rispondere alle domande su ciò che hai fatto in passato e, per estensione, ciò che ora conosci. Non elencare solo dove hai lavorato, di 'quello che hai fatto.

• progetti: porta qualcosa che hai creato con te e offri una demo rapida. Mostra il tuo codice e sii disposto a spiegarlo. Ciò ti consente di mostrare le tue capacità tecniche sul tuo stesso terreno. (Se è qualcosa a cui anche altri hanno contribuito, sii molto chiaro su ciò che hai fatto rispetto a ciò che altre persone hanno fatto. Se puoi, è meglio mostrare qualcosa che è interamente tuo.)

• scrittura: se hai scritto articoli, un blog o un libro o un articolo di rivista, prova a presentarlo prima dell'intervista in modo che gli intervistatori abbiano la possibilità di leggerlo.

• laurea o certificazione: si tratta di un esame quasi simile a quello che probabilmente otterrai.

In breve, il tuo obiettivo è quello di fornire quante più prove possibili che tu abbia la conoscenza che l'intervistatore sta cercando.

Cattive notizie: non importa quale sia, probabilmente dovrai sempre affrontare una o due domande tecniche inventate quando intervisti per un lavoro. Anche se davvero li stupisci con la tua esperienza e puoi dimostrare che sei esattamente il ragazzo che stanno cercando, faranno comunque alcune domande sulle strutture di dati o altro. Non esiste un aspetto negativo per l'azienda: la persona che sta cercando dovrebbe essere in grado di rispondere a queste domande durante il sonno, e apparentemente ci sono molte persone che non possono . Inoltre, alcune organizzazioni hanno rigide procedure di assunzione che richiedono loro di porre le stesse domande a ciascun candidato; gli intervistatori non sono liberi di decidere che conosci le tue cose e possono semplicemente saltare le domande tecniche.

Probabilmente, questo è il ruolo delle certificazioni e dei gradi. Se si desidera un test standardizzato della familiarità di qualcuno con un particolare linguaggio di programmazione, è possibile cercare persone con una determinata certificazione linguistica. Se vuoi un test standardizzato di conoscenza generale dell'informatica, cerca qualcuno che abbia una laurea in informatica.

Il problema, ovviamente, è che sappiamo tutti che questo tipo di credenziali è tutt'altro che perfetto. È troppo facile per le persone richiedere un esame di certificazione una volta finalizzati gli argomenti dell'esame senza effettivamente apprendere nulla o essere in grado di applicare le conoscenze. Una parte piuttosto consistente di solidi sviluppatori non si preoccuperà di passare attraverso il processo di certificazione. E cercare di essere certificato su tutto ciò che un datore di lavoro sta cercando (lingue, processi e metodologie di sviluppo, ecc.) Sarebbe piuttosto oneroso. Anche i titoli di informatica sono fallibili: ci sono persone che completano la laurea senza mai riuscire a imparare a scrivere codice utile e ci sono persone che imparano a scrivere un codice eccezionale mentre si specializzano in qualcos'altro.

Dato che gli approcci standardizzati si sono dimostrati insufficienti nel mondo reale, è eccezionalmente improbabile che un esame standardizzato vada meglio. Quasi sicuramente finirà per essere giocato proprio come gli esami di certificazione esistenti. Le persone si affollano per l'esame o accedono alle domande da "discariche cerebrali". Gli sviluppatori esistenti non finiranno tutti per sostenere l'esame. E i datori di lavoro non sarebbero disposti a fare molto affidamento sui risultati dell'esame. Quindi vorranno ancora porre domande tecniche in un'intervista.

Oltre a ciò, tuttavia, una buona intervista tecnica (ovviamente, ci sono cattivi intervistatori e cattive domande proprio come ci sono cattivi sviluppatori) dovrebbe anche riguardare la valutazione di come l'approccio di un candidato si intreccia con il team attuale. Una buona intervista dovrebbe valutare le capacità comunicative di un candidato e le sue abilità trasversali tanto quanto valuta le loro capacità tecniche. Sono molto più interessato a un candidato che pone buone domande per chiarire i requisiti e che spiega bene il loro processo di pensiero anche se non escono immediatamente con l'algoritmo migliore su qualcuno che si presenta con un ottimo algoritmo ma non può spiegare la loro risposta in modo efficace o discutere in modo efficace i compromessi.

Il test attitudinale programmatore / analista senza lingua fornisce una misura obiettiva del potenziale di un candidato di lavoro per comprendere e applicare ragionamento, logica, matematica informatica e regole procedurali. LPAT non verifica il candidato in un linguaggio informatico specifico. Vedi http://www.aprtestingservices.com/business/lpat/