[OT] Aiuto per amico che va a colloquio di lavoro

[BaBBuino]

Ho un amico tecnico che deve andare ad un colloquio di lavoro dove sono richieste competenze Linux e programmazione su QT per Sistemi Embedded.

Lui è un programmatore generico, conosce QT ed è discreto conoscitore di Linux, però non ha grandi competenze su Sistemi Embedded.

Cosa si può studiare nell’arco di una settimana, che manca al colloquio, per avere un pò più di risorse su cui fare conto?

Io gli ho suggerito di studiarsi qualcosa su Embedded Linux e poi qualcosa di generico sui SoC che si accoppiano quasi nativamente con Linux e qualche sistema industriale su base x86.

Avete qualche suggerimento? Vi prego di evitare battute ironiche. Ha una settimana e piuttosto che niente, è meglio piuttosto. Poi non è che sia proprio digiuno del settore.

Astro, Leo, MauroTec, lock, voi che siete i CRANI del settore, avete qualche scaletta veloce da suggerire per prepararsi al colloquio?

[leo72]

Sicuramente deve approfondire la conoscenza base del sistema Linux, ossia capire come Linux vede e gestisce le periferiche, il kernel ed i moduli, la programmazione in C/C++. Nei sistemi embedded molto è fatto via terminale per cui questa è la prima conoscenza da avere.
Se poi chiedono le Qt, potrebbe dare un'occhiata a QtCreator, che è un'IDE per lo sviluppo di applicativi Qt/C++.

Sistemi embedded è un pò generico, sa che tipo di SoC usano nella ditta? Almeno potrebbe cercare un pò di documentazione

[BaBBuino]

Na... purtroppo le informazioni che ha sono solo sul C, C++ (e qui va bene) Linux e QT. Il tutto relativo a Sistemi industriali Embedded.

Cmq faccio tesoro di tutto quello che mi dite. Riga di comando eh?

Ma per gli I/O, I2C, SPI quella roba lì insomma come si programma? Lui non è mai sceso così "in basso".

Naturalmente non si tratta di Raspberry, CubieBoard o robe simili, ma presumo (?) io, che si tratti di quelle schede mini ATX con sopra ATOM, Pentiun III, Pentim M (+ qualche Cirrus Logic sfigato), o al massimo qualche reincarnazione ARM.

[leo72]

BaBBuino:
Cmq faccio tesoro di tutto quello che mi dite. Riga di comando eh?

La "riga di comando" è molto DOSsosa.. Su Linux si chiama "terminale" o "console"

Ma per gli I/O, I2C, SPI quella roba lì insomma come si programma? Lui non è mai sceso così "in basso".

Naturalmente non si tratta di Raspberry, CubieBoard o robe simili, ma presumo (?) io, che si tratti di quelle schede mini ATX con sopra ATOM, Pentiun III, Pentim M (+ qualche Cirrus Logic sfigato), o al massimo qualche reincarnazione ARM.

Siccome tutte le periferiche su Linux sono dei file, generalmente l'accesso avviene tramite moduli che vengono precaricati nel kernel (il driver fisico per la periferica) e le uscite varie impostate tramite lettura/scrittura di dati in determinati file.

[Maurotec]

Sistemi embedded e programmazione C++/Qt e altri linguaggi di alto livello sono due competenze separate.

Scrivere applicazioni con C++/Qt non è un gioco da ragazzi, se si hanno competenze approfondite in questo settore non si possono avere competenze lato embedded basso livello. In sostanza quelli che hanno competenze approfondite da entrambe i lati rappresentano l'eccezione, quindi io consiglio di non studiare nulla di nuovo.

Se anche si presentasse uno con entrambe le competenze non sarebbe in grado di produrre con tempi sufficientemente brevi e comunque lo stipendio sarebbe sempre lo stesso, e ricordati che si tratta di eccezioni.

Il kernel linux è molto complesso, mica è semplice fare un modulo, cioè è semplice farlo non funzionante, poi per farlo funzionare serve la conoscenza intima del kernel.

Visto che il colloqui si svolge in Italia (penso) è probabile non abbiano le idee chiare neanche loro sulle competenze, se è così, gli chiederanno entrambe le competenze e lui gli dovrà dire: Guardi che si tratta di due figure professionali separate, il programmatore low level e l'high level, ovviamente io sono un programmatore high level.

Ciao.

[BaBBuino]

MauroTec:
Sistemi embedded e programmazione C++/Qt e altri linguaggi di alto livello sono due competenze separate.

Scrivere applicazioni con C++/Qt non è un gioco da ragazzi, se si hanno competenze approfondite in questo settore non si possono avere competenze lato embedded basso livello. In sostanza quelli che hanno competenze approfondite da entrambe i lati rappresentano l'eccezione, quindi io consiglio di non studiare nulla di nuovo.

