Category: Technology
When I develop applications, any time I can forgo repeating myself I usually take the opportunity to save myself the time. The same applies to a lot of my daily routine at work. If there’s a way I can do things better, I’m all about it. So when I started conducting interviews, the first thing I started thinking about was how I can make this as stream lined as possible.
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!
