Downloaded 38 times
Uploaded byAlessandro Nadalin
A Rocket Internet experience @ ForumPHP Paris 2013
This document outlines Alessandro Nadalin's experience building a technical team at Rocket Internet. It discusses hiring young candidates and using unconventional interview questions. It describes evolving the architecture over time from a monolithic structure to microservices using a service-oriented architecture. The goal is to make the system more independent, loosely coupled and maintainable. Through delegation, the team was able to release more frequently and focus on training others.
More Related Content
Similar to A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
- 1. A ROCKET INTERNET EXPERIENCE AlessandroNadalin, 22nd November 2013
- 2. AGENDA 1. Context 2. Responsibilities 3.Building the team 4. Get started 5. Mutate 6. Delegate 7. BONUS
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. Automated tests areuseless
- 11.
- 12.
- 13. 3. Building theteam
- 14. You can't makeeveryone you know relocate
- 15. You can't relocateyour company
- 16. How to hirea very good (middle-eastern) team?
- 17.
- 18. They forget aboutthe clock and are usually attracted to new technologies
- 19. Moreover, there isno big bias.
- 20.
- 21. How many PHPindians companies are out there?
- 22. How many ofthem do you know?
- 23.
- 24. Ask for partialovertime
- 25. No one expectseveryone to know about everything, that is why we hire people and train them
- 26. Training has acost that both the employer and the employee have to split
- 27. Means overtime for changinglabels it's useless, of course
- 28. but OT isfine, get over it
- 29. It's a matterof what both parts offer for / in those extra-hours.
- 30.
- 31. Who is FrederickBrooks?
- 32. What is thesecond-system effect?
- 33. What does PEAAmean?
- 34. What is adata mapper?
- 35. Why is itcool?
- 36. Why is OOPbetter than procedural code?
- 37. What happens whenyou hit enter in the browser bar?
- 38.
- 39.
- 40. An interview isalways a good opportunity for learning. Given that you can effectively teach stuff with the pyramid interview...
- 41. ...wear shorts ifyou want.
- 42. ...ask how manycabs are out there if you want.
- 43. If you askweird questions... Putting the candidate in a no-comfort zone will let you know how he or she reacts to variable situations and unknown problems.
- 44. If you wearshorts... Gain authority on the field, not on paper
- 45. If you wearshorts... Gain authority on the field, not on paper Remember people not to be judgemental
- 46. If you wearshorts... Beach after Work!
- 47.
- 48. At the endof it...
- 50.
- 51. "It takes 3months to be effectively productive"
- 52.
- 53. "Because the developerscan't understand the code"
- 54.
- 55.
- 56. Why don't theyunderstand the code?
- 57. "Because the codeis not that domain driven"
- 58. Solution #2 Replace thesoftware
- 59. In the next4 months, we would have replaced our entire architecture with a RoR application and parts of the architecture with NodeJS...
- 60. ...if I wasthat dumb.
- 61.
- 62. Know-how and toolsfor free is something you can't easily drop. Instead of replacing a monolithic approach with another monolithic approach, you split the system in layers and work on each of those layers.
- 63. So, why isn'tthe code domain-driven?
- 64. "Not everyone knowshow decoupled DDD works"
- 65. And that's perfectlyfine.
- 66. Imagine Fabien asyour boss when you were a Rookie?
- 67. We're all bornn00bs
- 68.
- 69.
- 70. Socratic approach Question something Raiseyour thoughts
- 71. Socratic approach Question something Raiseyour thoughts Let them elaborate
- 72. Socratic approach Question something Raiseyour thoughts Let them elaborate Drown together
- 73. Socratic approach Question something Raiseyour thoughts Let them elaborate Drown together Accept evidences
- 74. Socratic approach Question something Raiseyour thoughts Let them elaborate Drown together Accept evidences Ready to move on
- 75.
- 76.
- 77. Do not changepeople because you want things to get better. Change things because you want people to feel better.
- 78. Do not changepeople because you want things to get better. Change things because you want people to feel better.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86. All of thisbesides day-to-day development
- 87. ~3 months: 1deployment a week
- 88. ~6 months: 1deployment a day
- 89. ~9 months: 2/3deployment a week
- 90. ~1 year: ½deployments per week
- 91. ~1.5 years: whenevers**t is ready
- 92. "Instead of replacinga monolithic approach with another monolithic approach, you split the system in layers and work on each of those layers."
- 93.
- 94.
- 95. A software designbased on discrete software components, "services", that collectively provide the functionalities of the larger software application
- 96. You typically startwith the infamous web application which does everything on its own
- 98. Then you realizethat to provide a chat system to your users PHP might not be the best...
- 100. And soon youalso decide, to improve performances, that your frontend should have its own in-memory persistence, to be faster and you put it into another service
- 102.
- 103.
- 105. And eventually, yourlead architect will come up and tell you that your Java-based chat sucks and should be replaced with...
- 106.
- 108. In human-understandable words,SOA is a software design which embraces splitting a monolithic, totalitarian software architecture into smaller pieces, thus making them independent, loosely coupled and more maintainable
- 109. A backend serviceexists...
- 111. ...and a newfrontend pops out
- 113. Another one mightwant to deal with the same data...
- 115. And ask thefirst one to compute some data...
- 117. And once it'sdone, there might be the chance we want to raise an event...
- 119. And monitor ifthere is a problem...
- 121.
- 122. No one isdesigning Web Services for you anymore
- 123.
- 124. Software design iscrucial
- 125. Don’t limit yourselfto develop stuff
- 126.
- 127.
- 128.
- 129. A company of~200
- 130.
- 131.
- 132.
- 133.
- 134.
- 135. More time topair and teach
- 136.
- 137.
- 138.
- 139.
- 140. Alessandro Nadalin @_odino_ Namshi |Rocket Internet
- 141. Alessandro Nadalin @_odino_ Namshi |Rocket Internet VP Technology
- 142. Alessandro Nadalin @_odino_ Namshi |Rocket Internet VP Technology odino.org
- 143. Thanks! Alessandro Nadalin @_odino_ Namshi |Rocket Internet VP Technology odino.org
- 144.
- 145.
- 146.
- 147.
- 148.
- 149.
- 150. Thanks! Alessandro Nadalin @_odino_ Namshi |Rocket Internet VP Technology odino.org