Joel's test as a tool of the interviewee
Many khabrovachane probably familiar with the test Joel ( translation ). If in a nutshell, Joel Spolsky proposes, on the basis of his chosen criteria, to evaluate to any engineer how good his team is.
However, based on the test, you can evaluate not only your current team, but also the future one . Imagine that you came to an interview in a project. You have learned something about the company from the Internet, from friends and colleagues, but you know a little about the project where you will have an interview. It makes sense to ask your counterpart about their project. Most likely, the answer on the part of the employer will be limited to the substantive part - what we do, who the customer is, how long, what goals, what kind of person they are looking for and why.
Suppose you liked this part and you thought about moving into this project. Potentially you will have to work with these people for the next few years (well, at least for months). Therefore, it makes sense to ask about the project in more detail. But at the same time, and future fellow team members to probe - what are they for peppers? ;)
')
And here it turns out that the aforementioned Joel test is very well suited for finding out details about the project. With one significant caveat - the test was made more than twelve years ago. During this time, the industry has significantly made a step forward. Therefore, it makes sense to slightly correct the questions, taking into account this fact.
Each of Joel's 12 questions can be slightly reworked and used as a seed to discuss a particular aspect of development in the team you are interviewing. Following each of the original questions, I listed several directions in which they can be developed.
If the interlocutors say that 6 or less - IMHO you can say goodbye right away. If 7 or more - then you can sit longer and clarify the details. Especially about the items with which everything is not very good. If none of the interlocutors knows what Joel's test is and who Joel is - it makes sense to politely say goodbye and leave;)
Now VCS is a rule, so you probably will not hear the answer “no”. Therefore, you should ask what version control system do your counterparts use? If it turns out that this is some old and slow system, it is likely that the processes in the project (or in the entire company) are slow or the people do not understand the advantages of modern systems compared to the old ones. It makes sense to ask if Git or Mercurial is in the near future, and if there is, ask what prevented it from moving to it earlier, and what benefits they plan to receive during the transition.
It also makes sense to ask how the work with repositories is built - in which branches the development takes place, at what moments and by what rules are the murgi made, how stable is the trunk, are there any checks at commits (that the project compiles, that tests pass, that the codestyle correct), etc.
And a great addition from kamentov - is the code checked before integration into the repository by people ? In other words, is there a Code Review project?
Can your counterparts build / deploy / chouvastam their product (or what do you have there) in one step? In two steps? In other words, is the build automated? If not, it makes sense to ask why it is not automated. What prevents it from automating and thereby saving human resources (and nerves)? At this stage, a lot of interesting things about the project can be found out.
As you know, stable nightly builds are a sign of some minimal quality of a project and a way to quickly find critical errors. Do your peers perform daily assembly of the project? Is there a Continuous Integration server on the project? Which one How does he help engineers? What resources are allocated for CI?
Again, now everyone is using bug trackers. So what's interesting is: what bug tracker is used? What processes are built around it? Who, how and to whom throws tickets? It's comfortable? What doesn't you like about the current bug tracker or the processes around it? What activity is registered in the tracker (bugs, features, backports, regular tasks), and what is not.
Do your counterparts correct existing errors before writing a new code? Not all? Why? What are corrected and which are not? Who decides whether to correct this error or score? If there are a lot of open bugs in the project (even if only P4 and P5), this is a sure sign of not very high product quality and lack of resources, developers. It can threaten with sweeps, overheads and tacky nerves.
Well, or just everybody likes the project and people just slaughter it. Do you want to work in such a project?
Does your vis-à-vis work schedule? How relevant is it today? Do you have plans for the week? For a month? For a year? The lack of an up-to-date plan is a sign of immaturity of management or a lack of understanding of the final goals of the project. Conflict situations often arise in such projects - for example, when a customer comes in and it turns out that it is completely incomprehensible when the next release will come out with the features he needsjust yesterday .
Is there a draft specification? Who writes them? Do they often change? How are their changes tracked? What actions are taken if the specification for the already working functionality suddenly changes? Specification is generally the only way for the customer and the contractor to agree among themselves. This is also a way to verify that the task is performed from and to, and that it is exactly what she performed.
Are there peaceful conditions for the work of engineers? How many people still a person sitting in the room where you will sit? Do people in their workplace talk on mobile phones? Do they eat right in front of the computer? Are there any rules about what the workplace should look like? Is anything in the room being discussed, distracting others?
I do not know about you, but all of this is really very important to me. I used to work in a quiet environment.
Are modern computers given to engineers for work, or are they forced to use obsolete slag? Will you have the freedom to choose an OS, IDE, word processor, antivirus, etc.? Is all software in the office (project) licensed? Winda? Vord? If you need a software for $ 100 for work, will you buy a license for it? And for $ 500? And for $ 1000?
Programmers' salaries are now in the thousands of dollars, so a negative answer to these questions will show a lack of understanding of the elementary moments of the project management or the entire company. In addition, the lack of suitable equipment and religiously faithful software can easily demotivate an engineer.
If not - then you need to run at a run, if it is not Google . How many testers are in a project? What is the quantitative ratio of testers and developers? What do testers do - manual testing or automatic? Do the developers write any tests (unit, regression)? Are testers team members or belong to a neighboring unit? The second case means an invisible barrier within the team, so it makes sense to ask how, in this case, the interaction between the testers and the programmers is built.
I think you will find out the answer to this question)) But the topic is important. Imagine that you were not asked to write a code for an interview. It means, most likely, your future colleagues were not asked either. So, there is a non-zero probability that they write code is not very good. Or maybe they know this and are afraid to screw it up in front of you? In general, if you do not ask to write code, it makes sense to be on your guard.
Do you test your project on "random" people? In general, anyone except the developers and the customer saw the project? If no one has seen the project, there are some chances that the project is inadequate. The fact is that the customer and the contractor are not the most appropriate parties with regard to various aspects of the project. They are prejudiced and interested. A third party can help both in controversial points. so easy to see shoals, imperceptible zamylennom eye.
Something like this.
Plus, there are still obvious questions (salary, schedule flexibility, etc.), but they are not related to the development process, so we omit them in this topic.
And what would you ask?
However, based on the test, you can evaluate not only your current team, but also the future one . Imagine that you came to an interview in a project. You have learned something about the company from the Internet, from friends and colleagues, but you know a little about the project where you will have an interview. It makes sense to ask your counterpart about their project. Most likely, the answer on the part of the employer will be limited to the substantive part - what we do, who the customer is, how long, what goals, what kind of person they are looking for and why.
Suppose you liked this part and you thought about moving into this project. Potentially you will have to work with these people for the next few years (well, at least for months). Therefore, it makes sense to ask about the project in more detail. But at the same time, and future fellow team members to probe - what are they for peppers? ;)
')
And here it turns out that the aforementioned Joel test is very well suited for finding out details about the project. With one significant caveat - the test was made more than twelve years ago. During this time, the industry has significantly made a step forward. Therefore, it makes sense to slightly correct the questions, taking into account this fact.
Each of Joel's 12 questions can be slightly reworked and used as a seed to discuss a particular aspect of development in the team you are interviewing. Following each of the original questions, I listed several directions in which they can be developed.
0. How many points does Joel's test score?
If the interlocutors say that 6 or less - IMHO you can say goodbye right away. If 7 or more - then you can sit longer and clarify the details. Especially about the items with which everything is not very good. If none of the interlocutors knows what Joel's test is and who Joel is - it makes sense to politely say goodbye and leave;)
1. Do you use a version control system?
Now VCS is a rule, so you probably will not hear the answer “no”. Therefore, you should ask what version control system do your counterparts use? If it turns out that this is some old and slow system, it is likely that the processes in the project (or in the entire company) are slow or the people do not understand the advantages of modern systems compared to the old ones. It makes sense to ask if Git or Mercurial is in the near future, and if there is, ask what prevented it from moving to it earlier, and what benefits they plan to receive during the transition.
It also makes sense to ask how the work with repositories is built - in which branches the development takes place, at what moments and by what rules are the murgi made, how stable is the trunk, are there any checks at commits (that the project compiles, that tests pass, that the codestyle correct), etc.
And a great addition from kamentov - is the code checked before integration into the repository by people ? In other words, is there a Code Review project?
2. Can you assemble the product in one step?
Can your counterparts build / deploy / chouvastam their product (or what do you have there) in one step? In two steps? In other words, is the build automated? If not, it makes sense to ask why it is not automated. What prevents it from automating and thereby saving human resources (and nerves)? At this stage, a lot of interesting things about the project can be found out.
3. Do you perform daily builds?
As you know, stable nightly builds are a sign of some minimal quality of a project and a way to quickly find critical errors. Do your peers perform daily assembly of the project? Is there a Continuous Integration server on the project? Which one How does he help engineers? What resources are allocated for CI?
4. Do you use an error database?
Again, now everyone is using bug trackers. So what's interesting is: what bug tracker is used? What processes are built around it? Who, how and to whom throws tickets? It's comfortable? What doesn't you like about the current bug tracker or the processes around it? What activity is registered in the tracker (bugs, features, backports, regular tasks), and what is not.
5. Do you fix bugs before writing new code?
Do your counterparts correct existing errors before writing a new code? Not all? Why? What are corrected and which are not? Who decides whether to correct this error or score? If there are a lot of open bugs in the project (even if only P4 and P5), this is a sure sign of not very high product quality and lack of resources, developers. It can threaten with sweeps, overheads and tacky nerves.
Well, or just everybody likes the project and people just slaughter it. Do you want to work in such a project?
6. Do you have a current work plan?
Does your vis-à-vis work schedule? How relevant is it today? Do you have plans for the week? For a month? For a year? The lack of an up-to-date plan is a sign of immaturity of management or a lack of understanding of the final goals of the project. Conflict situations often arise in such projects - for example, when a customer comes in and it turns out that it is completely incomprehensible when the next release will come out with the features he needs
7. Do you have a specification?
Is there a draft specification? Who writes them? Do they often change? How are their changes tracked? What actions are taken if the specification for the already working functionality suddenly changes? Specification is generally the only way for the customer and the contractor to agree among themselves. This is also a way to verify that the task is performed from and to, and that it is exactly what she performed.
8. Do your programmers have a relaxed working environment?
Are there peaceful conditions for the work of engineers? How many people still a person sitting in the room where you will sit? Do people in their workplace talk on mobile phones? Do they eat right in front of the computer? Are there any rules about what the workplace should look like? Is anything in the room being discussed, distracting others?
I do not know about you, but all of this is really very important to me. I used to work in a quiet environment.
9. Do you use the best tools available?
Are modern computers given to engineers for work, or are they forced to use obsolete slag? Will you have the freedom to choose an OS, IDE, word processor, antivirus, etc.? Is all software in the office (project) licensed? Winda? Vord? If you need a software for $ 100 for work, will you buy a license for it? And for $ 500? And for $ 1000?
Programmers' salaries are now in the thousands of dollars, so a negative answer to these questions will show a lack of understanding of the elementary moments of the project management or the entire company. In addition, the lack of suitable equipment and religiously faithful software can easily demotivate an engineer.
10. Do you have testers?
If not - then you need to run at a run
11. Do applicants write a code during an interview?
I think you will find out the answer to this question)) But the topic is important. Imagine that you were not asked to write a code for an interview. It means, most likely, your future colleagues were not asked either. So, there is a non-zero probability that they write code is not very good. Or maybe they know this and are afraid to screw it up in front of you? In general, if you do not ask to write code, it makes sense to be on your guard.
12. Do you conduct corridor testing of usability programs?
Do you test your project on "random" people? In general, anyone except the developers and the customer saw the project? If no one has seen the project, there are some chances that the project is inadequate. The fact is that the customer and the contractor are not the most appropriate parties with regard to various aspects of the project. They are prejudiced and interested. A third party can help both in controversial points. so easy to see shoals, imperceptible zamylennom eye.
Something like this.
Plus, there are still obvious questions (salary, schedule flexibility, etc.), but they are not related to the development process, so we omit them in this topic.
And what would you ask?
Source: https://habr.com/ru/post/159689/
All Articles