November 21, 2012 at 20:14Joel's test as an interviewee tool
Many Khabrovachites are probably familiar with Joel's test ( translation ). In a nutshell, Joel Spolsky suggests, on the basis of his chosen criteria, evaluate any engineer how good his team is.
However, based on the test, you can evaluate not only your current team, but also the future . Imagine that you came for an interview in some 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 interview. It makes sense to ask your counterparts about their project. Most likely, the response from the employer will be limited to the substantive part - what we do, who the customer is, how long, what are the goals, what kind of person they are looking for and why.
Suppose you liked this part and you thought about moving on to this project. You can potentially 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. And at the same time to test future teammates - what kind of peppers are they? ;)
And here it turns out that the aforementioned Joel test is very well suited to find out details about the project. With one significant caveat, the test was written more than twelve years ago. During this time, the industry has stepped forward significantly. Therefore, it makes sense to slightly correct the questions in light of this fact.
Each of Joel’s 12 questions can be slightly revised 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 areas in which they can be developed.
If the interlocutors claim that 6 or less - IMHO you can immediately say goodbye. If 7 or more - then you can sit longer and clarify the details. Especially about those points 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 the rule, so you probably won't hear the “no” answer. Therefore, you should ask what version control system do your counterparts use? If it turns out that this is some old and slow system - probably the processes in the project (or throughout the company) are slow or people do not understand the advantages of modern systems compared to old ones. It makes sense to ask if there are Git or Mercurial in the near future, and if so, ask what prevented you from switching to it earlier, what benefits you 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 according to what rules the merges are made, how stable the trunk is, whether there are any checks during commits (that the project is compiled, that the tests pass, that codestyle correct), etc.
And a great addition from kamenty - is the code checked before integration into the repository by people ? In other words, is there a Code Review on the project?
Can your counterparts complete the assembly / deployment / chouvast of their product (or cho you have there) in one step? In two steps? In other words, is the assembly 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 can be found out about the project.
As you know, stable nightly builds are a sign of some minimal project quality and a way to quickly find critical errors. Do your counterparts complete the 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 on CI?
Again, now everyone uses bugtrackers. Therefore, this is interesting: what bugtracker is used? What processes are built around it? Who, how and to whom throws tickets? It's comfortable? What do you dislike about the current bug tracker or the processes around it? What activity is recorded in the tracker (bugs, features, backports, regular tasks), and which is not.
Do your counterparts correct existing errors before writing new code? Not all? Why? Which correct and which not? Who decides whether to correct this error or score? If the project has a lot of open bugs (even if only P4 and P5) - this is a sure sign of not very high quality product and lack of resources, developers. This can threaten rummages, overheadheads and battered nerves.
Well, or just everyone all the FSUs on the project and people simply hammer. Do you want to work in such a project?
Do your counterparts have a work schedule? How relevant is it today? Do you have any 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 misunderstanding of the ultimate goals of the project. In such projects, conflicts often arise - for example, when a customer arrives and it turns out that it is completely incomprehensible when the next release comes out with the features he neededyesterday .
Are there any specifications on the draft? Who writes them? How often do they change? How are their changes tracked? What actions are taken if the specification for already working functionality suddenly changes? The specification is almost the only way for the customer and the contractor to agree among themselves. This is also a way to verify that the task is completed from and to, and that in general it is done.
Are calm conditions created for the work of engineers? How many people are still people sitting in the room where you will be sitting? Do people talk in their workplace on cell phones? Do they eat right in front of the computer? Are there any rules about what a workplace should look like? Are they discussing anything right in the room, distracting others?
I don’t know about you, but to me all this is really very important. I used to work in a quiet environment.
Do engineers get modern computers for work or are they forced to use obsolete slag? Will you have freedom in choosing an OS, IDE, word processor, antivirus, etc.? Is all software in the office (project) licensed? Windows? Word? If you need software for $ 100 for work, will you be licensed for it? And for $ 500? And for $ 1000?
The salaries of programmers are now estimated at thousands of dollars, so a negative answer to these questions will show a lack of understanding of the basic points by 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 have to run, if it's not Google . How many testers are in the project? What is the quantitative ratio of testers and developers? What do testers do - manual testing or automatic? Do 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 the interaction between testers and programmers is built in this case.
I think you’ll find out the answer to this question)) But the topic is important. Imagine that you were not asked to write the code for the interview. So, most likely, your future colleagues were also not asked. So, there is a non-zero probability that they write the code not very well. Or maybe they know this and are afraid to screw up in front of you? In general, if you are not asked to write code, it makes sense to be wary.
Do you test your project on “random” people? Did anyone other than the developers and the customer see 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 certain aspects of the project. They are biased and interested. A third party can help as in contentious issues. it's easy to see shoals invisible to a blurred 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 will omit them in this topic.
What would you ask?
However, based on the test, you can evaluate not only your current team, but also the future . Imagine that you came for an interview in some 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 interview. It makes sense to ask your counterparts about their project. Most likely, the response from the employer will be limited to the substantive part - what we do, who the customer is, how long, what are the goals, what kind of person they are looking for and why.
Suppose you liked this part and you thought about moving on to this project. You can potentially 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. And at the same time to test future teammates - what kind of peppers are they? ;)
And here it turns out that the aforementioned Joel test is very well suited to find out details about the project. With one significant caveat, the test was written more than twelve years ago. During this time, the industry has stepped forward significantly. Therefore, it makes sense to slightly correct the questions in light of this fact.
Each of Joel’s 12 questions can be slightly revised 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 areas in which they can be developed.
0. How many points does the Joel test project gain?
If the interlocutors claim that 6 or less - IMHO you can immediately say goodbye. If 7 or more - then you can sit longer and clarify the details. Especially about those points 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 the rule, so you probably won't hear the “no” answer. Therefore, you should ask what version control system do your counterparts use? If it turns out that this is some old and slow system - probably the processes in the project (or throughout the company) are slow or people do not understand the advantages of modern systems compared to old ones. It makes sense to ask if there are Git or Mercurial in the near future, and if so, ask what prevented you from switching to it earlier, what benefits you 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 according to what rules the merges are made, how stable the trunk is, whether there are any checks during commits (that the project is compiled, that the tests pass, that codestyle correct), etc.
And a great addition from kamenty - is the code checked before integration into the repository by people ? In other words, is there a Code Review on the project?
2. Can you assemble the product in one step?
Can your counterparts complete the assembly / deployment / chouvast of their product (or cho you have there) in one step? In two steps? In other words, is the assembly 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 can be found out about the project.
3. Do you do daily builds?
As you know, stable nightly builds are a sign of some minimal project quality and a way to quickly find critical errors. Do your counterparts complete the 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 on CI?
4. Do you use an error database?
Again, now everyone uses bugtrackers. Therefore, this is interesting: what bugtracker is used? What processes are built around it? Who, how and to whom throws tickets? It's comfortable? What do you dislike about the current bug tracker or the processes around it? What activity is recorded in the tracker (bugs, features, backports, regular tasks), and which is not.
5. Do you correct errors before writing new code?
Do your counterparts correct existing errors before writing new code? Not all? Why? Which correct and which not? Who decides whether to correct this error or score? If the project has a lot of open bugs (even if only P4 and P5) - this is a sure sign of not very high quality product and lack of resources, developers. This can threaten rummages, overheadheads and battered nerves.
Well, or just everyone all the FSUs on the project and people simply hammer. Do you want to work in such a project?
6. Do you have an up-to-date work plan?
Do your counterparts have a work schedule? How relevant is it today? Do you have any 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 misunderstanding of the ultimate goals of the project. In such projects, conflicts often arise - for example, when a customer arrives and it turns out that it is completely incomprehensible when the next release comes out with the features he needed
7. Do you have a specification?
Are there any specifications on the draft? Who writes them? How often do they change? How are their changes tracked? What actions are taken if the specification for already working functionality suddenly changes? The specification is almost the only way for the customer and the contractor to agree among themselves. This is also a way to verify that the task is completed from and to, and that in general it is done.
8. Are your programmers provided with a relaxed working environment?
Are calm conditions created for the work of engineers? How many people are still people sitting in the room where you will be sitting? Do people talk in their workplace on cell phones? Do they eat right in front of the computer? Are there any rules about what a workplace should look like? Are they discussing anything right in the room, distracting others?
I don’t know about you, but to me all this is really very important. I used to work in a quiet environment.
9. Do you use the best tools available to work?
Do engineers get modern computers for work or are they forced to use obsolete slag? Will you have freedom in choosing an OS, IDE, word processor, antivirus, etc.? Is all software in the office (project) licensed? Windows? Word? If you need software for $ 100 for work, will you be licensed for it? And for $ 500? And for $ 1000?
The salaries of programmers are now estimated at thousands of dollars, so a negative answer to these questions will show a lack of understanding of the basic points by 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 have to run
11. Do job candidates write a code during an interview?
I think you’ll find out the answer to this question)) But the topic is important. Imagine that you were not asked to write the code for the interview. So, most likely, your future colleagues were also not asked. So, there is a non-zero probability that they write the code not very well. Or maybe they know this and are afraid to screw up in front of you? In general, if you are not asked to write code, it makes sense to be wary.
12. Do you do corridor testing of program usability?
Do you test your project on “random” people? Did anyone other than the developers and the customer see 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 certain aspects of the project. They are biased and interested. A third party can help as in contentious issues. it's easy to see shoals invisible to a blurred 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 will omit them in this topic.
What would you ask?