Bryan's Coding Corner

This is Part 2 of a 3 part series on how you should go about figuring out if a company is right for you during the interview process. In Part 1 I looked at how to evaluate the people you see outside of the interview and the equipment you’ll use, in this part I’ll look at questions you should ask your interviewers, and in Part 3 I’ll look at software and development tools/methods.

• Technical Manager
  • What would you say your job is/What are your day-to-day tasks? With this question you’re trying to build up a good feel for the manager’s style. What do they say they do and what does it really mean? You should watch out for any managers that think they make decisions (or even help make decisions) about anything technical. A manager’s job is to point their programmers in a certain direction and then make sure absolutely nothing gets in the way, not even themselves. If you haven’t already you should go to www.joelonsoftware.com and read everything he has to say about management style.
  • Do you/how do you evaluate a programmer’s performance? No matter what some people may tell you, your performance as an employee is and must be evaluated in some way. Without some sort of performance evaluation there is no way to separate the wheat from the chaff, the superstars from the cave trolls. The danger is that some managers like to try to make their job easier by using metrics which are almost always gamed by programmers. Seriously, we are programmers, it is our job to figure out how a system works and either make it work better or use it to our advantage. Run as fast as you can from anyone that claims to use a metric and especially if it’s a “secret” metric that they came up with. Metrics like number of lines of code (ever seen Hello World take up 200 lines of code?), bugs per feature (guess how much time the team will spend fighting over easy features), and most insidious of all, how “interesting” is the solution the programmer came up with (I’m not kidding, I’ve heard of this). If you ever see the last one even being hinted at you need to run away screaming and try to rescue as many of the poor saps trying to maintain all of those disparate “interesting” solutions as you can on your way out.
  • What is your development process? Please God let there be a development process. You’re going to ask this question of everyone who interviews you that has anything to do with the development process. It is very illuminating what the different levels claim the development process at a company is. You should trust the lowest level you talk to the most but never bring up the differences during the interviews if you want to get the job (not to mention that it will probably skew the answers if you mention it beforehand). Watch out for managers that claim they practice agile or extreme programming and actually just use that for an excuse to never design or architect a solution before coding starts. Even with those practices there is a lot of architecture and design required before the first line of code, just not nearly as much as with a waterfall methodology. Also you shouldn’t necessarily be afraid of the waterfall model, in certain circumstances where requirements are going to be relatively static or well-known in the beginning the waterfall model works just fine.
  • Have you programmed? What languages? Not really a big deal, a good question to start off with. One thing to watch out for is someone who’s programmed a little bit but never really produced anything (programmed in school, as a side project, etc). Some of this type think they know how to program and don’t listen to the people who actually do when it comes time to make a decision. At best their expertise is likely just out of date (look for the shops writing programs in C that are not for small embedded systems).
  • Do any upcoming technologies excite you? Why? You need to have some idea of what’s coming down the pipe to ask this one because you want to be able to have a conversation. Count the buzzwords, if they make up more than 30% of the total word count you’re dealing with someone that probably doesn’t have a clue. Currently (beginning of 2009) buzzwords to watch out for are “the cloud”, “meta”-anything, and if you hear the words “Web 3.0” you probably just want to thank them and leave. This is the person you have to trust to aim you and your fellow programmers in a direction that will be profitable, not into the ground. If they don’t know what they’re doing you shouldn’t waste your time.
  • Have you read Peopleware, Mythical Man Month? Not a requirement but give this guy a gold star. Just as with your colleagues, you want to try to gravitate toward managers who are intent on furthering themselves.
  • What is the turnover rate of your team? How many have been hired in the last year? How many have left/been let go? Long story short: high turnover is bad. High turnover indicates a crappy place to work, if there are more than 10 people and the turnover is more than 10% don’t even bother unless you want to hate your life. Closer to 5% seems more normal.
