iOS projects are increasingly complex while development teams also keep getting bigger. On-boarding junior engineers onto such teams is a real challenge. In this talk I want to share with you the process we put in place at my company, along with some best practices we learned on the way.

1. On-Boarding New Engineers:
Best prac*ces & lessons learned
Vincent Pradeilles (@v_pradeilles) – equensWorldline
!

2. Why?
2

3. Why do I care
about on-boarding?
3

4. I'm part of the Mobile Team in
Lyon
4

5. Our main project is the iOS
apps for the French bank
[redacted].
5

6. This project is built arround a
fairly complex architecture.
6

7. At the same )me, our client
has an ambi%ous roadmap.
7

8. So we o&en need to bring
new engineers to the team, in
order to meet the deadlines.
8

9. This situa)on has been a real
challenge
9

10. To tackle it, we chose to
invest in a realiable on-
boarding process aimed
towards our new recruits.
10

11. Why should you care
about on-boarding?
11

12. I don't think that we are the
only team that faces such
challenges
!
12

13. At Worldline, our projects
require that we operate
increasingly complex
technical stacks.
13

14. At the same )me, our
recruitment effort focuses on
young graduates, that have a
limited experience.
14

15. 15

16. If we want them to smoothly
and produc4vely find their
place within our organisa4on,
we need an appropriate on-
boarding process.
16

17. On-boarding?
17

18. On-boarding is the process to
make someone reliably
independent within an
organisa7on.
18

19. This organisa+on can be a
team, a project, a client
por5olio, etc.
19

20. On-boarding is both a
technical and managerial
process.
20

21. In this talk, I'll focus mainly on
the technical side.
21

22. But it doesn't mean that the
other side should be ignored
!
22

23. What's inside our process?
23

24. Basically, we begin by asking
our new recruit to code a
mobile app that displays
weather data.
24

25. 25

26. This gives us the opportunity
to progressively introduce our
technical stack.
26

27. The app is meant to be
wri0en incrementaly.
27

28. Star%ng with a UI that displays
hardcoded data...
28

29. ...then moving on to decoding
sta0c JSON files...
29

30. ...to performing API calls, etc.
30

31. The goal of this approach is to
avoid a technical
overwhelming
!
31

32. Instead focusing on the value
value each individual layer of
the stack brings to the whole.
32

33. How is it executed?
33

34. The whole process typically
lasts between 2 to 4 weeks,
depending on how
experienced our recruit is.
34

35. This training period is
definitely an investment, but
one that will pay dividends.
35

36. We have a training plan that is
available on an internal
GitLab repository.
36

37. 37

38. On their first day, we hand out
a printed copy to our recruits.
38

39. It helps communicate clearly
what is expected of them.
39

40. We also assign a mentor, that
will oversee the training
period.
40

41. On a daily basis (idealy on the
morning), we schedule
mee(ngs between mentor
and mentee.
41

42. Those mee(ngs are meant to
review progress and set
realis.c goals for the day.
42

43. In order to be efficient, those
mee.ngs are 'meboxed.
43

44. At the beginning, they last a
1/2 hour, then their dura2on
decreases as weeks go by.
44

45. They are a great *me to
discuss difficul)es
!
45

46. But also to explicitely point
out what was successfully
achieved
!
46

47. Once the trainning plan has
been completed, it's 2me to
be a part of a real project!
47

48. How do we deal with the
arrival on a real projet?
48

49. To facilitate things, it's a good
idea to also assign a mentor
for the first months.
49

50. (This second mentor can be
different than the first one)
50

51. His/Her role will be to help
introducing the project's
structure, processes, etc.
51

52. He/She'll also be able to give
feedback to the management
on how things are going.
52

53. The leap from junior
to seasoned engineer
53

54. A"er a few successful months
on the project, it's 4me to
grow!
54

55. The engineer has acquired
skills and proficiency, he/
she's not really a junior
anymore.
55

56. It's the perfect ,me to
indtrocue a stretch project.
56

57. It's a task that requires more
autonomy than before and
has a rela4vely high visibility.
57

58. It can be a refactoring task, a
new challenging feature, etc.
58

59. It's an opportunity for the
engineer to move on to a
more senior role.
59

60. And it's also natural
conclusion to the on-boarding
process.
60

61. That's it
61

62. (Not really )
62

63. Recap
63

64. Recap
What makes a good technical on-boarding process?
64

65. Recap
What makes a good technical on-boarding process?
• A well-defined training plan
64

66. Recap
What makes a good technical on-boarding process?
• A well-defined training plan
• Realis3c and incremental goals
64

67. Recap
What makes a good technical on-boarding process?
• A well-defined training plan
• Realis3c and incremental goals
• Daily 1-o-1's to discuss progress and difficul3es
64

68. Recap
What makes a good technical on-boarding process?
• A well-defined training plan
• Realis3c and incremental goals
• Daily 1-o-1's to discuss progress and difficul3es
• Steps to evolve from junior to seasoned engineer
64

69. What are the best prac,ces?
65

70. ⚠
Word of advice
66

71. Taken individually, the
following best prac5ces all
sound kind of obvious.
67

72. However, ge*ng all of them
right turns out to be pre3y
tricky
!
68

73. # 1
69

74. On boarding is a rela%onship:
it’s best to assign a single
mentor for the whole process.
70

75. When several mentors are
involved, it can get confusing
for the mentee.
71

76. # 2
72

77. The training period is a good
%me to make mistakes,
becomes they won't carry any
real consequences.
73

78. A possible side-effect of
having a wri7en curriculum, is
that people might feel that
perfect results are expected.
74

79. It's important to make it clear
to the mentee that mistakes
won't be held nega2vely
against them.
75

80. On the opposite, the ability to
understand and learn from
mistakes is a valuable
mindset.
76

81. # 3
77

82. The same way, it's also
important to encourage
autonomy.
78

83. Some mentees might stay
blocked on problems, because
they are not sure of how they
should be approached.
79

84. It's useful to point out that
a"empts to solve a problem
will be valued, even if they
don't end up in success.
80

85. # 4
81

86. Cri$cal thinking is important.
82

87. A technical stack is the result
of choices made in the
context of a given project.
83

88. They are by no means an
absolute truth!
84

89. It's important to point out
what alterna've approaches
might look like.
85

90. A great trick is to provide links
to conference talks that
discuss those alterna4ves.
86

91. # 5
87

92. Knowing the difference
between facts, best prac3ces
and opinions.
88

93. Facts are demonstrable, they
can be scien/fically proven.
89

94. You're code doesn't build,
that's a fact.
90

95. You can't disagree with it and
s/ll be right.
91

96. Best prac*ces are relevant
choices given a par*cular
context.
92

97. Project X chose framework Y
because of constraint Z.
93

98. Opinions are personnal
preferences, based on
experience and/or biais.
94

99. I prefer thiw way of doing
things.
95

100. Communica)ng clearly in
which of those categories a
piece of informa)on lies is
extremely helpful.
96

101. This &me it's really over
97

102. Ques%ons?
98

103. Contact
Twi$er: @v_pradeilles
99