Employment

When the candidate finally passes the interview and/or internship and when both the company and the candidate reach an agreement on employment, the candidate becomes an employee. However, first comes a trial period of 3 months, during which the candidates are evaluated on whether they are experienced and skilled enough to work on the projects. If that is the case, then they are employed indefinitely.

Engagement Status

Since we as a company work on both client and in-house projects, this section also covers how employees’ engagements are handled and what their possible engagement statuses are, based on clients’ needs and employees’ wishes, needs, skills, knowledge, and experience.

Engaged in Client`s Project

If an employee is already engaged in the client`s project and both sides are happy with the cooperation, there’s nothing to fix then. We might propose another employee as a new team member if the client's up for it. We also do that when the team and/or the client see there’s a lot to do on the project and that it would be beneficial for the project to include more members and split the workload.

Client has Requests

When a client accepts our proposition or initiates a request for a new developer on their own, they usually want to conduct interviews with our potential candidates. These candidates are then being prepared by their leads and mentors for the scheduled interview. Similar to their work during internships, leads and mentors provide guidance, documentation, and tutorials to employees based on client’s needs and requirements. This usually includes workshops, lessons, and simulations.

The candidate then has an interview with the client. Apart from talking to the client, asking and answering questions, the candidate also takes notes of the questions asked, reactions, the tone of conversation and focus points. At the end of the interview, the candidate is encouraged to ask for direct feedback from the client. This is to prevent possible miscommunication and misinterpretation, as well as to capture the client’s initial response and reaction, before the refined and calculated answer is sent back from the client.

The candidate afterwards forwards the client’s questions, the candidate’s answers and feedback from both sides to their assigned lead, who documents this. This documented information can help other potential candidates for the same client in the future, during their preparations. 

Finally, when the client provides his final feedback and choice of the accepted candidates to our company, we document this as well. This result and any additional feedback are also documented as post-mortem[1] . Information like this helps us notice and analyze success rates of candidates, as well as acceptance rates and client expectations.

In-House Projects

Of course, not working on a client's project doesn’t mean that the employee doesn’t have work to do. Depending on their tech stack and whether they’d like to learn new technologies, they can be assigned to existing in-house project teams or tasked to create a new project from scratch. These projects can be focused on research of technology or on creating an app for internal or public use.

Employees would, as usually, have a project manager keep track and help them organize their work, creating roadmaps and such. If there’s a usable version of application, part-time or full-time QA members could help test it. And of course, they would have other supporting developers, , if available.

Past Issues

Over time, we noticed that interviews and internships are not enough to seriously engage an employee ion a project. We wrongly thought that they’ll be able to jump into in-house projects and pick up additional organizational and analytic knowledge along the way. Then a client request would pop up, which they could answer and go for an interview. However, inexperienced and shy employees usually couldn’t pass client interviews several times in a row and they weren’t experienced enough to participate in meetings and refinements on in-house projects.

Common Dangers of Learning On-the-Fly

Split Focus between Learning and Working

While engaged in a project, be it in-house or client, employees often found their focus was split between learning and working. A challenging task could get thrown their way; they would sometimes panic, try the first thing that comes to their mind, and get stuck countless times without changing the approach. Not that different from their internship experience, our leads and mentors would help them of course and tell them to research other approaches. Now they switch back to learning, but they feel guilty that they’re not working on the task but learning for far too long in their opinion. Logging learning hours on the task itself feels wrong, now several hours or days over the estimated time. On client projects, the feeling of guilty increases, because both they and the company are evaluated by the client through their work. 

Onboarding

When joining the project, there’s always an onboarding process and a task created for it, but it always feels like there’s not enough time to capture, learn and understand everything. Additionally, other team members’ time is taken into consideration. Now the onboarding task for one employee has several logs from each member. The employee can sense this, and thus stop asking questions, which is counterproductive for their onboarding process. Again, add the client’s evaluation and things get even more uncomfortable.

Active Mentoring

The onboarding process gets finished, the employee starts getting their first tasks and usually needs additional help and mentoring, which may or may not be available at the given time. Mentors have their tasks to finish as well, which they’ve estimated beforehand, and they may not even be with the employee on the project. The employee is stuck yet again, feeling overwhelmed and helpless.

Knowledge Gathering and Comparison

All these things increase the already difficult knowledge gathering related to domain and architecture. The project might use a tailored approach to organization, reporting and communication. However, the inexperienced employee doesn’t know if those things are done the right way, since they don’t know what is the right way. Therefore, it’s hard to compare anything with their existing knowledge.

Insecurities on Interviews and Projects

Imposter Syndrome

All the previously mentioned dangers usually result in employee’s insecurities in interviews and on projects. They start overly criticizing themselves, questioning their career decisions, constantly doubting their knowledge, skills and abilities. The “imposter syndrome” kicks in and they don’t feel they belong where they are. In interviews they get nervous and stop thinking straight, failing questions related to topics they otherwise know.

Lack of Confidence

Lack of confidence prevents them from asking questions, asking for help and providing suggestions. This results in almost no participation in project meetings, refinements and reviews. In interviews they feel that the question is weirdly put, but don’t ask for additional information, thinking it must be them who don’t know the answer at all. They’d get the task, move it from sprint to sprint without finishing it, before someone with more experience notices that the task itself is not defined correctly. Now they feel they’ve failed the whole team, the client, the company and themselves.

Lack of Experience

Knowing they already lack experience, they start perceiving themselves through the clients’ eyes, valuing the years of experience (or lack thereof, to be exact) more than the knowledge gained. Thus, they show nervousness in the interviews, especially when reading the client’s reaction after answering the questions related to how long the employee has been working[1] . They find that showing their knowledge after that is not easy at all. In project meetings they don’t participate much, fearing that the client and/or the team won’t take the employee seriously or will perceive them as egoistic and a show off.

Lack of Knowledge

Additionally, the lack of knowledge of best practices, implementation standards and conventions, results in code that’s hard to review and maintain. Emotionally interpreting team’s and client’s comments about their code changes lowers their self-value. Not knowing how to handle exceptional cases and analyze previously unknown situations, in addition to their lack of experience, can trigger panic attacks or self-targeted aggressive behavior. This brings them closer to giving up and calling it quits.