• Project Manager
  • What do you do/have you done when a project is not going to meet a deadline? What would you do in the future? First, you should know that the correct answer is to cut features. Actually the correct answer depends on how far you are away from the deadline and how far behind they project is. If the deadline is still a long way off you start by prioritizing features, evaluating your process, making any changes where it is lacking while implementing the highest priority features and evaluating the changes, and then cutting features as needed until the deadline and estimates match back up. If the deadline is not so far away you cut features and cut them deep. Only if the project is going to be less than a week late is “crunch time” an acceptable answer.
  • How and by whom are schedule estimates prepared? How are they adjusted as the project goes on? Here’s a fun one. Why is it that so many times it is not the people who will be doing the actual coding that make the time estimates for the schedule? You wouldn’t trust a guy who’s never touched a hammer to tell you how long it would take to make a house but for some reason many people who’ve never coded a day in their lives seem to feel qualified to make time estimates. Inevitably at these places the schedules will be unrealistic, deadlines will be passed, features will be cut, testing will be non-existent, etc. If you avoid every company that does this you would only have the option of about three companies in the world to work for, but take it into consideration.
  • Roughly what percentage of projects meet their estimates? Short schedules suck, if many projects don’t meet their estimates it means you will get at least one unrealistically short schedule in your time at the company.
  • Have you read Mythical Man Month? I know I said it wasn’t required reading for managers, but PMs are different. They had better at least know what the myth of the man-month is and be able to explain it forward and backward to their boss.
  • How are decisions about requirements/features made? You’re watching out for anything like “the sales guys come to us with a list of features the customers want”. Seriously? Do you also go down to Home Depot, tell the guy at the counter what lumber and parts you’ll need, and have him tell an interior designer what to design? A programmer’s job is to find solutions to problems and then steadily make those solutions easier until you don’t have a problem anymore. The sales guy’s job is to find the people with problems (customers) and convince them that their programmers can solve said problems. Do exactly what an interior designer does: figure out what the problem is, find out the customer’s preferences, make some mock ups and present them to the customer, and then make the best mock up. Let the programmers figure out the features. Many large, successful software companies have a special position for this or have it be part of the program architect’s job.
  • What is your development process? Like I said, ask everyone, look for differences, and analyze what those differences may mean.
