Back in the past, an interview process was a simple one for a techie.
They tested your basic knowledge of the given language/discipline and then, if you were a fit, they looked at your suitability.
And this would usually work out fine.
What does the interviewer do nowadays ... especially when you see the long list of requirements they append to the job sepcification?
I find that the written test that usually some interviewers who haven't got an expert on tap are a waste of time.
Surely there is no other way than to ask a few questions about recent projects with a general basic test to ensure that the interviewee is not messing one around.
After 20+ years in the business, a written test is somewhat tedious and where does one begin subject-wise?
There's a lot of knowledge that is picked up temporarily and filed/discarded after use ... the brain can only store so much. Surely it's about one's capacity to come up with a solution rather than the ability to recall all aspects of programming syntax and other answers.
Nowadays, it must be more useful to discuss the frameworks one employs and higher level design processes rather than just low level syntax.
What do you like about Spring? When would you use Hibernate? Any thoughts on the employment of Groovy? Design Pattterns, discuss ...
Is this person moving with the times? Or are we just happy to get a one-track technologist?
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment