Doesn't it seem strange that when you're about to change jobs and need to go through an interview, the first thing you think is 'I need to prepare for the interview'? You solve problems on HackerRank, read Crack the Coding Interview, memorize how an ArrayList works and how it's different from a LinkedList. Oh, and they might ask about sorting algorithms, and clearly, it's unprofessional to say that quick sort is likely the best choice.
But wait, you program 8 hours a day, tackle interesting and non-trivial tasks, and you'll be doing roughly the same at your new job. Yet, you still need to prepare for the interview in some way, not just refine your daily skills but also learn things you haven't needed at your current job and probably won't need at your next one. To those who argue that computer science is in our blood, and that if you wake us in the middle of the night, we should be able to write the breadth-first search on a pillow without even being conscious, I respond that if I were to join a circus and my main trick was exactly thatâthen perhaps yes, I agree. This skill needs to be tested.
But why check irrelevant skills for the current job? Just because it's become trendy? Because Google does it? Or because your future team lead had to learn all sorting methods before going through an interview and now thinks that 'every good programmer should know the implementation of finding a palindrome in a string by heart.'
Here's the thing, you're not Google. What Google can afford, ordinary companies cannot. Google, after analyzing its employees' data, concluded that specifically for their tasks, engineers with an Olympiad background perform well. Moreover, in building their selection process, they can afford the risk of not hiring a few good engineers because they canât easily solve mathematical problems. But that's not a problem for them; there are plenty of people wanting to work at Google, and the position will be filled.
Now letâs look out the window, and if there are still engineers in front of your office who want to work for you and your developers are more often looking for another Spring annotation to use on Stack Overflow rather than the nuances of ranking algorithms, then it seems like itâs time to consider whether itâs worth copying Google.
Well, what if Google has let you down this time and didn't provide an answer? You should check exactly what the developer will be doing at work. What do you value in developers?
Set criteria for whom you want to hire and develop tests that specifically assess those skills.
ThoughtWorks
What does ThoughtWorks have to do with this? This is where I found an example of an exemplary interview. Who are ThoughtWorks? In brief, it's a high-end consulting company with offices all over the world from China and Singapore to the Americas, focusing on consultation in the development sphere for about 25 years, with its own science division led by Martin Fowler. If you search for a list of 10 books that are a must-read for Software Engineers, probably 2-3 of them will be written by folks 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 built on providing high-cost services, but the client pays for phenomenal quality, which is derived from expertise, internal standards, and of course, people. Therefore, it is vital here to hire the right people.
So, who are the right people? Of course, itâs different for everyone. ThoughtWorks has determined that for their business model, the most important criteria for developers are:
- The ability to engage in pair programming. It is this ability, not experience or skill. No one expects people to have practiced pair programming for five years. But being receptive to others' opinions and able to listen is an essential skill.
- The ability to write tests, ideally practicing TDD.
- Understanding SOLID and OOP and being able to apply them.
- Presenting oneâs opinion. A consultant has to work with the clientâs developers and other consultants, and there isnât much benefit if someone can do something well but is completely unable to convey this to the other team members.
Now it is important to evaluate these skills in the candidate. Here, I want to share my experience of interviewing at ThoughtWorks. Let me say right away that I interviewed in Singapore and passed, but the recruiting process is standardized and will not differ much from country to country.
Stage 0. HR
As is often the case, a 20-minute interview with HR. I won't dwell on it, just to say that I have never met an HR who could discuss the companyâs development culture for 15 minutes, why they use TDD, and why pair programming. Usually, at this point, HRs lose steam and say their process is normal: developers develop, testers test, and managers manage.
Stage 1. How good are you at OOP and TDD?
An hour and a half before the interview began, I was sent a task to create a Mars Rover simulator.
Mars Rover TaskA 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 coordinates 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â make 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 deployed rovers. 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 coordinates and the roverâs orientation.
Each rover will finish 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 coordinates 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 cannot share the task that was sent to me, it is an old task that was given several years ago. But trust me, the fundamentals remain the same.
It is important to highlight the evaluation criteria. How many times have you encountered situations where things that are important to the candidate are completely irrelevant during the evaluation, and vice versa? Not everyone thinks the same way you do, but many can adopt your values and follow them if clearly articulated. Therefore, from the evaluation criteria, it is immediately clear that the most important skills at this stage are
- TDD;
- The ability to use OOP and write maintainable code;
- pair programming skills
So, I was warned to spend these 1.5 hours thinking about how I am going to tackle the task, rather than writing code. We will write the code together.
When we called, the guys briefly introduced themselves and what they do, and suggested starting the development.
Throughout the interview, I never once felt like I was in a job interview. There is a sense that you are developing code as part of a team. If you get stuck somewhere, they help, advise, discuss, and even debate among themselves on the best way to proceed. During the interview, I forgot how to check in JUnit 5 whether a method throws an Exception â they suggested continuing to write the test while one of them Googled how to do it.
Literally a few hours after the interview, I received constructive feedback â what they liked and what they did not. In my case, I was praised for using Sealed classes as an alternative to object null; for writing pseudocode before writing the actual code on how I would like to control the rover, thus getting a draft of the classes, at least those involved in the robot's 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 for the presentation, 15 minutes for questions.
I chose Clean Architecture by Uncle Bob. I was interviewed by a couple of people again. This was my first experience presenting in English, and honestly, if I had been in a stressful situation, I might not have managed. But again, I never felt like I was at an interview. It was just like usualâI talked, and they listened attentively. Even the traditional Q&A session didnât feel like an interview; it was clear that the questions were asked out of genuine interest in my presentation, not to 'sink' me.
A couple of hours after the interview, I received feedbackâmy presentation was very helpful, and they genuinely enjoyed listening to it.
Stage 3. Production Quality Code
Informing me that this was the last stage of technical interviews, I was asked to bring the code to a production-ready state at home, after which I would submit it for review and schedule interviews where the task requirements would change, necessitating code modifications. To give a sneak peek, I can say that the code review is conducted blind; the reviewers do not know the position the candidate is applying for, do not see their CV, and do not even see their name.
A call, and once again a couple of guys on the other side of the screen. It's just like the first interview: the key is not to forget about TDD, to explain what you're doing and why. If you haven't practiced TDD before, I recommend starting right away, not because it's necessary in companies, but because it significantly simplifies your life, reducing stress levels, if you will. Remember how you used to frantically search for the bug that only reproduces through the browser, and you couldn't replicate it with tests? Now imagine having to catch such a bug during an interviewâyou're guaranteed a couple of gray hairs. So, what does TDD provide us? You've changed the code and unexpectedly realized that now the tests are failing, and you can't figure out what the error is at first glance? Okay, you tell the interviewers, 'Oops,' hit Ctrl-Z, and start moving forward step by step. Yes, developing with TDD is a skill you need to cultivate, the ability to move toward your goal in a way that your tests are permanently green, not red for half a day because 'you have a major refactoring.' It's just as much a skill as writing maintainable code or performant code.
So, how well your code adapts to changes depends on the design you originally laid out, how simple it is, and how good your tests are.
After the interview, I received feedback within a few hours. At this point, I realized that I had nearly passed and only a little was left before meeting with Fowler.
Stage 4. The finale. Enough technical questions. We want to know who you are!
To be honest, I found this line of questioning somewhat perplexing. How can one understand what kind of person I am after just an hour of conversation? And even more so, how can that be understood when Iâm speaking in a foreign language, quite poorly and awkwardly, to be frank? In past interviews, I found it easier to tell my story rather than answer questions, primarily due to my accent. At least one of the interviewers was Asian â and their accent is somewhat distinctive from a European ear. So, I decided to take a proactive approach â to prepare a presentation about myself and suggest sharing it at the beginning of the interview. If they agree, there will be fewer questions for me; if they decline, well, three hours of my life spent on the presentation isnât such a high price. But what should I include in the presentation? A biography â I was born here and there, went to school, graduated from university â who finds that interesting?
If you do a bit of Googling about the culture of Thoughtworks, you can find an article by Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] that outlines the 3 Pillars: Sustainable Business, Software Excellence, and Social Justice.
Letâs assume that my Software Excellence has already been evaluated. Now I need to demonstrate Sustainable Business and Social Justice.
I decided to focus on the latter.
To start with, I explained why ThoughtWorks is important to me â I read Martin Fowler's blog back in college, which sparked my love for Clean Code.
Projects can also be presented from different angles. I developed software for the medical field that simplified life for patients and, according to rumors, even saved a life. I also developed software for banks, which in a way simplifies life for citizens, especially if that bank is used by about 70% of the countryâs population. This isn't about Sberbank or even about Russia.
Want to know more about me? Okay. My hobby is photography; I've been holding a camera for about 10 years and have photos that Iâm not too embarrassed to show. Additionally, for a while, I helped a cat shelter by photographing cats that needed permanent homes. With good pictures, itâs much easier to find a cat a home. I probably photographed around a hundred cats đ.
In the end, 80% of my presentation was filled with cats.
Right after the presentation, I received a message from HR stating they didnât yet know the interview results, but the entire office was already impressed with the cats.
Ultimately, I received feedback â I satisfied everyone as a person.
However, during the final conversation, HR tactfully mentioned that Social Justice is very good and necessary, but not all projects are like that. He asked if that scares me. In short, I may have overdone it a bit with Social Justice; it happens đ
Summary
As a result, I've been working in Singapore at Thoughtworks for a few months now, and I see that many companies here are adopting 'best interview practices' from Google, using little papers and Whiteboards for coding, even though knowledge beyond Spring, Symfony, RubyOnRails (underline as needed) isn't required for the job. Engineers take a week off before interviews to 'prepare.'
At Thoughtworks, in addition to reasonable candidate requirements, the following principles are prioritized:
Joy of Interviewing. Indeed, if you want to attract the best talent (and who doesnât?), the interview process is not a market where slaves are chosen, but rather a showcase where both the employer and the candidate evaluate each other. If the candidate associates pleasant emotions with the company, it is quite likely that they will choose that company.
Multiple interviewers to mitigate bias. At Thoughtworks, pair programming is the de facto standard. If this practice can be applied in other areas, TW strives to do so. At every stage, two people conduct the interview. Thus, each candidate is evaluated by at least 8 people, and TW tries to select interviewers with different backgrounds, various fields (not just tech), and genders.
Ultimately, the hiring decision will be made based on the opinions of at least 8 people, and no one has the right to a decisive vote.
Attribute-based hiring Instead of making a decision based on whether the candidate is liked or not, a form has been developed for each role and for each stage, including the attributes to be evaluated. It is highly advisable to assess not the experience in a specific skill, but the ability to apply it. Thus, if the candidate has not had the opportunity to apply any skills, such as TDD, but nevertheless strives to apply them, listens to advice on proper usage â they have every chance of passing the interview.
Education Certificates not required TW does not require the candidate to have mandatory certificates or education in Computer Science. Only skills are evaluated.
This is the first interview, among those I have attended at foreign companies, for which I did not have to prepare. After each stage, I did not feel drained like a lemon; on the contrary, I was happy to be able to apply best practices, that people on the other side of the monitor value this, and apply them every day as well.
After several months, I can say that expectations were completely met. What sets ThoughtWorks apart from a regular company? In a regular company, you can find good developers and pleasant people, but the concentration of them in TW is off the charts.
If you want to join 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 you that the link is a referral; if you join TW, I will receive a nice bonus). Choose an office you like, you don't have to limit yourself to Europe, after all, every 2 years TW will be happy to relocate you to another country, as it's part of ThoughtWorks' policy, this way the culture spreads and averages out.
Feel free to ask questions in the comments or ask me to recommend you.
If the topic seems interesting, I will write about what it's like to work at ThoughtWorks and how life is in Singapore.
Source: habr.com
