So there you are, sitting in the small conference room after having been grilled on your life story for the second or third time in as many hours. Your interviewer has just concluded her battery of questions. She closes her notebook and asks the obligatory, "So, do you have any questions for us?" Your mind races through a series of possible tactics. Conventional wisdom at this point dictates that you ask questions about topics like benefits or corporate culture--or even the scope of work in a way that reflects back to some significant item on your resume that you thought might have been missed. Although asking questions along these lines is both informative and expected, there is another series of questions that you may want to delve into.
About five years ago a colleague of mine, Eric Grab, and I were both contemplating career moves. We discussed at length the key elements at places that we had worked that had made working there either enjoyable or miserable. We came up with the traditional list of criteria such as work environment, supervisors, creature comforts, salary, and fringe benefits. All were good criteria, but they also applied to just about any career at just about any place of employment. So what we set out to do was to come up with a list of questions unique to the IT industry. We wanted to compile a list of questions that would help evaluate a position at an entirely new level. Over the years, we have both asked questions along these lines many times over and honed our list to ten questions. What follows is not only that list of questions, but also our thoughts on what different answers mean to us. You, of course, will want to couch the questions in your own style, and your analysis of answers may vary significantly from ours, but use these questions as a foundation and ask lots of follow-up questions if you don't get enough information. I find this is often necessary because the interviewers are seldom prepared for this type of questioning.
I divided the list of questions into topics with one initial question on each topic and some suggestions for follow-up questions. Development Tools What development tools do you use?
This is a fairly straightforward question and a good one to lead with because it will get your interviewer warmed up for your other questions. If development tools have already come up before this point in the interview, you can ask, "What other development tools do you use?" The best way to get a sense of what you will really be doing once you get the job is to know all the tools that will be at your disposal. The first answer that you get may be something along the lines of "We use product X as our Integrated Development Environment," and most interviewees are satisfied with an answer like that. Follow up with questions about what they use for version control, debugging and profiling, query building, automated testing, and documentation. These are all important tasks that can be tedious without the proper tools. For me, one of these questions is a showstopper. If you are going to be on a project of any significant size and they don't have good version control software, it is only a matter of time before they have a disaster and guess who is going to be working nights and weekends to clean it up. Object-Oriented Programming Do you use object-oriented programming methodologies?
If the position you are applying for is as a Java programmer, the answer will be "yes," but again you need to dig deeper. Ask follow-up questions on topics like design patterns and refactoring. If they are using a relational database in their system, ask how they do their object-relational mapping. The goal here is for you to determine if they are actually doing object-oriented programming or if they are just using object-oriented languages. This might not matter that much to everybody, but nothing is quite as painful as having to work on procedural code that has been written in an object-oriented language. Development Methodologies What development methodology do you use?
For me, acceptable answers to this question vary greatly by the position I'm applying for. If it is a small company or a small team with in a large company, then the more informal methodologies are acceptable, whereas if it is a larger company or large team, more formal methodologies are preferable. Most methodologies fall into either the classical waterfall model or an iterative model. I prefer the latter, but if they are using a methodology that you are not acquainted with, be sure they walk you through it and that you are comfortable with it. A good follow-up question is to ask how closely they adhere to the methodology. Requirements How do you gather requirements?
Although this may or may not tie into what development methodology is being used, it is a good question to ask. You can even follow up by asking for an example of how a requirement flows through their process from inception to delivery. It's amazing that, although this is the core of what most organizations do, they sometimes don't have a well-defined or repeatable process. Design How does your company communicate design?
I have found that, since you can't actually ask, "Does your company do design?" this question is a good substitute. From the answer, you will be able to discern two things. First, you'll be able to determine whether they really do design work, because if they don't, there is nothing to communicate. Second, you will get a sense for how they do design. Is there a systems architect that does all the initial design work, or does the whole team work on it together? Collaboration and Tracking How do you track progress? Is it by individual tasks or by overall projects? Is it by the individual or by the team?
Phrase this as you see best, but I look for two things here. First, what metrics they use for measuring work and, second, whether this method encourages collaboration. I have found that the actual metric used to track a project has a profound effect on the project itself. While a good metric should not change the outcome of a project, here are some metrics that I have seen applied to projects and how they affected the project. At the first company that I worked for right out of school, they tracked productivity by the number of lines of code written per individual. So, of course, they got lots and lots of lines of code, and programmers were actually penalized for writing reusable code or reusing someone else's code, although people did do a lot of cutting and pasting. Later, they changed this metric to be the ratio of bugs found in the code to the number of lines of code. So it turned into the most overly tested, verbose software I've ever seen. Don't get me wrong; testing is good, but programmers were penalized even if errors were caught in the quality assurance (QA) cycle. In another company I worked at, the metric was just number of hours worked--or, as they called it, "effort." Everybody worked lots and lots of overtime. The result was an entire team of burned out programmers who didn't work efficiently. In general, people will always gravitate toward doing whatever is being tracked, so make sure whatever it is that they track is something that you like doing. The second thing I look for in what they track is whether the metric supports collaboration. I have found that the best projects for both team productivity and my own personal growth were those in which collaboration was either encouraged or required. Scope and Deadlines How do you scope projects and set deadlines?
What I'm looking for here is whether you get a say in your own destiny. If project management--or even worse, marketing--is setting the requirements, scope, and deadlines, and there isn't a feedback loop for estimates from the developers on how long they think it is going to take, then you may be in for a death march. A great follow-up to this is to find out when and where they make course corrections. Do they check status every day, week, or month? How do they adjust the schedule? Do they cut scope, push off the deadline, or just assume that everybody will start working harder and faster near the end of the project? Meetings What are the regularly scheduled meetings?
What I look for here is a balance between no regular meetings and so many that you can't get much else done. I like to add up all the time spent in meetings and figure out what percentage of my overall time will be dedicated to meetings. Testing How do you test?
I subscribe to the theory that testing is how you determine when you are finished with a particular coding task. In other words, once all the tests pass, you are done and ready to move on to the next task. Also, a good QA process keeps everybody happy. Let's face it; there are going to be bugs and you want a safety net in place to catch you. I also like to ask about how automated their testing is. As a developer, I want the freedom to make changes without the worry of breaking something in an unrelated area. Only automated testing can give me the comfort level that I need. Coding Standards Do you have a coding standard or style guide?
I like to ask this question because I hate it when everybody on a project has their own style or naming conventions. It seems like I always wind up working on the code written by the guy who has never used a variable name longer than three letters and puts all his curly braces in the wrong places. I really like the idea that all code in a project should have the same look and feel regardless of who wrote it. In the long run, I think everybody working with it benefits by being able to spend more time on understanding meaning rather than syntax. Ask Away! Asking these questions has an interesting side effect. In most cases, although you are the one asking the questions, the interviewer's opinion of you is going to become more favorable because you obviously would ask these questions only if you have had a great deal of hands-on experience.
This list of questions should give you some additional criteria by which to measure any programming position that you may be applying for. We have developed this list over a number of years based on our own personal experiences. It is even helpful to imagine how you would answer these questions as they pertain to your current or previous positions. The questions cover all phases of the software development lifecycle including requirements gathering, design, development and testing. In addition the questions cover all of the ongoing activities such as meetings, deadlines and task tracking that any position may require. Knowing which development tools will be at your disposal will give you a better feel for what the position will entail. Determining what development methodology the company uses, how they determine system requirements and whether they really utilize the benefits of object-oriented languages will give you a feel for the environment of the company. Inquiring about design, coding standards and meeting and feedback loops in determining scope and deadlines will give you a better feel for how successful communication is in the company. Knowing how the company tracks projects and therefore what they emphasize will help you evaluate if it is something you would enjoy doing for the foreseeable future. Also a beneficial side effect of asking these questions (besides learning the answers) is that you demonstrate a great deal of knowledge to your interviewer just by asking the right questions. I trust you will find this list as helpful as I have.
Acknowledgement: My thanks to Eric Grab for his contributions to this article topic.
Michael J. Floyd is an Extreme Programmer and the Software Engineering Technical Lead for DivXNetworks. He is also a consultant for San Diego State University and can be reached at Michael_Floyd@mcpressonline.com.
|
