UPD: Read the latest information about the 6nomads Talent Review Process here.

We spoke to one of our experts, Eugene Pyatibratov, experienced React developer with a variety of projects under his belt. If you want to know why full-stacks are mostly a myth, how baths help developers, how to not get lost in the programming jungle, and how the 6nomads review and interview process works, read on!

— Eugene, to start, please tell us a bit about yourself and your experience, so that our audience may better understand something about who our experts are.

— I have been programming for 5 years, during 4 of which I've worked remotely. I started as a junior in a company that developed multiplayer games. And now I'm a partner in an international project, I fulfill the role of an architect and lead developer in two teams in different countries.

I present myself as a frontend developer using React, although I could work with Node, mobile development and I have experience with UX/UI.

— There was an interesting line in your profile that you're looking for "long-term, interesting projects". What is an "interesting project" for a developer?

— Technically difficult. Small projects are more likely to be "templates" and those don't really give you an opportunity to grow. If you're constantly working on small projects, you run the risk of falling behind. Technologies change all the time, it's not easy to keep up.However, it doesn't hurt to look at small projects. They could come from big companies that could later offer you a job, if they like your work. I would advise keeping an eye out for these kinds of projects, especially from prospective companies, but be careful, not going for those that need something done last-minute. It's hard to get out of the habit of writing quickly and poorly later on.

Big projects offer the experience of working on a team and working with Github and Gitlab. In a team, you're remain disciplined to write quality code, because you won't be the only one using it.

— You call yourself a front-end developer with full-stack experience. But we've encountered a myriad of rage-filled comments from full-stacks who didn't find the specialization they need in the list of those that we offer. They thought it unfair that we limit them to just front-end and back-end. On our part, that was a fully conscious decision, because in many full-stack's opinions, most of that is quite basic knowledge and skills. Whose side are you on?

— People often think themselves to be better and more experienced than they actually are, that's where all our problems and miscommunications come from and why it's gotten so hard to tell mid-level from senior.

From my experience, I can also say that full-stacks aren't particularly strong in either. Jack-of-all-trades are usually only good at one thing, all their other directions are barely kept up. In interviews, this comes up very quickly. Of course, there are exceptions, but laughably few. It's hard to be at the forefront of trends in multiple places at once.

I've written lots of code on Node, but I know I'm better at React. I have good experience in UI/UX, I've developed apps, websites, but I see all of those as things that strengthen my front-end abilities. My experience in UI/UX allows me to work closer with designers, which can't upset customers, as they often don't know all the ins and outs of the work, they just want to get a final product with their ideas realized. Being skilled in more than one field of work is great, you need to be able to look at a product from different perspectives. If you don't understand what the user needs, you could add something nice that works well but is completely useless. And if you only understand what the user needs, but can't implement it, you won't get far, either.

Companies often contact me because of my experience in different fields because my deep-rooted knowledge of the required processes allows me to see mistakes clearly, which allows for interesting solutions, not just practical ones, which a lot of people like. When assembling a team, I try to find people who have interest and passion, not just those who want money.

— You have 4 years of experience in remote work, what do you value in this type of work?

— My workday goes from 8 am to 10 pm; if I were to spend a few hours a day going to an office and back, a lot of that time would have been wasted.

— In all these years, have you found any tips for optimizing working outside of an office?

— None in particular. I drink 3 cups of coffee per day as breaks, during which I consider solutions to current problems.

If there ever is a problem that I just can't solve, I go and take a bath. The pressure disappears, my brain starts working differently. I've had days where I've had to use this method twice.

— "That's the beauty of remote work" is what everybody is probably thinking at this point.

— Development, remote development even more so, is more of a way of life than a job. I love the feeling of being flooded with energy, inspiration, and motivation that I get when I figure out a solution.

People don't often live in the moment, they just do the work to get money. For me, finding new solutions, looking at problems from different points of view, perfecting my skills — all of these are personal interests.

— Ok, now let's talk about how our review process works and the candidate interview. Tell us how do you evaluate candidates' Github: what do you pay attention to, what are some red flags? In general, what observations can you share after looking 97 profiles and conducting 17 interviews?

— There was one thing that happened really often: a candidate says they're a super awesome specialist, but their Github profile is empty. At this moment, I don't want to lose a good specialist, but I also don't want to let an unqualified person through.

A serious flaw is a comment in code in a language that is not English. English is the standard, if said developer works on a team, most members would be uncomfortable.

Another red flag — too many comments. If I see something like "this changes the state" next to a standard operation in React, that's a sign the person doesn't really know what they're doing, as that is a pretty useless comment to a professional.

I also pay attention to the code's architecture, the person's movement through the code. Some are proud of having 500 lines of code in a single document, but that's not good, this person doesn't care about how neat the code is or how difficult it will be for others to work with it. Everything must be split into logical parts that are easy to test, understand, and assemble.

I also look to see whether the candidate writes in tests. If the repository has a functional test, that means the specialist cares for the code, knows why they're writing it, and how all the components should work.

If the code is full of outdated standards, then the candidate doesn't follow the industry, or the code was written according to a video course, which turned out to be who knows how old. In any case, I would bring this up in an interview.

The bigger the candidate's technological stack (confirmed by their Github), the better I understand them as a specialist. Overall, I try to look at a developer as one whole instead of finding a problem spot and immediately rejecting them. If there are many mistakes in the code, then this person is not yet qualified, but if I can kind of see them in a few places, then those are things that just need to be worked on, especially if we consider that most Github projects are done by developers after work, in their free time.

— That's a nice way of approaching it. What do you usually look at during an interview?

— In the beginning, I always ask the candidate what they consider themselves to be – a junior, a mid-level, or a senior? This helps me understand how accurate their views of themselves are. If they call themselves a senior but then can't answer simple questions, then they could incorrectly understand a task and not finish it in time and don't deserve trust as a specialist.

After a short introduction, I ask about technology. My questions are always different, they are based on the candidate's Github, and are meant to go deep and find that spot where they stop understanding what they're being asked. If I don't find such s spot, then I conclude that the person is a professional with a deep understanding of their area of expertise.

Next — the technical part, two tasks. This is what gets me to my final decision.

The biggest problem is that the majority think of themselves way more than they should. If a person has many years of experience and is confident they can master any technology, they think they can confidently write down that they know React after learning it for a few months. Yes, they will get there after a while, but the details will be a huge problem — Devil's in the details.

Most developers have all their projects done under NDA's, and this problem could be easily solved with a technical task, but not many sought-after specialists would bother, they just don't need it — they're spoiled while in demand. Experienced specialists know that as soon as they leave their job they will be offered 5-6 new ones.

— What would you advise people to learn today? What technologies will be, or already are, in-demand?

— I would advise mobile development. And presenting yourself as either frontend or backend, but having experience in both areas. This is the only way to be a quality backend or frontend developer — no one needs a Jack-of-all-trades.

Developers need to know that we are a resource, like apples at a market. We need to study technologies to make ourselves shiny and attractive to the client, but also functional and useful. Also, it's important not to spread yourself out too much, don't just do everything, heading into the jungle. Be a specialist, otherwise, it's hard to grow into a qualified professional.

I'm sure that the developers who will always be one leap ahead of everyone else will be those who are truly passionate about their field, because it changes every day and it's crucial to stay on top of it all. It's also why you need to keep your own projects in mind. For example, my team and I are developing a mobile game right now. There, I am the lead and the architect. Specialists who want to join us kind of find their own way to us. In the future, it could morph into a whole studio.