October 28, 2013 at 14:05Re: Developer interview (alternative / addition)
I could not get past the topic " Questions for an interview with middle / senior iOS Developer " and the article " Developer Interview ". I want to offer an alternative or additional approach to the interview of developers.
Parsing a govnokod or a hundred motley questions on a piece of paper is, of course, fine, but if this is the only stage of the interview, it makes you want to ask something like: “Are you serious?”
Are you tired of the fact that the interviews have a specific position of the developer they ask you a lot of garbage that is quite divorced from life that you want to quickly forget after such an interview (nightmare mode is a test for 150+ questions and a psychologist at the end)? I do not deny that evaluating the quality of the code is veryit’s important, but assessing the quality of a particular piece and drawing great conclusions from it is definitely wrong.
In addition, too many so-called developers have no idea how to build the architecture of the application, how to correctly divide the components into modules, and how to introduce flexibility for subsequent changes to the project. And questions like questions from the topic " Questions for an interview with middle / senior iOS Developer " will not let you know how well a person uses his knowledge in the implementation of the project.
Let's look at the example of an android developer (you can adapt for any field, but you understand that without specifics, this article would simply be criticized, so let's talk about android).
What I propose: we take a popular, large (in terms of functionality) and complex (in terms of implementation) application and talk about how the candidate would have made it !
Why is this a good option?You will be able to accurately assess the level of the developer in the design and implementation of software, his knowledge of the platform and other nuances that are important to you, as well as just having a good time (in the case of a competent candidate, and he will be more interested than in a typical interview). + You can understand how sociable a person is, how he will join your team, can he explain his decisions to others?
Parsing a piece of code or memorized answers to fuzzy questions will not let you know how then this person will cope with real tasks on a real project (but I'm not saying that you should not ask this, it is possible, but this should not be the basis of the interview).
For example, take the Vkontakte application for android (it is large, complex and familiar to many).
Again, I propose to discuss the implementation of a project that has already been launched, works and there is something to talk about. Do not just abstractly crackle about the canons of OOP and competent horse architecture in a vacuum, but take a specific application / web service / substitute your own and discuss the aspects of its design and implementation that interest you. I hope you catch this thought.
You will see that the conclusions that I will draw after each section of “What We Will Talk About” are universal and suitable for many areas of software development (you can always adapt everything for your field).
I would open the application / site / etc on the device (it is not abstract to discuss everything) and, in fact, start a conversation: “Imagine that you need to implement such an application, let's discuss how you would do it?” And went on questions. Open some screen and ask: “how would you do ...”
(Android development is just an example)
After these questions, you will understand what projects this developer has had to do and what role he played in them, what experience in designing applications he has behind him.
After these questions, you will understand the level of development skills for a specific platform (in this case, android)
After these questions, you will find out how strong the candidate is in development, as in science, practical knowledge is excellent, but without theory he will not be able to "create his own", but only copy someone, while usually worsening the implementation.
After these questions, you can figure out how he will join your team and cope with the work in your company, you can discuss your approaches to the organization of development
This approach is NOT suitable for companies whose recruitment is on stream and for each interview a hard 15-20 minutes. But it can work well for a small team of professionals who need an extra professional person.
+ With this approach to the interview, you can accidentally miss an amateur talk, who eventually flakes your project, because in words, he is Leo Tolstoy, but in fact ... So, whatever that was, I suggest giving test items (now 99% will say that this garbage is complete, time is needed and all that. BUT this is the only normal wayIn addition to Open Source projects, check the quality of the code that the developer issues, his attitude to the timing and to the interpretation of requirements, implementation, to work with VCS, etc., you understand).
What do you think? For me - this approach is interesting for both sides and effective, also for both sides. It’s immediately clear what the candidate’s gaps are (and possibly the interviewer’s), and the candidate understands what skill is required of him, what he knows, what he doesn't know. Great, after all. The most epic when you pored over an interview for 2 hours answering a ton of questions from SQL to Java and C, and then after a week they tell you that you seem to be nothing, but we won’t take you. And you sit and think, what am I messing up with?
I don’t say “you all do it wrong”, I offer an alternative / addition for current approaches and would like to hear your opinion, I hope you didn’t waste your time and brought out something useful for yourself, thank you.
PS such an approach to the interview can remove these idiotic requirements for work experience on a specific profile. You know, I’ve seen a lot of programmers with the experience of 3+, 5+, 10+ and even 15+, but they still haven’t learned how to program, what they give out is such a turd that you want to throw it, hide in a corner and cry, but these people get their 100k + and think that they are gifted. If you are posting a vacancy, please put in the column the work experience: “it doesn’t matter if you programmed well” or “from the year” and do not filter out candidates based on this criterion.
PPS all of a sudden, but I myself haven’t conducted any interviews yet (I’ve done enough), but I think I’ll be there soon and will try to do something like that. So, I haven’t tried it myself, but I advise you. Criticism is welcome, although I’m sure that everyone will say that such an interview takes a lot of time. I have an argument for you - it is better to spend a little more time at the interview stage.
UPD: As an addendum to the post: you should not discuss projects that you yourself have already implemented , most likely your opinion will be biased in relation to the candidate's answers
Parsing a govnokod or a hundred motley questions on a piece of paper is, of course, fine, but if this is the only stage of the interview, it makes you want to ask something like: “Are you serious?”
Are you tired of the fact that the interviews have a specific position of the developer they ask you a lot of garbage that is quite divorced from life that you want to quickly forget after such an interview (nightmare mode is a test for 150+ questions and a psychologist at the end)? I do not deny that evaluating the quality of the code is veryit’s important, but assessing the quality of a particular piece and drawing great conclusions from it is definitely wrong.
In addition, too many so-called developers have no idea how to build the architecture of the application, how to correctly divide the components into modules, and how to introduce flexibility for subsequent changes to the project. And questions like questions from the topic " Questions for an interview with middle / senior iOS Developer " will not let you know how well a person uses his knowledge in the implementation of the project.
What do you suggest, man?
Let's look at the example of an android developer (you can adapt for any field, but you understand that without specifics, this article would simply be criticized, so let's talk about android).
What I propose: we take a popular, large (in terms of functionality) and complex (in terms of implementation) application and talk about how the candidate would have made it !
Why is this a good option?You will be able to accurately assess the level of the developer in the design and implementation of software, his knowledge of the platform and other nuances that are important to you, as well as just having a good time (in the case of a competent candidate, and he will be more interested than in a typical interview). + You can understand how sociable a person is, how he will join your team, can he explain his decisions to others?
Parsing a piece of code or memorized answers to fuzzy questions will not let you know how then this person will cope with real tasks on a real project (but I'm not saying that you should not ask this, it is possible, but this should not be the basis of the interview).
For example, take the Vkontakte application for android (it is large, complex and familiar to many).
Again, I propose to discuss the implementation of a project that has already been launched, works and there is something to talk about. Do not just abstractly crackle about the canons of OOP and competent horse architecture in a vacuum, but take a specific application / web service / substitute your own and discuss the aspects of its design and implementation that interest you. I hope you catch this thought.
You will see that the conclusions that I will draw after each section of “What We Will Talk About” are universal and suitable for many areas of software development (you can always adapt everything for your field).
And how to conduct such an interview?
I would open the application / site / etc on the device (it is not abstract to discuss everything) and, in fact, start a conversation: “Imagine that you need to implement such an application, let's discuss how you would do it?” And went on questions. Open some screen and ask: “how would you do ...”
What are we going to talk about?
(Android development is just an example)
1. Architectural moments
- How do we organize trips to the network? (service or asintak, or both? Or maybe your own thread pool)
- How to create a database (ORM, pure sql, how will we resolve multithreaded problems? By the way, can you put NoSQL in it ??)
- What about data caching? (what is possible on files, and what is in the database, what is disabled, cache size limit)
- How to implement api level? (here it’s just about which approaches will be applied, let’s say all server response models inherit the basic one, network error handling, api error handling) Much
attention should be paid to this issue, as things like the server-side api implementation are then used throughout the project, so it should be simple, and ready for improvements / changes in the future (KISS in general) - Discuss right away about the serious libraries that the developer wants to drag into the project (about the serious ones, I mean the ones that tightly bind hands in the future, for example Robospice, ActionBarSherlock (I'm in the know about ActionBarCompat), AndroidAnnotations, etc)
After these questions, you will understand what projects this developer has had to do and what role he played in them, what experience in designing applications he has behind him.
2. Platform specifics
- Fragments! (you do everything on them, and why? where and how would you use it, here you can open NavigationDrawer in Vkontakte and ask how the top-level navigation in the application is arranged, why it was made like that and so on)
- The life cycle of the components of an android application (task, activity, fragment, service)
- Approaches to organizing responsive-ui applications (typesetting, theme styles, animations, dp, sp, how they work, how to typeset them)
- Important differences between API level <11 and API level> 11
After these questions, you will understand the level of development skills for a specific platform (in this case, android)
3. General literacy in programming and development (many have such a mess in my head on this topic ...)
- Data types (where and what would he use in the application? How to store in memory a list of news, a list of contacts, knowledge of the implementations and contracts of List, Map, Set, an understanding of where to use which structure, complexity of operations
- Algorithms (knowledge of the complexities of basic sorting algorithms, for example, the contact list can be sorted by different criteria? Other job-specific algorithms)
- Architecture
from Arthur: OOP (inheritance, encapsulation, polymorphism, abstraction, why are these pieces and how are they interconnected?), (Patterns, why are they, if there are previous 4 pieces? Which ones do you know? And which ones can? Relation to them), for fun FP (that knows, maybe tried, what’s the point)
After these questions, you will find out how strong the candidate is in development, as in science, practical knowledge is excellent, but without theory he will not be able to "create his own", but only copy someone, while usually worsening the implementation.
4. Evaluation of deadlines, potential teamwork
- A rough assessment of the implementation of the beta version of such an application (Vkontakte) if the developer is only one + designer and tester (I would say, six months full time of the work of all team members, subjectivity depends on skills, of course, but it will make it possible to understand how close it is to reality)
- If you add more developers, how would he distribute the work on the application (here you can understand how the developer as a whole imagines teamwork)
After these questions, you can figure out how he will join your team and cope with the work in your company, you can discuss your approaches to the organization of development
That's all. Important notes and IMHO author
This approach is NOT suitable for companies whose recruitment is on stream and for each interview a hard 15-20 minutes. But it can work well for a small team of professionals who need an extra professional person.
+ With this approach to the interview, you can accidentally miss an amateur talk, who eventually flakes your project, because in words, he is Leo Tolstoy, but in fact ... So, whatever that was, I suggest giving test items (now 99% will say that this garbage is complete, time is needed and all that. BUT this is the only normal wayIn addition to Open Source projects, check the quality of the code that the developer issues, his attitude to the timing and to the interpretation of requirements, implementation, to work with VCS, etc., you understand).
What do you think? For me - this approach is interesting for both sides and effective, also for both sides. It’s immediately clear what the candidate’s gaps are (and possibly the interviewer’s), and the candidate understands what skill is required of him, what he knows, what he doesn't know. Great, after all. The most epic when you pored over an interview for 2 hours answering a ton of questions from SQL to Java and C, and then after a week they tell you that you seem to be nothing, but we won’t take you. And you sit and think, what am I messing up with?
I don’t say “you all do it wrong”, I offer an alternative / addition for current approaches and would like to hear your opinion, I hope you didn’t waste your time and brought out something useful for yourself, thank you.
PS such an approach to the interview can remove these idiotic requirements for work experience on a specific profile. You know, I’ve seen a lot of programmers with the experience of 3+, 5+, 10+ and even 15+, but they still haven’t learned how to program, what they give out is such a turd that you want to throw it, hide in a corner and cry, but these people get their 100k + and think that they are gifted. If you are posting a vacancy, please put in the column the work experience: “it doesn’t matter if you programmed well” or “from the year” and do not filter out candidates based on this criterion.
PPS all of a sudden, but I myself haven’t conducted any interviews yet (I’ve done enough), but I think I’ll be there soon and will try to do something like that. So, I haven’t tried it myself, but I advise you. Criticism is welcome, although I’m sure that everyone will say that such an interview takes a lot of time. I have an argument for you - it is better to spend a little more time at the interview stage.
UPD: As an addendum to the post: you should not discuss projects that you yourself have already implemented , most likely your opinion will be biased in relation to the candidate's answers