Here you can find important information about how Vacuumlabs cooperates with external contractors.
How can you become one? You can help us by providing your stand-by Developers, Designers, Project Managers, Product Owners, etc.
Our house, our rules. Please take the time to understand and practice our Values while we work together. We need to build a personal relationship in order to trust each other and then do business together based on that trust. These are “standard partnership prerequisites” and you can apply them to any relationship. However, we at Vacuumlabs do have a few special requirements:
We require the presence of Vacuumlabs on the project in every case. This might happen in various combinations – from having one external developer augmenting the Vacuumlabs team, to having more developers within a Vacuumlabs team, all the way to having an external team led by a Vacuumlabs PM (an unusual, but possible, scenario).
To ensure the quality of delivery for our clients at all times, all developers, including external ones, need to pass our specific interview process. You can find more information about our interview process in the next section.
Our business is changing rapidly, therefore we sometimes do have ad-hoc requests or changes within our collaborations. For example, the project we interviewed a candidate for is no longer available. We do our best to mitigate these cases, but we cannot guarantee that no changes will occur.
We work as one Vacuumlabs team in the eyes of the client. Therefore, your developers will receive access to our Slack (for communication), JIRA (for tracking of billable hours) and some additional tools used at Vacuumlabs. Don’t worry, the developers will receive a brief onboarding to these tools.
Honesty is the basis of all good relationships and therefore we want to be completely honest with you from the beginning.
We do have a specific setup within Vacuumlabs Externals cooperation: our [Vacuumlabs] External Partnerships team does not share any information with our Recruitment team. Therefore, the External Partnerships team will not guide the Recruitment team to start “hunting” for your developers, which we would consider highly unethical. On the other hand, the External Partnerships team will not prevent our Recruitment team from talking to your developers. This is due to the fact that we do not include a “no-hire policy” in our External contracts. We did so in the past, but it caused a lot of internal overhead for very little benefit. For the past year, we had only one occurrence of our Recruitment team coincidentally approaching an External contractor to discuss direct cooperation.
As our Recruitment team has their own way of approaching candidates – searching through a lot of attributes, such as education, experience, interests and extra-curricular activities – we as the External Partnership team do not want to interfere with their process. We approach these cases individually and more on a relationship than a contractual basis.
To ensure quality delivery for our clients at all times, all of the developers need to pass our interview process.
At Vacuumlabs we are looking for smart engineers with a passion to learn and explore new skills and technologies. The knowledge of any particular language or technology is not required during the interview process.
Our business is changing rapidly, therefore we sometimes do have ad-hoc requests or changes within our collaborations. For example, the project we interviewed a candidate for is no longer available. We do our best to mitigate these cases, but we cannot guarantee that no changes will occur.
The problems the candidate will face require critical thinking skills. Each candidate will be expected to reason their code’s correctness and efficiency even without running it. To stress the focus on thinking, the on-site interviews are conducted on a whiteboard.
The candidate will be writing a real, executable program at every round of the interview. As we are not testing knowledge of any particular technology, the choice of language is theirs. It is necessary to have knowledge of reading and writing test files as well as a familiarity with basic data structures and algorithms.
Even though it might look like a pure coding challenge, interviewers are interested in more than that. Areas they observe include:
TIP
The first round is done via our online testing application. The time limit for this round is 3 hours.
The candidate will be presented with a coding challenge. The aim is to download a large input text file for which the written program has to produce a correct output file. There are unlimited submissions and the system will respond with immediate feedback on whether the solution is correct or not.
There is no need to overengineer the solution — the only criteria is to produce a correct output file. The program’s efficiency won’t be judged this time.
TIP
During this round, the candidate meets with the interviewer at one of our offices or via video call if the former is not possible. This round should take 2 hours, but we usually allocate an extra 30 minutes in case the meeting takes a bit longer.
Coding challenges are the main focus of this round. These are harder than the first round, but the interviewer is present to provide hints. The coding is done on a whiteboard. We’re not obsessed with 100% correct syntax, so there is no need to remember the whole SDK of the selected ecosystem.
Similar to the previous round, the candidate will solve a coding challenge on a whiteboard. The meeting should take 2 hours, with 30 extra minutes to eliminate time stress.
Part of the interview challenge may include a design problem. The candidate is asked to design an application and explain their reasoning behind the choice of tools, models, processes, and data representation.
Finally, we make time for the candidate’s questions, if any arise during the interview process.
There is quite some controversy about what a good interview should look like. There are people who consider coding on a whiteboard almost insulting.
For many (otherwise skilled and talented) engineers, typing the code on the computer unleashes the worst coding habits they have. Only a few engineers spend enough time thinking.
A typical engineer jumps directly into the coding, even if they’re not sure what exactly they are going to implement. During coding they are focused mainly on whether it compiles, putting accuracy and good design on the back burner. When a flaw is discovered, they tend to patch it —sadly, usually by a semi-random modification to the code which fixes one issue but creates another one.
A whiteboard, on the other hand, influences you in the exact opposite way. All the quick code-producing tools were taken away from you, so the only thing you can do quickly is think. Since coding is hard (and refactoring even harder), this motivates you to stay reasonably high-level and come up with a plan for what you’re going to implement. You start with some high-level drawings or sketches and only then do you transfer them to pseudo-code and finally into code.
Finally, this does not apply only to junior engineers. Some of the best coders do a lot of whiteboarding before they actually start coding. The difference is not that senior engineers do not need whiteboarding, the difference is they understand why they need it.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
By submitting this form you agree to the processing of your personal data according to our Privacy Policy.
By submitting this form you agree to the processing of your personal data according to our Privacy Policy.
Retail Banking
B2B Banking
Fintech and Neobanks
Wealthtech
Product
Engineering
Operations
Ai
Blockchain
Latest Whitepapers
Interested in a specific topic?
Let us know - we are happy to help
Thank you for contacting us! One of our experts will get in touch with you to learn about your business needs.
