Wiki : interview:teamwork
 
Table of Contents

Teamwork

Teamwork is not only working in a team, developers quite often share much more than simply the work space, they share the same code and the same problems. Would be fair enough if they also shared the same solutions and if they could work together to find them.

In the beginning, there wasn't many good developers around. Whenever you find someone good, it didn't matter if he could work in a team or not or if other people could tolerate him or not, he was good and that was what mattered. It was also a problem for the developer himself, he had to do virtually everything, they were often called heroes and instead of having several teams per project they had several projects per one-hero-teams.

Nowadays, not only the problems are much more complex but companies figured out that this is not a good way to work so today it's more likely to find heroes working on a regular job being bored than actually hacking the universe as they once did. Being a hero was like being a Jedi but it was not good for the companies and no one wants a hero anymore since the Sith Empire had taken the universe.

Heroes now must learn to behave and do teamwork and that's what this section is about. Non-heroes double-must do teamwork as there is nothing worse than newbie that can't cooperate.

Projects

  1. Your boss have a new project and you're the best match to do it but you already have work for months now. What do you do?
  2. A new company-wise project is created and you'll have to work with non-technicians, often stopping your technical work to explain them what's going on and keeping an eye on technical things they might be doing wrong. How would you feel about it?

Colleagues

  1. You're writing a core library that most teams use it. A colleague you don't like too much (maybe because he's a show-off newbie) needs to use part of it and will assist you with your code to better match their needs. How would you tackle the interaction and how much credit will you give in his oppinions when changing your code?
  2. A colleague in your team is dodgy and most of the time pretend to be busy all the time. That doesn't affect you very much, would you tell your boss? And what if it did affect you?

DIY

  1. You need some libraries from a team that is as responsive as an anechoic chamber and your boss is pissing you off to finish this project by Friday. Would you escalate and blame on the lib team or develop the required functions yourself? Can you think of another solution? Could you have done it better in the beginning, avoiding this situation?
  2. Your project is split in two parts but the other developer is helpless. Would you do your part and mark all dependencies on his part as “pending” and forget about it? Or would you go and develop his part (even if you won't have credit for that) just to finish this bloody work? Anything else?


 
interview/teamwork.txt · Last modified: 05 09 2007 19:15 (external edit)
 
Recent changes RSS feed Creative Commons License Driven by DokuWiki