When I conduct interviews, I want to see you code. I don’t want to see your code, I want to see you type something from scratch. That means, brand new, as in not something you’ve already done (or copied from somewhere else).
I’m not the kind of person that really get’s turned off by interviews. I actually enjoy them sometimes. It can be a good test of my skills and knowledge. A lot of the time it shows me whether or not I’m good at explaining what I know. Communication is very important to me in my career. Lately, however, I’ve taken a different role in the interviewing process. I’ve become the one giving them instead of taking them. I thought today would be a good day to talk about interviews I’ve had, and what kind of interviews I think make up “good” interviews, and which one’s I think are “bad”.
When you plan a road trip, you’re really only concerned about figuring out one thing: how long will it take me to get there? But for projects, this isn’t always the case. The same formula applies, though.
Once your team has estimated a set of features, and assigned each feature their “point value”, it’s time to start measuring your team’s velocity!
Now that we understand the concept of estimation, we need to talk about how this “credit system” applies to our velocity.
In order to calculate velocity, we need to know how to figure out the amount of effort involved for each feature that a team works on. Before we can get to that, though, we need to determine something else which is crucial. Who, exactly, should be estimating the effort?
Velocity is the key to any project’s success. Plain and simple. I think that just about every project in some way or another tries to figure out this metric. It’s how this metric is obtained that is so important.
