(Michel Quoist – dal testo “Parlami d’amore”)
“Ascoltatemi ancora,
si dice infatti che dalla bocca dei bambini viene la verità:
se sono un bambino, sfuggito dal carnaio notturno,
trattenuto da un filo d’amore lanciato da chissà dove.
Se sono un bambino caduto dal nido, abbandonato da padre e madre,
rapiti o mortalmente feriti alle sbarre della loro gabbia.
Se sono un bambino nudo, senza panni d’amore, o con panni imprestati,
ma col diritto di vivere, perché sono vivo.
E se nello stesso istante persone innamorate piangono davanti a una
culla vuota,
consumandosi nel desiderio di accarezzare un bambino.
Se sono ricchi d’amore che ritengono sprecato, e vogliono
gratuitamente donarlo,
perché cresca e fiorisca ciò che non hanno piantato.
Allora voglio che vengano silenziosamente a chiedermi
se io desidero adottarli come miei genitori del cuore.
Ma non voglio dei fanatici del bambino, come collezionisti d’arte
che cercano febbrilmente il pezzo raro che manca alla loro vetrina.
Non voglio clienti che hanno fatto l’ordinazione e, pagata la fattura,
reclamano il loro bebè prefabbricato.
Perché non sono fatto per salvare genitori dalle membra amputate,
ma loro sono stati fatti, misterioso percorso, magnifico progetto,
per salvare dei bambini dal cuore malato, forse anche condannato.
E sarà come addormentarci l’un l’altro.
Io berrò il latte di cui ignoravo il sapore,
ascolterò musiche sconosciute, imparerò nuove canzoni
sulle vostre dita, sulle vostre labbra genitori adottati,
decifrerò lentamente l’alfabeto della tenerezza.
E l’amore sconosciuto per me prenderà volto
alla luce dei vostri occhi.
Voi innesterete le vostre vite sulla mia crescita selvatica
e grazie a voi io rinascerò una seconda volta.
Così sarò ricco di quattro genitori,
due lo saranno della mia carne e due del mio cuore e della mia carne
cresciuta.
Voi non giudicherete i miei genitori sconosciuti,
li ringrazierete e mi aiuterete a rispettarli.
Perché dovrò riuscire lo so, ad amarli nell’ombra,
se un giorno vorrò poterli amare nella luce.
E se in una sera di tempesta, adolescente focoso, impacciato di me
stesso, io vi rimprovererò di avermi accolto,
non vi addolorate, ma amatemi ancor di più:
lo sapete, perché un innesto prenda ci vuole una ferita e, chiusa la
ferita, rimane la cicatrice.
Ma io sogno.
Io sogno perché non sono che un bambino in viaggio,
lontano dalla terra ferma,
la mia parola è muta e il mio canto senza musica.
Ciò che vi dico piano non potrò dirlo ad alta voce, se non il giorno
in cui, avendomi voi adottato,
mi avrete messo in cuore tanto amore e autentica libertà,
sulle mie labbra parole sufficienti,
perché possa dire: papà, mamma, io vi scelgo e vi adotto
allora saprete che il vostro amore è dono, e che è riuscito”
Strcpy blues
Where do you set the notch for a C programmer declaring “good C/C++” in his/her resume? It’s “developpa” hiring time again at the company I work for, so I am conducting some technical interviews with junior programmers to find the best candidate.
Before this point we had many internal discussion about having the candidate to perform some coding during the interview or not, to the point I got a reputation of being the Bad One – a sort of a Torquemada of the C Language.
In fact I fairly agree with many others that if you are looking for a programmer (i.e. someone who writes code for a living) you should see how he/she actually writes code. Some colleagues felt embarrassed in asking this to an experienced programmer or were afraid of intimidating excessively the candidate.
Then we had a couple of hires whose skill claims weren’t exactly matched by their real skills, therefore we eventually agreed on proposing the candidate to write a few lines of code then using those as a base for more profound questions.
With the best intentions of making the candidate at ease we asked to write the implementation of a short standard library function, say memcpy, strcpy or strcmp. In order to have a common base for evaluation I focused my demand on strcpy.
Such functions should be famous enough not to scare anyone and easy enough to implement so that further discussion (improvement, optimization, pitfalls…) could be tackled to know better the candidate’s attitudes.
Well, I was wrong.
The first problem my candidates encountered was well before the implementation, in fact they had trouble in the definition of a string in C. Most of them opted for a function signature employing an undefined type “String”, someone opted for a pair of square brackets at the right end of the name.
That sheds an unsettling light on the candidate’s knowledge both of the standard library and the C string concept.
Anyway I didn’t say anything and left candidates going on. For all of them it was clear that a loop was needed, but most of them panicked on the string length. As I expected from the string type, no one of them was sure about what a C string is. One said that he expected a string length somewhere. So I pointed them in the right direction stating that a C string is more a convention that a language type, consisting in a sequence of characters terminated by 0.
Most of the candidates were able to use the array notation with an assignment. Notably one candidate failed to write the assignment operator pretending that it was the double equal (he said this twice, he was pretty emotional, but I am afraid he’s really convinced).
No one of them attempted the pointer way with post-increment. I am not a fan of the pointer notation, sometimes it is clearer, sometimes is not. For simple cases like this the optimizer is able to convert the source into the most optimized version. But I expected that a candidate could go the pointer way in order to impress the interviewer. Anyway it wasn’t the case. Worse a candidate had a doubt whether he should dereference or not the pointer with the array notation.
Well, we were looking for a junior C programmer, but I didn’t expect such low score in the C knowledge. Maybe in their experience they hadn’t chance of using the string part of the C standard library, but I would say that pointers were quite stranger to most of them.
Given the technical interview I underwent in my career and the technical interview I read about in Internet forums, I would say that in other countries programmers (even junior) are better prepared, while in Italy it seldom occurs in interviews to require the candidate to write lines of code.
I quite agree that the knowledge of the specific language is not everything for evaluating a candidate, but I think it says a lot about his/her interests, will to learn and to work as a programmer. For these reasons I tried to be flexible, ignoring details of C syntax rather focusing on the problem solving abilities. But the lack of a starting point (the code implementation) seriously hampered my options.
Also I recall that when I left the school anyone in my university friends circle could craft a strcpy in a matter of minutes (I would add blindfolded, but that would be an exaggeration). So have the times changed? Or it is my memories going wild? Should I lower the notch or changing entirely the kind of interview questions?
From the management point of view (as they told me) a junior programmer is expected not to be fluent in a programming language and I expect that a junior has no experience of medium/large code base and software engineering can be just abstract rubbish (at best) to him/her. So I have been instructed to look for learning skill and passion. I found a hard time in formulating questions for evaluating the learning skill of a candidate (well I had some ideas about mazes, food and electrical shocks, but they told me that can’t be done with humans… even if they are junior programmers).