Progressive Development : interviewing

Motley says: “To prepare for an interview, just make sure you can code on a whiteboard (Part 2)”

James Waletzky — Fri, 30 Oct 2009 05:29:00 GMT

Summary

[This entry is a follow-up to "To prepare for an interview, just make sure you can code on a whiteboard". A few of the important messages are repeated and clarifications are provided to make a complete package.]

Motley: I thought I could rely on natural coding ability for my interview. I was wrong.

Maven:

YourNetwork + DueDiligence + Preparation + SmallTalk + ClarifyingQuestions + ThinkOutLoud + ThinkCreatively + Design + DriveWithTests + ConcludeAndFollowUp = Job Offer!

______________________________

[Context: Motley, er… Mary, has just had an interview with another company and did not receive a job offer. He is discussing strategies with Maven around what went wrong.]

Motley: <bumps into Maven in the hallway with no apology>

Maven: Hey! What's up, Mot? You don't seem to be your normal bright and cheery self.

Motley: Ah, nothing. I, err… I mean Mary, just got some bad news. She interviewed at another company and did not get an offer. She thought the interview went well, and she is obviously brilliant and has a lot to offer to the company. She is confused why an offer was not made.

Maven: Hmmm… "Mary". Let's cut to the chase. YOU interviewed somewhere else, didn't you?

Motley: Shhhh… keep your voice down. Fine. Guilty. Yes, it was me. I am not serious about taking another job, but a friend of mine wanted me to visit the company he works for, and I thought it would be good interview practice. It was good practice, but it is a blow to the ego not to be successful since I know I am good. I guess I stink at being interviewed.

Maven: Well, if you have a few minutes, let's chat about the job search and interview process for a software developer. Firstly, you did the right thing by leveraging your people network in finding a position. That approach improves your odds of success, and can lead you to open positions that are not widely advertised.

Motley: Yeah, in this particular case I knew another developer at the company. He put me in touch with their HR person, and they were willing to create a position if things worked out.

Maven: Excellent! That is a great way to find opportunities. Next, I recommend you do a fair amount of due diligence to find out if the company is a good match prior to committing to interview. Interview them as much as possible. No sense wasting time in an interview if you feel like it is not a good match. Additionally, do an informational interview with the hiring manager. This session is typically one hour in duration and gives you a chance to ask questions, and the manager a chance to find out more about you. You may determine after this hour that the position is not worthy of follow-up, which saves your time and theirs. After the informational, talk to a few other people in the company across various roles if they allow it. Will you effectively collaborate with these people? Do they share your values? If the answers are yes and they invite you for an interview, go for it.

Motley: Since I already knew someone in the company, I really did not do much more research, but it is a good point.

Maven: Did you prepare for the interview?

Motley: I read the couple of books you pointed me to previously, but that's about all. Some questions did take me by surprise, such as where I see myself 3 years from now.

Maven: It is extremely important to prepare for an interview. Although you do not know exactly what questions they will ask you, you can hypothesize at the types of questions you will receive. For example, it is common practice in a developer interview to ask about your previous experience, pose a design problem, ask open-ended questions about your views, present a couple of whiteboard coding questions, and learn more about your personality. You should be prepared to answer these types of questions.

Motley: I focused more on coding, and practicing some different types of problems.

Maven: That's great! You need to go further, however. Know your strengths and weaknesses. Know where you are going with your career. Know something about the problem domain of the company. Know about the company itself. Know the org structure. Play with the product if possible. Come up with ways to improve the product and/or team given limited knowledge. Know the characteristics of a good UI design, if you are applying for that kind of position.

Motley: That is a lot to do to prepare for an interview! I don't have that kind of time!

Maven: You have time when you make time. These things are important to successfully securing a position, so make it a priority. Plus, don't just waste the effort - make notes. I use OneNote to track all my potential interview answers and over time build up a collection that I continually review and refine.

Motley: Is that "all" for preparation? <sarcasm>

