Doesn't it seem strange to you that when you are going to change jobs and the need arises for an interview, the first thing you think is "you need to prepare for the interview." Solve problems on HackerRank, read Crack the coding interview, memorize how ArrayList works and how it differs from LinkedList. Oh yes, sorting might be asked, and it would obviously be unprofessional to say that quick sort is likely to be the best choice.
But wait, you are programming 8 hours a day, solving interesting and non-trivial tasks, and at a new job you will do the same plus or minus. But nevertheless, in order to pass the interview, you need to somehow prepare additionally, not even hone your daily skills, but learn what you didn’t need either at your current job or are unlikely to need at the next one. To your objections that computer science is in our blood, and wake us up in the middle of the night, we are obliged to write with our eyes closed on a pillowcase walking around a tree in width without even regaining consciousness, I will answer that if I get a job in a circus, and my main the trick will be just that - then perhaps yes, I agree. This skill needs to be tested.
But why test skills that are irrelevant to the current job? Just because it has become fashionable? Because Google does this? Or because your future team leader had to learn all the sorting methods before passing the interview, and now he believes that “every good programmer must know by heart the implementation of finding a palindrome in a string.”
Duck, you are not Google (s). What Google can afford, ordinary companies cannot. Google, having analyzed the data of its employees, came to the conclusion that it is specifically for him, specifically for his tasks, that engineers with an Olympiad past are good at dealing with them. What's more, in building the selection process, they can afford to run the risk of not hiring a few good engineers because they can't crack math problems so easily. But this is not a problem for them, there are many people who want to work at Google, the position will be closed.
Now let's look out the window, and if there are still engineers who want to work for you in front of your office who have not set up a tent camp, and your developers are more likely to look on stackoverflow for what next Spring annotation should be put, and not the subtleties of ranking algorithms, then, apparently, it's time for you to think about whether to copy Google.
Well, if this time Google failed and did not give an answer, what to do? Check exactly what the developer will do at work. What do you appreciate in developers?
Draw up criteria for who you want to hire and develop tests that test exactly those skills.
ThoughtWorks
What does ThoughtWorks have to do with it? It was here that I found an example of an exemplary interview for myself. Who are ThoughtWorks? In short, this is a High-End consulting company with offices around the world from China, Singapore to the Americas, which has been consulting in the field of development for about 25 years, has its own Science division, headed by Martin Fowler. If you search for a list of 10 must-read books for Software Engineers, then perhaps 2-3 of them will be written by the guys from ThoughtWorks, such as Refactoring By Martin Fowler and Building Microservices: Designing Fine-Grained Systems by Sam Newman or Building Evolutionary Architectures
by Patrick Kua, Rebecca Parsons, Neal Ford.
The company's business is based on providing quite expensive services, but the customer pays for phenomenal quality, which is made up of expertise, internal standards and, of course, people. Therefore, it is vital to hire the right people here.
What are the right people? Of course, to each their own. ThoughtWorks has determined that the most important criteria for their developer business model are:
- Ability to work in pairs. It is ability, not experience or skill. Nobody expects that people who have been practicing Pair programming for 5 years will come. But being receptive to other people's opinions, being able to listen is a necessary skill.
- Ability to write tests, and ideally practice TDD
- Understand SOLID and OOP and be able to apply them.
- Present your opinion. A consultant has to work with the customer's developers, with other consultants, and there is not much benefit if a person knows how to do something well, but is completely unable to convey it to the rest of the team.
Now it is important to assess precisely these skills in the candidate. And here I want to talk about my experience of interviewing at ThoughtWorks. I will say right away that I went to Singapore and passed, but the recruiting process is unified and will not differ much from country to country.
Stage 0. HR
As is often the case, a 20-minute interview with HR. I will not dwell on it, I will only say that I have never met an HR before who could talk for 15 minutes about the development culture in the company, why they use TDD, why pair programming. Usually, HR's droop on this question and say that their process is normal: developers develop, testers test, managers drive.
Stage 1. How good are you at OOP, TDD?
1.5 hours before the start of the interview, they sent me an assignment to make a Mars Rover simulator.
Mars rover missionA squad of robotic rovers are to be landed by NASA on a plateau on Mars. This plateau, which is curiously rectangular, must be navigated by the rovers so that their on-board cameras can get a complete view of the surrounding terrain to send back to Earth. A rover's position and location is represented by a combination of x and y co-ordinates and a letter representing one of the four cardinal compass points. The plateau is divided up into a grid to simplify navigation. An example position might be 0, 0, N, which means the rover is in the bottom left corner and facing North. In order to control a rover, NASA sends a simple string of letters. The possible letters are 'L', 'R' and 'M'. 'L' and 'R' makes the rover spin 90 degrees left or right respectively, without moving from its current spot. 'M' means move forward one grid point, and maintain the same heading.
Assume that the square directly North from (x, y) is (x, y+1).
INPUT:
The first line of input is the upper-right coordinates of the plateau, the lower-left coordinates are assumed to be 0,0.
The rest of the input is information pertaining to the rovers that have been deployed. Each rover has two lines of input. The first line gives the rover's position, and the second line is a series of instructions telling the rover how to explore the plateau. The position is made up of two integers and a letter separated by spaces, corresponding to the x and y co-ordinates and the rover's orientation.
Each rover will be finished sequentially, which means that the second rover won't start to move until the first one has finished moving.
OUTPUT:
The output for each rover should be its final co-ordinates and heading.
NOTES:
Simply implement the requirements above and prove a vacuum cleaner works by writing unit tests for it.
Creating any form of user interface is out of scope.
Solving the problem by following a TDD (Test Driven Development) approach will be preferred.
In the short time available, we are more concerned about quality than completeness.
*I can't post the task that was sent to me, it's an old task that was given a few years ago. But believe me, basically everything remains the same.
Separately, I would like to draw attention to the evaluation criteria. How many times have you had to deal with a situation where things that are important for a candidate are completely unimportant when checking and vice versa. Not everyone thinks the way you do, but many can accept and follow your values if they are clearly stated. So, from the evaluation criteria it is immediately clear that the most important skills at this stage are
- TDD;
- Ability to use OOP and write maintainable code;
- pair programming skills
So, I was warned to spend those 1.5 hours thinking about how I was going to do the task, not writing code. Let's write the code together.
When we phoned, the guys briefly told who they were and what they did and offered to start development.
During the entire interview, I never once had the feeling that I was in an interview. There is a feeling that you are developing code in a team. If you get stuck somewhere, they help, advise, discuss, even argue among themselves how best to do it. At the interview, I forgot how to check in JUnit 5 that a method throws an Exception - they offered to continue writing a test while one of them googled how to do it.
Literally a few hours after the interview, I received constructive feedback - what I liked and what I didn’t. In my case, they've been praised for using the Sealed classes as an alternative to the null object; for writing pseudo-code how I would like to control the rover before writing the code, and thus getting a sketch of the classes, at least those that are involved in the robot API.
Stage 2. Tell us
A week before the interview, I was asked to prepare a presentation on any topic that interests me. The format is simple and familiar: 15 minutes presentation, 15 minutes Q&A.
I chose Clean Architecture by Uncle Bob. Again, I was interviewed by a couple of people. It was my first presentation experience in English, and, perhaps, if I had been in a stressful situation, I would not have coped. But then again, I never felt like I was in an interview. Everything is as usual - I tell, they listen carefully. Even the traditional question and answer session was not like an interview, it was clear that the questions were asked not in order to “sink”, but those that really interested them in my presentation.
A couple of hours after the interview, I received feedback - the presentation was very useful and they really enjoyed listening to it.
Stage 3. Production Quality Code
Warning that this was the last stage of technical interviews, I was asked to bring the code to production-ready state at home, then send the code for review and set up interviews where the requirements for the task would change and the code would require modification. Looking ahead, I can say that the code review is carried out blindly, the reviewers do not know the position that the candidate is applying for, they do not see his CV, they do not even see his name.
Phoned, and again a couple of guys on the other side of the monitor. Everything is like at the first interview: the main thing is not to forget about TDD, tell what you are doing and why. If you haven't practiced TDD before, then I recommend you start doing it immediately, not because it's necessary in companies, but because it makes your life a lot easier, reduces stress if you like. Remember how you had to frantically search for an error with a debugger that is reproduced only through the browser, but you cannot reproduce it with tests? Now imagine that you have to catch such a mistake during the interview - you are provided with a couple of gray hairs. What do we get with TDD? We changed the code and suddenly realized that now the tests are red, but what is the error you can’t understand the first time? Okay, say “Oops” to the interviewers, press Ctrl-Z and start walking in small steps forward. And yes, the ability to develop using TDD, you need to develop in yourself, the ability to go to the goal so that your tests are permanently green, and not red for half a day, because “you have a big refactoring”. This is exactly the same skill as the ability to write maintainable code, or productive code.
So, how well your code responds to changes depends on what design you originally laid down, how simple it is, and how good your tests are.
After the interview, I received feedback a few hours later. At this stage, I realized that I was almost through and there was very little left before the “meeting with Fowler”.
Stage 4. Final. Enough technical questions. We want to know who you are!
To be honest, I was somewhat puzzled by such a statement of the question. How can you understand what kind of person I am in one hour of conversation? And even more so, how can you understand this when I speak a language that is not my own, and, frankly, very lousy and tongue-tied. In previous interviews, it was easier for me personally to tell than to answer questions, and the accent is to blame. At least one of the interviewers was Asian - and their accent, shall we say, is somewhat specific to a European ear. Therefore, I decided to take a proactive approach - prepare a presentation about myself and, at the beginning of the interview, offer to talk about myself with this presentation. If they agree - then at least there will be fewer questions for me if they reject the offer - well, 3 hours of my life spent on a presentation is not such a high price. But what to write in the presentation? Biography - Born there, then, went to school, graduated from the university - but who cares?
If you google a bit about Thoughtworks culture, you can find an article by Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] that describes 3 Pillars: Sustainable Business, Software Excellence, and Social Justice.
Suppose that Software Excellence has already been checked for me. It remains to show Sustainable Business and Social Justice.
Moreover, I decided to focus on the latter.
To begin with, he told why ThoughtWorks - while still at the institute, I read Martin Fowler's blog, hence the love for Clean code.
Projects can also be presented from different angles. He also developed software for medicine, which made life easier for patients, and even, according to rumors, saved one life. He also developed software for banks, also a kind of simplification of life for citizens. Especially if this bank is used by 70% of the country's population. This is not about Sberbank and not even about Russia.
Do you want to know about me? OK. My hobby is photography, one way or another I have been holding a camera in my hands for 10 years, there are photographs that I am not very ashamed to show. Also, at one time, I helped a cat shelter: I photographed cats that needed a permanent home. And with good photos, it is much easier to attach a cat. Probably filmed a hundred cats 🙂
In the end, 80% of my presentation was filled with cats.
Immediately after the presentation, HR wrote to me that he still did not know the results of the interview, but the whole office was already impressed with the cats.
In the end, I waited for feedback - I satisfied everyone as a person.
But HR, during the final conversation, tactfully said that Social Justice is very good and necessary, but not all projects are like that. And he asked if it scared me. In general, I went too far with Social Justice, it happens 🙂
Сonclusion
As a result, I have been working in Singapore for several months at Thoughtworks, I see that here, too, many companies are adopting “interview best practices” from Google, using leaflets and Whiteboard for coding, despite the fact that knowledge is beyond Spring, Symfony, RubyOnRails ( underline as appropriate) is not required in the work. Engineers take a week off before an interview to “prepare”.
In Thoughtworks, in addition to adequate requirements for the candidate, the following principles are at the forefront:
Joy of Interviewing. And for both sides. Indeed, if you want to get the best shots (and who doesn’t?), then an interview is not a market where slaves are selected, but a bride show where both the employer and the candidate evaluate each other. And if a candidate associates pleasant emotions with a company, it is likely that he will choose this particular company.
Multiple interviewers to mitigate bias. At Thoughtworks, pair programming is the de facto standard. And if this practice can be applied in other areas, TW tries to do it. At each stage, the interview is conducted by 2 people. Thus, each person is evaluated by at least 8 people, and TW tries to select interviewers with different backgrounds, different directions (not only techies) and gender.
Ultimately, the hiring decision will be made based on the opinions of at least 8 people, and no one has a decisive vote.
Attribute-based hiring Instead of making a decision based on the “likes and dislikes” of the candidate, a form was developed for each role and for each stage, including the evaluated attributes. At the same time, when assessing, it is highly advised to assess not experience in a particular skill, but the ability to apply it. Thus, if the candidate did not have the opportunity to apply any skills like TDD, but nevertheless he tries to apply it, listens to advice on how to use it correctly, he has every chance to pass the interview.
Education Certificates not required TW does not require a candidate to have a required certification or education in Computer Science. Only skills are evaluated.
This is the first interview I've had with a foreign company that I didn't have to prepare for. After each stage, I did not feel squeezed like a lemon, but on the contrary, I was glad that I could apply the best practices, that people on the other side of the monitor appreciate it, and also apply them every day.
After a few months, I can say that the expectations were fully justified. How is ThoughtWorks different from a regular company? In a normal company you can find good developers and nice people, but in TW their concentration is off the charts.
If you are interested in joining ThoughtWorks, you can view open positions
I also suggest paying attention to interesting vacancies:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Software Engineer: , ,
Senior Data Engineer:
Quality Analyst:
infrastructure: , ,
(I want to honestly warn that the link is referral, if you go to TW, then I will get a nice bonus). Choose the office you like, it doesn't have to be limited to Europe, after all, every 2 years TW will be happy to move you to another country, because. it's part of the ThoughtWorks policy that the culture is spread and averaged out.
Feel free to ask questions in the comments or ask me to recommend you.
If the topic seemed interesting, I will write about how it works at ThoughtWorks and how it is to live in Singapore.
Source: habr.com