Se anche si presentasse uno con entrambe le competenze non sarebbe in grado di produrre con tempi sufficientemente brevi e comunque lo stipendio sarebbe sempre lo stesso, e ricordati che si tratta di eccezioni.

Il kernel linux è molto complesso, mica è semplice fare un modulo, cioè è semplice farlo non funzionante, poi per farlo funzionare serve la conoscenza intima del kernel.

Visto che il colloqui si svolge in Italia (penso) è probabile non abbiano le idee chiare neanche loro sulle competenze, se è così, gli chiederanno entrambe le competenze e lui gli dovrà dire: Guardi che si tratta di due figure professionali separate, il programmatore low level e l'high level, ovviamente io sono un programmatore high level.

Ciao.

OK Mauro, grazie.

Non l'ho scritto per non fare la figura dello sborone, ma quando chiedono troppe competenze, così eterogenee, ho sempre pensato anch'io che il richiedente non abbia per primo le idee chiare, e spesso si tratta di un lavoro fuffa.

Inoltre ho usato le tue stesse parole descrittive al mio amico: programmatori di Sistemi Embedded canonici programmano MCU a basso livello. Il massimo di astrazione all'hardware che impiegano è l'usare qualche libreria grafica proprietaria per costruire una HID (Human Interfacce Device) ovvero un'interfaccia uomo-macchina, detto più semplicemente: un monitor, un display dove l', operatore interagisce con la macchina.
Dall'altro lato ci sono i programmatori "sistemisti" ovvero molto più legati al sistema operativo ad alto livello sul quale poi creano applicativi, di alto livello appunto.

Ho due amici, che sono un riferimento in entrambi i mondi, ma uno lavora in Westinghouse in un laboratorio dove lavorava il Dott. Zener (si, quello del diodo!) e l'altro in AnalogDevices, ovviamente in USA e con stipendi annuali a 6 cifre. Ovvero sono figure rarissime.
Tutti gli altri programmatori che conosco, sono figure da 1170 euro al mese a 10 ore al giorno...

Vabbè... tornando in tema qualcosa gli vorrei far studiare in questa settimana. Che gli dico, di guardarsi qualcosa su Embedded Linux o altre versioni ridotte per Microcontrollori? Leggicchiare qualcosa su Arm?

[leo72]

Con i SoC di oggi, con potenze dell'ordine dei centinaia di MHz e memorie dell'ordine del GB, un sistema Linux embedded con una interfaccia grafica non è mica più una rarità, anzi è la norma. Dire che un programmatore embedded lavora su MCU è ormai non più del tutto corretto.
Anche la Rasp, per schedina di base che è, ha un SoC capace di far girare un ambiente Linux con GUI.

[BaBBuino]

Ecco appunto. C'è sempre da capire cosa ha bisogno l'azienda; se un programmatore Linux o un programmatore di MCU, visto che difficilmente si trovano in un singolo individuo entrambe le skills.
Mi riesce difficile vedere un generico programmatore Linux che riesce a gestire nel minimo dettaglio un Frame su CAN bus.

Posso ipotizzare che voglia un eccezionale Programmatore hardware, che faccia cantare periferiche come CAN, SPI ed Ethernet a basso livello e che sia anche un eccezionale programmatore di almeno 6 linguaggi, come Visual Basic, .NET, C#, C++, Phyton e Borland Delphi, e magari anche Assembly x86-ARM, su Linux , Windows e Android, che sia anche Amministratore di Rete, di Sistema, che conosca UNIX, AS400 e almeno almeno anche un pò di Solaris, ma sopratutto che non voglia più di 1000 euro...

[zoomx]

leo72:
La "riga di comando" è molto DOSsosa.. Su Linux si chiama "terminale" o "console"

Si chiama shell e ce ne sono diverse anche se attualmente la più comune è la bash.
Tu accedi alla shell tramite terminale o console che potrebbe essere anche via seriale o via telnet.
Sugli embedded ci sono shell limitate basate solitamente su busybox.

[BaBBuino]

Daje! Non fate i cani morti. Dategli qualcosa da studiare per il fine settimana a sto poraccio, almeno studia e non sta in ansia a pensarci su! Diciamo che studiare può avere effetto rilassante. Non pensate solo al poco-quasi-niente che caverà dal buco.

Non è il solo candidato: sono in due o tre per quel posto e credo tutti nella stessa situazione di preparazione (tutti Softweristi Linuxisti). Magari basta che dice due parole in più bene dette, rispetto a quegli altri, e ha già un piccolo vantaggio.

