Interviewing Experienced IT People?

thricenightly writes "After more than 20 years in IT I've learned that the most valuable people in a team are frequently the old timers. Young pups straight out of college might (think they) know all the latest buzzwords and techniques, but in the real world, where getting working products delivered on time and on budget is of paramount importance, people who have been doing the job for a decade or two tend to be the people I'd rather be working alongside. I've recently been elevated to a position where I get to interview and choose those who get hired in my department. Although I'm very much focused on choosing the right person for the role regardless of age, experience or whatever, it's probably fair to say the more mature applicants will get a more sympathetic hearing from me than they might from most other interviewers for IT roles. The question is, what do I ask older applicants to get them to demonstrate the value of their experience? My current gambit is something like 'IT is seen as a young man's game. My next applicant after you is 23 years old. What do you know that he doesn't?' This gets responses ranging from the vague to the truly enlightened. All next week I'm interviewing for a number of senior software designer and developer roles. What should I be asking of the more experienced applicants, and what responses should I be looking out for?"

Slashdot ID

I recently took a job at a web hosting company. During my interview with the senior admin, my 5-digit slashdot ID gained me major bonus points... especially since I'm only 24 years old.

Re:Slashdot ID

I think this is exactly what the OP was talking about. Sure, you're a huge computer nerd and can code anything and make it work, but that's a very small part of a software dev job. Collaborating with others, sharing ideas, designing, working with customers, leveraging your position to gain resources, convincing management why you're right, scheduling, so on and so on.. you don't get that coding at home and you don't get that at school.

I was fortunate enough to be thrown in to it and gain the experience in the Air Force, and how anyone "gets their foot in the door" blows my mind. I have some very smart friends who are very capable, but in an actual work environment, they'd be completely lost, and that goes for most everyone fresh out of college with a computer science degree. Experience is what makes you useful. An experienced programmer doesn't need experience in a particular language to be at least servicable, but a hotshot young gun could know a language like the back of his hand and be worthless.

I'm not saying I don't think you are capable or even that I don't think you have the experience. But whereas you (I'm assuming semi-jokingly) refer to how long you've been on slashdot as evidence that you know what you're doing, I would refer to the projects I've worked on and not only the work I've done, but how I've affected the team working on them as a whole and how they've affected me.

Which brings me to the OP's question. Some of the important things I listen for in interviews is how people have dealt with adversity. Name a problem you had on a project and how it was overcome. Name a time your solution was wrong and how you dealt with it. Tell me about a time you had a problem with someone on your team and how you overcame it. The technical stuff is a given -- look at their resume. I want to know how this guy will make us successful.

Re:Slashdot ID

What do I get for a low 3 digit one? :P

What they bring

'IT is seen as a young man's game. My next applicant after you is 23 years old. What do you know that he doesn't?'

I think you'd find they have a keener understanding of how to bring a civil suit for age discrimination.

Re:What they bring

I don't have mod points but I would agree with the previous post. Even implying that age is a consideration in any way would just invite a lawsuit. When you say the old timers are more capable of "getting working products delivered on time and on budget", how do you measure this? Ask questions that might flesh out whether your measure of deliverables is the same as your potential hiree's measure of deliverables.

What you want is not so much an employee that is necessarily older but an employee with predictable skills, attitude, and way of thinking (or at least tolerable) in your eyes. As a bonus, you end up with the most compatible person for the role, regardless of age.

I don't get it

Are you looking for ways to justify hiring more experienced candidates instead of less experienced candidates? Are you worried that the older folks you interview won't outshine the younger folks like you want them to? If you want to build a successful team, you should probably just make hiring decisions based on who you think will be more successful. Your pre-interview biases can only hurt your company and the industry.

Re:I don't get it

There was a trend to hire young IT people because certifications were the thing to have, and younger people work longer hours for less money. The problems with those types of qualifications are starting to bite the IT industry on it's collective ass.

If you want qualified personnel, ask questions that quantify them as a good technical and social fit. Pick some script language they don't know. Ask them if they would take a few minutes to create a 'hello world' script. If all they know is one programming language as seen via one particular IDE... well, it's something you want to know.

It's odd, but hobbies can tell you a lot or nothing about an individual. If they skydive twice a month on average, it says something. If they are working on an OSS project and can show you the sourceforge page... that says something.

There are other considerations; There are not many young Cobol programmers. If an applicant was invovled with the team that implemented X.25 for a large IT company back in the 90s, he's probably a better fit for X.25 network systems than a 23 year old would be.

If all you need is a [name your language here] monkey... you can find that in any age.

Look at your requirements, find a good match to that. Age does not dictate value, but experience can. Anyone of any age 'can' have the right experience, but statistically, it usually works out a bit lopsided.

Questions about Experience

