Interviewing Experienced IT People? 835
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?"
Interesting question ... (Score:5, Interesting)
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.
Ask about priorities (Score:5, Interesting)
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.
Old goats vs young whipper snappers (Score:5, Interesting)
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.
Experience vs Time (Score:4, Interesting)
I have about 7 years full time experience under my belt not counting college or any small jobs through high school. I have a lot to learn and seek out people to learn it from. I have met truly ignorant individuals, age has no preference here. Wisdom comes with the right kind of experience. I have learned more this last year bouncing around different jobs than I did at the job I sat at the previous 5 years.
So yes, ask the question, and make sure you get an answer from the younger and older individuals, you will find that a couple of your kids with 10 years of experience will far outshine the older guys with 25 years doing a repetitive job. Same for a 5 year vs a 10 year.
Wisdom is what I look for, not knowledge.
Real-world scenarios (Score:2, Interesting)
If you have 20 years in IT then you should be able to come up with a scenario that goes like "X happens, then Y happens, what do you do?", because ideally you've gone through that kind of thing enough times.
I like the one where I ask them to work through setting up a build system and proper source control for an already-in-the-second-phase project they're taking over as architects. The key there is not only how they do things from a technical perspective, but also if they ask questions like "is there an existing system or procedure in place and who designed/owns it" or things like that. Coders I can get for a dime a dozen; software developers that can function within a large project on the other hand, are few and between.
I also sometimes ask them to do a high-level design of a software application that controls an elevator system in a building. The way they approach that, especially how they abstract problems and manage complexity, is very revealing.
Other than that, the standard 50 question deep tech rounds up quite nicely.
Ask questions that test pragmatism (Score:5, Interesting)
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.
Re:no! (Score:2, Interesting)
Don't mention age!
I agree with Lord Ender bad idea.
Might as well let applicants browse the floor and take whatever equipment they want/burn the company down.
Focus on what you really want instead.
...the people I'd rather be working alongside...
Ask yourself why do you really prefer them. Are they more stable and knowledgeable. Look for those qualities in your applicants. Open your mind to the possibilities. You may find some younger candidates that surprise you. Also you wont be wasting time with irrelevant questions when you should be getting to know your applicants.
Ask: You have a project that is on time but just under deadline. A new technology comes out that could potentially cut development and cost in half. How do you proceed?
Re:Passion is critical (Score:3, Interesting)
Wish I could mod you up at the moment.
I think this is more important than many people realize. You do want to see evidence of experience and a grasp of concepts. (Some people, while eager, are simply trying to "bite off more than they can chew" by interviewing for too complicated a position for their current skills.)
But overall, yes! The person who "lives and breathes I.T." will be FAR superior to the person who views it as "just a way to get a paycheck every couple weeks".
What 20+ Years Have Taught Me (Score:4, Interesting)
My next applicant after you is 23 years old. What do you know that he doesn't?
I know what "Failure" means. Another thing I know that the 23 year old has no concept of is, "What takes to have a medium to complex project completed."
What are you proud of? (Score:5, Interesting)
If you want to get information on how your older geeks think, just ask them, "Of what project you've worked on are you most proud - and why?"
If their eyes light up and you get enthusiastic responses then you know they do this job for the love of the project - the thrill of the chase... And that means they'll be an enthusiastic and contributing member to your team. If you get dull responses then they are in it for the money - or are burned out and might not be the asset you want..
Re:Im young (Score:5, Interesting)
Re:What they bring (Score:2, Interesting)
If we rephrase this into different terms, the problem becomes clearer:
Sir, the next candidate is a hot woman. Can you tell me what advantage a cock has over two lovely boobs in a low cut blouse?
Asking an old guy what his age brings over a younger candidate is similar and you should probably just judge candidates on their relevant capabilities rather than how many times they've had a chance to blow out a birthday candle.
Re:uh.. (Score:5, Interesting)
Older workers might be more experienced, but also have more time to develop bad habits. Instead of asking questions like the one you listed, think up a few scenarios and ask them what they would do in the situation.
I don't think this is stressed enough. Age/experience has a very goldilocks approach in IT. It can be too hot and too cold. You can get the old dogs stuck in their tricks that want to port your entire system over to what they've been doing, or you'll get the ones that are so jaded in the civil war against management and marketing that they are nothing but a poison thorn in your IT department. You can also get masters of their craft that are seeking new ways to expand themselves, but may get bored with the tasks you have for them and leave just as quickly as they came. You'll probably get something inbetween.
These are all different cogs for different machines. Maybe you just need a human appliance in your IT department that you can rely on like a laborador to get his job done. Maybe you need someone who's unafraid to stick up for the IT in front of marketing/management (because lack of competent project managers?). Maybe you need a magnanimous whirlwind to roll through your department and get the engines greased and running on the right track within a short amount of time.
For your money, unless they're pursuing IT as a post-retirement hobby, the older ones will typically cost you more for their output compared to the younger ones, but they'll typically be more reliable as well -- as an imprecise generalization.
Age is no predictor of value (Score:2, Interesting)
Re:I don't get it (Score:5, Interesting)
A skydiver would know. Ever panic and make a mistake? Skydivers don't do that often. Those who do are often not around to tell you what happened or went wrong. Staying calm under pressure is a skill, not just an attitude. Taking risks is a good thing in moderation. Repeatedly taking the same risk creates skills. Crossing the street is a skill you learned long ago, but it takes practice and always involves risk. Risk taking has many forms. It's more of a strength than weakness.
Translated: Yeah, ok, I don't know language xyz or have not used ABC IDE, but lets go for it if that is the management decision. A skydiver (as an example) will also know that if you are asking for something that will probably cause an accident, the time to speak is before getting on the plane, not as you jump out of the doorway. There are other things I could relate to skydiving... or other hobbies. The point is that personal activities tell you more than many certification papers will if you understand what you are looking at.
Certs are like the Md after someone's name.
Q: Know what they call a doctor that graduated 800th out of 800 in their class?
A: Doctor.
Do you care where your doctor graduated in their class if they have performed dozens of operations just like you're about to undergo with 100% success rate? A walking breathing skydiver that jumps twice a month is like that.
Character is worth a lot. You can glean what a person's character is like from a lot of things. These were just examples. Some might not want a risk taker on their team.
On mentoring. (Score:3, Interesting)
The best way I've found is to set up situations that you've found in the past and let the new guy make the same mistakes you made. In a controlled environment.
In my experience, most of the mistakes are repeated over and over. For the same reasons. With the same expectations.
Experience is what differentiates what WILL work (and why) from what SHOULD work.
The best thing about learning from a mistake with a mentor is that you also learn what the characteristics of the breakage are. And how to look for them.
My favorite question: (Score:3, Interesting)
What is the most fascinating technical problem you've ever solved?
Re:Old goats vs young whipper snappers (Score:2, Interesting)
I'm 44 and guessed "righty tighty lefty loosy" was about the sexual habits of republicans and democrats. Wish someone had asked me that in an interview.
I find, as an interviewee, I am way less tolerant of bs companies and psychotic hr people in interviews. I'm probably a prima-donna, but I'm not going to brown nose some clown just to get a new gig. That is an attitude you are unlikely to find in a 20-something, with crushing college loans and a desperation to find out if they can do the job or not.
The biggest problem with old geeks is getting them to shut up. If the OP has problems getting old geeks to talk, there may be a reason for it - you might not be that interesting to them, and they are either being polite, or waiting for the good bit.
You might start with a gambit like 'if at any time during this interview you wished you hadn't come, just tell us, we won't be offended'. If that doesn't work, offer them a beer; either way, you'll at least get some respect from them.
Re:Here's your answer.. (Score:1, Interesting)
It looks like crap and it doesn't even validate [w3.org] (94 errors).
Re:Ask about priorities (Score:3, Interesting)
Well, after the same generic blah-blah that it's unique to every application, I'd try to draw up three classes that could be at starting point at least.
For any project where the users choose your service:
1. User experience. Else nobody uses it anyway.
2. Fault Tolerance. They don't ask support, they're gone.
3. Security. You'll be under constant attack once you have a user base.
4. Uptime. You bet they expect the service to be there when they want it.
5. Backup, as a followup on security.
6. Customer Service. If they they ask at all.
7. Documentation. Nobody reads it, they drop out at #2 or #6.
If it's forced upon them like employees:
1. Fault tolerance. A system you must use and doesn't work is hell.
2. User experience. Not because you care but poor software waste employee time.
3. Documentation. A lot of employees do learning by rote memorization.
4. Customer support. Employees expect support and call it early.
5. Uptime. Systems down cost very big bucks.
6. Backup. Lost employee time is again usually big bucks
7. Security. Might be much higher, but usually protected intranet.
Backend systems:
1. Fault tolerance, if the backend dies everything dies
2. Uptime, it usually needs high availability to feed other systems.
3. Backup, otten the backend holds all the master data.
4. Security, again it holds the master data.
5. Documentation, make sure noone breaks this thing.
6. Customer Support, no direct users and the backend shouldn't have problems.
7. User experience doesn't really apply as we don't have users.
Best Practices
This one I don't count in the list - it's a means to achieving everything else and not a priority in itself and you use as much as is beneficial.
Of course, this can be *completely* wrong if it doesn't fit my idea of a typical project. But anyone should at least figure that there's some general differences between an internet-facing public service and a typical corporate intranet application.
Re:Here's your answer.. (Score:2, Interesting)
But that young person is closer to school, meaning they learned from not just your mistakes but the mistakes of the industry over the past 30 years and very likely the youngsters were playing with real-world code long before they ever could have counted it experience.
You learned something applicable to actual programming in school? All I learned about was Turing machines.
I coded a lot of useful programs before I ever hit college, up to some fairly sophisticated character generators for my gaming group. While I was in college, I learned that everything I knew about programming was wrong, that I was an idiot for using BASIC, and that everything I really needed to know was in Maths. I graduated with less applicable programming knowledge than when I went in, couldn't get a programming job anywhere, and I've actually applied my college knowledge exactly once in the last eight years since.
College and universities aren't teaching you about the mistakes of the industry over the past 30 years. They're teaching you about the mistakes of the industry made before the last 30 years. Forget about the degrees. Ask them for an example of code that they've written, or ask them to write a simple function for you right there. You'll learn far more about their skill as a programmer than age or resume will tell you.
Problems from Project Euler [projecteuler.net] seem to be a popular choice.
Re:What they bring (Score:3, Interesting)
Sadly, having interviewed people straight out of top 5 university CS programs, the answer might be "what a hash table is".
Most important: measure attitude (Score:3, Interesting)
They are passionate about what they do and did not want to get into management where their talents would be wasted. You want these ones.
They're grundging old farts that constantly got looked over for promotion etc. You don't want these.
Ask them about previous jobs. If they bitch and moan about "clueless managers" etc etc then they're probably in the latter group. Remember, most organizations are pretty much the same; they'll soon be grumbling about yours too.
Good ones will typically be able to articulate what they did within a business framework with measurable outcomes: "Improved xxx by yyy%". They will typically have a pretty good handle on ideas like process improvement etc. Look too for good mentors. No point in having experienced people if they just sit in the corner and don't interact with the young 'uns.
Re:Here's your answer.. (Score:1, Interesting)
I'm curious what your definition of "often" is in this case. While I find people across age groups that are lazy, I'm finding it far more likely with younger people these days being the worst in that they want things handed to them and want to minimize what they actually put into the job.
I noticed the same thing... Young Gen-X people seem to be the ambitious type, but the young Gen-Z people tend to expect things handed to them... I noticed that a lot, and even heard of books being published to help employers deal with these new breed of workers...
When I graduated college 10 years ago, I was one of those ambitious people... I often stayed at work till 10pm to insure our products/projects met their milestones etc...
Recently we hired new hires that are of the new generation. So far, many of these people are out the door as soon as the clock hits 5, regardless the status of their projects and when the milestones were... Even when I'm travelling on business and am halfway across the world, they don't want to take any personal time to give me a hand (even if it's to upload a project they are past due on). They didn't even bother taking their work laptops home, because they don't want to "work" outside of work.
They told me they'll upload it when they get in the office. (I called 3pm their time, so they should have been IN THE OFFICE, but they left early). I asked for it at 7am their time, but they said no. Said they'll do it when they come in at 9:30am. Of course that was useless because of the timezone difference, because the meetings would have been over by that time. Had they been in the office at 3pm, or logged in, or whatever, I would've had a full day to get the project/kinks worked out at the client site... But because of their lack of team-spirit, we had to waste the opportunity of being in Europe to test the integration on-site. The next opportunity for on-site integration testing at a different client location was 4 months away. You can guess what that did to schedules...
Especially considering the project was supposedly already done, but this person never bothered to check in their code to the source code repository so I had no access to it. The only copy was on this person's notebook, which was not with her, and not powered on, so it wasn't on the network.
When I was their age, there were times when I would log in, or be in the office from 1am to 7am just to make sure I was aligned on the same time-zone so I could work with the team remotely (budget restraints on travel)
Very frustrating...
Re:Questions about Experience (Score:3, Interesting)
forgive my ignorance, but if you are in a closed loop, would you not end up at the same point if you followed left vs right?
Re:Slashdot ID (Score:3, Interesting)
I have rejected potential employees on their reaction to this one question, and I've been hired to positions myself based entirely on my reaction to it.
Re:Here's your answer.. (Score:3, Interesting)
Which is better and why?
a.)if(true==$variable)
or
b.)if($variable==true)
Re:Here's your answer.. (Score:4, Interesting)
I'm 46 and recently got recruited from a mechanical engineering position (~25 years in the business) to a more of an IT support-type role.
As the least experienced team member (but most experienced, engineering-wise) I was given what I perceived to be a busywork task, i.e., I "felt I was too good for the job" which was essentially data entry. After a bit of poking around on the internet and phone calls to contacts I was able to automate the process and document it, reducing manual input hours for future projects.
If I hadn't said to myself, "Myself, doing this repetitive work in this age is silly and beneath me, so I'm going to find a better solution" I'd be entering that data still.
Enthusiasm and teachability (Score:2, Interesting)
I've seen a lot of things but I don't know everything and usually come away from a contract having met some good people and having learnt.
I think that retained enthusiasm for computing and still being teachable and curious mean that I'm still getting hired.
BTW, you young-uns get off my lawn!
Re:No. (Score:2, Interesting)
Yes, I understand the Worker's Party accomplished many things, especially in the 1930's....Volkswagen, for instance. (Don't invoke Godwin's Law on me here, dammit! It's relevant!)
Don't assume. Unions did accomplish much, but now they're rife with corruption, greed, and sloth. It's time for a reboot. Oddly, you still managed to think that is was my hubris being served, when I was the one talking about new unions, new movements... the UAW aren't the only ones, either. I see Teamsters making $25/hr, and they get to go home at night, when the "common man" still gets paid $0.28/mile, they short him 10% of the miles he runs, and he spends 2 weeks at home, unpaid, in a year. The other 50 weeks, he's on the road, getting cussed at for driving a slow rig that tears up the roads and pollutes the air, while soccer moms are cutting him off in traffic on the way to Wal-Mart to buy the very freight he's carrying.
Honestly, where's this "soar free" crap you're spouting out the side of your neck? I would like to see modern unions fight for the "common man" instead of serving their own special interests. I understand things are different on the other side of the pond, but until you've been herded like cattle through a security gate and metal detector because your employer is worried you'll steal a $1 DVD from him while you've been packing boxes in a 105F warehouse for $7/hr for the last 12 hours with a 30 minute lunch and 2 15 minute breaks, I'll thank you to shut the fuck up.
don't hire out of college... (Score:1, Interesting)
Answers can be faked, Problem solving can't (Score:2, Interesting)
We've recently hired a few new programmers. All did well during interviews (Duh!) but not all are working out well. What's struck me most is that none of them lied or misrepresented them self in the interviews. They just can't solve problems.
Soon after I joined the team my boss started calling me for what he calls a "Sanity Check" Basically, a group problem solving / brain storming session. While I thought it odd that he would seek my advice, I found the exercises both educational and gratifying because was able to bring new direction to our product with my ideas. When asked to interview a couple new prospects last week I took advantage of the opportunity to do a sanity check on something I was assigned. I explained the problem concisely and presented alternative solutions I was considering. then I asked the candidate what he thought I should do. These discussions with the candidate told me more about their ability to solve problems and work in a team than the interview and resume ever could. Having a candidate solve a contrived problem gives an impression on their capability but using a current real world problem was much more valuable to the interview.
Re:Here's your answer.. (Score:4, Interesting)
In a more general IT sense, you're not too far off the mark.
The question isn't meant to test the technical ability of a candidate - though is certainly can be used that way. It is more effective as a method by which the interviewer forces the interviewee to display critical thinking skills. Even if the interviewee answers incorrectly, the interviewer will likely have some insight in to their thought process - an important factor when evaluating specific experience.
At a previous employer I worked for, the team prepared a list of 10 very difficult technical questions (both related to the position and not) just for this purpose. One of the goals was to get the interviewee to say, "I don't know." Bonus 'points' were given if they added, "...but I'd like to know." The point of getting the candidate to say that was to see if they're smart enough to admit their lack of knowledge/experience and seek assistance when they really don't know the answer to a problem.
Print this Thread out and Distribute It (Score:2, Interesting)
Excellent comments so far. Sadly a vast majority of the places I've interviewed have bombarded me with the minutia of a programming language or process. Yet somehow I seemed to be working with about the same ratio of incompetent people at those places as the places where I was hired through a far less formal interview process. And actually I'm pretty sure there tended to be more incompetent people at those places. Just about anyone can memorize an API or process. Very few can troubleshoot an operational issue for shit.
Now that I've gotten 10+ years in this field under my belt I don't fill out applications (That's what a resume is for. You think I have time to fill out 50 individual applications every time I look for a new contract.)
And if I go into an interview and get asked how threading works or what method do you have to implement on the Serializable interface at least in my head I'm thanking you for my time and walking out the door.
I've been doing this for 13+ years. Worked for at least 20 different companies. I'm going to assume that you know a fair amount about programming if you're a software manager and you should be able to tell from my resume that I HAVE to at least know how to program.
The best interviews I have had are the ones where I ask the interviewer what they are doing from an application and systems perspective and I then highlight the positions that I've held that bear a strong similarity to the goofiness and deficiencies of what they are doing. I've yet to work for a company that did everything the most efficient, effective, pretty UML textbook way.
The strengths you get from senior developers are the fact that whatever messed up system you have for development they've probably encountered and know how to work effectively in. They should also have been involved in enough projects that they can immediately translate whatever business process you are trying to model to a similar project they have worked on in the past.
To toot my own horn, I'm one of the best there is in the industry. I'm not saying that there are not more talented people than me. There are. I rarely meet them where I'm working.
As that, I've noticed that I spend about 75% of my time ironing out the business processes behind the application and only 25% of my time developing code. It's not that I don't develop a lot of code. I'm usually a one man team developing the entire application and performing the DBA functions, release management, QA, etc. It's just that I've become so good at the development aspect from my experience that that component of the process is trivial to me.
I guess the best analogy would be to compare it to interviewing a bike courier. Would you feel the need to probe him with questions about how a bike works and if he knows how to change a tire? Or would you be more concerned with questions about how he conducts himself on the business side of his job? You'd think you could take it for granted that he can ride a bike. Sadly, in this profession, I guess that's just not the case. However, it's extremely annoying for those of us who've spent our entire schooling and careers mastering the subject to have to suffer through interviews where to return to my analogy, you're basically asking me, a professional Tour De France rider, to describe how to ride a bike so you can feel comfortable that I can actually ride one so that you'll hire me to deliver your packages for you. AND if I don't describe it exactly how you want to hear it, you'll say "I don't think that guy ever rode in the Tour De France. I don't think he even knows how to ride a bike."
Yes, It's hugely insulting. I pretty much consider those kinds of interviews a test to see how much insult I will take. Preparation for treating me like a piece of equipment once I work there.
Re:You are not assessing competence with that. (Score:2, Interesting)