Cross-complaints between interviewees and interviewers are common when it comes to positions oriented to programming. The first point to the poor technical understanding of the interviewer, their attachment to an incongruous or useless list of questions or a questionnaire of the type multiple choice examination on technical details that - luckily - the internet has relieved to remember, among others.
The second stresses a certain haughtiness of the people of the sector (in times of fat cows), little or bad predisposition to be understood when technical issues are touched and especially a whiff of contempt for any competition beyond purely technical: punctuality, presence , Formality, communication, etc.
5 Questions For Job Interviews to Programmers
That shows just a button, although I have the feeling of having read several more examples these days.
I wondered what I would ask as an interviewer. I clarify that I do not have much experience as such, although I quite interviewed. This is a selected armed from the questions that I remember, plus some modifications.
The greeting, the look, the clothes, all that.
I do not consider myself very qualified to examine these details in fine, so I leave the advice to the interviewee in charge of the experts.
What I can mention is a couple of points that help to locate and see the interviewer better "from this side": if you do not have technical knowledge, you have to clarify it from the outset (the interviewee must be able to know how to locate it). To have time available, to pay attention, to interrupt with kindness, not to discuss and, as far as possible, to express disagreements (it is worth for interviewees, too: let the other be buried only). If appropriate, state the reasons for the disagreement once and objectively.
1. Why are you looking for a new job?
I like that question to break the ice, it is usually one of the typical, so the interviewee is not surprised (why make him feel uncomfortable?) And his answer gives us an overview of their main motivations, tastes and preferences. Interesting details can also be seen: Are you not giving a "compromise" answer? Does it seem to have it ready?
A job search necessarily involves some kind of malaise about the current situation, I believe. Does it sound sincere in expressing it?
2. How is the project you are working in or the last one in which you have participated?
It can be personal or work (will have to see where it points). Is it correct in the use of technical words? Do you try and avoid them when your partner does not have enough knowledge? Can you summarize a complex project in a few words?
3. What is the most difficult problem you have faced and how have you solved it (if you have succeeded)?
On the way back, it will be necessary to see if he can locate himself and make himself understood without going into excessive details. There is also the issue of honesty: you may not have succeeded in solving the problem alone, or you have not done so at all. It's a way to explore your resources: do you use the internet? bibliography? Do you ask for help from other people or do you prefer to research on your own? We solve problems all the time, and in all development there will be something, however minimal, that we have never done.
4. Could you write a brief summary of (what is or what you imagine it to be) a "normal" work day?
All programmers can read and write code. Easier, more difficult, more or less entangled, that only involves more or less time and effort to understand it, we will finally know what it does. On the other hand, the code is an issue that the interviewer is probably not qualified to evaluate.
But can you decently write in natural language? In daily practice there is a lot to write apart from code: you have to produce comments, documentation, notes or design guidelines that other people (or yourself after a long time) should be able to decode. You also have to report mistakes, exchange mails on complicated issues, sometimes communicate directly with people outside the team.
This is one of the most important points for me (see Software development as a communication system and the importance of being able to read and write). A badly written note a month ago involves redoing all a research paper for not being able to decode it. An incorrectly reported error can not be corrected. An unspecified or poorly decoded task is hours or days of lost work. A mail out of the team with misspellings - or directly incomprehensible - is cause for embarrassment for the team or the company ... not to mention a misspelling in an application message!
Needless to say, whoever writes correctly usually reads more than correctly, so with this brief review we cover everything.
Okay, it does not have to be Borges, but ... The content will also show what you expect from a "normal" work day, what situations you find common, and allow you to compare it against the environment in which it will actually develop.
5. A hypothetical situation ...
I think this is a question that is asked a lot, with its variations. It starts with a brief story: "You have your first assignment, that means demonstrating what you are capable of. You see that you are not managing to solve it in your normal working hours. ?
Do you know? Do you stay until later to solve it? Looking for help? A colleague, the boss, who? Try to hide it?
I think this covers more or less explicitly everything important for a programmer, beyond the technical, and in the answers and in the modes is the rest.
