Lecture
We talked with IT specialists who interview Senior-level candidates to find out the criteria and requirements for the role. We also asked them about the weak points of today's senior developers.
If you give a senior simple, boring tasks, he will soon start adding variety to the routine"
Andrey Marchev , Development Director , 15 years of experienceA Senior specialist, pardon the tautology, must have mature technical skills and mature soft skills. On the technical side, this means knowing and being able to apply "standard" solutions, understanding why they became standards, where their limits lie and what happens if you don't use them. A "creative solution" sounds nice, but usually brings more problems than benefits. As for soft skills, it is important to be aware of your own emotions, to communicate with other team members and to take responsibility.
I hire people who meet my requirements. In today's reality, it is possible to find them. Yes, sometimes I make the wrong choice. But again, that is my mistake, not a case of everyone around me being bad.
Speaking of general trends, lately (about 6 years) Senior-level candidates have been increasingly afraid of responsibility. Before, people asked how they could grow into a team lead / manager; now they ask who will be their mentor. And such a question from someone who is applying for a Senior or even a tech lead role sounds strange.
If you give a senior simple, boring tasks, he will fairly soon start adding variety to the routine. Although in my practice strange situations with Senior employees are rare. And the more "senior" a person is, the fewer of them there are :) If all employees have the same professional problems, the company clearly has problems with recruiting and management.
One thing I found interesting (though not the company owner) was watching an excellent specialist (and there is not a shade of sarcasm here) sink a project by trying to introduce new technologies into it. Every week, a new one.
Be absolutely honest with the candidate during the interview. If there is no documentation, the code is "in chocolate" only on the surface, and over the next year you will need to keep it from dying, then say so. You will not be able to hide it for long anyway.
Be absolutely honest with yourself when hiring. If you are looking for a Manual QA lead and the person says they want to move into automation, that is hardly a good choice.
A comfortable workplace, a good salary, adequate management and so on are no less important components. Like attracts like. It is foolish to hope that a good specialist will stay long in a team of incompetent schemers.
There is also another option: offer a special "perk" and look for people for whom it is a supreme value. For example, the ability to take a vacation of unlimited length at any time. In this case the hiring process will be difficult and staff turnover extremely low (it will be hard for people to find another company like that).
Has conducted more than a hundred interviews and made offers to 35-45 specialists.
In my view, the Senior level is somewhat more serious than "a bit more experience." It should mean that the specialist mastered the profession technically long ago, operates in business categories and sees problems holistically. A Senior specialist, if he is sure there is a more rational technical way to solve a business task, has the right to convey his vision to management. Adequate management in that case is obliged to listen and discuss the proposal. A Senior, of course, can be wrong, like any other specialist, but his duty is to shape solutions and justify them.
In our realities, it varies. Our situation is distorted by the activity of outsourcing giants, for which a person was for years mainly presented as "a rate at which a specialist can be sold." I worked with product companies and I think that was the primary filter: specialists of that level mostly already know business models and come with matching expectations and an understanding of my expectations as an interviewer.
The other side of the outsourcing coin is that our programming market was raised only by outsourcers. Unfortunately, for about 10 years we almost had no local customers, and so all specialists (myself included) appeared together with customers from "over there." The market was empty and filled quickly, and grades were invented monthly in the fight for every dollar. The eighteen-year-old senior appeared precisely then, and not out of nowhere. Only communication with foreign colleagues cleared our minds: it was not quite clear how, on the other side of Skype, there is a person twice your age, far more talented, with more knowledge and experience, while the senior here is you.
Product companies usually do not have clear development cycles, time estimates are almost always "for yesterday," and the specification is "on napkins." There is often a need to test business ideas at minimal cost in minimal time, so such companies / projects need specialists who can offer quick solutions for various scenarios. A senior is exactly the one who can do this and predict future needs.
In contract development, where there is a formalized technical specification, a clear vertical hierarchy and the possibility to appeal to the classic "that wasn't in the spec, and now everything has to be redone," there is no need for a person who knows the next steps. So they look for a specialist who will "bang out" code according to the architect's plan. And a middle is the ideal option in this case. A senior who has worked successfully in a product company will either be bored in outsourcing and leave, or retrain into an architect. And why the company needs that, and at a high price at that, is not very clear.
I am convinced that an interview for a Senior position should differ from the others. It should take the form of a dialogue "about life." Only discussions of complex situations as close to real ones as possible. A detailed answer from a web senior to the question "How would you design your own CDN for video streaming, and what problems do you see along the way?" will tell you much more than 50 questions like "Where is the error in this 30-line function?". Questions from the candidate to the potential employer are also important. It is in these moments that it becomes clear what the candidate lives by and what he expects from you.
In working with seniors, I think I was lucky. Most specialists stayed for a long time, and everything was within expectations. There were isolated situations that caused bewilderment. For example, one guy, a great specialist, disappeared from view once a month. He did not answer calls, did not come to the office, and when he reappeared, he told amazing stories straight out of school folklore about a trolleybus and how he helped grandmothers cross the road. After the third similar episode we parted ways.
I also remember a situation when a guy came to a Senior interview whose profession, it seemed, was welder. Without warning, he just walked into the office with the words: "I'm talented, and is the salary really that much? What do I need to do?" Since there were 3-4 interviews that day, I missed the moment that the guy had not been scheduled for one. The dialogue turned out to be amusing, and I remembered precisely his interview. There was also a meeting where the candidate said he would tell about himself only after we agreed on the final salary. Supposedly, everything was clear to him, so why drag it out, and if not, he would go to another company. I had to tell him he had better go to another company.
And one candidate was very worried about the number of days off. Since all the companies I worked with always followed the state calendar, this seemed strange to me, so the interview ended quickly.
Our seniors quickly "catch a star." At the same time, compared with foreign colleagues, their qualifications are mediocre, they lack experience, cannot plan and do not see problems holistically. In my view, 75% of our seniors in web programming are actually upper-middle. This is happening against the background of a certain rethinking of levels: today, for a business, a talented middle with a spark in the eyes can be significantly more valuable than a senior who has already sniffed some easy money and divides work into what is worthy of him and what is unworthy. I have repeatedly encountered the position "I'm a senior, carry me on your hands."
I think, first, companies should find out whether they really need seniors and why. If the answer is yes, in my opinion, three things can retain a senior with 15-20 years of experience today:
I believe the money factor takes a back seat here. Any senior freelancing will outbid almost any company offer, but will get almost zero "stability."
From candidates I expect a high level of mastery of programming fundamentals: variables, functions, conditions, loops, classes, methods. Also the skill of reusing code on practical tasks.
In our realities, small companies (up to 75 people) often practice an informal approach to hiring programmers: an employee conducts the interview and asks a question without having criteria for evaluating the correct answers. Often the interview is limited to a friendly conversation.
For example, questions like "What do you think about technology ....? How would you solve the problem of heavy server load? What was your biggest achievement at your previous job?" do not have enough context to form criteria for a correct answer. This way you can evaluate the candidate as a person, but not his professional level.
Another feature of interviews, as a rule in large companies, is that the interviewer is either not interested in hiring the candidate (perhaps he will work in another department) or, on the contrary, is too interested, when the work is urgent or there is a hiring plan that must be fulfilled.
In both cases the success of the interview depends on the mood of the person conducting it, and little on the candidate himself.
Examples of good interview questions are in the format of algorithmic tasks. For example, "You need to design a relational database for a social network in which users can add each other as friends. What tables and columns will you create for this?".
One of my main requirements for a candidate is the ability to solve a task of any level of complexity in line with the position held. A Senior Developer must perform Junior, Middle and Senior level tasks well. Candidates who claim the title of senior often fail on elementary tasks that any student can do.
Another absolutely terrible aspect is a Senior candidate's unwillingness to devote enough time and effort to the interview. The person does not understand that within a couple of hours it is decided how and where he will spend a quarter of his time over the next several years. When I decide to hire a specialist, I mentally pull a suitcase with 50k-100k dollars from under the table and give it to the candidate. That is roughly what a Senior costs the company, counting all expenses. And despite this, the candidate is not ready to set aside a couple of hours of his time. It is disappointing to see such an attitude.
Interview mishaps happen constantly. There are candidates who first inflate themselves to the Senior position, even though they know for certain that they fall short of it. Such a person will put off the moment of practical tasks until the last and try to keep the friendly-conversation mode, in which nobody owes anybody anything.
Another group of candidates is overconfident. They readily start any task. If they cannot solve it, they confidently prove that it is impossible or that their solution is correct and the best. This seems especially pointless given that I have seen at least a hundred candidates do this task and know all its details.
Sometimes specialists work in "inadequate" companies, and this shapes their weaknesses. In this context, an adequate company is one whose actions are aimed at making a profit. Unfortunately, many now exist to please the vanity of their management. Their salaries and staff are, as a rule, inflated, and their technical solutions resemble shooting sparrows with a cannon.
The situation may be complicated by the fact that the criteria for evaluating programmers in such companies are also inadequate, and less competent people manage more competent ones. A programmer who develops within such a structure learns inadequate principles of work. And when moving to a new place he feels disoriented. Even if the developer has long professional experience, it then takes quite a while to bring him around so that he interprets that experience correctly.
I put the emphasis on professional growth. Our reality is that we have no top-level technology companies, such as Google, GitHub, Shopify and the like. I try to show by my own example that the level we call Senior Developer is far from the limit, and I offer to reach for more together.
There is a model of specialists called T-shaped. It seems it was first described by Valve in its handbook. The point is that a specialist should have deep expertise in one area and know a little about other areas and fields. Deep expertise lets you contribute to the project, and broad horizons let you combine it effectively with other expertise and make communication with the team easier. I think this model aptly describes what a Senior specialist should be. It should be expertise in solving a certain type of problem or building a certain type of solution, and not simply "in applying a technology." For example, "an expert in building mobile business applications" or "an expert in optimizing cloud solutions," and not "a .NET expert." Such specialists have mastered several technologies, tools and approaches, follow the emergence of new ones and pick the right combination for each project. Whereas a "hammer-application specialist" solves all problems with a hammer.
As for personal qualities, I would single out two: the ability to communicate effectively and to solve problems. The first is a critical skill, because nobody can deliver a modern project alone. You will inevitably have to communicate with other specialists, with the customer and possibly with the users of the system. Discuss requirements and solutions, argue for them to others and demonstrate the results of your work. How skillfully you do this determines how much time you spend on communication, how clearly you understand your tasks or the customer understands how hard it was to build a new feature or fix a bug. In my experience, the quality of communication is more important to a project's success than the presence of deep technical skills.
Problem solving is what the client seeks specialists for: so that they come and solve his problem. A Senior specialist is expected to analyze project problems in his area, find solutions and unblock the work of less experienced colleagues.
It is not easy for us to find Senior specialists with such skills, so they are highly valued. Especially those who have both skills. I conditionally call them "starters": these are engineers with whom you can begin new projects. Because what is needed to start? To show the customer that we have expertise and that we can deliver the project. For that you need to talk with him, hear the customer, demonstrate that we understand him, analyze the input information and the problem, and find one or several solutions. It often happens that a company has free people but nobody to start the project, because there is no starter.
In interviews I ask candidates to draw the high-level architecture or design of one of their past projects of their choice, to see how well the person understands how the system is structured as a whole.
Once, a candidate started drawing blocks. I glanced at the resume, and there were 4-7 different projects. And I said: "Tell me, which project did you choose for this task?" And the candidate answered: "It doesn't matter, this is the architecture of any project." This was, of course, not the answer you expect from a Senior engineer. It is rather a manifestation of the "I know how to use a hammer, hand over whatever you have there..." approach.
It seems to me that mostly our engineers pay attention only to technical skills. Either because they think that is all they should do, or because they do not consider other skills important for projects. It must be understood here: a project is something more than a software product, and its success is not the same as a perfectly written program. Therefore it is important not only to be able to write efficient code, but also to gather requirements, identify technical risks, plan and estimate tasks, give demos and presentations, and so on. Improving communication skills would make our work easier and more pleasant and raise our professionalism in the eyes of customers.
The second thing is general maturity, life experience, the ability to accept circumstances and constraints, and various life situations. When, for example, you do business with Polish, Swedish or American colleagues, you always feel that you are working with adults who came to do a job. For example, something in the project is not ideal: part of the technical solution, something went wrong in the processes, or the customer's team was disliked. Our developers are used to complaining and waiting for someone to come and do something about it, instead of proposing changes to the project or even initiating and implementing them. "The project is lousy because we plan sprints wrong here" instead of "Next time let's try to plan the sprint not like this, but like this."
Unfortunately, there is no way to guarantee that a sense of responsibility for the project will be present when working with our colleagues. Perhaps because the average age of our specialists is lower. Perhaps because of the sense of security that working in IT gives. So one can relax a little and be capricious, and pile extra work on nanny-managers and HRs. Whatever the reason, I cannot find anything positive in it.
Senior developers are specialists with about 9 years of experience or more, they are over 35, have seen more than one project and lived through several technologies. They have worked with different types of clients and most likely at several companies. I think they value their time and effort and do not want to waste them. Seniors have developed banner blindness, so colorful job descriptions and banners do not work on them. Instead, they will be grateful for short messages that contain only the essence, without any decorations, so they do not have to hunt for that essence.
They are hired to solve problems in specific areas. Therefore a Senior specialist expects to be given an area of responsibility where he can make professional decisions, take risks, make mistakes and enjoy successful solutions. He will count on cooperation with a competent project manager and architect. And he will want open communication with these people and with management: if something needs to be done, say so, do not look for phantom motivators.
I think it is important for such a specialist to understand why something is being done, and he will look for a reason behind each of his tasks. Of course, a senior is pleased when his contribution to the project and the company is seen and valued, and when he is respected.
Has conducted more than 900 interviews. For Senior positions, several hundred. Of these, he hired about a dozen specialists.
In general, the division of developers into levels is quite conditional. For me, the value a specialist brings to the project matters more than a subjective "title." So by Senior I mean an effective and experienced developer.
A Senior in one subject area, when moving to another, may for some time become less effective than a Middle. But thanks to his experience, a "real" senior will master the new field and eventually reach his high productivity. Ideally, a Senior specialist should write code that will be convenient for other developers to maintain and develop in the future.
Equally important are the following (the items are in arbitrary order):
In my experience working with developers from our country and with specialists abroad, engineers with the title Senior can be either good professionals or not so good. Our company does not use the Junior / Middle / Senior grading. But, of course, more effective employees, who bring more value with their work, receive higher pay.
When I meet an engineer from another company, what matters to me is how he understands the project and the level of his authority. I remember joining one company. After the interview, when the question of my grade came up, I said that it made no difference to me whether I was considered Junior or Senior. What matters to me is what I will be working on and what the level of pay will be. And then they took me on as a Senior developer.
During interviews it often happens that a candidate does not show enough competence to claim the level of pay he wants. If I see that the specialist can still be useful to the project (roughly speaking, not quite Senior, but a good Middle or even a Junior) and at the same time is motivated to grow (that is, he could become a Senior in the future), I may offer him a job. But the level of pay depends on his contribution to the project.
Sometimes this suits the candidate, and in the future, as his level of competence rises, his salary grows. Sometimes the candidate does not agree. For example, if at his previous job he earned more than I am ready to offer (a person can be a good specialist in his own field, but my projects need different knowledge and skills). Or the person overestimates his professionalism.
It also happens that I am unable to assess a candidate well. Once I interviewed a great, experienced specialist, but the pay I could offer him was still lower than he expected.
Let me give a few examples.
A significant part of our code is written in C and C++. And it is very surprising when a candidate claims Senior-level pay and at the same time does not know how a for loop or formatted output with printf works. Or cannot explain what a balanced sorted binary tree is, and compare the efficiency of some operations in such a tree with a two-way list.
I also assess a candidate's ability to apply new knowledge to practical tasks. I describe a fictional programming language that contains only 5 commands, and ask the candidate to use it to program the behavior of a microcontroller. Some candidates cannot do it and refuse, saying: "I haven't learned such a language before." Of course they haven't. But in everyday work you have to learn a lot of new things, and if an engineer is unable or afraid to do that, he is definitely not a Senior.
I will speak about those who are still more Senior than not. Our engineers may be more focused on solving a formally stated task than on solving the client's real problem. Of course, it is the responsibility of the customer and the manager + team lead to formulate the essence. But if a Senior engineer focused not only on an individual task but on the product as a whole, that would give a better result. Developers from the West are often stronger at this. Also, some seniors are not ready to work effectively in a team with less experienced specialists and pass on knowledge to them so that the whole team works better.
The level of English among our developers is on average worse than among Israeli, German, French or Scandinavian colleagues. I would not say that it greatly hinders work (for technical communication the level of English of our developers is usually sufficient), but we still have room to grow. In our company we run English courses for employees. We invite teachers to the office, and specialists attend classes twice a week during working hours. And I see how, over time, the quality of communication with foreign colleagues improves significantly.
As for the shortcomings of Senior engineers from the West, I have encountered various situations. For example, an engineer has considerable experience in hardware (HW) development, where his level may truly be Senior. And although he does not understand software (SW) very well, he was put in charge of it. And instead of consulting more experienced SW developers, the person tries to come up with the SW architecture on his own. Or an engineer with the title Senior writes code and does not extract shared large parts into functions, preferring copy-paste instead. He does not know how pointers work in C, cannot formulate a problem in a task tracker and writes "the system broke" without details. Or he has problems with soft skills - he does not show up on time for a scheduled meeting.
A real Senior developer is usually more mature than the mythical "22-year-old Senior." That is why in the company we try to create comfortable working conditions for professionals: flexible working hours, a good work-life balance and sufficiently long vacations, as well as a high level of pay, the opportunity to work as openly as possible and to build something that people around the world actually use.
Has conducted several hundred interviews, about 23% of them with candidates for a Senior position (hired 9).
To determine a specialist's level, you have to look at both soft skills and hard skills. By soft skills I mean communication, the ability to reach consensus, and an understanding of what the product is, that there must be a result at the end, and how to measure it. Usually such a person helps colleagues grow, both technically and in terms of "soft" competencies.
Hard skills are the ability to write code that others easily understand and can change. To see what may become a problem and where, on the contrary, something can be factored out. To think about how a given solution will work and change over time. To be able to learn and transfer principles from one environment to another. Not to be afraid to try doing things the way they are done in the industry where that makes sense (not to be afraid to go against authorities).
Lack of experience with a specific technology is not a problem. It is just a tool that can be figured out. At YouScan, for example, it is important that a Senior understands the final value of the product and asks himself and others questions. Perhaps something is better not done, and something else should be done and measured, or done in a completely different way.
It is also important that the person writes code that will be easy to maintain and change. For me this is especially valuable, because, according to statistics, companies often rewrite 97% of their code entirely.
Overall, there are few so-called product developers in our labor market. IT specialists more often build features than a product. They are tied to common approaches even where the process could be simplified.
The difficulty of working with Seniors is also that a person's specific experience often overlaps only partly with what a particular team needs. So the candidate's value lies precisely in the overall level, and specific technologies are less important, yet candidates often focus their self-development precisely on specific technologies.
Each company has to figure out whether it makes sense to hire seniors at all. Sometimes a strong middle is the best option. Because if he learns quickly, investing in him means making an ideal senior for the team. A senior usually already has a formed view of certain methods and approaches to work, and there is no guarantee he will fit. However, if he suits you, you will do everything to hire and retain this person.
In addition, remember that different companies see the Senior level differently (and this is not only about outsourcing). A common tool for assessing a developer's level is the so-called Engineering Ladders Framework .
If you are only starting to build a system of growth guidelines for your colleagues in your company, I also advise you to look at a selection of how other companies have done it.
There is no universal standard for the Senior level in the IT industry. Each company builds its own criteria of technical knowledge and experience for such a specialist. What is common is that a person reaches this level through achievements and excellent results at work.
As for SoftServe specifically, we have clear frameworks for determining employee levels, which cover both hard skills (level of technical expertise) and soft skills (productivity, responsibility and other qualities). A separate department, the Software Development Office, is responsible for developing and continuously improving them. Among its functions is developing a plan for growing less experienced specialists to the Senior level. Because for a company that aims to build a successful business, it is important to grow its own talent.
For SoftServe, not only technical knowledge plays a large role (although the emphasis is placed on it), but also business competencies (client- or company-oriented). In addition, from our Senior specialists we expect active participation in the life of the professional community: speaking at conferences, running meetups and workshops, and mentoring less experienced colleagues.
Companies often reduce the system of motivating employees to develop professionally exclusively to salary raises. This leads to professional burnout. After all, with such an approach the excitement about something new and unexplored, which lies at the heart of the IT industry, is lost.
An important aspect of retaining seniors in the company is to give people an understanding of how they can grow, and to help them develop the corresponding skills. For them, the next career step is the position of tech lead or team lead, whose task is already managing a team. So the focus needs to be on developing management skills. And then what?
The first scenario is project management. Many seniors become wonderful managers, since they know the technological side of the project and have the skills to work with a team, because they went through it themselves. The second scenario is architecture. Here too the business goals and the client's goals come first, not technology. This does not suit everyone.
I often hear from developers: "Management is not for me. Architecture is interesting, but working with the client and constant communication make me uncomfortable, and I want to explore technology or engineering practices." For them the value lies precisely in generating ideas and implementing them with their own hands. And what accompanies these processes is not exciting. To keep people in the company, it is important to offer challenging technology projects. Otherwise engineers will burn out. At SoftServe we build the career map taking these features into account.
There is a clear list of knowledge and skills a Senior must have. Is the candidate applying for this role? Do they have the skills? Welcome. And it does not matter whether they have one year of experience or ten. Here I recall one candidate with huge potential and motivation. For example, a developer came to us. Within two years he became a senior. Then he chose the architecture track and in another two years became a Solutions Architect. A good example to follow.
Comments