The Guerrilla Guide to Interviewing
Статья рассказывает о подходах к [[найм сотрудников]] в рамках команды разработки.
TL;DR:
- Весь найм проходит в плоскости да/нет.
- В сотруднике мы хотим видеть два качества: смышлённость и доведение дел до конца.
- Процесс собеседования состоит из: приветствия, диалога о предыдущем опыте, простой задачи, сложной и обменом обратной связи с двух сторон.
- Необходимо на своём уровне составить список красных и зелёных флагов по ответам кандидата.
- Необходимо тщательно подходит к тому, какие вопросы выбирать про личные дела кандидата.
Everybody gives lip service to the idea that people are the most important part of a software project, but nobody is quite sure what you can do about it. The very first thing you have to do right if you want to have good programmers is to hire the right programmers, and that means you have to be able to figure out who the right programmers are, and this is usually done in the interview process.
At the end of the interview, you must be prepared to make a sharp decision about the candidate. There are only two possible outcomes to this decision: ==Hire or No Hire. There is no other possible answer.== Never say, “Hire, but not for my team.” This is rude and implies that the candidate is not smart enough to work with you, but maybe he’s smart enough for those losers over in that other team. If you find yourself tempted to say “Hire, but not in my team,” simply translate that mechanically to “No Hire” and you’ll be OK. Even if you have a candidate that would be brilliant at doing your particular task, but wouldn’t be very good in another team, that’s a No Hire. In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire. You’ll solve some short term pain in exchange for a lot of long term pain.
Never say “Maybe, I can’t tell.” If you can’t tell, that means No Hire. It’s really easier than you’d think. Can’t tell? Just say no! If you are on the fence, that means No Hire. Never say, “Well, Hire, I guess, but I’m a little bit concerned about…” That’s a No Hire as well. Mechanically translate all the waffling to “no” and you’ll be all right.
OK, I didn’t tell you the most important part—how do you know whether to hire someone?
In principle, it’s simple. You’re looking for people who are
- Smart, and
- Get things done.
People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts.
People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, but they soak up good people’s time.
How do you detect smart in an interview? The first good sign is that you don’t have to explain things over and over again. The conversation just flows.
Before the interview, I read over the candidates resume and jot down an interview plan on a scrap of paper. That’s just a list of questions that I want to ask. Here’s a typical plan for interviewing a programmer:
- Introduction
- Question about recent project candidate worked on
- Easy Programming Question
- Pointer/Recursion Question
- Are you satisfied?
- Do you have any questions?
One: Look for passion. Smart people are passionate about the projects they work on. They get very excited talking about the subject. They talk quickly, and get animated. Being passionately negative can be just as good a sign. “My last boss wanted to do everything on VAX computers because it was all he understood. What a dope!” There are far too many people around that can work on something and not really care one way or the other. It’s hard to get people like this motivated about anything.
Two: Good candidates are careful to explain things well, at whatever level. I have rejected candidates because when they talked about their previous project, they couldn’t explain it in terms that a normal person could understand. Often CS majors will just assume that everyone knows what Bates Theorem is or what O(log n) means. If they start doing this, stop them for a minute and say, “could you do me a favor, just for the sake of the exercise, could you please explain this in terms my grandmother could understand.”
Three: If the project was a team project, look for signs that they took a leadership role. A candidate might say, “We were working on X, but the boss said Y and the client said Z.” I’ll ask, “So what did you do?” A good answer to this might be “I got together with the other members of the team and wrote a proposal…” A bad answer might be, “Well, there was nothing I could do. It was an impossible situation.” Remember, Smart and Gets Things Done. The only way you’re going to be able to tell if somebody Gets Things Done is to see if historically they have tended to get things done in the past.
It’s the kind of problem that any programmer working today should be able to solve in about one minute. Some examples: - Write a function that determines if a string starts with an upper-case letter A-Z - Write a function that determines the area of a circle given the radius - Add up all the values in an array
I ask interviewers to write immediate feedback after the interview, either a “hire” or “no hire”, followed by a one or two paragraph justification. It’s due 15 minutes after the interview ends.
Link:: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/