The main focus in the IT recruitment process goes towards finding the people with the best technological (and abstract reasoning) skills. Rightfully so, these technical capabilities are THE necessary prerequisite for any good employment in our industry.
At the same time, the big employers are also oriented, in their hiring strategy, towards searching and matching the best "characters" to a particular advertised position. This is understandable as the big companies are more stable than the start-ups, so the large organizations will invariably put more emphasis on long-time stability than on short-term outstanding results. That's why the corporate hiring staff usually has two main approaches.
The first approach consists in using classically established psychometric forms for employment (an example: a couple hundred questions to be answered very fast on a matter of 90 minutes).
The second approach consists in using Situational Judgment tests. For instance, this kind of testing is given as a pre-screening step when applying for jobs with the European Commission.
The psychometric quizzes are used frequently in the IT industry in Romania, but in US/Canada the IT applicants for corporate jobs can be more usually confronted with live (not written) Situational Judgement tests.
Practically, one is introduced to a scenario with a probable conflict outcome, where the interviewer plays one of the characters and the interviewee plays the character with the position he/she applies for: let's say as senior developer. Then a dialogue follows, with contradictions and arguments, where the interviewee has to find the best possible outcome of the given situation. The exchange can get heated! Moreover, during the interview the roles could be changed, or exchanged and at the end. If the outcome is deemed a failure (for example the simulation of the project failed), the applicant is asked to assign a percentage of "blame" to each actor involved.
Too often an obvious, unavoidable and constant source of tension is overlooked: in a software development team IT engineers have a tendency to be dismissive towards project managers. This tendency is understandable: computer programming requires a lot of complex education and effort. However, software project management does not require that much formal education prerequisite, not even close! Many developers say that, if selected any person on the street randomly, one would have good chances of finding a better manager than the current one inside the organization! Basically, the relation "political power versus education" between developers and IT managers can appear completely reversed when compared, for instance, to the relation from the army between soldiers and commissioned officers: in software industry, a project manager usually has less high training than its subordinates!
Moreover, to make the things even stranger, managers see that many developers lack social skills and can be pretty introverted. I know from personal experience that the more a developer avoids interacting with the people, the more they like taking refuge in the perfect world of mathematics and computer science! Whoever has experience in the IT industry knows that the facts above are not at all an exaggeration, but a real fact.
These communication (or attitude) problems are mostly encountered in our field, and are especially self-evident when compared with the other jobs available on the market.
The bigger the company, the more is it focused on finding the "good" psychological traits of the potential employee.
It is best to be prepared and to expect preconceptions during an interview, preconceptions based on many stereotypes: nationality, region, gender, age, family status, you name it.
Be curious and at times more assertive than the majority of Romanians!
A real example of an interview scenario where Situational Judgement is required:
There are 5 people in your team: one project manager, one architect, one team-leader and 2 developers, one of the developers being yourself. For the sake of simplicity, we won't consider the other usual actors such as the testers or the business analysts.
It is Friday and the architect scheduled a meeting to present a critical module to be developed next week when it must also be finalized and deployed to the client. The architect presents the proposed design, which you find good. However, after some time in the presentation, you see a better solution. At the end of the presentation, the Architect asks (and this is where the play starts):
- So, this concludes my presentation. Does anyone have anything to add, any thoughts?
(What would you do?...)
After the exchange of ideas between the architect, whose role is being played by the interviewer, and the developer who is impersonated by the job-applicant, we fast forward the scenario a few days.
Let's say we are now on the next Wednesday afternoon, whenonly a couple of hours of development remain before code-freeze. You (the developer) read the module implemented by your colleague and notice that your fellow programmer did not follow the specifications that were agreed on last Friday, but rather implemented your solution that you identified as being better than the one proposed by the architect!
(What do you do? ...)
And here again, a pretty interesting (with heated arguments) improvised discussion between the two developers can follow. It can be played by the interviewer-interviewee or between any combination of actors (depending on the answer to the question: what do you do next?).
At the end of the improvisation, if the project failed, the big management wants to make somebody, at least one person, pay.
You as developer, participant in this story, how would you calculate and spread the blame among all five participants, so the sum of all the fault is 100%?
by Dan Suciu
by Petra Ivașcu