I'd start with an open ended question:
"You are in a maze of twisty little passages, all alike...what do you do?"

I'd follow it up with a more direct problem solving question:
"I need to get all the primes less than 1000, and all I have are these punch-cards...go."

Interesting question ...

Definitely an interesting question.

Most senior (read: geezer) geeks I know have firmly held opinions on ... just about everything. In most cases these opinions are the distillation of decades of experience. This doesn't mean that they are (necessarily) stuck in a rut, but it does mean they are unlikely to be swayed by the language/methodology du jour.

So one thing I would want to know is can they work in the specific environment you have in place (or planned). I've got 35 years and N^2 languages behind me, but you say 'Java' and I say 'Life is too short'.

Another valuable trait in a senior member is the ability to pass on their experience to other members of the team. This can be as a role model, as a mentor, or even as someone who gives periodic instructional seminars. A way to keep balance might be to have some of the younger members give talks on things that are more cutting edge and that the seniors might enjoy learning. For example, I've been using RCS/CVS/SVN since God was a young child, but I had someone half my age sit me down and give me a real tour of Mercurial (hg) and it blew me away.

I'll be interested in hearing what you come up.

Passion is critical

I think I've found that hiring passionate people, whether loaded with experience, or fresh out of college is the key. Someone who is passionate about technology and their job will ultimately lead you to a better work place, and will continually strive to improve on their work. Some people may be good because they've been doing it for a long time, but if they don't particularly care about the job, you can't expect them to continually want to do great things for your company, nor stick around all that long.

Ask about priorities

Here's a question you can ask every applicant. There is no right answer, but it would be interesting and telling to see what they do with it.

Organize these IT concepts by priority:

Uptime
Backup
Customer Service
Security
Documentation
User Experience
Fault Tolerance
Best Practices

Add/subtract terms as you see fit. You get the idea.

Ask about their mistakes

Ask them to talk about the mistakes they've made or project failures they've been a part of.

If they claim it's never happened, or it wasn't their fault, etc, then they probably are lying or stupid.

If they can explain the failure, why it happened and how they've avoided the same thing in subsequent projects you've probably got a good one.

Old goats vs young whipper snappers

As a 45 year old IT person and one time manager, I would ask older IT folks about current technology that you use or plan on using. I'd also find out how current are they on the IT market in general. And I would try to figure out if the person I am talking to is willing and able to integrate with my IT department.

I don't want to generalize much, but there is a tendency for older IT folks to fall behind, often far behind, the tech curve. You know, as we get older, we have other priorities which is OK, but you want that experience they have, but you also want someone who can take your company forward. But older IT folks are also very capable to get upto speed on newer tech often quite quickly.

I wouldn't assume, either, that the young'uns are going to know the latest tech either or even be exposed to it. I do think it would be a mistake to think you could take an older IT person and put them into a mentorship role and have that work out.

no!

Don't mention age! Don't mention you are discriminating applications based on age (even if you phrase it as being "more sympathetic"). You are setting yourself up to get sued bigtime!

I consider it to be a major problem that nobody in IT is willing to train junior-level employees up, anyway. But if you are convinced you need gray hair to do the job, ask them to give examples of projects they have lead in the past. That will give you a legal, meritocratic approach to being a discriminatory bastard.

Interview the person like you actually care, oh an

oh and ...

IT interviewers tend to be terrible as the person who is interviewing proceeds to treat the applicant like auditing a software application. The same terms, styles and such simply don't apply. They are people just like everyone else, only with less showering and better toys.

You interview IT people much like you would interview anyone else:

You ask them deep questions, that require more than a few words to answer.

You put them in problem situations they would normally face and find out their process for working through them.

Get a feel for how comfortable they are with you and other interviewers, culture fit is incredibly important for small organization sizes.

Actually have READ their resume and ask them questions on some of the more small or trivial things.

Ask questions about where they want to be in 5 years, how are they with shifting priorities, what's their work goal for the next two months. Get a feeling for how they deal with change over time.

Ask them what they dislike most about their field. What they LOVE about what they do.

Get them to describe any long term projects they may have been part of and what they feel was their ultimate contribution to it being a success.

Ask them about their worst fuck up, everyone has one. This says a lot about a person when they can easily tell you one and how they learned from it. ... and for fuck's sake don't ask lots of stupid little nit picky questions unless you are sure they are embellishing on their field knowledge. Asking someone about the different arguments to a specific command or sub call shows that *you* don't get it. There's more in IT than anyone person can know, find out instead how they go about learning new things and how actively they do so.

Re:Interview the person like you actually care, oh

Don't ask the old guys
"about where they want to be in 5 years"

