Greetings to all of you, my dear readers!
Today, I want to share my thoughts on a long-standing issue and perhaps discuss it in the comments.
I frequently come across articles discussing poor interview practices for programmer positions, which I believe are quite relevant and, hopefully, readable by HR departments of both large and small companies.
In our areas, as far as I can tell, there is a demand for interesting entities such as DevOps engineers. I belong to those who do not quite grasp this phrase (yes, yes, DevOps methodology, etc.), so I see some differences in the career paths of this group of specialists.
First and foremost, I firmly believe that everyone has their own circle of interests, even in the workplace; for some, it's cloud computing, for others, deeply exploring Application servers, configuring Java, or, heaven forbid, writing YAML code. Hence, we have so-called Infrastructure engineers, Build engineers, Senior YAML Developers 🙂.
All this allows, on one hand, to find a person who is best suited to your pool of tasks, but on the other hand creates misunderstanding during interviews.
Based on personal experience, having conducted several dozen interviews and participated in various capacities as a respondent, I want to share my view on everything that is happening.
The first and probably my favorite anti-pattern is the desire for someone to do everything, or not being clear on who is needed; we will look at a bunch of candidates and figure it out then. This probably applies to any field, but there are specific nuances here.
As I have noticed, people are more drawn to job postings with the word DevOps than System Administrator, although I believe that at the Senior level, the scope of tasks is drastically different in these two areas.
Any employer who genuinely needs a sysadmin writes DevOps in the job title, listing absolutely everything in the job request, K8S/Java/Gradle/OracleDB, etc., even though the person will essentially deal with supporting the K8S cluster and maintaining the OracleDB stack independently from the team.
So what kind of interaction format is there between Developers and Operations?
It turns out that there is no established process for interacting with the team, and in fact, there is no operations department, so you will have to set up the developers' computers yourself.
This option actually suits some candidates, but let's be honest, this is a Senior System Administrator position, so why not write it that way? What is so shameful about it? Is there really a difference in salary based on job titles? But the company's budget remains the same, and no matter what you name the ship, it will sail according to its budget.
I've even heard that nowadays candidates automate everything quickly and integrate into product development using Python, as if it doesn't matter that Python is the same everywhere. The difference in worldview and approaches is not taken into account.
I usually differentiate between the levels of specialists who come in, and I see specific issues for each of them.
Junior — for me, a Junior DevOps is someone who has reached a medium level in system administration / development. Here, I can nicely differentiate between solid Linux enthusiasts who want to grow in a new field, or developers who want to do good for other developers. Strong individuals, with some debugging skills, log searching, or a portfolio of coded projects.
I've met both system administrators who have tried something and wish to touch on cloud technologies, as well as those who have experimented with front-end and back-end and for some reason found their interest in DevOps processes.
At this level, I am always confused when candidates start throwing around an enormous stack of technologies, Puppet, Ansible — why haven't they tried everything? K8S, K3S — what’s the difference? How many types of databases do you know? Why so few? How does encryption work in Java? Especially those who have come from development, although they are very valuable, there is always work for them in this field.
I am always at a loss when this happens; the first question I want to ask is — why??? The second thought that comes to mind is — is the interviewer themselves ready to answer questions about such a diverse technology stack? Do they really want to hire a junior and pile everything on them?
This often happens in various body shops, where they need to sell someone for a certain project and need to fill resumes with more impressive terms, or the company just does not want to hire anyone, but simply looks at what juniors are out there.
Level Middle
There are several extremes in my opinion. First, it's probably difficult to clearly define what qualifies a person as a middle-level specialist. They are either pushed down to junior or treated like a senior, trying to pay a senior's price for a middle-level role (right, the market decides—nothing personal).
The most surprising thing I've seen is diving deep into coding, grinding with Python, torturing Java GC—more specific issues—or, on the contrary, uncovering gaps in long-forgotten knowledge, running through networks, OS driver types, smirking and maliciously thinking about how someone could forget that. And then, the most interesting part happens!
In my opinion, at the middle level, a specialist develops a circle of interests and a personal perspective on what they want to work on—either becoming a buzzword expert on the latest stack, shoving into a trickster role, or gearing up for terrifying enterprise challenges by delving into code performance.
In my opinion, it's worth asking about the processes the person has worked with, what they found most interesting and what not, and based on that knowledge, building a cluster of questions, definitely mapping them to their stack. Otherwise, after an engaging hour or two discussing OpenShift cluster configuration, hiring someone and placing them in charge of monitoring might not please either party.
Senior Level
Ah, my favorite level.
You have before you a strong specialist who has grown through various projects, a person who already knows what they want and what they don't like as much.
And that's when the show starts:
— deep questions on system administration (see the first anti-pattern)
— deep questions about Linux in general from theory far removed from practical knowledge (the OSI levels is a top question)
— academic questions on coding (because the interviewer doesn't really know the field; they were just asked to interview a strange DevOps candidate)
I'll make a small remark here. Once, in an interview, I was asked to write some piece of code. On a piece of paper. You know how everyone loves that; we write every day; paper is everything.
After completing the task, I received a verdict, after reviewing my notes and solution, that the algorithm would be suboptimal. I suggested that the interviewer write their own algorithm, to which I received the response, 'That is not part of the interview.' I asked for a moment, tweaked the code a bit, and showed it, asking whether this would be faster or slower. The response I got was to move on to the next question. The difference was in how the code worked in a loop versus without one, and I had prepared an explanation of why one approach was better than the other. After that, I was no longer interested in answering questions or working with this person.
It should be noted that we are all different, and any small detail that seems insignificant to you may discourage the candidate.
— Typically, specialists at the Senior level have a clearly defined tech stack, but instead, we start delving into related technologies. For instance, you have Ansible listed, great, but we use Puppet. We just invited you over so tell us about Puppet. Wonderful! Have you worked with OpenShift? We have K8s, and we don't know the differences, but your experience is irrelevant. Fantastic!
There is also a subclass — I personally take interns with the potential to grow into juniors.
I want everyone to understand that an intern is a being that is not yet fully formed. It terrifies me when interns are pushed to the level of a solid Junior and then, with a satisfied look, are offered an internship (sometimes unpaid, horror!).
Don't do that.
In my opinion, an intern is either a senior-year student or someone who really wants to 'move into IT.'
With students, it's straightforward — get to know what they study at university, what they have done on their own, and see which topics light up their eyes — if they do, ask why specifically DevOps and what they know about it. Feel out the person and understand whether it will be enjoyable to work with them going forward, and if you want to teach this particular person something.
With those who want to 'move into IT,' it's a bit stricter — check how much the person self-learns, what they did before coming to the interview, and a good option is to look at their GitHub, if they have one, the density of commits, and what exercises they have completed. Also ask why they chose DevOps, since frontend can be more fun and intricate, right?
And finally, I want to advise you once again to determine who you really need, and you will immediately find the right person. Identify the needs, look at the expert as a specialist, find their strengths, and successfully utilize them in your work. Be attentive to the interviewee; they have come to you for a conversation, not a competition to see who can trip the other up.
Source: habr.com