Maven: You can always do more. Ask the people around you for the types of questions they like to ask in an interview - that will give you an idea of the kinds of problems you may be asked. Another important piece of preparation is to ensure you have good questions prepared for the interviewers. You are interested in the position, so show it by finding out more. Interviewers love thoughtful questions. Write them down so you do not forget them in the heat of the moment. Ask about company and product direction, team culture, and current challenges.

Motley: Wow - interview preparation is going to be a big investment!

Maven: Do you want the job or don't you? No need to answer. One other thing I like to do load up my favorite Internet search engine and type in the names of the people interviewing me (if known). I do a bit of background checking on them, which does two things: (a) gives me a clue on the types of questions they may ask; and (b) gives me some topics for chit-chat at the beginning of the interview.

Motley: We talked previously about that, and no, I didn't do it. In this case I did know who the interviewers were ahead of time, so talking about background would have been a great conversation starter. I should have done that.

Maven: Now, the interview itself. How did you handle it?

Motley: In a nutshell, I walked in, sat down, waited for them to start asking questions, jumped up to the whiteboard to solve the programming problems, and left.

Maven: I am obviously missing some details on what happened, but I'll try to build on your experience. First, grab yourself a cup of room temperature water for the interview (room temperature water is better for the vocal chords), as you will do lots of talking. Be on time or early. When greeted, use a firm hand shake, look the interviewer in the eye, and introduce yourself. Then I like to take a look around the office for items of interest (e.g. a picture of the family) or leverage some of my background info and start with some small talk.

Motley: Is there really any point to the idle chit-chat? Seems like a waste of time.

Maven: On the contrary. Some small talk sets the tone for the interview and can get both the interviewer and you smiling and in positive spirits. Remember that you never get a second chance to make a first impression. Use it wisely. It also helps you drive the beginning of the interview and ensure positivity is flowing.

Motley: Fine. So I get past the chit-chat and into the core questions. Any advice, Dr. Phil?

Maven: Oh, please don't call me that! Let's take a common scenario in an interview - you are asked a technical question. First thing that I like to do is practice active listening - repeat the problem back to the interviewer. This practice accomplishes a couple of things: (a) you ensure you understand the problem; and (b) it gives your brain more time to process your approach. Follow this with thinking of clarifying questions, and start writing your assumptions on the whiteboard. Whatever you do, always think out loud. The probability is very high that the interviewer does not necessarily care that you come up with a concrete correct answer. Instead, they generally want to see your thought process. Do you ask the right questions? Do you make the right assumptions? Do you stick with the first solution that comes to mind? Additionally, don't ramble - get to the point.

Motley: Repeat the problem, ask clarifying questions, write down assumptions, and think out loud. I cannot say I did all of those things in my interview, so something to work on.

Maven: Right. When solving the problem, there are a few strategies to help you think creatively:

Can you break assumptions on the input? For example, would preprocessing and having a sorted input make the solution easier?
Look at the problem in reverse. Does starting at the result and moving backwards help? Does processing the input in reverse order help?

Know your data structures. For example, perhaps a less-used data structure like a trie is the best suited to your problem.

Understand "Big O" notation. Many interviewers like to ask about the performance of your algorithm, and "Big O" notation is a standard descriptor.
If asked about a well known algorithm, state that you would look it up and refer to the write-up to code it. You may not get away with this, but give it is worth a shot.

If you get stuck, do not be afraid to ask for your help. You would do that on the job, wouldn't you?

Motley: Decent tips. Anything special about coding problems?

Maven: There are a few things special tips when doing coding problems. Important tips are to design the solution and drive the solution with tests:

Continue to think out loud - don't go dark. Remember, the interview wants to see how you think.

Avoid jumping into coding - think through the problem and do a design if necessary.
Solve the easy problem first. Do not prematurely optimize. Do not forget boundary conditions.

Start with an API signature for your function and clarify with the interviewer that it looks reasonable.

My personal preference is to drive the solution with tests, and take a Test-Driven Development approach. Start with the most basic inputs and generate the right output. Then create more tests and continue to refine.
Talk about your best coding practices, but do not necessarily do them on the whiteboard. For example, state that you would assert at a particular point, or that you would add a comment header to the function, or that you would normally catch a particular error condition (like out-of-memory).

Motley: Wow, there is a lot to it. I usually just jump right into coding and come up with an answer.

Maven: You can do that, but you miss the opportunity to prove your value in other ways. Interviewers want you to put thought into a problem, just as you would on the job. Other small tips include maintain eye contact as much as possible to show confidence, and avoid getting flustered - take deep breaths and think through the problem. Remember: you are not going to write your best code on the whiteboard - it is about how you think.

Motley: Okay, I've solved the problem and now I am done, right?

Maven: Uh, no. You need to finish up by concluding and following-up. Ask those questions you prepared in advance. Then thank the interviewer, and ask what the next step is. Also, after you leave I recommend immediately sending an e-mail to those on your interview loop thanking them for their time and stating that you enjoyed meeting everyone. They made a big investment our of their day in interviewing you - the least you could do is thank them. Be as polite as possible . If they turn you down for one position they may call you back later with another opportunity if they like you. And as a friend of mine, I.M. Wright says, "Don't be a jerk." Being nice can pay dividends later.

Motley: Wow, that is a lot of information for one basic interview. Now I have to try and leverage it.

Maven: You like math, right? Here is the formula for for interview success:

YourNetwork + DueDiligence + Preparation + SmallTalk + ClarifyingQuestions + ThinkOutLoud + ThinkCreatively + Design + DriveWithTests + ConcludeAndFollowUp = Job Offer!

You have to factor in natural talent and ability, but let us assume you have that covered.

Motley: Do you always have to put such a geeky spin on things? It gets old.

______________________________

James' Pointer: Having just gone through a set of interviews at Microsoft, I sat down and thought about some of the things that helped make me be successful at the interview loops. The formula above is what I came up with. Different things work for different people, but these are some techniques that I have tried and seem to have worked. I would be interested in hearing your formula, and best practices for being successful at interviews.

BTW, I am transitioning over to a new development role on the Xbox team, and am very excited with the new opportunity!

Maven's Resources:

None this time.

Motley says: "Building a great team is all about finding the best coders"

James Waletzky — Tue, 03 Jul 2007 19:25:00 GMT

Summary

Motley: The last person I interviewed was a coding wizard! She'll make a great addition to the team!

Maven: Coding is important, but good team members must match team values, be strong in the core competencies, and be passionate about what they do.

______________________________

[Context: Motley is reflecting on an interview he just conducted with a job candidate]

Motley: I just finished interviewing a candidate for a position on our team. She was a coding wizard on the whiteboard! IQ is off the charts! I think she would make a great fit for the team.

Maven: Good stuff! Did she seem like she would be good to work with? Was she a nice person?

Motley: Well, she actually came across as a bit ego-centered and my first impression, although it's hard to tell in 60 minutes, is that she has a pretty harsh personality - unlike me of course. She also was not the greatest communicator, but those coding skills were amazing!

Maven: No matter how good a coder she is, if she is not enjoyable to work with and cannot work well as a team, she will not be an asset. To be a good developer, you must do more than code.

Motley: Well, how do you really judge someone like that? What really makes a good team fit?

Maven: Several ways. Remember we talked about values previously? One reason it's a good idea to enumerate your values and the team's values is to make sure that new team members can fit within that value system. If the team values quality over number of features, someone that just cranks out code not caring about quality will not fit in. You probably don't want to come out and ask a new candidate explicitly for their values, but you can lead with questions that will surface them.

Motley: Our team definitely values great coders!

Maven: Yes, but there is more than that, right?

Motley: Fine. Quality is important. Being a good team player is important.