• Team Lead
  • In what way do you carry out your leadership role? Most team leads are simply the best or most experienced programmers on their team. Unfortunately, little thought seems to go into whether or not this person can be an effective leader. So what ends up happening is that the team takes their best or most productive programmer and cuts down the amount of time they can spend programming to around 50% while getting no or even a negative benefit as far as team leadership goes. Team leads should be mentors, leaders, and firefighters. They are the ones who delegate tasks, interface with management, keep the team on track, mentor new/younger programmers, and frequently fight the little fires as they occur. If they think they are do or are going to do and significant development work either they’re delusional or some aspect of what their job actually should be will suffer. Since this person will directly effect how the kind of experience you will have at this company make sure that you will get along well and they are competent enough that the team will run smoothly.
  • What would you say your split is as far as programming/management? As I said above, programming is only a small part of a team lead’s job. If they say the split is anything above 50% programming ask some more questions to figure out just how delusional they are. Hopefully they just think of keeping the team on track, mentoring, and fighting fires as part of the programming aspect which isn’t really a bad thing. Personally I would include mentoring and fighting fires as part of the 50% that is programming.
  • How do you train new people/bring them up to speed? This will be your first few months even if you’re an experienced programmer. Make sure the process will meet your needs.
  • What is your development process? This is probably the person with the most accurate handle of what the development process actually is, pay close attention to their answer.
  • Why do you use [whatever language]? What are the benefits and drawbacks of using it on this project? Every language has pros and cons for every application. A team lead had better know what they are and why this language was chosen for this particular project. Make sure they have actually considered the pros and cons and the decision wasn’t “religious” in nature.
  • What are each of your team member’s strengths and weaknesses? As team lead they have to know how to use each team member to the best of their ability and potential. While they probably shouldn’t want to name names you need to make sure that they recognize that each person is not interchangeable and certain people are going to be better or worse at certain tasks.
  • How long have you been at [company]? What did you do before? A team lead should have been at the company for a year or two or they will not have gained the sufficient trust from management to be able to do their job. They also should probably have had at least one other job at another company to make sure they have seen other ways of doing things. Also make sure they aren’t the type that hops from one company to another every two years. You want to join a team that is stable and that stability comes directly from the team lead.
  • Did you go to college? What was/were your major(s)? This one might not matter to some but if you want to make quality software the team lead had better have taken at least a few university CS classes. You learn many things learning to program on your own and people that learn to code on their own are almost invariably the best programmers. However, you have to have a solid foundation in algorithms & data structures, memory management, and a host of other topics that you really only learn in a CS program in order to be able to make good and informed decisions that a team lead has to make every day.
  • What programming/process related books have you read? What did you think of [any that you've read as well]? A team lead has to keep learning, period. If they haven’t read any books about current programming languages and tried them then they won’t know they benefits of other languages and which is the best choice for this particular project. If they haven’t read about different processes or teamwork methodologies then your team won’t be operating at full potential. Just make sure they read and it isn’t only Teach Yourself Head First PHP for Dummies in 7 Days.
• Colleague
  • Did you go to college? What was/were your major(s)? Ask this question for the same reason you asked the team lead. You will be having to maintain each other’s code. If you’re constantly having to refactor because your colleague uses an array when they should use a linked list or they don’t know what recursion is you’re going to get very annoyed (or at least I would). Additionally, if the company is having this person interview you they are probably considered one of the better people on the team. Try to aim for a company where this person is better than you so you can continue to learn.
  • How long have you been at [company]? What did you do before? The reasons are the same as for asking the team lead. You’re hoping they’ve been there for a little while but have still seen some other ways of doing things.
  • What programming/process related books have you read? If you want to be on a good team your colleagues need to keep learning as well. Some people can program for 3 years and get 3 years worth of experience. Most do not. Most people will program for 3 years and get 1 year worth of experience 3 times. Reading, learning, and applying new ideas is the only indicator you have of which kind of person you will be working with.
  • How does your team lead go about leading? Find out what they think the team lead does. You’ll have to actually analyze the likely sugar coated answer but the results can be very illuminating.
  • How does your manager go about managing? For the same reasons as the question about the team lead. What you don’t want to hear about is how they swoop in and make decisions that are technical in nature.
  • How realistic are schedules? What happens when a project is behind schedule? Make sure their answers jive with the PM’s.
  • What is the skill level of the team?/Where do you think you fit within the skill level of the team? If the person has been their for a while they know who’s good and who isn’t and in which area each person excels. Try to use this information to figure out how good the team is. If you think you’re going to be the most skilled person on the team you should either realistically evaluate yourself or look at another company.
  • Does the team go out for lunch or happy hour occasionally? A team needs to mesh to reach its full potential. To do this you have to occasionally do things together outside of work. Make sure the team gets along and has a good dynamic or you will only be about half as productive as you could be.
  • What are the specs of the computer you use? Are they adequate? If you’re not going to have the best computer you can utilize (within reason) then you are wasting your time here. I don’t care if it’s the latest and greatest computer, if it saves me 5 minutes a day then it pays for itself in a year. Also having fewer than two monitors is unacceptable, if every programmer doesn’t have two monitors on their desk just leave. No, I’m not kidding.
  • What about your chair/desk? Are they comfortable? You’re going to be sitting there for 8 hours a day 5 days a week. You’d better be comfortable or you’ll be fidgety and unable to get in the zone (flow, whatever the word is this week). This will make the day go slower for you and your day be less productive for the company. Therefore you being comfortable at your desk is a win-win for you and the company.
  • What is the environment around where you’ll sit like? Noisy? Foot traffic? Climate controlled? Once again you want to find out about comfort and ability to focus. If you can’t focus you’re wasting both your and the company’s time. I don’t know about you but I have much better ways to waste my time than being unproductive at work.

A quick word about panels – Panel interviews are terrible for evaluating the company. It’s rarely possible but see if you can speak to individuals during at least one round of interviews. If you can’t you have to take into account the makeup of the panel and try to get a feel for the company by questioning the people there. Realize though that the answers are likely to be more guarded and glowing. Panelists are going to be paying more attention to what they say because they are talking to more people and there is probably at least one boss/employee relationship in the bunch. Do the best you can.

Hiring & Interviewing