They don't give a toss as long as they are coding/testing etc.
Take it from me, once you get to a certain age, you don't give a shit about the greasy pole.
They know their limitations and thus can work within them and get on with the job.
And yes, I have called an old boss of mine a dipstick.
He didn't give me the sack. He just labelled me as an awkward bastard as what I told him about the project was true and it saved his ass.

I'm 55 and happlily desiging complex systems. I don't want to be a manager or team leader. I'm a Designer/coder/Architect/General Dogsbody who will tell you whats what with a proposal/project. Once my new boss understands that, we generally get along fine. Which is why I am a contractor and not a permie. I'm no threat to their job.

Ask questions that test pragmatism

I'd rather have a pragmatist than an idealist any day.

I also don't want to hear never-ending whining from an open source evangelical. If I ask your opinion, and you say Microsoft sucks, that's fine. I asked. But after that, if Microsoft is part of the job, I want to know I don't have to listen to you bitch about it.

In fact, you might describe the environments/toolsets and ask the candidates how they feel about them.

Experience with disasters

Mention how your company is committed to Total Quality Management and ISO 9000 processes. If the guy doesn't start running for the exits, he's not learned anything from his experiences. Try and have someone track him down and explain that you were just testing before he makes it to his car, or you'll never see him again.

A lawsuit?

My current gambit is something like 'IT is seen as a young man's game. My next applicant after you is 23 years old. What do you know that he doesn't?' This gets responses ranging from the vague to the truly enlightened. All next week I'm interviewing for a number of senior software designer and developer roles. What should I be asking of the more experienced applicants, and what responses should I be looking out for?

I think what you're doing is probably a worker's rights violation (disclosing others candidates' ages, asking candidates to make a case for a job based on their relative age). Even if it isn't or you don't get sued, no good employee would want to work for someone who interviews like that.

You should not be a manager. Nor should you be interviewing anyone. You represent your company extremely poorly and open them up to legal action. Or did I (and the editors) just get trolled?

The interviewer's delima

Sounds like: "I am wanting a senior developer, but he needs to be less that 25 years old". Do you work for HR by any chance? You will probably want some who has 20 years of Java development next!? ;)

Way To Get Sued

My current gambit is something like 'IT is seen as a young man's game. My next applicant after you is 23 years old. What do you know that he doesn't?'

It is illegal to discriminate against anyone over the age of 40. (For the US. Differs elsewhere.)

A question like that demonstrates, clearly, that you see age as a factor.

You see it in terms of encouraging older applicants.

People who don't get what they want are often somewhat bitter and tend to remember things differently.

They are going to simply see, "He openly voiced an issue with age. I'm over 40. I didn't get it. I'm suing."

Lawsuits aren't about who's right and wrong. They're about how much it costs you to defend yourself even when you are right. Your company may settle, even though you know you're in the right, to avoid court costs. They may win but still be out the tens of thousands it cost to defend themselves. Either way, you're the idiot who asked a stupid question and cost them a fortune.

Don't put age in to any question. Don't put gender in. Don't put marital status in. Don't put sexuality in. Don't put race in. Just leave them alone.

If you really want to give older people a chance, ask a question that's so removed from "age", no one can sue you over it. Try, "We've talked about specific experiences. What do you think the benefit of your culmulative experience is?" Then the guy who's got 20 years of it can be guided to what you're looking for.

But mention age, sex, race, sexuality, marital status, etc. and you're begging to get hurt.

You'd never ask, "I've got a male coming in next. Tell me how your being a female gives you an advantage he doesn't." or "I've got a white guy coming in next, tell me how the experience of growing up black in America helps give you the edge." Don't be stupid enough to do the same thing with age.

Know?

IT is seen as a young man's game. My next applicant after you is 23 years old. What do you know that he doesn't?

The proper response from this geezer would be, "I know that I can and will crush him under my boot heel, and then then you if you dare ask that question again."

Re:What mistakes have you made?

That good GPA indicates you passed up a lot of opportunities that you'll regret later.

Re:Wrong idea!

Dear Slashdot,
    I have a set of pre-interview biases. How can I frame my interviews to support those biases?

Re:Here's your answer..

You don't get rights just because you're young, old, black, white, yellow, pink, blue, male, female, etc...

Yes, all people are created equal, that does not imply that all people ARE equal.

Experience matters, as does intelligence, attitude and aptitude.

If you can say you have the experience that someone older has, as well as the attitude and aptitude of the older applicant, then you are equal, if you don't have that experience, attitude or aptitude, then you aren't, it's as simple as that.

It's not age discrimination, it's making a decision weighted on key factors that mean more than any education.

I'd rather hire someone with years of experience, a can-do attitude and the technical aptitude that enables them to almost intuitively understand a system or troubleshoot a problem, than someone with only a few years of experience, a PHD and a "I'm too good for your job" attitude any day.