Maven: Something else to look for in new team members that they meet the core competencies of the team. Examples of competencies include passion for quality, technical passion, interpersonal skills, creativity, being action-oriented, having confidence, and listening and communication skills. It's important to enumerate the core competencies for both the team and the company to ensure that someone new has skills in those areas. For each position you want to fill, describe the competency levels that the new person is expected to possess. And don't forget, someone coming into a management role versus someone coming into an engineering role will have slightly different competencies.

Motley: So what do you do with these competencies?

Maven: Chances are good that a new team candidate will go through multiple interviews (i.e. more than one person). Assign each interviewer in the interview loop one or two of the core competencies to focus on, so that you get good coverage throughout the loop. Each interviewer can tailor their questions around their assigned competencies and come up with an overall rating for each competency. This approach brings more structured questioning to the interview and minimizes the odds of different interviewers probing the same areas. You get a more well-rounded evaluation of the candidate.

Motley: Ok. So we identify the core competencies and value system for the team, describe how well each candidate must match up with the competencies before they are hired, and assign different interviewers one or two competencies to probe. Sounds like a lot of work!

Maven: A little bit of work now pays off dividends later. Plus, you driving this process will look great on your next performance review!

Motley: I'll get right on this. Not for the review benefits of course, but because, ummm, for the good of the team.

Maven: And as for the new person you just interviewed?

Motley: Well, we didn't approach the interview from that perspective, but based on the competencies I have in mind, she meets technical passion just fine but fails on lots of the other stuff. No hire.

Maven: Sounds like the right decision to me.

______________________________

Maven's Pointer: Microsoft has spent a lot of time identifying the core competencies for various professions in the company. An example that is publicly available is the Microsoft Education Competencies, which follow very closely from software development competencies. Many competencies are in common and the general framework applies, including how to tailor interview questions. Check it out for a great example.

Maven's Resources: Microsoft's Mission and Values, Microsoft Education Competencies

Motley says: "As an interviewer, I need to prove I am better than the candidate"

James Waletzky — Tue, 26 Jun 2007 20:04:00 GMT

Summary

Motley: I can't hire someone better than I am - they'll move up the corporate ladder quicker!

Maven: It's your job to hire the best person for the job and to follow best practices as an interviewer.

______________________________

