interviewing the interviewer

looking back i am surprised at how little importance i saw in the process of interviewing the interviewer.

it’s pretty simple – for me the main criterion is how good the people are that i will be working with. they have to be better than me, and i have to be able to learn from them. once this is in place, everything else does not matter as much.

it would be ideal to work on a great project, but even given a bad project, good people can make it worthwhile.

how do you recognize great people? well, i wrote about it before. everything else is icing – useful, but not a replacement for the good people.

ideally, you already know them – user groups, conferences, friends, books, mailing lists, or you simply worked with them in the past. this is how it should be – you are setting out to work with people you look up to on the projects that interest you.

disclaimers galore: mid size to big company, certain amount of evilness is expected and tolerated for a greater goal. this is mostly a memory crutch for myself (i actually had it written down and would whip it out during the interviews).

personal

• how long have you worked here
• why did you come to this company
• what is some of the cool stuff that you are proud of
• why do you like it here
• what do you dislike about working here (blunt, but you’d be surprised what people blurt out)
• your background (education, previous companies, interests)
• top challenge you are struggling with right now

i had a prospective manager interview me once, and he kept telling me how boring the job was, and how stupid the users were, and how underpaid i would be. while i appreciated the frankness, i could not believe that he expected me to take up a job after such introduction. the whole concept of marketing your company to a prospective employee apparently never even entered the picture.

working conditions

• make sure you see where you will sit (i know i was ashamed to show prospective employees around; at least we had aeron chairs!)
• developer setup – monitors, machine, software installs, certain tools
• what does it take to get software (purchased, installed)
• do you get admin rights on your machine. can you install wireshark/vmware/cygwin/firefox and plugins/etc

team

in general i am after gelled teams – those that know each others’ strength and weaknesses, those that figured out how they can work together and get stuff done. those that simply have fun

• i want to talk to people i will be working with (often people from other teams interview you, and then you end up working with another set of people you’ve never talked to)
• collaboration – does everyone hide their little piles of documents on shared drives and guard them, or is it wiki, company-wide forums, at least sharepoint for the team? how do people share knowledge, within the group and between the groups?
• team culture – everyone for themselves or are they out to learn, help, share
• does team eat lunch together (i found it a pretty good indicator of how well people gel, and i always tried to get people to have lunch together at least once a week)
• day in life

org

• org chart – make sure you know who you are reporting to, who is your boss reporting to, where you fit on the org chart. it might seem silly, but if you are out to get stuff done and you work for a bigger company it matters what your actual title is. after you are hired it might turn out that you have landed at the bottom step of the ladder. that shiny title you got was just that – a title, meanwhile it is your actual pay grade that drives the salary and to an extent how much clout you get. once you are hired, it is much, much harder chew your way through, because then you are subject to the usual organizational inertia, policies, etc, etc. negotiate upfront!
• schedule flexibility (can i work from home?)
• do you expect me to work weekends
• how many hours is the team currently working
• dress code
• what does it take to get stuff done (get a new app/tool up and running in prod, roll your own monitoring, push through an idea, etc)
• mobility within company (in most places HR has a policy that you have to work for a year or more in the position you have been hired for before you can move; is mobility tolerated? encouraged? do they care?)
• growing people – training (books, classes, conferences, tuition reimbursement)
• top org problem you’ve got right now (they might balk, but they might reveal something interesting)
• turnover rate (could be very telling) – how long each of the person you talked to have been with the company, how many people leave
• career path – where can i go, what can i do, how can i move within the company, what are the options, what is the organizational chart like, what is being done to help understand it and climb it. i do not quite trust overly formal you-do-this-you-get-that approach (see Steve McConnell, for instance), but it is helpful to know where you stand and what it takes to grow

in addition, i really like the idea of mentorship – assigning a mentor to a new hire. ideally it happens naturally (in a nurturing and caring team), but it would help to make it a recognized practice. it would be someone with significant experience in the industry and in the company; this person will help to “bootstrap” the new hire (in the ways HR never could) as well as help them navigate the company and grow. having a fellow employee in this role as opposed to an HR generalist will be much more effective.

software development cycle

• source control, automated builds, tests
• qa people
• what sort of testing is done
• how are the requirements gathered and tracked
• how are defects and enhancements gathered and tracked
• how is development organized – timeboxed iterations? waterfall? chaos?
• infrastructure – how much access do you have, who runs it
• monitoring
• automated deploys
• how are releases promoted to prod
• support (be careful here – it might end up in a rabbit hole into the never-ending infrastructure improvements and tweakage – late-night pager fire drills and other joys. i believe in eating your own dog food when it comes to running your own stuff, but this is different from looking after the apps that someone else develops. if you are after a developer’s position, clarify the amount of support the team is doing currently and expects you to do)
• are people proactively fixing things and constantly improving, or is that discouraged (heavily regulated complicated development, throw over the wall support (especially if it is offshored), people just do not care, etc)
• what happens at the end of the project (retrospective? what happens to the team? i want to see the team gel and remain together for the next project)
• code reviews (encouraged? non-existent?)
• who maintains the app once it is live
• how are standards created and maintained
• how are best practices disseminated (arch review board with astronauts? hands-on architects? workshops? training?)

current project

• make sure you understand what you are being hired for – that new spiffy project might never materialize
• where will this project be in a year (could it be one of those “pump and dump” gigs, where you are merely a body to be used and disposed of at the end?)

other

• what are you looking for in the ideal candidate

this last one is interesting. it took me a while to realize that (surprise, surprise!) i simply might not be someone they are looking for.

i noticed that being interviewed puts me in a mode where i am trying so hard to be liked, to please the interviewer. this is certainly natural, but quickly becomes evil, if not held in check (“yes, i would love doing 24/7 support for that cobol app written by mental asylum patients during their work therapy course twenty years ago”).

it is simply counterproductive for both of us. yes, this is a job they’ve got, and yes, it is important, and someone has to do it. indeed, i could do it, just like i could do a myriad other things, but i am after something else. this is perfectly OK, unless you are desperate, of course. and this is where the trick is – know what you are worth and always remember what is important to you and what you are after.