[Maurotec]

BaBBuino:
Daje! Non fate i cani morti. Dategli qualcosa da studiare per il fine settimana a sto poraccio, almeno studia e non sta in ansia a pensarci su! Diciamo che studiare può avere effetto rilassante. Non pensate solo al poco-quasi-niente che caverà dal buco.

Non è il solo candidato: sono in due o tre per quel posto e credo tutti nella stessa situazione di preparazione (tutti Softweristi Linuxisti). Magari basta che dice due parole in più bene dette, rispetto a quegli altri, e ha già un piccolo vantaggio.

Mahhh, i BaBBuini in natura sono testardi? No perché non vorrei fosse il tuo nik ad influenzarti, cambialo e vediamo.
Se ha lacune lato *nix system, digli di colmarle, cioè cose del tipo come trovare una occorrenza in un file di cui non si conosce il nome all'interno di un tree usando find, poi il sistema di configure e build e il gestore di pacchetti, anche qui si tratta di altre competenze, ma almeno sapere come si crea un pacchetto rpm, es rpmbuild -ba --target=i686 /SPECS/avr-gcc.spec oppure per debian (ad esempio io non me lo ricordo).

In una settimana non può studiare quello che si studia in anni, e controproducente e si rischia di dire cazzate, e allora meglio dire non so, devo documentarmi.

Ciao.

[Bertu65]

Per esperienza posso suggerire che durante un colloqui, anche se non si conoscono bene le cose, sapere di cosa si tratta é molto importante perché mette l'intervistatore nella in condizione di pensare di avere davanti una persona a cui non si dovrá dire tutto ma che saprá indirizzarsi da sola dove serve.

Meglio quindi un'infarinatura su molte cose, specificando che non si ha avuto occasione di approfondirle, piuttosto che fare scena muta.

oviamente IMOHO

[astrobeed]

Bertu65:
Meglio quindi un'infarinatura su molte cose, specificando che non si ha avuto occasione di approfondirle, piuttosto che fare scena muta.
oviamente IMOHO

Dipende dalla persona che ti "interroga" durante il colloquio, se capiti con un "bastardo di lungo corso" come il sottoscritto, in passato mi è capitato diverse volte di fare selezione personale per un progetto, stai pur certo che con una infarinatura ottieni solo un bel "grazie ci faremo sentire noi", ovvero il modo politicamente corretto per dire "sei una pippa non mi servi"

[leo72]

zoomx:
Si chiama shell

In inglese, in italiano si chiama terminale

[leo72]

lock:

leo72:
Siccome tutte le periferiche su Linux sono dei file

Non tutte!

La scheda di rete non e' un char-dev, e nemmeno un block-device, e va gestita a socket, concetto simile ma non uguale al file. Le schede video hanno un altro modello ancora che non ci azzecca nulla ne con i file ne con i socket, e le can bus un altro, ecc.

Hai ragione, lock. Ma tralasciamo scheda video e rete, che sono casi particolari.
Normalmente una porta o una periferica a blocchi come un HD ha un suo file. Tu hai /dev/sda per il tuo bell'HD sul 1° slot ecc..

[leo72]

@Babbuino:
concordo con Mauro, in una settimana non si impara ciò che non si conosce. Se ha già esperienza di Linux e programmazione Qt in teoria ha già buona parte dei requisiti soddisfatti. Se la programmazione riguarderà un sistema embedded, quello è un mondo particolare che dipende molto dallo specifico SoC su cui lavora la ditta, mica può studiarsi tutte le piattaforme che esistono per sapere le differenze. Se un domani sarà assunto, approfondirà quelle relative allo specifico SoC su cui lavorerà. Per ora può solo leggersi un paio di libri, una guida di Linux per ripassare un pò il sistema e le sue basi, e se trova un testo sui sistemi embedded, leggersi anche quello per farsi un’idea di cosa siano. Punto.

[BaBBuino]

Bertu65:
Per esperienza posso suggerire che durante un colloqui, anche se non si conoscono bene le cose, sapere di cosa si tratta é molto importante perché mette l'intervistatore nella in condizione di pensare di avere davanti una persona a cui non si dovrá dire tutto ma che saprá indirizzarsi da sola dove serve.

Meglio quindi un'infarinatura su molte cose, specificando che non si ha avuto occasione di approfondirle, piuttosto che fare scena muta.

oviamente IMOHO

Grazie Bertus, è proprio il principio del "piuttosto che niente è meglio piuttosto".

Penso anch'io che l'infarinatura possa far dire quel qualcosa in più che può avere buone impressioni sull'interrogante.

Rimango ancora in attesa di altri suggerimenti. Stasera incontro l'amico e vediamo il da farsi.