this creates a new division: where we now had 2 types of developer (newcomer vs. core team) we’d have 3. So I guess that the intention is to remove the newcomer level
people in the new level (working on an external project) will be less onboarded than the current newcomers: less access to tools (and to servers), and less knowledge of our handbook and processes. They may not see the real core-team-member experience (including picking tasks, dealing with budget issues, estimating tasks, deploying servers, discussing processes, planning a full sprint, dealing with spill-overs, …). They may see a lighter (and easier) version of OpenCraft. If they pass the test and they like it, they may still not like the real version
time logging requires access to JIRA. Granting access to JIRA gives access to a lot of private information (internal infrastructure, clients, …)
And questions:
after successfully finishing the small project, do they become newcomers for a short time? (onboarded to most systems, but not having core team member responsibilities yet)
My idea would be to replace the screening review process (i.e. the first two weeks of a newcomer) with the process suggested by Braden. After they pass it, they become newcomers. After 6 more weeks (i.e. already 2 months in OpenCraft) there’s a review and they become core team.
The difficult part seems to be finding suitable tasks, with the right budget, access level, timing, difficulty level, …
Yes, but that’s always a risk with any new job. They can read the handbook (and maybe watch some videos?) to get a good idea of how we work, and the trial project will really help too. But if they pass, join the team, and find they don’t like it, they can always quit, as long as they give sufficient notice. The trial period doesn’t really change their options in that regard, just how much onboarding/offboarding is needed.
That’s up for discussion, but I was thinking more of considering them essentially a full team member right away. Some of the responsibilities should be added in after a few weeks to make their onboarding less overwhelming and some accesses should be granted only as-needed for the first few weeks. What you are suggesting sounds very similar to the current process, with many of the same drawbacks.
@jvdm@paulo@raul I see we have some new people starting, but I haven’t heard anything about using this new process. Are they all on the “normal” trial period? Would one of you like to try this out with me for the next hire?
@braden Newcomers that were selected for bebop already got onboarded.
If we want to try this, we need to change our interview script. We mention about 2 months trial period at the end of the interview. So it will be wrong to give them info about 2 months trial and then giving a project instead. It might confuse them.
@braden Thank you for working on this - it would be a much more efficient way to go at this. We just need to make sure we test it, so +1 for trying it for the next hire.
@shimulch@paulo@jvdm Would one of you be willing to take care of a ticket to draft the PR of the change this would make to our recruitment process, with @braden as reviewer? And then keep the PR open while testing to apply it to the next recruit, merging it if we are happy with the results?
Thanks again for the work on this, it’s actions like these that will allow to adjust to the market changes we are facing, and relieve the strain these changes have put on our production line and on the team.
As per @giovannicimolin’s comment here some members actually not familiar with the recruitment process. So here is a summary of the new process.
Stage
Activity
0
We prepare a list of trial projects for a recruitment sprint.
1
Recruitment Managers preselects candidates and invites them for interviews.
2
Recruitment Managers conduct interviews with preselected candidates.
3
Recruitment Manager evaluates the interview and another recruitment manager reviews it.
4
Admin Specialists schedule a 2nd interview with Xavier.
5
If the candidate is accepted in the 2nd interview, contract signing is done. Admin Specialists create an onboarding and offboarding checklist.
6
Recruitment Manager picks a Trial project from the list and assigns it to the candidate. A team member is assigned as the reviewer of that task. The candidate is given limited access to Jira and Mattermost.
7
The whole cell does a review of the trial project and decides whether to accept the candidate or not.
8
If accepted the candidate joins as a core team member. All-access are given and all kind of tasks (except being a reviewer of trial projects) are available to the new member. Except for the dev mailing list.
9
A developer review (full cell) is held after 2 months of onboarding. There is no extension. We check for red flags and try to keep our quality of work with this review. If there is no such issue we add the member to the dev mailing list as well.
ok to try something new.