[Context: Cynthesis has a free position on Motley's team and he is to be involved in the interview for a new candidate]

Maven: Hey Mot, I have something to show you-

Motley: Not now! I have a candidate coming over in 10 minutes to interview for a new position on my team. I have to finish reading this news article and then get over to the interview room.

Maven: Cool. What kind of background does she have?

Motley: How should I know? I'll find out when I interview her.

Maven: You mean you have not read her resume???

Motley: Nah. I get in there, give her a few coding questions, make sure she does not match my level, and then consider her for the job based on what I just saw.

Maven: Ouch. Don't you think that her experience should come up in the interview? As we discussed previously, coding is important, but you also need to make sure she can back up the contents of her resume and fit in as a team player.

Motley: I might glance at her resume a bit during the interview. That's good enough.

Maven: Au contraire, mon frere. I recommend reviewing her resume up front and tailoring your questions to her experience. You cannot ask her to code some stuff up in C# if she has only used Java, for example.

Motley: If she's only used Java then I don't want her on the team!

Maven: Oh, that is soooo naïve. C# and Java are very similar, and the class libraries are much alike. I would judge her more on her general technical merit and team fit as opposed to what languages she knows. Plus, it's not all about whether you can outdo her in an interview. Wouldn't you just love to have someone on the team that you could learn from and help grow yourself personally? If I come out of an interview having learned something from the person I am interviewing, that contributes a lot to my hire or no hire decision.

Motley: But if she's better than I am she'll probably climb the corporate ladder faster than I do!

Maven: It's not about climbing the ladder. Are you here just to climb the ladder or do you want to do your best to help the team, the company, and create a kick butt product?

Motley: Fine.

Maven: Here are some suggestions for interviewing in case you are interested:

Ask open-ended questions. E.g. "Tell me about a time". Follow-up with questions based on the answer and really get into depth on a few topics vs. high-level breadth on many topics.
Make sure you don't dominate the conversation. The interview is about the interviewee - you want to hear them speak as much as possible to make a value judgment.
Role plays work great. Put them in a tough situation and see how they come out of it. Play devil's advocate, but tell them you are doing so to ensure you don't come off as rude.
Your final decision at the end of the hour-long interview (recommended time) should be "hire" or "no hire". Make sure the person can really do the job. If you are unsure of the candidate, the default decision should be "no hire".
Write up a really good summary of the interview. The format I like to follow is "Summary" (brief overview of the interview and my decision), "Details" (the questions I asked and how the candidate answered them), and "Conclusion and Follow-up" (concentrate on unsure areas and where the next interviewers should probe). This write-up provides history and covers your butt should legal action take place in the future.
Make the candidate feel relaxed - start the interview with some small talk before jumping into some technical questions. You could also ask them to tell a story from their past that might be relevant to this position.
Don't use canned questions off the Internet. You found the questions, so chances are good so did the candidate. How many times have I heard "How do you detect a cycle in a singly linked list?" for example.
Avoid questions that have a "trick" in them and if the candidate doesn't get the "trick", they don't stand a chance. These kinds of questions (especially brainteasers) really don't prove anything.

Motley: There are some good tips there. Fortunately I already do most of that. But guess what?

Maven: What?

Motley: I AM NOW LATE FOR THE INTERVIEW!! I told you I didn't have time to chat. Now step aside so I can judge team fit for the newbie.

______________________________

Maven's Pointer: Make sure you spend time preparing as an interviewer. Plan some questions in advance based on the requirements for the position and the background of the candidate. You want to come across as professional and show that you take the interviewer responsibility very seriously. Would you want to work with a team where the interviewer is unprepared and wants to make himself look better than you? It does not leave you with a good feeling about the team and may ultimately affect your decision of whether to take the job should you get offered the position.

Maven's Resources:

Chris Sells Blog on interviewing at Microsoft: http://www.sellsbrothers.com/fun/msiview/
JobsBlog: Technical Careers at Microsoft: http://blogs.msdn.com/jobsblog/

Motley says: "To prepare for an interview, just make sure you can code on a whiteboard"

James Waletzky — Wed, 20 Jun 2007 01:58:00 GMT

Summary

Motley: If I can code well on a whiteboard, I am a shoe-in for the job.

Maven: There is more to just whiteboard coding - make a good first impression, do your research, and prepare, prepare, prepare.

______________________________

[Context: Someone Motley knows is interviewing for a new job. Motley wants some advice some Maven on how to interview effectively ]

Motley: Hey Mave, what are you up to?

Maven: Hmmm… you're coming to visit me with a nice query of what I am up to. This is an unexpected surprise! But, it probably means you want something.

Motley: I resent that! Do you think I only proactively talk to you when I want something? Well, errr, okay. Maybe you're right. Anyway, let's cut the idle chit-chat. I do have a question.

Maven: Fire away, Mot. I'll do what I can.

Motley: Well, my friend, um, Mary - yeah, that's it, Mary - is in the midst of a job hunt. She has lined up a couple of interviews and was asking for some tips on interviewing. I told her to just make sure she can code on a whiteboard - that seems like the #1 tip for a developer. However, it feel s like forever since I have been on a job interview, so I told her I would ask you to see if you had any tips in addition to my fantastic nugget of advice.

Maven: Interviewing. That sure is a stressful time. Having gone through it very recently here at Cynthesis, I'll let you know what I did to prepare. Firstly, preparation typically involves more than just practicing your whiteboard coding. Chances are good that in a technical interview Mary may be asked to code on a whiteboard, but there are some strategies to do it effectively.

Motley: I don't know what - if I see a wizard come in and code up a SAX XML parser on the whiteboard, he's got my vote for "hire"!

Maven: Well, first, I typically do a bit of preparation work. The first thing I need to figure out is if the company and/or team is really right for me. I'll read through the company's web site, learn about their products, read about the management team, and read what the press has to say.

Motley: Research the company both from the business and technical perspective. Check.

Maven: Then I'll try and figure out the names of the people that are interviewing me. Teams will usually give that information. Then I'll Google - damn! Caught myself again - I mean Windows Live Search on the names to see what I can find out. Have they written some interesting articles? Do they have a blog? That kind of thing. That gives me a bit of insight into their character and gives me some hints on what kinds of questions I'll be asked. It also helps with the small talk at the beginning because I now know something about the person interviewing me.

Motley: Research the people interviewing me. Check.

Maven: Next, I have a couple of books that I like to scan over to help me brush up on some concepts people often ask about but I don't necessarily use all the time. Often I fail to understand why I get asked these questions, but I digress.

Motley: So what books do you recommend? I am not a big believer in software engineering books, but I need some help here.

Maven: The first one I brush up on is Programming Interviews Exposed. It takes you through some technical interviews and discusses the mindset a developer typically has during an interview. After I read this and think about how the interview will go, I remind myself to think out loud, start with the basic solution first and optimize, and think about boundary cases and other test scenarios. I then make sure that even if I don't have time in an interview to do everything that production quality code requires, I at least talk about - like running FxCop for example.

Motley: Good tips. Think out loud. Give the interviewer some clues as to how you would behave on the job. Check. Other books?

Maven: Another oldie but goodie is Programming Pearls. This book covers a bunch of problem-solving scenarios, such as sorting, vectors, searches and others. It's great for helping turn up the creativity notch. Examples are in C++. One other thing I'll do is grab an algorithms book and review some basic stuff. I have a big white algorithms book from university that I use, but it's cryptic. I recommend you grab yourself a book that focuses on your language of choice. There are lots out there.

Motley: Books around algorithms. Check. Any other advice?

Maven: Practice! Make sure you are in the mindset before the interview. The week leading up to it code up some toy problems like atoi() or some kind of sort. Code it like you would on a whiteboard. Also, don't be afraid to be creative! Suggest hair-brained - but reasonable - solutions to problems. In fact, if you'd rather code in the IDE like VS, ask the interviewer to use her PC! Why not get the aid of help and intellisense while you code the problem. That's what you would do on the job anyway! I am amazed more people don't do this.

Motley: Very cool. Yeah, why not get the aid of the tools. If they say "no", I always have the whiteboard.

Maven: We could go on with advice, but I don't want to overwhelm you. Hopefully James is listening to this conversation and can get all the fine readers to share some advice. I hope they make a comment so we can all learn from each other!

Motley: Yeah, I'd love to hear more advice from some more intelligent individuals than you. There must be good stuff out there for me to sponge up.

Maven: So when is your interview??

Motley: It's not me dude! I am happy here, even with you bothering me every day.

______________________________

Maven's Pointer: Many interviewers make up their mind about hiring someone in the first 10-60 seconds of the interview. Check out Blink for more information. As a result, it is really important to make a good first impression. Complement or ask the interviewer about something you know makes them happy, like a photo of their family. Mention something positive you read in a blog entry. As they say on TV, you never get a second chance to make a first impression.

Maven's Resources:

Programming Interviews Exposed, by Mongan et al, Wrox, ISBN: 047012167X, April 2007.
Programming Pearls, by Jon Bentley, Addison-Wesley Professional, 2nd Edition, ISBN: 0201657880, September 1999.
CareerBytes: Top 10 Technical Interview Tips, http://www.codeproject.com/gen/work/TechInterviewTips.asp, October 2006.
Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell, Back Bay Books, ISBN: 0316010669, April 2007.

Motley says: "Want to join a new team? Just find a cool technology"

James Waletzky — Wed, 23 May 2007 07:58:00 GMT

Summary

Motley: The only thing that matters in finding a new team or company to work for is the technology and the money they offer you.

Maven: Technology is nothing without a sound business strategy and a competent group of people running the company. People are more important than technology.

______________________________

[Context: Motley just discovered that another developer in the company, Marcia, is leaving the company]

Motley: Hey Mave, did you hear that Marcia is leaving the company?

Maven: No, what's up? Why is she going? Things are definitely on the up-swing around here.

Motley: Her husband got a really cool job down in the valley, so because employment is pretty plentiful down there, she figured she could find a good position too. There's lots of cool technology being built down there - just take your pick and join the company that builds it.

Maven: There's a little more to choosing a company and, in particular, a team, than just the technology that it builds.

Motley: Oh yeah, I forgot. Money factors in of course! That's my main value after all!

Maven: So you mean you would join a new company if they are doing something cool and they'll give you a decent paycheck. That's your only criteria?

Motley: Pretty much. That's what makes me happy - at work. Off work, a little exercise, a nice looking girl, and a beer all complete life off-hours!

Maven: Jeez Mot, you need to look a little more widely and examine your happiness. It doesn't do any good to work on cool technology for a decent paycheck if the company goes under a month after you join. They need a solid business plan, show results, and have a promising future. Do they keep customers happy? Are they successful? Are investors interested?

Motley: Blah, blah, blah, as Steve Ballmer would say. Cool technology always leads to success.

Maven: Well, I definitely cannot agree with you there. What about Microsoft Bob? Oh wait, bad example - that technology sucked. How about OS/2? The Apple Newton? Digital Audio Tape? All cool stuff, but without a solid business plan that solves real customer problems and does it well, the companies were doomed.

Motley: Those are in the minority.

Maven: Those are the ones you hear about. There are thousands you don't hear about. What about the people in the company? Do you want to work with a bunch of crappy developers? What about your manager? Do you want to work for an incompetent manager?

Motley: Are there managers out there who actually do something useful? Um, I hope my boss isn't at her desk over there. Phew. That would have been an "insert foot in mouth" moment.

Maven: Okay, I know you're joking. At least I hope so, considering your boss is right behind you.

Motley: Wha-!

Maven: Kidding! But seriously, count your blessings - you currently have a fantastic boss. That won't always be the case, however. When you look for a new job, first off, you need a goal. If your goal is to work on cool technology and that's it, well, ignore the rest of what I have to say. However, if your goal is career development and maybe some management experience if that's your thing, here are a few things to do due diligence on before joining a team:

What is your new boss like? Do you like her as a person? Does she have a vision?
Will you be micromanaged? Trust me, Mot, you won't like that. How do you find out? Talk to your future peers (her other reports).
What is the health of the team? Are people happy? Are they seeing results?
What are your peers like? You'll have to work with these people on a day-to-day basis. If you can't stand them, coming to work is no fun.
Is the group's mandate strategic to the company? You don't want to work on a team that doesn't matter.

Motley: I still think technology is king - you have to work on something interesting. But, I definitely don't want to work with a bunch of losers, I'll give you that.

Maven: I could go on with things to look for, but you get the idea. Hopefully you are not going anywhere anytime soon as you are a great asset to Cynthesis. But, when that day does arrive and you decide to pursue something different, keep in mind that the business and people are more important than the technology.

Motley: By the way, I was hoping that you were leaving along with Marcia. Any chance?

Maven: You're just full of jokes today, aren't you.

______________________________

Maven's Pointer: Definitely make it part of your due diligence when finding a new job to interview as many people as is practical before taking the position. A manager, for example, will never indicate that they micromanage people, but his or her reports will usually tell the true story. Talk to them, and be prepared for the interview with some canned questions.

Maven's Resources: None.