Could not pass by a topic "
Questions on interview middle / senior iOS Developer " and articles "
Interview of the developer ". I want to offer an alternative or additional approach to the interview of developers.
An analysis of a govnokod or hundreds of different questions on a piece of paper is, of course, fine, but if this is the only stage of the interview, then it causes a desire to ask something like: “Are you serious?”
Are you not tired of the fact that during interviews for a specific position of a developer you are asked quite a bit of bullshit that you want to forget as soon as possible after such an interview (nightmare mode is a test for 150+ questions and a psychologist at the end)? I do not deny that assessing the quality of a code is
very important, but assessing the quality of a particular
piece and making big conclusions from it is definitely wrong.
')
In addition, too many so-called
developers have no idea how to build an application architecture, how to competently separate components into modules, how to introduce flexibility for subsequent changes to the project. And questions like questions from the topic "
Questions for an interview middle / senior iOS Developer " will not let you know how well a person uses his knowledge well in the implementation of the project.
What do you suggest dude?
Let's look at the example of the android developer
(you can adapt for any area, but you understand that without specifics this article would simply be criticized, so let's
talk about android).What I offer: we take the popular, large (in terms of functionality) and complex (in terms of implementation) application and talk about
how the candidate would have done it !
Why is this a good option? You will be able to accurately estimate 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, and also just have a good time (in the case of a competent candidate, and he will be more interested than in a typical interview). + You will be able to 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 the questions in the floppy questions will not let you understand how this person will then cope with the real tasks on a real project (but I don’t say you don’t have to ask, you can, but this should not be the basis of the interview).
For example, take the
Vkontakte application
for android (it is big, complex and familiar to many).
Once again , I propose to discuss the implementation of a project that has already been launched, is working and has a lot to talk about. Do not just abstract about OOP canons and knight’s competent architecture in a vacuum, but take a specific application / web service / substitute_ and discuss aspects of its design and implementation that interest you. Hope you caught that thought.
You will see that the conclusions I will draw after each section “What we will talk about” are universal and suitable for many areas of software development (you can always adapt everything to your sphere).
And how to conduct such an interview?
I would open the application / website / etc on the device (not to discuss everything abstractly) and, in fact, would start the conversation: “Imagine that you need to implement such an application, let's discuss how you would do it?” And went on the questions. Open some screen and ask: "how would you do ..."
What are we going to talk about?
(Development under android is just an example)
1. Architectural moments
- How do we organize trips to the network? (service or async, or both? Maybe your thread pool)
- How do we make a database (ORM, clean sql, how are we going to solve multi-threaded problems by the way? Or maybe NoSQL can be shoved at all ??)
- What about data caching? (what is possible on the files, and what's in the database, what is invalid, limiting the cache size)
- How to implement the level of api? (it’s just about what approaches will be applied, say all server response models inherit basic, network error handling, error handling from api)
Great attention should be paid to this issue, since things like server api implementation are then used throughout the project, so it should be simple, yet ready for future improvements / changes (KISS in general) - Immediately talk about serious libraries that the developer wants to drag into the project (about serious ones, I mean those that are tightly tied hands in the future, for example, Robospice, ActionBarSherlock (I'm aware of ActionBarCompat), AndroidAnnotations, etc)
After these questions, you will understand what projects this developer has done and what role he has played in them, what experience in the design of applications behind him.2. Specificity of the platform
- Fragments! (you do everything on them, and why? where and how you would use it, you can open NavigationDrawer on Vkontakte and ask how the top-level navigation in the application works, why it was made like this and so on)
- The life cycle of components android applications (task, activity, fragment, service)
- Approaches to organizing responsive-ui applications (layout, theme styles, animations, dp, sp, how they work, how to type them)
- Important differences between API level <11 and API level> 11
After these questions, you will understand the level of skills to develop for a particular platform (in this case - android)3. General literacy in programming and development (many have such a mess in their heads about this topic ...)
- Data types (where and what would he apply in the application? How to keep in memory the list of news, list of contacts, knowledge of implementations and contracts List, Map, Set, understanding where to use what structure, complexity of operations
- Algorithms (knowledge of the complexity of basic sorting algorithms, for example, a list of contacts can be sorted according to different criteria? Other vacancy-specific algorithms)
- Architecture
from arthur : OOP (inheritance, encapsulation, polymorphism, abstraction, why these things and how they are interconnected?), (Patterns, why they, if there are previous 4 pieces? What knows? And what can? Attitude to them), for the sake of interest OP (that knows, can tried, in what an essence)
After these questions, you will find out how strong the candidate is in working out, as in science, practical knowledge is excellent, but without a theory he cannot “create his own”, but only copy someone else’s, while, as a rule, worsening the implementation.4. Assessment 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 that from half a year the full time of work of all team members, subjectivity, depends on the skills, of course, but will let you 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 development organization.That's all. Important notes and author's IMHO
This
approach is NOT suitable for companies in which the recruitment of personnel is put on stream and for every interview a hard 15-20 minutes of time.
But it may well be suitable for a small team of professionals who needed an extra professional person.+ With this approach to the interview, you can accidentally miss an amateur talker, who will eventually finish your project, because in words, he is Leo Tolstoy, but in practice ... So, whatever it was, I suggest giving test tasks (now 99% will say that this is complete garbage, time is needed and all that.
BUT this is the only normal way , apart from Open Source projects, check the quality of the code issued by the developer, his attitude to the terms 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 is immediately clear what the spaces are for the candidate (and perhaps also for the interviewer), and the candidate knows what skill is required of him, what he knows, what he does not know. Fine after all.
The most epic when you pored on an interview for 2 hours answering a ton of questions from SQL to Java and C, and then a week later you are told that you are like nothing, but we will not take you. And you sit and think, in what I nakosyachil?I do not say “you are doing everything wrong”, I offer an alternative / addition for current approaches and I would like to hear your opinion, I hope you have not wasted your time and learned 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 have seen a lot of programmers with 3+, 5+, 10+ experience and have even seen 15+, but they never learned to program, what they give at the exit is such a poop that I want to throw away, 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 the work experience in the column: “it doesn’t matter if you’ve programmed well” or “from the year” and don’t sift out candidates by this topic.PPS suddenly, but I myself have not yet conducted interviews (I have done enough), but I think I will soon, and try to do something like that. So here, he did not try, but I advise you. Criticism is welcomed, although I am 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 addition 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 answers of the candidate