OUTSTAFFING IN BIG TECH: FROM EXPERIENCE TO MENTORSHIP

Integrating a new employee into a Big Tech company is not easy, and it’s not just about outstaffing— even full-time hires spend their first month getting access, submitting requests, and waiting. That’s why contracts are usually signed for at least six months, allowing a couple of months to get familiar with the team and the project.

I didn’t experience any difficulties with team dynamics or hierarchy issues when joining projects. I was always treated like an in-house developer, and initially, my colleagues made allowances for me being new: "Danil doesn’t have access yet, he’s still getting settled." I adapted quickly—I solved my first task on my first project in about a week. Access was granted in a makeshift way—they just sent me a zip archive with the code, but it was enough.

The team had calls that weren’t directly related to my tasks but helped me better understand the project’s direction and overall development. Since I was new, I asked to be added to all possible meetings, even those where my input wasn’t strictly necessary. I didn’t just sit there silently—I asked a lot of questions and suggested solutions for technical problems. Often, I’d hear, "We hadn’t thought about that. Let’s do it this way!" That was a great feeling.

In another company, I had to speak English frequently. It wasn’t too difficult overall, but when setting up HR automation and working with third-party systems, a challenge arose: the support team of one of the integrated services had many engineers from India. Communicating with them was a unique experience—their English had a strong accent, making comprehension difficult. However, with in-house foreign colleagues, it was much easier, as most communication was text-based.

My advice for developers: don’t be afraid to ask questions, join as many calls as possible to understand the project better, be proactive and suggest solutions, and learn English.

At the start of one project, we miscalculated an estimate, which caused a delay in the release. We were integrating multiple systems, and at first, we thought the process would be straightforward—100% doable in a set number of hours. The client purchased ready-made SaaS solutions. However, during development, we found that documentation was either missing or incomplete. We had to spend time researching and retrieving documentation to understand how the systems worked.

One of the integrations required voice communication with Indian tech support, which added to the challenge. The lack of clear documentation led to a slight overrun in our estimates. Since each task depended on multiple external systems, we had to dive deep into their functionality before forming a clear solution.

This experience taught us to approach estimates more responsibly: first, research key points and documentation and verify whether the required functionality is physically possible within the given system. Because we worked with external systems, if a required feature didn’t exist, we couldn’t simply add it ourselves.

Over time, we learned to create more flexible solutions, anticipating potential client requests like, "Actually, I want this instead." If we already understood the project’s direction and system capabilities, we designed implementations that could be easily modified in the future. This adaptability became a creative part of our work.

One major issue on that project was poor code quality. Since we worked closely with analysts (not developers), best practices were often ignored. For example, in Python, there are established coding conventions, but they weren’t always followed, leading to bloated, complex, and unreadable code.

Architectural decisions were also questionable—not at a global level, but in task-specific implementations. There were multiple ways to solve each problem, yet the simplest, most brute-force approach was often chosen. Variable and function names were sometimes unclear, and certain functions contained so much code that understanding them was nearly impossible without carefully reading every line. Additionally, outdated approaches were used when more elegant solutions were available.

Early on, a lot of time was spent just deciphering the code. A contributing factor was the client’s unique terminology. I received access to their Notion documentation late in the process, but the team was always accommodating—answering questions thoroughly and dedicating time to explanations. There was never an attitude of "just deal with it"; instead, the team was friendly and helpful, which made me enjoy the project and team even more.

As a department head, I conduct weekly one-on-one meetings with outstaff developers to discuss their progress and any needed support. If disputes arise, we listen to both sides and seek a fair resolution.

For example, a backend developer was assigned to a major project but was also given frontend tasks because he had previous frontend experience. While he handled them well, his primary interest was backend development. After discussing the issue, we decided he should speak with his lead and propose focusing mostly on backend tasks, taking on frontend work only when necessary. This conversation resolved the issue, and his workload was adjusted accordingly.

When a client hires an outstaff developer, they have specific requirements. If a candidate doesn’t meet these criteria, they won’t be hired. As for learning on the job, when faced with tasks like migrating a database, we were provided training materials and articles to study the new syntax. Since this was essential for completing the task, it was tracked during work hours.

For broader professional development, Doubletapp invests in its employees: team members attend conferences, enroll in paid courses, and buy technical books; they can dedicate 10% of paid work time to learning; they receive a 50% discount on English courses.

Both we and most of our clients are interested in having skilled, motivated professionals, as we work on long-term projects together.

Preparing for outstaff interviews starts with algorithm practice. Every technical interview includes an algorithmic section, where at least a couple of problems must be solved. We conduct mock interviews, provide algorithmic problem sets, and compensate employees for the time spent practicing.

In web development, specific algorithmic knowledge is practically required in only 2% of cases. But companies use algorithm challenges to test how candidates think, adapt to problems, and whether they have a mathematical mindset.

Another key preparation step is highlighting relevant experience to attract clients. We help developers present their projects in the best possible light by emphasizing complex technical aspects. This makes resumes stand out, increasing interview success rates.

At Doubletapp, our internal grading system often lags one step behind corporate expectations. For example, what we consider mid+ aligns more closely with a senior level in the broader job market. As a result, it's common for a developer classified as mid-level within our company to be placed in an outstaff project at a mid+/senior level. If they successfully pass all interview stages—HR screening, algorithmic challenges, and technical assessments—the client may classify them as a senior developer.

There are cases where grade evaluations differ. For instance, in April 2024, we assigned a frontend developer to a project as a senior, but the client initially classified them as mid+. Four months later, we initiated a grade review, and after gathering feedback, the client confirmed that the developer met senior-level expectations. As a result, they received a promotion, higher responsibilities, and an increased rate.

At Doubletapp, we conduct performance reviews every six months, often leading to grade promotions. While most of our contracts with clients are fixed for a year—including salary and grade—we actively negotiate grade adjustments and compensation increases whenever justified.

Poaching is an inevitable part of outstaffing, and we encounter it regularly. For a company like ours, which invests in its employees, this practice can be frustrating. Some clients are upfront about it—one of them even openly stated their willingness to hire an outstaff specialist in-house. In other cases, developers receive direct offers to switch employers, despite contractual restrictions. Some companies actively target promising professionals, hoping to lure them away.

Our employees sometimes receive such offers but usually decline because they genuinely enjoy working with us. Doubletapp provides a great work environment, a supportive team, and handles everything—from organizing interviews to resolving disputes with clients. This stability and support make staying with us more attractive than switching to an in-house role.

Outstaffing provides unique opportunities that are harder to find in a traditional in-house role. It allows developers to work on multiple large-scale projects with international companies without the hassle of job-hopping.

Typically, when you join a big tech company, you may spend two to three years on the same project. However, in outstaffing, once a contract ends, you can move to another company and start fresh on a new project. This setup is an excellent way to gain insight into how major tech companies operate internally and build connections with top industry professionals.