|
When we get someone in to do some pair programming we typically don't do a "blank exercise" that they'd be able to do on a whiteboard. Instead, I introduce a bug in our system (typically our frontend website, because that's easy to visualize) and tell them to debug it. The bug can be something simple like flipping the checks on our login page so only invalid credentials are allowed for logging in. I tell them they shouldn't be shy about asking questions, Googling or whatever they need to find the bug. Our codebase is pretty big and it's interesting to see what happens next: Some people get overwhelmed and have no idea where to look. They may spend a huge amount of time just poking around. Some of them start talking about interesting design patterns they learnt about while getting their MCSE while failing to fix the bug. Others clam up. The best developers quickly find (or ask!) the main website project, figure out where the controller is, find an AuthenticationService and fix it. Even more bonus points for those that jump straight to the unit tests and run them to find out what's wrong. It becomes much easier to determine if someone will fit in when you do an exercise like this.
|
# ¿ May 16, 2014 13:50 |
|
|
# ¿ Apr 28, 2024 08:26 |
|
I've made this switch in a fairly small organization. My main advice to you would be to make sure that there's actually enough people to justify your role as a full-time architect. I personally got frustrated by getting lots of requests to design things from management and in the end only the barest of MVPs got implemented due to lack of engineering capacity.
|
# ¿ Oct 22, 2014 13:13 |
|
baquerd posted:just plain failing by missing important things that then blow up in my face.
|
# ¿ Oct 22, 2014 15:28 |
|
Kyth posted:If you're doing it right as a developer, you're going to work in many languages over the decades.
|
# ¿ Feb 29, 2016 10:19 |