Slashdot Mirror
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?"
The show's just beginning; the lights they are a dimmin'
I love this thread so much!
You insensitive clod!
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.
I think you'd find they have a keener understanding of how to bring a civil suit for age discrimination.
As a 23-year-old IT professional, I strongly recommend you interview more of them. ;)
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
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.
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."
Take it to the limit, everybody to the limit, come on, everybody fhqwhgads.
The Age Discrimination in Employment Act prevents discrimination on the basis of age of people over 40. If you ask a question about what the next interviewee who is only 23 doesn't have that you have and you don't hire the older employee, you might be accused of age discrimination. Good luck with that.
And what have you learned from them?
Ubi dubium ibi libertas: Where there is doubt, there is freedom.
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.
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.
Not Any more get back to work WE WILL REPLACE YOU WITH SOME ONE WHO WAS 5 years with WINDOWS 7
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.
What is your name?
What is your quest?
What is the airspeed velocity of an unladen swallow?
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.
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.
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.
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
How do think people get 20 years of experience? I'd say you should hire based on qualifications, RELEVANT experience, and (if its for a programming position) quality of code portfolio. 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.
While I don't know if this is the same in the States, asking an interview question involving age in the manner you suggest would be firm grounds for a discrimination suit in Canada. I'm not saying that such things aren't asked, but it's not uncommon for these Human Rights cases to proceed under our Charter.
"You can't win. You can't break even. You can't quit." -A. Ginsberg
... and describes he's having the following problems delivering a product out the door to a customer site that's overseas with engineer support staff that have been up and traveling for 24 hours to get there.
Do you
A) Tell him "Call tomorrow- it's quitting time"
B) Bend over backwards to help.
C) Grouch about it
D) Solve it in 6 key strokes or less.
We have quite a few 'old timers' around our organizations. They think they 'know' it all, too, and they don't. In fact they're much more of a hindrance. We just, after a 3 months of complaining, got one to agree to replace the motherboard in a sun station- we had gone so far as to SCOPE the signal lines on the ports to point out there was a voltage issue... and that didn't even phase them.
A newer younger engineer would have simply yanked the board and dropped a new one in- which, btw, worked perfectly.
There are no right or wrong questions- it's the attitude towards helping out your fellow coworkers that's important. They don't teach it in school but the industry does burn it out. If they're older and they still have the right attitude (including how to help skunk work a project that doesn't have funding through leftover hardware) then they're the right choice.
If they don't have the helpful attitude, they're the wrong choice- age independent.
I work with a multitude of qualified and unqualified IT folks through the military and other contractor sites. All in all it's all about the attitude- that is the one thing I can recall about every single site. Most of the young ones are better with that... but I'm open minded.
Got the 'T' Shirt.
So, where do we start?
I wrote my first computer prog in Sept 1972. Punched Cards, Fortran, ICL 1901.
I, like many people who have been in the IT biz this long (& Longer) have seen it all before. We know how it should all come together.
Want to follows SSADM? - No probs
Agile or Rad? - No probs.
Sandbox project? - Hold on while we roll up our sleeves.
Another advantage is that we are old enough to be able to say 'Hold on a moment' This ain't gonna work' or even 'No'.
Many younger IT hotshots can't do that. How do I know? Well I was one once many moons ago.
What is often needed to make a project run well, on time and on budget is the right mix of experience and enthusiasium as well as age. If this all gells and the team is the right size (No to big) then it will generate it own momentum and things will get done.
What successful projcts do not need are 'Prima Donnas' of any age.
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.
--- I do not moderate.
I'm young and I'd rather work with young people because I find they learn new things more quickly and are easier to teach. OP is older and would rather work with people his own age because of their experience and wisdom and reliability or whatever. Admit that your preference has to do with your own age and move on.
As a classic example, I often point to a database design and a zipcode field. A newbie (and for that matter most people) would declare that zip codes need to be stored as integers and should they need to be formatted with a dash, that can be handled in the application layer. Now this is true in a general sense except for one thing... east code zip codes start with a zero. What will happen when you cast that zip code starting with a zero into an integer field? It's going to trim that leading zero.
Now an old timer will know this and set the zipcode field as a varchar.
The newcomer will not understand how to create objects as well as an old timer will generally as well. An old timer has alot of experience in creating objects and relationships and they have an easier time duplicating real life scenarios into a program or database.
This is my sig. There are many like it but this one is mine.
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.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
How experienced are you? It sounds like you don't have much experience and are thus having trouble gauging others. Is there anybody more experienced in your company who would be able to make better choices? Or are you trying to hire yourself a new boss or lead to report to?
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.
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.
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?
a. Tell me the best thing you ever did, why you think it was the better thing you did, and what you learnt from it.
b. Tell me the worst mistake you ever did, why you think it was the worst thing you did, and what you learnt from it.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
While I'm sure your heart is in the right place, you're looking for something specific and are labeling it in a very unfortunate way.
There's nothing wrong with wanting experience. Try to bear in mind, though, that this experience COULD be obtained in other ways. Fill in whatever examples you want, but YEARS OF LIFE are not necessarily at all what you are looking for - instead you want to know what was learned in that time.
So, by that metric, "My next applicant after you is 23 years old" is a horrible lead-in. You're just begging for an old-coot response, and that kind of environment certainly doesn't make HR Directors smile.
Try something more like, "Tell me something about your work experience that qualifies you for a 'senior level' position". Or, "Give me an example of a time where your work experience really worked in your favor."
Again, replace the desire to find age with finding experience instead. It really, mostly means the same thing, and it doesn't have to be IT-related experience either. One of my best employees used to drive trucks, and I consider him very experienced indeed.
Agism is a common problem.
Do not mention age as a threat: 'The previous applicant is 23 years old, what can you do [geezer]?'
Age discrimination is bad.
If you are actually in a position to be doing interviews. You should know the direction your company is headed, the technologies used, and the common issues you have internally.
The right questions and answers are truely ONLY applicable to your own site. Nobody on /. should be able to tell you what to look for, because we don't know the actual situation.
You are looking for the wrong thing here. What if you would define what exactly in your experience shows that senior members work out better and work out from there?
- Experience and attitude matters. Certainly. There are different kinds of experience and different kinds of attitude. Define what are you looking for.
- People that are not uptight on proving themselves when they are not yet ready for are important, certainly. Balanced work/home relationship - important. Look for signs, not assume things based on age.
- Candidate that will freely and meaningfully discuss his favorite or most missed features from tools he supposedly knows - priceless.
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.
I'd rather be riding my '63 Triumph T120.
I think the big question for older people is not about how young they started. It's about the ability to keep up with the times. I know people who program in Fortran because they learned it in college and "do not have time to learn another language".
I like to ask at least one question that I do not expect them to be able to answer. My personal favorite is "Explain set theory as it applies to relational databases."
Insert Generic Sig Here:
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!? ;)
Jumpstart the tartan drive.
Project. Estimation.
The skill of determining how long an IT development effort will take is something only expereince can give. It was never mentioned during my computer science education and I doubt is emphasized by anyone in academia today, but in the profession it is sacrosanct. Ask them about their last estimation effort. Then ask the 23-year-old what he would do. I can practically guarantee the experienced programmer's answer was superior.
Have they ever been a team lead? I understand not moving into management proper, but if they are a 20 year veteran and have never been a team lead, chances are they've never really operated on a very high, senior level of work expectation unless they're in a niche field. If they're a general purpose software engineer, and have never--not once--taken a position where they were directing other engineers, chances are they were never trusted by their employers to operate as a true senior engineer.
Before anyone blasts me here, I have never known a single senior engineer with 20 some years of experience who has been a good employee worth having and has never had a few people they regularly tasked who had little experience. They weren't managers, but they were responsible for giving tasking and work to junior employees.
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?'
Any statement you make like this will cause a variety of responses, of which only a few are positive. To find out what these guys have going, you do what you'd do in any intelligent interview. You pose a few problems and see what comes out of them. In particular, you'll want to find out something they cannot do, then make them do it. I know that seems cruel, but you can watch how they think, watch how they learn (when you hint them with parts of the problem) and learn whether they just stop and say "NO. I don't know that. I won't try."
Expect that old timers are sometimes just as much incompetent lying little know-nothings who cannot write a FizzBuzz program as the younger set. Test them. See what they can do. And when you find one who can code and think, hire them!
I know the different between what I know and what I think I know.
This also brings the issue of how dose one get experience. Now first is it a Senior position you are hiring for then yes 20 years experience wins but for a junior and intermediate position, 23 year old vs 40 year old should be treated fairly as that 23 year old could be the best kid since sliced bread in 5 years while the very experienced person in a junior/intermediate position may not be pushed to limits, may just slide buy and may just be lazy and over speak there experience.
But besides that the side and interesting note here is that if you rule out the younger guys/girls, and most do then in 20 years how did those 23 year old now 43 year old get his/her experience. This is something I have noticed that people don't want to hire the 23 year old for reasons you stated but then that person who would become what you need, and willing to learn and can FAST dose not get experience and is just slowed down. Young It people have a EXTREAMLY hard time getting decent jobs in the junior to intermediate areas as there is always someone more experienced who will take the pay get it. I am only 27 and got a LUCKY BREAK and I stress LUCKY but I know people who where A students, had soem work experience end up working at the mail as no one would hire as not 10 years experience for a junior position. that was me a few years ago, but not everyone will get a lucky break or have a unkle who is a CEO of Dell or something.
I don't mind the idea of the kids getting less pay and not getting seniour position but when they can't get a junior position as the guy hiring wants a senior guy it can end up hurting the up and comers who are the future of technology.
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.
Ask the applicant to set up Wollongong TCP/IP networking on an AT&T 3B2-400.
Employers are not allowed to use age as a determinate when it comes to who they should hire. I hope you enjoy being sued.
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."
It is taken for granted in this industry (and many others) that more experience == good. There has been some recent research in this area, specifically in engineering management, and the management of innovation, that suggests that when working in innovative, rapidly evolving areas, trying to come up with novel solutions and build novel systems, experience can be /detrimental/ as it acts as a ball and chain to the way things used to be done, and hampers an innovative mindset that tries to figure out a better way to do things.
See, for example, "Innovators' Insights - Which Schools of Experience Should Your Executives Attend?". Anthony, S. D., & Christensen, C.M. Nov 2004. Harvard Management Update. Harvard Business Publishing
Describe the work you are hiring the person for, and ask them why their experience would be an asset and not a detriment to the work you are doing. Ask them to explain their thoughts about learning new skills, using new methodologies, vs doing what they have always done for the past x years over again.
It is my firm opinion that an ability to grow and learn and evolve is the single most useful skill for any employee.
and not the kind who loses tool bags, because lad, you need one baaaahd././
Give them examples of past situations or problems that have come up in your personal experience; ask them how they would deal with those situations. They don't necessarily have to be technical -- indeed, it would probably be a good idea to ask about how they would deal with interpersonal friction, too.
And for the younger candidates, you can reverse your original question: "My next candidate after you has X more years of experience than you; what can you offer that he doesn't?" It may help you sort out the cocky pups who think a college degree makes them king of the world.
http://www.tenjou.net/
You are asking for trouble. If you end up not selecting this individual, he may feel that it is because of his age and if you get sued the question will sound biased to a judge and jury. Consider something like "How has your experience benefited you in problem solving, and what is it that you have learned from it that less experienced applicants might not have yet realized?" or something similar.
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."
The most important thing to weed out is whether they fit within the mold of the team as a whole. Ask them their personal strengths and how those would translate to your team...have them explain how they can use that knowledge with a younger group. Then find out how much up to speed they are with new technology and buzz. Even an older IT person needs to at LEAST know of newer technology even if they don't know how to implement and use it...their knowledge could help someone younger get through a newer problem or to teach them some discipline in the job or just be there for a paper-clip fight. Their knowledge matters most...then how they can relate it/add it to the TEAM. If THEY can figure out how to make themselves useful within your group that will make them most valuable and most likely to fit in and be an asset to the group. Just make sure you don't land someone that is so set in their way that they argue every point with you...I've had those types too.
your question is stupid: "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 older guy you are interviewing doesn't know anything about the guy that you will be interviewing next. He cannot possibly answer that question with any honesty.
How about asking them:
"Why are you willing to work for the same salary I'm going to pay the 23 year old?"
People are different. Some people can do the same things for decades and not learn a thing. I know a 60-yo developer who still says that X is going to take two weeks, when I can say instantly that it's more likely to take 6 months.
Then again there are those who live and also learn. From these people you should expect to see e.g. some of the following:
1. Ability to see what's relevant and what is not. Experienced people should be able to prioritize well, and see the forest from the trees. Junior people often pay attention to things that aren't all that relevant, i.e. miss the big picture.
2. More practical, less idealistic. Experienced people accept that the purpose of most companies is to make money, not to use emacs where it doesn't fit.
3. Better w/people. Experience helps w/dealing w/people. Many find the correct balance between hard and soft w/time. You should know when to push things, and when not to.
4. More experience means more experience in many areas. People who have lived for long tend to have better understanding of a wide variety of issues ranging from history to psychology to business and politics. More knowledge and more experience means that they can see things more clearly and come up w/stuff the young ones cannot, because they don't have the equal processed information databased between their ears.
5. They have made many mistakes from which they have had the chance to learn. I know I have already done my share of mistakes, and I have worked very hard to not to repeat them. Within this process of self-perfection lies the potential for true greatness.
There' surely are many more things, but here's my quick 2 cents.
The lyf so short, the craft so long to lerne
which are like Burger Flippers.
They will write code for near minimum wage or under $25,000 a year with a comp sci degree or Microsoft certification. Usually aged 22-30, no spouse, lives at home with parents, and works 80 hour weeks with no extra pay.
But does a sloppy job and systems crash 12 times a day or more, but good enough to get work done.
The 35 to 65 aged IT workers will draw too much salary via their experience and will be worth $45,000 to $150,000 a year as Master Programmers. They will do quality work and the computer system never crashes because they close every object they use and free up memory and other advanced programming techniques. But since quality takes longer to code that sloppiness the Bit Flipper is usually hired over the Master Programmer as most managers don't understand how computers or programming works and hires and keeps the ones that can code the fastest. Not the best at the job, not the higher quality work, and not the more experienced or professional either.
Bit Flippers are usually narcissistic and selfish, or more like egomaniacs, but they tend to keep to themselves and write code most of the day while cussing out coworkers and managers under their breath.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
...I think you should focus less on age and experience and more on recognizing potential.
Obviously your age and experience have not prepared you for management. If you insist upon being a manager, develop an innate ability to read people, and pick them for their skills as well as their potential. This is why managers are not hardcore code monkeys, but instead people handlers.
.. or at least, I have left until there is need for experience from someone who has not yet retired (but would rather sit on his hands than allow himself and skills to be trivialized by the assistant accountant) but has been involved with high performance systems at the hands on level (ranging from RTL, CPU microcode, massive hw logic, C, C++, STL, unix, python, embedded) since mainframes.
Noone values true understanding, just the appearance of experience.
One common thing I noticed on resumes of younger IT candidates was the '18 month bounce'. The string of jobs they list all had right around 18 month durations. Which is just enough time to get familiar enough with a technology/process and put it on your resume before hunting for a new job.
The older candidates had longer stretchs of time at companies unless there was reorganizations/acquisitions or other events outside of their control.
I think it's a mindset thing. I don't know if younger candidates understand that a pattern of leaving just when you should be starting to add real value is a very bad thing to do to the company that hired you. It may be a 'what can you do for me' mindset.
Yes, I'm a bit of a codger myself in the IT field. When I was interviewing I would always ask what the candidate could do for the company. It's amazing how many of the candidates had no idea how to answer that but had plenty of statements of what the company could do for them.
If an interviewer asked me what you did I would thank them for their time and stand up to leave. If they don't know the difference between almost two decades of relevant work experience and a newly minted college degree then I don't want to work there much less spend the time explaining it to them.
The problem is that knowledge is typically easier applicable than experience. You have to make sure that the experienced people know how to bring in their experience.
Additionally, you have to consider what is more important in your situation.
And remember that just because someone's been working in IT for 20 years does NOT mean that they have 20 years worth of experience. They might have 1 year of experience, twenty times over.
What I'd be interested in is how they understand the changes from when they first started to today.
And where they agree and disagree with the changes.
After years and years in this industry, people form opinions.
In my opinion, WinNT was great at 3.51 and became unstable at 4.0. Moving to 2000 was okay but they've kept the same scheduler all the way to 2008. Not to mention that they never learned to insist on clean divisions between apps and data and system config and user preferences in such a way that makes backing up the data and the config and the apps simple.
Don't get me started on the ease of making system backups on a Sequent system. They had bootable tapes. If anything went wrong I could restore the OS by just booting it with the last backup tape.
Uphill! Both ways! In the snow!
And I had to write a WYSIWYG word processor for an abacus! Without beads! Before zero was invented!
Regardless of the age of my interviewee, I ask "why" a lot. I have the person describe what they did in this or that position or job and what decisions they made or contributed to. When they finish telling me about some decision, I always follow up with "why". Their answer will generally tell me whether or not the person is lying or exaggerating their role, but it also tells me a lot about their reasoning process. I'm not much concerned about whether or not I agree with their decision as much as how they arrived at it. As for old geezer (like me) oriented questions, you could ask about what they know from 20 years ago that still applies today. Make them be specific though. I'd also ask them to talk about how they learn and how they help their colleagues learn and grow. When I interview the "young 'uns" I ask questions about the aspects of development that aren't as much fun or as glamorous to see if they are serious. I put them into decision making mode and when they give me an answer, I ask them why. From my perspective, oneâ(TM)s abilities to reason, learn and share knowledge trump expertise in some technology. Technology changes all the time.
Very often, people confuse simple with simplistic. The nuance is lost on most. - Clement Mok
"Young pups?" Please.
I have decades of experience. Would you please tell me the name of the company you are hiring for so I don't accidentally end up working with someone as pompous and patronizing as you?
Your problem isn't others who "might (think they) know" things. It's the guy you see in the mirror who thinks he knows the "real world." I won't shed a tear if the responses to one of your oh-so-clever questions is a lawsuit for age discrimination.
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..
"Straddling the sword of technology..."
The question is this:
Given a software project such as (briefly describe a project the candidate might typically be asked to handle), how would you do it? What steps would you take?
We then let them speak. Everytime they stop speaking, we say "And then what would you do?"
The Question is terrific for evaluating a person's approach to software development. For example:
and so on.
You're an idiot if you think age or years of experience correlates to being competent. I tend to find the opposite is more likely to be true if anything. Old timers have had way more chances to get into the roles they're in by being promoted by people who dont understand what they do than people who've only been in the industry a few years, they're more experienced at office politics and blaming others for their failures, they tend not to have grown up with computers making them less adaptable, and perhaps most importantly their skills are quite often stale and outdated - if they've been in the same job for years, which they most likley have seeing as how older people tend to jump around less than younger ones, they dont know anything except the things they did in that job.
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.
You may require a specific skill set or technology, but the reality is that math and customer service hasn't changed all that much.
The servers need to work, the apps need to run and the customers and users need to be happy. If you need someone to twiddle something in the Next Hot New thing, hire the old guy and get him a code monkey.
Additionally, what the employee doesn't do is likely to be as valuable as what they will do. By the time someone hits their 40's or better, they're unlikely to say "screw the company" and fly off for week long drunken orgy with your secretary. They're also unlikely to do socially inappropriate things in front of customers or do really stupid things with your hardware like yanking good drives on a production machine "to see if the RAID works".
If you hire the right person, he's also likely to know how to cover your butt when something bad happens, where the young guy with nothing to lose would be just as happy to throw you under the bus.
Isn't agism illegal in CA (and in most states)? I discuss an applicants experience, but have been told not to discuss age. Same as race, I would not ask if someone was asian or hawaiian in an interview, even if I was from Hawaii. If I did they can claim that is why I did not hire them. Btw, most of the 50+yo applicants I have interviewed were entry level with only a couple years experience.
Out of curiosity, are you (or have you ever been) a Microsoft employee? It's been years, but every time I talked to a Microsoft recruiter, every other sentence had the word 'Passion' in it.
I'm ok with co-workers enjoying software. I think its great when they find computers paradigms fascinating. But I'm not sure I appreciate co-workers having passionate experiences with their computer.
I interview people for a variety of technical jobs...
Given the same intelligence and professionalism, younger people tend to be more aggressive, have a better grasp on the latest tech, and most likely be more willing early adopters. OTOH, the older people tend to be more cautious, weigh the options more, and not stumble as much.
You really want a mix of the two; you want older people to leaven the mix, provide balance and guidance (often both personal and professional) and younger people to be the shock troops of pushing the envelope.
I would never ask a point blank age related question; I would ask, however, things like
"You are the leader of a project team. You've been given a legacy application in a language that no one on your team is familiar with. You have partial documentation of the application and full documentation of the language. Describe your approach to developing a set of specifications and a work plan to re-implement this using current methodologies. Write a memo to your management outlining the issues and the work plan. Include requests for resources outside your team you may need."
If you were to do something like that you'd learn a lot about how people approach a problem. That's where experience comes in.
I think experience has more to do with interest and application than with "time in grade". I am in a similar position, where I interview and select staff for the IT department I run, and I am myself a "senior geek" as someone put it in a previous post. I look for depth of experience, and applicability to the environment. Some 20-somethings have a significant ability to dig into a problem and resolve it or develop a solution to a problem. Some 50+ folks with 30 years in the field have similar abilities, and some, just as frequently as the 20-somethings, patently do not. The "fresh out of college, gung-ho, all the latest buzzwords in their iphone" categorization is a label, just as the "experienced veteran" is, and neither really do anything more than prevent someone from making a real assessment rather than assuming their first impression is the sole and impeccable truth. I look for interest, for willingness to learn, and for an understanding that the practical result is the focus, not the method used to get there. The "real world" is very rarely well represented in the academic environment in my personal experience; it takes real hands-on with a meaningful task to get the kind of experience that is of value. By the same time, I know people that don't have 20 years of experience; they have 2 years of experience 10 times. There's more to it than just being there; making a difference is not a function of age, but of application. Forget the preconception that someone just out of school doesn't know what they are doing, and that someone with 10 years in the trenches does; it bears just as little relation to reality as the assumption that someone fresh out of school knows the latest methods or has the most recent insight. Remember that it is not the first to try it, but the first to make it do something of value that is the one who succeeds. Someone interested, willing to learn, and confident enough in their own experience to try, while still recognizing when it is time to seek help gets my vote every time. How old that person is has no place in the decision, or in my approach to seeking their value.
You can ask them anything you want, but just show them where the docs are. No one can or will memorize everything about any job. that's what books and Online reference material were designed for. The only thing they will have memorized are the things they worked on last.
No matter how low their slashdot ID and no matter what questions you ask, this (posting this on slashdot) won't end well.
Why bother
Don't ask anything that even remotely looks like it's age related. If it gets out to the younger applicant, though unlikely, you may have an expensive age discrimination lawsuit to ask. It doesn't gain you or your company a thing to be so candid.
Do not mention other applicant's at all. Simply ask what experience they bring to the table that's relevant to the job, and what similar work they've done. Ask this for each applicant. "I spent 10 years working on critical system XYZ" is a much better response than "I helped the cute chick at the IT lab get her assignment in on time". Also, if an applicant answers this question well (regardless of age) it can lead in to more detailed questions and you follow up with the younger candidate if he or she gives a good answer.
These posts express my own personal views, not those of my employer
"Do you know COBOL"?
The contest for ages has been to rescue liberty from the grasp of executive power. -- Daniel Webster
For kicks, here's a clear-cut quote:
(c) It shall be unlawful for a labor organization-
(1) to exclude or to expel from its membership, or otherwise to discriminate against, any individual because of his age;
"ARE YOU A VIRGIN????"
In times of universal deceit, telling the truth gets you modded -1 Troll
Honestly, the question doesn't make much sense. I don't mean the one you ask your applicants, I mean the one you asked us.
Is your salary range wide open? Most positions I know of that might attract qualified senior people are completely out of range for someone who's 23. If I were asked this (and I'm not THAT far past 23, though I started professionally at 21) I'd be surprised. No one that young has really had a chance to accumulate the experience required for the positions I interview for.
So if your salary range is low, you actually might want to discard your more experienced candidates. They should all hold better positions, and the ones that don't you don't want. There will be exceptions of course, but finding them might be rough.
But let's assume it is wide open, or at least a large range. What are you actually looking for? It sounds like you want people who are 'good'. That's pretty vague. Are certain skillsets required? Are you willing to let them learn on the job if they show promise (my current position uses a language I was unfamiliar with, but I made it obvious during the interview that I knew how to program)?
If you're looking for generic questions, then ask them how they would go about solving a variety of problems, from simple to complex. While what they consider a good or not so great solution is important, far more useful is the decision making process that made them arrive at the answer they gave you.
Also, a fun interview question I like to throw at people: I'll look at something they list multiple types of on their resume (usually OS and Database). Let's say they've listed MySQL, Postgres, Oracle, and MSSQL. I'll ask which is their preference. I don't actually care. It's a setup for the following question, which is why? Many candidates will pick one and not have a reason.
Me: What about Oracle do you prefer?
Candidate: It's the best database.
Me: In what way?
Candidate: ummmm
in contrast, I was perfectly okay with:
Me: Why do you prefer Solaris?
Candidate: It's the one I'm most familiar with.
Bottom line, figure out what you want. It'll make it much easier to know when you find it.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
If they answer "yes" I put a small mark on their application next to their experience. I find this answer indicates naïvété. I hear "I don't have enough experience to have realistic views or expectations of the field." In this case a "yes" answer drops them a bit lower in ranking.
:)
Work in IT long enough that you experience your first dressing down (because his favorite screen saver quit working) from an idiotic supervisor whose idea of advanced technology is a toaster. Work in IT long enough to have your non-IT coworkers complain that they see you around all the time when the network is working correctly, and you disappear (into the NOC) when the network goes down. Work in IT long enough to *not* hear praise at how quickly you recovered the entire system after the server crash, but hear instead about how much overtime you burned (40 hours) in two days.
If you say "yes" after all of that, either you're lying or you're so pumped up on Prozac you could giggle your way through Saw IV.
-Joe
Get off my virtual lawn, you damned virtual kids!
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.
Now that I'm very close to 40, I see what I used to be like when I was late twenties, early 30's. They think they know it all, and what they don't they can read. Well, sorry you'll find there is no substitute for experience. 90% of the little gotcha's while developing aren't something you will read about, only experienced. I was just consulting at one company loaded with late twenties, early 30 year old "Directors." Comical to say the least.
So I'd ask questions along the lines of what isn't in a book yet about a particular technology. See if they understand the lessons from experience. If they focus on saying things like dynamic languages are great, I love ruby or "Agile/extreme programming", just walk away, either experience has taught them nothing or they have no experience.
A question which can separate the wise from the inexperienced is: "given a situation (interviewer can make up), what do you think is the best approach: 1) to use the existing code or 2) dump existing and write it all from scratch?" Regardless of the 'the situation', many newbies, especially from hot shot engineering schools often will answer #2 and give a coding estimate that is unreasonably short. Unreasonable for 2 reasons, one, they can't hit their estimate in the first place and second, to get the bugs out to make it a useful application often takes way longer than anticipated. I know this is a generalization, but its like Eisenhower said, "all generalizations are wrong including this one" - Lou
If this isn't blatant ageism, I don't know what is.
I'm 27 with 11 years of experience, and you want to know what my favorite buzz phrases are?
I'll spoil it for you:
I've seen some of the oldest programmers create some of the shittiest code. It caused maintenance headaches for literally years, and wasn't accomplished any faster than doing it the right way to begin with. And these guys were in their late 40s when they wrote it! Mr. Three-Dimensional-Arrays-In-Java, I'm looking at you.
I could tell just by looking at the style of code they wrote that they were C/C++ programmers with too much experience to write good Java code. Overlong, overcomplicated methods with cryptic variable names, heavy use of arrays, heavy use of magic numbers, and the list goes on.. Not to mention that for five years one of our companies primary application executed entirely as a side effect of its constructor because they didn't know how else to make code run in a class.
Long experience can actually do more harm than good. What I want to see is relevant experience code with a heavy emphasis on quality and maintainability.
Question everything
Tom Smykowski Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!?!
I am a 23 year old User Experience Architect and I've been working in the IT field since I was 16 years old. Before accepting my current employment, I encountered a firm that was big on age/experience and was comprised of mostly engineers in the 35-40 age bracket who had been working in the industry for 10+ years. I was asked a question almost exactly like the one you postulated.
Using simple math I constructed the following response, which I believe caused the interviewer trouble with the big wigs in the room:
I've been working in IT for about 8 years now of my 23, where as this older gentleman has been working for 15 of his 45. Since we have both been in the industry gathering career experience for the exact same percentage of our life experience, the question should be about quality and adaptability. Not quantity.
I wonder what happened to that guy...
My next applicant after you is 23 years old.
This is a great way to create liability for your company. Age discrimination is against federal law and simply mentioning it is cause to be sued. Simply put, don't!
My next application after you has a penis. What do you and your vagina know that he and his penis doesn't? Obviously that sounds bizarre but hopefully it make my point. Asking questions which imply age is part of the equation is simply asking each applicant to sue as they leave the interview room.
Simply put, don't!
First off, I am a geezer. Turned 69 earlier this week and still work 40 hrs/week doing intranet web design using Perl.
One of the things to look for is whether the experience candidate has 1 year of experience 20 times versus 20 years of experience (or in my case 40+ years). I've known geezers in both camps. You obviously want the latter.
Personally, I've been a slashdot reader since back before Rob sold it -- Hell, I even sent him a Christmas card with $10 in it for beer money back when things were starting and tough. I've always tried to stay current in the field -- and I go back to when you had to read Computerworld every week to do it.
My design and coding skills are good. My code is maintainable. But my real benefit to my company is my knowledge of the manufacturing plant. There really isn't a white-collar job in the plant that I couldn't perform because I know how the systems work, how the employees do their jobs, what data they need to do the job. They pay me for that institutional memory which I bring to bear when I design web applications.
They, quite frankly, are scared to death that I might retire.
dc
Largo, FL
What is the most fascinating technical problem you've ever solved?
As has been said repeatedly, do not go in for age questions. That's a lawsuit waiting to happen.
First and foremost, you need to define the job you are hiring for. For example, looking at all the responses on here, it would seem that the average response assumed that you were hiring a programmer. Since you said "IT", I'm guessing you're actually looking for either a systems manager or tech. But you need to know that is what you are hiring.
If you haven't done so yet, sit down and write up a detailed job description. List all of the duties expected of that position and the competencies required. Will this person be actually working on servers, workstations? Will they only be handling one area? Will they be a manager, and not expected to do the actual work themselves?
If you can't do that, you're already in trouble. You need to know what you are looking for before you will find it. You might go through the hiring process and find the best programmer in the world, who can write code to make a computer sit up and dance. The problem is, if you need someone to run and maintain your email system, that coder is probably not the best choice.
Once you have done your job and determined what it is you are hiring for, then start looking at the type of work that person will be doing. that should lead you to some questions which will determine whether or not they are knowledgeable. From there, ask them about their successes and failures. Give them some scenarios and see how they work through them.
But, if you value your company, do not ask any questions about age/sex/religion.
Necessity is the mother of invention.
Laziness is the father.
That is age discrimination. You shouldn't mention anything about age, nor should you immediately judge based on age. There are a lot of older people that are still doing the same damn thing they did 15 years ago because they haven't grown. And there are a lot of "younger" guys out there that are real rock stars, learn very fast, and contribute a whole lot more. theYou should base your judgment on their actual skills. And if you can't tell that from an interview, then its not the candidate's fault; your interview skills just suck.
You don't know what you "should be asking of the more experienced applicants, and what responses should I be looking out for" and you have a bias for a certain age group. I bet you'll pick the "best" qualified candidates.
A good way to test this at interview is to put a keyboard in front them and ask them to type as fast as possible. The smart ones will use copy-paste. The even smarter ones will use VB. Generally the more experienced ones will have written more lines of code (ideally in a very hard language such as Java, further demonstrating their sophistication) and this means they are definitely better.
Hmmm. I think I'd watch that one, if I were you. From me, it might elicit a response like "I know a good employment lawyer." Besides the intimation that you think I'm too old, calling it "a young man's game" makes me wonder if you hire women. Maybe I'm just a little too cranky because I just got my AARP membership this summer (and I missed my afternoon nap, besides), but I don't really want any references to my age in a job interview, any more than I want references to my gender, race, religion, or sexual preferences. Either I can do the work you need done at a price you're willing to pay, or I can't. The point of the interview is to help both of us figure this out, and my age has nothing to do with it.
About ten years ago, I had my first experience with being interviewed by a hiring manager who was significantly younger than I was. He wanted to know what was wrong with me that I had been working for the same employer for seven years, which was, I think, longer than he'd been out of school. I didn't take the job because it was contract-to-hire, but the suggestion that I was "old" when I hadn't even turned 40 yet irked me considerably.
But, anyway, since I wouldn't be interviewing unless I wanted to work for your company, I'd probably just make my lawyer comment and smile, to let you know you've stepped out of bounds, and try to come up with some blather about how there is certain virtue in experience, citing what examples I could of things I doubt the younger contender has ever seen in our field. I would talk about the transferable skills and knowledge that have allowed me to jump between a good half-dozen or so programming languages, and from dial-up serial communications and X.25 to IP on gigabit Ethernet. (My company hasn't made the jump to IPv6 yet.)
Now that I've answered your question, please get off my lawn!
"Who controls the past controls the future. Who controls the present controls the past." -- George Orwell
It seems this manager suffers from a highly typical epidemic in the IT (and really many other) fields: older = better Unfortunately, its really not the whole story and is quite typical of the middle-aged conservative manager. While older workers may indeed have more experience in whatever specialty in IT they're in, they also suffer from some serious drawbacks. They cost more. Hey, let's face it, labour is a market, and they're going to be a like a Mac - they'll 'just work out of the box', but they're going to cost a bomb. Continuing with the Mac analogy, they'll be harder for you to get them to work the way YOU want, since they'll have their own strong opinions about how your project should be done, which may or may not be beneficial or in line with what the organisation needs. Thirdly, it is a rare indvidual that decides to keep learning. After 20 years in the same field, most people aren't interested in the newest technology, the newest ways of doing things, and are generally far more conservative about the way things should run, and what tools should be used. This flows even down to their attitudes towards work, which they'll happily sit there doing some ridiculously mindless task without even beginning to think of a smarter or faster way of doing it, because "thats the way it's always been done". Sure, younger workers have their problems. Lack of experience may mean more mistakes, or they may be beset with (shock! horror!) confidence (perhaps in overdoses in some cases, its true), but the slightly smug tone in the OP suggests that a reevalution of older workers would be more than worthwhile.
I know that if I don't get this job I'm suing you for age discrimination not only for asking this age based question, but if you know the next guy is 23 and seem to care a lot about it, you are likely guilty and I'll finally be able to retire like I've wanted to for the past 15 years.
You forgot CowboyNeal you insensitive clod.
Life moves pretty fast; if you don't stop and look around once in a while, you could miss it. -FB
You can't tell somebody something like that. You aren't allowed to ask an applicant their age, nor can you discriminate against age.
Dot ARPA
The miracle of DNS
Syncing crypto across satellite links
Bit rates from 45.5 bps on up to the present
The Morris Worm
The Internet long before anyone could spell HTTP
Ada
dBase2
WordStar
Osborne (books and luggable)
16/32-bit software upgrades (and now 64-bit)
Y2K
I'm convinced that anyone in IT who is not equally experienced in both communications and computers is badly handicapped.
I'm on your lawn. How would you get me off of it? (the legal comments elsewhere are very very pertinent. If you actually asked the question about the 23 year old in CA you would face disciplinary action from your company and possibly a lawsuit from the candidate.)
You should simply find people who deliver. As close to the deadline as possible, with as few issues as possible. How will you know which ones they are? You can't in a couple of hours during an interview. They might come across as geniuses during the interview, but not really deliver when it comes to it.
Blind passion, in my experience (an ex-C++ developer recently on a sabbatical, just turning 30 and having worked at top companies with top people for almost a decade) tends to fade away with age. This is a natural process. It does not mean that work ethic leaves alongside the naivite of youth.
Do those of you in a long term relationship, or those married feel the same about your partner as you did when you first met them? No. Does that mean you don't love them anymore? Most likely not. It's just a wiser experience, and you know what buttons to push, and just hard enough for them to react.
So my only suggestion is: hire the most promising candidates, and let go the ones who didn't deliver, regardless of age. And _the_most_important_ aspect of how to keep the good ones after you've found them is: treat them with respect. We're not lifelong idiot adolescents that only require pizza and gadgets to be happy. We do outgrow our foolish youth quite fast, and then we tend to get pissed if we figure that our employers have done their best to shortchange us with tired catchphrases.
Let me rephrase that: you want to keep me, pay me what I am worth. It's as simple as that. It is, after all, a business relationship: I'm selling you my skills for money, so the money I get is a direct (and the only real) indication of what I am worth to you.
Here are the job requirements (in writing given at the interview table to each candidates)
Do you have any questions about them?
Now tell me how your experience and aptitudes and training enables you to meet this requirement.
and this one...
Take notes about what they say and your impressions and score each applicant.
By tying the question you ask to job requirements and the selection process to their answers, you stay legal in your selections...fair too. And by not asking a bunch of "I wonder" questions, you stay efficient.
The very fact that you have to reduce the job requirements to less than a dozen sentences makes you focus on what you really want/need from the position.
I would ask them to tell about some IT disaster that they have been involved with in their career. And then what did they do to prevent it from happening again.
It will give some insight into how they learn from mistakes and attempt to solve problems. This has worked for me in the past quite well.
It they cannot/do not answer they either lack the experience you are looking for or are incapable of admitting that they made a mistake. In either case you would have your answer at that point...
The real issue of experience in IT is not whether you can never make a mistake but how you handle it when you do - the younger ones often do not get that.
Here's some questions that should help you get to the substance of someone's experience, and past the alphabet soup of accreditations and acronyms. Only experienced people will be able to answer these with an ounce of credibility or insight:
1. Can you tell me about a project you worked on in the past that you would really like to have a chance to go back to and redo in one way or another, and why?
2. Can you tell me about a project or situation where you had to discover the requirements for the client, because they didn't really know what they needed (even though they might have thought they did)?
3. Can you tell me about a project that did not go as planned and why? / Can you tell me about a project that went exactly as planned and why?
4. Can you give me a brief history of web development techniques and innovations since the early 90s? (only relevant to web developers of course)
5. Is open source best understood as a development method, a social movement, or an ecosystem? (only relevant to positions relating to open source of course)
--Julian
I think you're right in the question you're asking.
When I was first applying for jobs (circa 2000), I saw places that asked for 15 years experience with Java. Which hadn't existed for 15 years. My point is that both old and new developers may have the same number of years experience with the tools/languages, since the tools have only been around so long (how relevant is Windows 3.11 experience?)
Also, the very fact you're getting responses from vague to enlightened shows your interview question is effective. You're not hiring everyone; the purpose of a good interview question IS to find the enlightened and hire them!
-- Political fascism requires a Fuhrer.
Ah, but the problem with older coders is:
The young whippersnappers will forgo life and sleep to put in the time they need to fix what they screwed up due to inexperience. But since they put in more time, it'll appear that they work harder. So if appearances count, don't hire the old people.
DT
Is this thing on? Hello?
User Experience
User Experience
User Experience
That's why I (and you) bothered to format our responses.
I'm a software visionary. I don't code.
You should be asking everyone the same questions - questions focused on specific objectives of the position you are hiring for and getting the candidate to explain how their previous work experience makes them the best qualified candidate for the job. It helps to understand how their previous organizations functioned, and it is also interesting to get them to explain the single biggest impact they made in those positions.
I think this is a good outline.
During the course of the interview, you try to find out what kind of work type of the candidate (creative, builder, organizer, producer), communication style (driver, analytical, advocate, facilitator), their focus (internal vs. external and/or task, department, function, multi-function), whether their previous experience is comparable to the position, technical competency, whether you felt their were being forthright, etc.
Try to keep standard interview techniques in mind - such as getting the candidate to talk four times more than you, make sure you have some standard questions to tease out details about dealing with constraints, conflicts, their leadership style, their perspective on what others thought of their work (which you then cross-reference against their references), and so forth.
The key is finding the right person for the role. When a job interview becomes a personality contest or wanting someone you'll like, you've failed. Get a good interview technique book. Hiring the right people is the single most important thing you are going to do. Don't think any the advice you get here is going to be good. You need to carefully think this through, have prepared questions and do everything you can to make a good assessment. It's not an easy skill - and it is one you will pay for in the long run if you muck it up.
I can't speak for the development world but the admin side I have been fighting the age discrimination issue from the beginning. Age should not matter, ability should. Right now I am the lead tech in the consulting firm that I am employed at and I am the youngest person there at the age 32. If you want to talk about experience I have been working with computers since a very young age. I have worked people that are younger, older and the same age and it all comes down to their ability. Not their age nor their experience, especially on paper.
Is he looking for someone to date? Why does it sound so much like he does..?
Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.
Including age based questions like that can get you in big trouble with the labor board (at least this is true here in California). The correct way to do this is to ask questions about experience, e.g. "what does your ten years of experience give me over the person with two years of experience?"
-- Will program for bandwidth
.... you realize that he is not trying to convince you to hire him but rather trying to decide if he wants to work for you.
I work with people young and old and I find that there is different value in what each bring to the team. Young, bright kids tend to have more energy, enthusiasm and inspiration. Older usually means family which reduces their enthusiasm for long hours and travel. Young engineers will usually have the "hard skills" (as in technical ability, programming knowledge, etc) and they learn very quickly. On the other hand they often lack soft skills such as the ability apply systematic troubleshooting to an unusual problem, the experience to instill calmness and focus in a crisis, the ability to "stealth manage" a project with an inept PM or the ability to fix a really stupid customer's problem while managing to make that customer look like a hero to his management.
Yes, often older engineers will be instinctively guided toward solutions they have seen work--which is sort of the opposite of innovation. Some older guys do fall behind on current technology. Others realize their only job security is their ability to learn new skills and seek out new problems. You want to hire the latter.
Youthful enthusiasm vs age and experience? I think you need both for a well-rounded team.
I know where the bodies are buried. Muhahahah!
I tend to disagree with the whole reasoning behind hiring older, so-called 'seasoned' IT veterans over younger candidates, and not because I am a 27 year old IT professional, but because this *VERY* same stereotype landed on me when I applied for my current position as a UNIX/Linux system administrator. My team currently is comprised of 5 teammembers, in which out of the other 4 teammembers, there is a 25+ year age gap between me and them. Thankfully age wasn't used against me, because I have confidence in my skillset and abilities and I'm certainly not afraid of jumping in and not just learning something, but mastering it inside and out in a short period of time. When I was still considered "the new guy" and still soaking in the environment, this is what I noticed about older, 'seasoned' system administrators: 1) Complacent as HELL 2) Drastically lagging skills on new technology 3) Excuse ridden 4) Use their "time in grade" as a way to troll out of doing work 5) Lack of skills in their own respect because they haven't kept up with technology themselves Say what you want, but only being there a short period of time, I am the lead sysadmin for our team and POC for almost our whole infrastructure. I think a lot of it boils down to initiative and drive. It's not very tough to figure out those types of traits in people. If anything you shouldn't look at how long some old dwarf's resume is, rather interview the person, not the paper. Contrary to popular believe (because we all do it): People do lie on their resumes and during interviews do get jobs.
Time spent working in an industry doesn't necessairly equal high levels of experience.
I've worked with people who've spent 20+ years in IT, and have only ever performed their job-function by following procedures, written with enough detail that a monkey could understand them. Or sometimes people who've got extremely specalized knowledge, only in a single product or technology, as soon as you ask them to do something other than export data from MYOB they fall in a heap.
Ultimately when hiring IT people you need to understand the position that they need to fill, are you looking for someone to create solutions? Are you looking for someone to support existing systems? Do you need someone who's an absolute gun at a specific type of system or technology?
The stupidest part of HR when hiring IT employees is the old "Generalist" vs "Specalist" argument, that is, the concept that someone who's spent 20 years working as a SysAdmin is more suitable for a role than someone who's only spent 5 years as a SysAdmin, and another 10 in various other IT-related roles. The thing to look for, is which one was actually WRITING the processes, systems and procedures, and who was FOLLOWING or USING them, this gives you knowledge of the candidate who posesses understanding of the field and who has rote-learned knowledge.
A Man's ethical behavior should be based effectually on sympathy, education, and social ties -- Albert Einstein
"Well, your next applicant will probably work real hard, and put in lots of overtime to solve your problems. I can typically solve the same problems without staying late."
As long as he's implying the guy is too old, he might as well ask him his religion and who he voted for in the last election.
Make some crack about the person's sexual orientation, and then for good measure, tell him that people of his racial group are untrustworthy. Heck if they have long hair, ask them if they ever wash.
If you want to have an interesting life, you've got to ask the hard questions!
You were mistaken. Which is odd, since memory shouldn't be a problem for you
Having gone through the same agony in a previous role, I found asking one simple poignant question is best and let them talk. For example, "In your last role/purpose/project, what was your most fulfilling design - and why did you chose to implement it that manner?"
or even easier,
"Are you good at what you do? give me examples."
the QUALITY Senior staff will ALWAYS provide concrete examples vs. newbie's w/ lack of real-world experiences. they can always explain the way to do it, but never the how we did it!
I'm in my late 40's and remember what I was like in my 20's - eager to go, spinning my wheels on a full-time basis and cussing about those old farts that seemed to do things "once" slowly that I did "fast" three or four times because I had no discipline. I see it in the 20-somethings we hire today; but a few of them have that special something that goes beyond technical knowledge and youthful energy.
I've seen knowledgeable, energetic, yet completely nonproductive young people who grew into listless and still nonproductive old farts. At the same time, I've seen moderately knowledgable but interested young people who grew up to become superstars in their 30's and 40's.
Don't hire somebody for want you need right now (Temp it instead). Hire the person for the qualities that you'll want around in 5 years. If additional knowledge is needed, there's training and education.
If you're in leadership, it's also important to differentiate between those who produce versus those who manage to look productive to the boss. If you've been in the workforce any time at all, I don't need tp explain that one...
Is there any point in submitting a serious answer to /.? Anyone who isn't registered gets no consideration, regardless of the effort in
the article. And there is entirely too many points given out to "Funny" regardless of the topic. I'm sorry, life isn't a generation Y
humour show.
The best person for the job is the best person for the job. If you describe the job as being something that requires someone with no
experience, that is where you will find the best person.
If you think you need experience, you really should sit down and think about things, as you cannot measure experience as a duration of exposure to an environment. Someone in a coma can have 10 years of exposure to your environment, are they going to be of use? I think ...", or better yet "blah, blah, blah". They will not sit down and write a proper job
the problem with many jobs, is that nobody is actually willing to write a good job description. They will reuse the existing job
description, they will say "typical requirements are
description.
Many people seem to assume that everybody eventually wants to be in management. I can assure you, that is not true. Some of us never want to be a manager, and it may have nothing to do with responsibility (common cop-out). If you want someone who can teach others, make it part of the job description. If you want someone with encyclopedic knowledge, make it part of the job description. If you want someone who is going to make the first pot of coffee every day, make it part of the job description.
A poorly written job description will get you as good a person as you put into the job description.
One thing I would try to do, is to get away from this bullshit that people have to sell themselves to get into the job. Salesmanship is
an exercise in biasing data at the best of times, and can degrade into fabrication of data. Neither of which is what you want in trying to
hire someone to do a job.
I've been interviewing lately, the worst thing I dislike is getting asked questions by some recruiter who has never setup a server or spent all night rebuilding one.
Get up!
I guess what I'd say is that when I encounter someone manifestly lacking in ambition or curiosity, someone who wants to "get by", they skew distinctly older.
But it's not as if my sample size is huge. I have speculated in the past that the reason IT doesn't have a ton of really strong older workers is because they all got rich and retired, and I'm only partially kidding. Of the tip top people I know, a significant percentage have a lot of money and no longer work by choice. There has been such a boom of opportunity that all the things you want in a person - smart, communicates well, understands business, gets things done, ambitious - translate directly into real dollars, even in side projects.
I have done my share of interviewing and working with the people I decided to hire (a very important distinction). The biggest recommendation I can give is to hire those people who wow you. Don't hire the "they are ok" folk and especially not the "clueless" or worse ones. If they are intelligent and have enough experience behind them regardless of age, they can pick up anything they need to know. I filled most positions I interviewed for with the wow crowd and was very happy and only resorted to the "ok" crowd for a few of the seats that I just could not seem to fill. I discovered that I should have waited until I found more of the wow crowd.
"Computer Scientists can count to 1024 on their fingers" (non-mutant, non-mutilatated, human computer scientists)
Asking different interview questions of IT veterans than you would of fresh-from-college types interviewing for the same job mostly (to be brutally honest) indicates that you have been promoted to a position for which you are (not yet) prepared. I don't mean that as a put-down; it's actually pretty common for people to be promoted to management without interviewing skills. Technical skills often get people promoted, but without a skilled mentoring manager to prepare the technically competent for management, they usually get thrown in green. In too many companies, interviews are conducted only by managers. I had the good fortune to have done a lot of interviews when I was an individual contributor, so that when I became a manager, I was already good at interviewing and used those skills to build a great team. But most people aren't fortunate enough to work for such a company.
Whatever the job is, the questions you should be asking on the technical side should be specific to the skill set for the job. If you're hiring somebody to work on a Java project, ask some Java-specific questions that will show whether the candidate can walk what s/he talks. Or Python, C, whatever. If you're hiring a network engineer, ask networking questions. Also, asking about some problem that solved and how it was solved is good. After all, you've already said that you know more experienced staff tend to be better at bringing in the project because of their experience, so don't ask about that. If interviews need to be re-tailored at all, it will probably be for the new graduates rather than the experienced people. For the n00bs, you know they won't have the depth of experience, so your questions need to help you build an informed opinion on whether or not they have sufficient skills or potential to enter your organization and be successful, learning well as they go along and under the guidance of yourself and other more senior staff.
Finally, get your own technical staff involved in the interview process. They can not only be very helpful in vetting people on technical knowledge, but also on personality fit. Personality fit is crucial; I've never made a hire recommendation for someone I felt didn't have personality fit with my team. That's so important that if a candidate doesn't have it, then the technical qualifications just don't matter. Additionally, it will help prepare your team for the day when some of them will themselves step into management roles.
Most of the answers here are dealing with the pros and cons of technical competence, the potential for age discrimination suits, and how time in grade does not always mean 'better.' I concur, but I have a different perspective. In keeping with the OP's question, my answer as an interviewee would be something like this:
You know, it's true that I'm much older than your next applicant. Perhaps he or she is well-versed in new technologies and might even know more than I do about specific areas. I also know that my journey-level competence with Cobol and dBase may not be of interest to you. If it's of interest to you, I'd love to talk about why I chose dBase to do a full-fledged accounts receivable system that was responsible for over a billion dollars of transactions for over ten years. It's kind of a fun story and I like to talk about it. It's one of my successes.
But in terms of what I know that is useful to you today, this month, compared to the 23 year old, I'd have to say my main strength is that I know how to behave. Let me explain. I've been around. I've seen companies and people succeed and I've seen companies and people fail. Almost never have either companies or people utterly failed because of technical incompetence. Companies fail most often because they have no vision of where they want to go. They try to do everything and wind up doing nothing well. I know it's common to blame bad management, but the way I see it is that companies will often promote their technically competent people into management positions where they have no training or expertise. They probably should have found a way to promote a technically competent employee into a better salary for being so competent, not move him out of his field of expertise. FRew companies do that. Naturally, I've seen people promoted for the wrong reasons. I think we've all seen that sort of thing. Good companies do that the least amount of time.
The other issue I see is technically competent people doing incompetent things, like having affairs in the office, like thinking they are too special for meetings, like spreading hate and discontent beyond their technical sphere because they think they are more important than the company. I've seen employees get their companies in trouble for a variety of reasons, none of which were knowing or not knowing the latest and greatest script language. It's usually some sort of people issue.
It's all about behavior. Are you hiring mature adults or would you rather have emotionally retarded geeks working for your company? To get along in the workplace you are going to have to learn several things pretty quickly. Things like don't hit on the cute woman in the office, accept the corporate culture; you won't change it. Be respectful, on time, and friendly to your coworkers. Don't call in sick on Monday because you were out partying all weekend. And, above all, if you are doing personnel-related duties, never ask an applicant anything about age, race, gender, or religion. It's illegal.
Since you just did that, I have a question of my own. Why should I come to work for your company when the next one down the street appears to be an up and coming winner that is professional enough not to ask about my age? They're more interested in what I can do for them and what successful projects I have accomplished in the past. What does your company offer that they don't? Same rule applies.
How about a moderation of -1 pedantic.
As a senior IT person, I find that most interviewers aren't qualified to interview me from a technical perspective. Often, they don't believe my background. Nothing on my resume is incorrect or even stretches the truth. It is all true.
As an interviewer, I try to:
- show respect for the other persons accomplishments whether that be graduating high school or re-writing the space shuttle flight software or starting google.com. Different accomplishments may be negatives to us. A constant blogger could be a liability to the company that we'd rather avoid. There are other online personas that we'd rather avoid too.
- Get a feel for the existing technical and people skills that the person has.
- Try to determine whether they can follow instructions and solve problems efficiently. There is a time for both.
- Try to determine whether they can jump into odd situations yet maintain a professional front. "What would you do if we asked you to visit Chile alone and install our software on 20 non-English systems next week?"
- Give the person a feel for our corporate values, process and expectations for results; we're small so we can't have any dead wood. Everyone is expected to produce results, do you feel you can work in that type of environment?
- Answer as honestly as possible any of their questions
- Point out the freedom we give our people to solve problems and the rewards for bringing new business into our company
- Determine if they are a social fit for our company. We like each other and don't want someone who will not add to our fun or who will be difficult to be around all day.
- Can help to increase our cultural diversity and bring different background to our environment. We aren't looking for someone just like us.
- We encourage outside activities that don't include computers and volunteering. A well rounded, highly experienced person that can produce results is what we want. Someone who thinks they know everything is a liability. Nobody does. Being respectful towards us, our partners, our customers and the waiter are each important. Tact is important when explaining that some things are best done differently that how everyone else does it.
Asking age centric questions in an interview is a sure fire way to get your company sued. Ask someone compentant in your HR group or legal arm about what is permissible when interviewing. In my experience, experience isn't always valuable. Work ethic and ability (and willingness) to learn regardless of age are key factors for success.
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.
Engineering is the art of compromise.
You'll have to figure out how to structure the interview yourself, and there's lots to choose from. Multi-day, multi-level? Parametric testing or not? Throw in a practical test or scenario?
But really what you're likely to get it a huge pile of tradeoffs in many dimensions. The CCIE who can design and maintain a rock-solid network may have poor people skills. The developer who writes mediocre code might be cheap enough to hire so you can train him. The uber genius who can solve any problem in before he's heard about it, and works great with anyone, will have 7 other jobs offers to consider, and you'll have to compensate him well to get him to work for you.
The old guy? He's got experience, but he might also be set in his ways and less open to new ideas. The new guy? Enthusiasm, but he ain't seen nothin' yet.
I'm 51 also and I'm doing web work that is more advanced than most all of the other 200 web developers in the department. I also am asked by others about how to do *this*, or why is *that* not working, even in things that I haven't worked on much for *years*. I also get along with more people better than most. I learn new technologies quickly and I'm a better problem solver than most. Maybe I'm rare, but I don't think a generalization that older IT folks fall behind is valid. I also know other old duffers like me that aren't falling behind. I think it depends on what you do on your job. I have never been tied down to COBOL programming (or anything like that). I think it is what you are doing on your job that makes a big difference, and that goes more to the employer.
I think it's paramount that fresh blood be brought in so it's not the same old folks who feel trapped in the system, and don't have enough fire in their hearts to go fight the fight anymore when someone says "you can't" for "insert stock response." I think that kind of person can be young or old, just typically found more with students fresh out of college.
It is not the questions you ask, but the questions the applicant asks you, that reveal the experience.
From a rookie you want the infamous "experience in exactly the tools and platform you are developing in". Because that saves you training expenses and gets her going from the start at a particular problem.
But from an old hand, you want someone that knows how to explore a field and ask the right questions. Someone that is able to quickly grasp the important things and sense where the dead bodies are buried and suggest some solutions she want to consider. So listen carefully, does the applicant demonstrate that he can in the (short) time of an interview get to the heart of your problems?
Also listen to the way questions are posed to you. Is there a sense of team work and collaboration? Or is it more "I know best how to do this!"
1) Age is not legal when considering an employee. 2) Everything your working on today is going to change or be replaced in 2-4 years for more tech. You might still have older stuff around, but chances are really good it will not be in heavy development. 3) Languages that are very portable will be around a while. But the platforms they are running are going to change to something else.
So what you should be asking is, how fast do you learn new widget tech xyz? How do you learn it? If you need 10 classes and hand holding thats an issue, someone that reads the book is what your looking for, because next year you will need a new set of books.
Check out how they think, working on something and being able to push it over the finish line, under time and on budget, with few flaws will save you a lot of money as a company versus what you saved on salary.
How long do you think this guy at the lower end of the pay scale will stay if they can get a 30% raise by taking a new job somewhere else. Retraining new people costs way more then salary if they flip the people every year and a half. Your expertise just left with that guy when they leave. That will cost you.
More experienced people will pursue the problem if they are motivated and will not settle for "To be Determined" when the server restarts for no reason.
On the flip side to all of this: If you can't manage people, motivate them with honestly, and understand they are real people, then you should look at why the last guys quit.
Whats the difference between a Clone Trooper and a Storm Trooper? Answer: Management
With one management change, they go from the good guys to the bad guys.
Seriously. If they go "what?" just shake your head and go "NEXT!"
Look at their posting history. If all they talk about is code code code, again, skip over them. People skills are more important.
Once you're old enough, you don't have to get into "pissing contests", and the younger ones around you don't waste their time trying, either, because they know it's not a good idea ...
Also, ask what their physical (you know, "dead-tree") library is like. They should have a decent number of books on the technology you're hiring them for, as well as IT in general. Also, books in unrelated areas, like sci-fi, mystery, crime, or biographies. They should have more books than games. Lots more books.
Also look for a sense of humor - you need it in this business. A sad sack will just drag everyone else down with them.
You wrote:"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 question will get you sued. Unless age is a bona fide occupational qualification (BFOQ in HR speak), you can't ask it, or questions designed to elicit it. This is no different than saying "IT is a black man's game, you're white, what do you bring to the party?"
I don't believe you are IT. If you are then perhaps you are playing the devil's advocate here? How can you quote the experience you claim and then wonder about what questions to ask? If you have truly worked in or alongside IT for the time you claim, the questions will be most obvious.
Let me play alongside you though and ask...what are you looking for? You say IT but what do you want him or her to do for you? The answers to these will also tell you what to ask.
Perhaps you should look at what you have to offer the prospective employee? I can think of two times that a potential employer being unable to answer that question legitimately to me that has decided the case.
Some of us have been doing IT longer than the acronym has been around. We can spot a recruiter or HR person who is full of it a mile away and a manager who doesn't know what they want or how to get it from 3.
This one drives me insane. I have been in IT for 8 years now (30 years old btw - Semper Fi) and by far will put to shame the dinosaurs I work with...
The "problem" with using older folks is they usually are slow to adapt to a fast paced environment or like the writer will immediately stereotype younger IT pro's. On the other side of the fence, younger folks in IT are more prone to lie about their experience or lack tact/bearing/etc. All qualities necessary for a professional environment.
I made this comment to an older IT pro when I first got into this field when he called me a young punk or something of the sort.
"I may young, but this young "punk" is taking jobs from dinosaurs like you!"
I was 'out in the cold' for a while this autumn after my division got shut down and I found what I thought was a good tactic in job interviews.
I'd interview them about halfway through the interview. I've been around the block a few times now and I want to work on well managed projects. No-one ever got defensive or arrogant, they all 'got it.' I usually got two or three interviews once we were underway with only a few exceptions.
It's not about arrogance, it's about us seeing if we're both going in the same direction.
Secondly, when it came to talking about experience, I'd say the reason you want to hire someone who's older is because I have actually done this before. I can tell --sometimes and not all the time-- when something is going to be a problem long before it gets put in the FedEx box to be delivered.
That's what experience gets you. So, actually I'm cheaper to hire.
I know that he doesn't know that he doesn't know anything!
I'll defer to Semler for specifics (start at http://en.wikipedia.org/wiki/Ricardo_Semler).
One technique Semco uses is to bring half a dozen candidates in together, and interview them as a group, in front of both the interview team and (if I remember right) any interested staff.
This way you get to see how people work in a group, after a fashion, and let them bounce ideas off each other.
If you don't hire the old dude, he's going to use the words that you used against you. Asking "What do you know that the 23 year old does not?" implies that you consider the 23 year old a better candidate.
Conformity is the jailer of freedom and enemy of growth. -JFK
You might be right.
Mind you, I haven't met your secretary ... female? Nice? Sounds promising.
(I can't remember the last time I had a secretary)
"Laddie, when I was your age, Pluto was still a planet"
"Cats like plain crisps"
I don't believe you seriously have guts and arrogance to ask this question. But if you do, the correct answer is "If you have to ask, the 23-year-old is probably the better candidate for you. Goodbye." That is at least what I would have told you.
No hard feelings, but my years of experience tell me that an average IT recruiter will not show any sign of respect towards his candidates unless treated like shit.
Good luck with that question... if you decide to go with someone else, you'll be at the wrong end of a nasty lawsuit and, based on the wording of that question, your company will be out a lot of cash.
Ask them how they solve a problem which includes networking, OS selection, possibly a hardware device which is connected to a server.....
If the guy starts with "I write a program in VB and it will take 3 months" run away....
If the guy says "I install this this this, then a proxy, then script it and if I really-really need to write any compiled source I to this-and-this" - that is your guy who solves problems and does not dick-around.....
Then again, you might think this is bullc*ap and go for the VB guy, and I might have described myself a little with scenario #2.
Still, I interview people, and see, that there are the VB guys, and then there are the guys who are in this for 12+ years, who know that there are a lot of things you can do with a shell, with just configuring something right, and without writing something with a compiler (bash, sh, csh, perl) and get the job done...... the guys who prefer csv because you can sed, grep , awk and you*name*it, instead a doc or an xls....
And you got it wrong, these guys also know the buzz-words, and will configure your "Time Capsule" right, and know how to use an iPhone .... :)
Btw I got a linkg form dailywtf which had a query (SQL) that generated a Mandelbrot Fractal ..... guess what ... nor my boss, not our network guys, nor OUR DBA know WTF a fractal was .... I really got sad..... 15 IT people and there was 1 guy who understood the beauty of this... and some of these guys are College degree IT people ....
They are the ones you DO NOT WANT .... you know what? Ask them if they know what a fractal is, and if they can access a web page with a shell and nothing else (telnet, netcat tops) ....
There's nothing wrong with hiring older people, and there's nothing wrong with hiring young people, but hire them on an individual basis, not because of their age. :P). I've also met older IT folks who have never progressed and are still stuck in versions of technology that haven't existed in more than a decade.
I've met older IT folks with lots of experience who knew all the quirks of what they were working on, had invaluable industry experience and were worth their weight in gold(and with older IT folks, that's usually a lot
I've met young folks who thought they were the best they'd ever be, or who thought they ought to be earning 6 figures right out of the gate and I've met young folks who were flexible, creative, and inspired.
Hire the best person for the job, if that's some guy with 20 years experience or a grad right out of university it doesn't matter. Experience is certainly valuable, but in this industry so much changes so quickly that it isn't as valuable as it is in other places. That doesn't mean you shouldn't hire older technicians, but it does mean that just because someone is older doesn't mean they'll necessarily be better.
Whatever your personal preferences are, the last thing you want is someone who isn't right for the job, or isn't right for the team, hire the best person who applies, and hire them for the job you're giving them, not based on some sort of "this is the ideal candidate" bullshit.
I was with you until the end.
If you're interviewing for a technical position, ask technical questions, stupid little nit picky questions, in great detail. There don't have to be many of them, and they can be easy questions.
I usually, literally, say, "I know these are easy questions. I don't want to insult you, but I need to weed out the people whose resumes are largely fictional."
We just phone interviewed a guy who had a phenomenal resume. 10 - 20 years (I forget) of experience with a variety of technologies, including at least 10 of C/Unix, which is what we were looking for.
We asked him what the "static" keyword means. And what a "*" does in C. He couldn't answer either one. He talked for a while, but there wasn't a complete answer in there.
I gave him the benefit of the doubt at first - he (sort of) explained what "static" means inside a function, but when I went back and pointed out that it meant something different on a global, he couldn't manage it. It seemed like he was reading back something that he didn't really understand, and for all I know, he was in Google, trying to figure it out while stalling.
So always ask a few easy tech questions.
Step 1) Read Post on Slashdot ...Court Ordered Profit!
Step 2) Figure what company this fellow works for and apply for a job, get declined
Step 3)
You're going to have to study and practice it. For starters, buy a book. Second, don't mention the word age or reference their age, not even in the context of their experience. 98 times out of 100 it's harmless, even when you reject the candidate. But there are lawsuit-happy people out there and you're likely to pass them by. Being in the habit of mentioning age in an interview guarantees a lawsuit in your future.
Sticking to their experience, the combo knockout that tends to separate the pack goes like this:
a. what was the significant thing you did while at job X?
b. what skills did you use to do that?
c. can you show me some of that code? Describe the architecture?
d. Wouldn't that have required an algorithm like blah-blah? How did you implement that, specifically?
e. Okay, you don't remember, but how would you do it today?
f. repeat for next job/experience.
Great candidates will engage you and show off what they know. Crappy candidates, the majority, will deflect and dissemble talking about how it was a long time ago, they were only part of a team, they've haven't used that language lately as they've been studying cool-new-language instead.
I particularly love that last excuse, I follow it with, "okay, how would you do this in cool-new-language today?"
There is no need to bring age into it.
These opinions guaranteed or your money back.
Many of the standard questions are distilled from years of real experience with real people from many fields.
"Why do you want the position of foo at My Company?"
. This particular question can be asked of applicants of all ages; and, reveals much useful information and insight into how the applicant will perform.
"I need a job"
"Every one has bills to pay"
"It's what I have done for the past X years"
"People are always going to need IT people; I am here to help"
Beyond all other technical questions, this question determines motivation. The above answers show any lack of interest or motivation in life in general -- regardless of age. These people are just here for the free buffet that comes with the bus ticket.
This single question alone will filter out the deadbeats who get to the interview stage. Then you can nitpick technical skills. But, I always choose motivated applicants with skills over experience every time regardless of age.
Every mans' island needs an ocean; choose your ocean carefully.
The thing that isn't really covered is why the individual is being hired. I interview a lot of people. The main things I have found to ensure "fit" isn't so much age v. experience, but attitude v. requirements. If you require...
...a project manager, an experienced person is a better fit (but they need to at least understand the technical concepts)
...a lot of customer/client facing, an experienced person may a better fit. (Not always. People can be grumpy and/or agree too quickly.)
...a lot of development, an experienced or a new hire usually works (depends on quality, size of release, schedule)
...a lot of testing, an experienced or a new hire usually works (depends on testing processes)
...a lot of documentation, experienced or a new hire is usually a disaster (get a real writer)
...a trainer, experience is always best
I'd be real careful posing the question with a mention of age in it like..I can just see some applicant that doesn't make the grade crying foul and ruining you month.
I Need someone to rebuild a Digitech Digital Delay pedal for me....for me...for me...for me.
First off, I can not say how much I agree with all the comments on age discrimination, do not, do not, do not mention or imply the age of a candidate (avoid saying things like "Wow, its been a while since you have been in school" or "Man, don't you miss those punch cards"). You will have a much more effective (and safe) interview if you focus on the main goal: - Finding a resource that meets your immediate needs - Finding a resource that can grow with your organization - Finding a resource who fits in with your culture. The third point is the most important. In all the interview and people I have hired, my best fits have been those that fit into the culture the best. From the fun loving college grad to the 25 year veteran of the industry, if the person demonstrates the commitment level you are looking for, a basic understanding of the technology or the issues, and the personality that most everyone in the team can work with, you can teach he/she anything else they need to know. Questions to ask: - What do you look for in a company you work for? (Look at the resume for multiple short term assignments one after the other, ask if the candidate is comfortable in a long term role and why they moved around so much, it's a legitimate question). - Ask about their technology experience? Do they have production support experience and are they comfortable being woken up at 2:00 am to debug a prod problem? Do they know how to debug or do they just have config experience? - Ask them to give you 3 examples of projects or programs they have written using the technologies you are interested in? Don't evaluate just what he/she did, look for detail and facts in the story they are telling you? If they are using terms like "One time I had to write a program that did pricing for a product" then they person may not be as detail focused as "A year and a half ago I wrote a ABAP z-program that determined the variable pricing for the widget product line based on the products Variant Config attributes and utilized a Ztable to determine the product hierarchy) (yeah, sorry, I am an SAP geek). I hope this helps. And again, read between the lines for your real answers. Basing a candidates potential based on the fact you have hired "similar" people in the past will always get you in trouble.
> 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.
Great Questions.
I can remember two job interviews. One was very probing, above but also technically. They'd ask me questions about how I designed some certain module, the problem I ran into, etc. It was an extremely good interview; exhausting, but by the end of it hey could see I knew my stuff *AND EQUALLY* I could see that they knew theirs. That's just as important.
But I also remember a badly run interview when this guy would ask stupid textbook definitions that only a graduate would know; the sort of stuff you cram for an exam but forget the day after because in the real world its useless. I'd quote them back as best I could remember when the cointerviewer turned to him and said "Is that right?" he laughed he didn't know but he'd have to Google it later. Real slick...
To n00bs: Know these threads are depressing if you are a graduate, but you'll find as a programmer you improve immensely over time. I've been coding for a long time now and when I come to a new problem, I already have lots of experience and have a good idea which way to proceed and what pitfalls await me. True as you get older learning new stuff becomes harder, but you get a vast bank of experience that counts for a lot. As OP says, not just technical issues, but social too. As good as you are, you can only do so much yourself, so being able to work IN A TEAM (not just have lunch with them but still do your own thing) makes a big difference.
In all the people I've worked with, a professional attitude is by far the most important thing (you can wear old T-shirts and ripped shorts and still be a professional). Truth is, coding isn't *that* hard. Many people learn to do it. It's about choosing the people you'd want beside you when you go into battle.
I'm at an age where I'm not sure if I'm for or against the idea that I've passed the mid-point in my life expectancy. Having some engineering training himself, my father taught me binary around the time the 4004 was introduced, with an cardboard egg carton and some marbles.
He also borrowed on my behalf *all three* of the terrible "modern era" computer books from the local university library. One of these books focused on photographs of IBM consoles there were already headed toward obsolescence when the IBM Selectric was the epitome of modernism.
One of the books had a tolerable explanation of boolean logic.
The third book was all about the use of flow charts to document and express algorithms. Since "home" computers didn't entirely exist yet, I tried drawing flow charts to help me get to school on time. It never entered my mind that perhaps the problem had something to do with staying up until 1:00am every school night reading any book I could get my hands on.
By the time the local school was teaching us how to multiply a pair of two digit numbers (a proficiency one gains in binary much sooner), I had determined to my own satisfaction that flow charts were a misguided tool, at best, in the depiction of intellectual property.
For the purposes of this discussion, I have the distinction of being on the downslope of life, while computers remain as much "in my blood" as a recent college grad who "discovered" computers as a young child before Linux had its first GUI. I'm of two minds on this question.
What's the extra two decades worth? Most of the time, I suspect not all that much. I wonder about this meme of older people having learned from their past mistakes. You read about that in Dilbert sometimes. People do learn, yes, but rarely in a good way.
Certainly, one gets better at blaming other people. Erecting taller fences around job responsibilities. Not landing the undoable core component on your own plate. Not panicking as much under deadline pressure, because you knew all along that the young guy next to you has a component twice as impossible as your own.
The ultimate accomplishment of middle-aged conservatism is to finish an aggressive project right on time, right on budget, and have the finished circuit not actually able to perform a real-life task of any commercial utility. I've seen the baby discarded with the bath water in service to "delivered on time, paid on time".
Learning from the past is an extremely variable skill. Some people have none of it, some people have a fair amount, and some people do or don't with a shocking mixture of randomness.
Prudence is usually accompanied by lessening of enthusiasm. Is it a good exchange? Not always.
I think I did my best work 15 years ago. Never on time, but I moved the rock in a way I rarely even attempt these days.
Compared to younger co-workers, my analytic and written skills are for the most part vastly superior.
My ability to pastiche together an almost-working prototype our of inferior code "just lying around" is not so good. I never mastered the trick of "almost working". Somewhere along the line I acquired the personal baggage that there is no reason an algorithm or a core block of code shouldn't be 100% correct. This is baggage I now struggle with daily. Older people have baggage. I might have more than my share.
Lately I'm working on an embedded project. I download sample code from the chip vendor. I look at the code and go "ugh, this was not developed with a spirit of purity and elegance". Then I freeze up like a deer in the headlights. Younger people don't seem to have this problem. From what I call tell, most younger people have been pastiching crap together since the day they first learned to type. Crap is situation normal, a core proficiency.
After curling up in a ball and muttering "architecture" to myself a few dozen times, I come out of my trance, and manage to find a way to move forward again, without rewriting gobs of ucky code to my
tip- if you want a cabinetmaker you don't ask them about their tool skills you ask them about cabinets they have made if they can make good cabinets they can pick up any tools you have that they havnt used before. IT is no different.
Jerry Kew (havnt my login to hand)
I dunno what planet submitter is talking about, but on my world, when I was looking for my first real programming job at 25, no one was super excited to get the next big young person. Interviewers were suspicious of my research university education, skeptical of my time in grad school and generally unimpressed with my short resume. "You have less than 10 years of paid C++ experience?" A lot of people were working with dated languages (Cobol, Cold Fusion) and technologies and didn't want some kid just out of school. I had to seriously lower my salary expectations and take a job with a really small firm who simply couldn't get anyone better than me. Submitter: you're not the only one biased toward older applicants. Some of my interviews started winding down when I walked in the door until I decided to grow a beard.
Just to let you know, you are violating the Age Discrimination in Employment Act (as well as probably other state statutes) by even mentioning age in an interview if you are in the U.S.
Age is a protected class for discrimination. The mere mention of age might have an old timer like yourself looking for a job.
Why is COBOL a tag for this Ask Slashdot? Most older technology workers do keep up their skills and can do newer technologies while including the wisdom of experience applying technology to the application and business. And some of us never did COBOL.
now we need to go OSS in diesel cars
You need to stop analyzing the box and reach out it's qualifying contents. Drive your questions towards that and you'll end up having non-discriminative questions with better information about the applicants. Look at each one as if they where exactly the same box and all you want is to know what's inside. That will keep you away from the law trouble and will make you a better interviewer. But, in the end, just like the candidates you intend to interview, it's not how old they are that will make them better employees, but how they deal with new experiences and what they keep from those experiences that will make them better. The same can be told about you. I assume that, if you came here to ask, you don't have the required experience to do it. So, why don't you ask someone with more experience (younger or older, doesn't really matter as long as he/she has proven experience) to guide you through this process? Just wanted to share one more thing. The way you made your question shows me that you have already made up your mind about hiring someone older and just came here for "endorsement methods" for you to present as criteria during the process of selecting an applicant. That seems true prejudice and, if that is correct, I think it's time for you to think over your concepts. The world has changed. Prove of that is that something never imagined for most people outside US happened, Obama will run the one of the most admired countries in the world. Nothing against McCain, but people here in Brazil were cheerful and joyful in the end of US elections. Think about it...
God is Real as long as it's not declared as Integer.
Young != Passion
Slashdot = Sarcasm
In my experience as a contractor, most of the openings were political rather than technical.
Slashdot = Sarcasm
I'd start by asking them what other IT skills they have that are secondary to the position you're interviewing for. A network engineer that's configured Apache, knows more operating systems than just windows, and has good presentation skills (translation: you don't have to hide him from upper management) will likely morph into whatever the day-to-day job requirements dictate.
While we're on the subject, how do you prove the opposite? Case in point... I've seen people retire that have decades of experience and still suck at their job. They've talked about volunteering at a non-profit organization, performing the same function. That's noble enough, but if it's so bad that it'd be doing the organization a dis-service, then it'd really be nice if there were a way to spot the bad apples.
____________________________________
http://techdojo.org/
I am probably more mature in this role most my age. I am only 20 and run the IT department for my family's business. I can say with absolute honesty I got the job because I am my father's son, but I kept it based on my performance. As a result of this being a family business I understood that it was not my own tech playground, the bottom line was the bottom line. I say this to make the point don't write off someone because they are young. Instead ask do they have the proper tech skills you need. I find that this is the easy part. The next question though is the kicker - do they understand that this is a business. The way I typically find this out is through asking about past projects and the challenges they faced on them. You may need to probe to get the information you are looking for but if they talk about time, budgets, or people and their allocation being a primary concern then that may be a candidate to concider. Of course this will naturally knock out almost all young people. But I have also learned to drop all of my prejudices, no matter how small. Because many of my greatest resources and connections have some for the most unusual of places.
I hope this doesn't come across the wrong way, but I have no idea what your next candidate may know, and it's a waste of time for me to guess. I would agree that the "Technology" constituent of "IT" may be the purview of younger players, but I have the "information" part, in the form of unique experiences, they can't possess. I would also propose the idea that "IT" is more than just the sum of it's named components, like a souffle is more than just eggs and cream, and it takes an experienced mind to guide the creation process. To make it interesting, there are frequently people involved, which can mean opinions, egos, fears, attitudes, and other hidden dangers - a plethora of foibles of the flesh. How many of your candidates have 30+ years of dealing with the human factor?
So let me reiterate that I don't want to throw darts at a hidden target. My apologies if that isn't what you were looking for. On the other hand, if you give me a situation or problem, and some parameters for a solution, I can probably offer you a resolution or two, with recommendations on the trade-offs. Perhaps even describe similar circumstances I've experienced. With your knowledge of the sandbox, and my experience with the sand, I'll bet we can come up with an answer that will make you look good, the group look competent, and help the company.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
How hot are your daughters, and how's their gag reflex?
When I answer these questions I get into long tirades so this time I wont:
1) Saying the age thing makes you look like a n00b and an ass hat at the same time.
2)Looking like an ass hat and n00b is bad enough alone but together it may be a deal breaker.
3)You just upped the ante by about 10,000-20,000 dollars once I prove to you I'm the right guy.
4)You've shown me it will be a simple task to convince you I'm the only guy for the job because of your naivete.
5) A real life example:
A young Russian programmer who worked with us developed a substantial amount of code but didn't document it well.
Suddenly he announced:
"Thanks Guys!" "I've had enough for a while." "I'm moving to Spain!"
Now they have to hire him back for about 10x as much just to maintain a piece of core(Legacy) infrastructure.
Think about this in the current economic climate.
Clients may be leaving or at least cutting back.
Your liquidity is down, hiring is frozen and you are shit out of luck. Now the Slave becomes the Master.
Solution: Hire someone more needy/hungry or mature who is more inclined to stay for the long haul.
And by the way even older IT workers consider anything over 3+ years the long haul.
Do NOT:
1) Hire ANYONE named Simon Travaglia.
2) Hire anyone reccomended by the aforementioned individual.
YOU HAVE BEEN WARNED!
Knowing Google's lust for data collection, the Soviet Union is still alive and well inside the psyche of Sergey Brin....
You're right, I'm set in my ways. The reason I use OpenBSD and djbdns is because everything else sucks.
But nowadays I spend my time with Greek gods, Jesus, and Arabic, so I really don't care if you think i'm significantly less adaptive to change.
The guy preaching Windows 95 can work shouldn't have been hired in 1996, nevermind 2008.
I know enough to not get the company in trouble by asking questions like this in interviews, and can advise you on how to hire new staff safely and effectively.
I'm 30 and I worked X.25 straight out of college in 2000, making me 30. I'm not old yet .... right?
....
I'm still a young whipper snapper right? Please
Older people have been doing things for longer - so they are probably good at it by now; otherwise they wouldn't have stayed in computing. The question is what they have been doing for all those years, and that may be more difficult to ascertain, because some of the important things are less often mentioned in a CV. That will in areas like adaptability, taking responsibility, creativity and a lot of other soft qualities. A person who has been through a lot of changes in his career will have developed his ability to adapt, for example.
I think there is a certain point after which a person's general experience begins to weigh more than their technical knowledge; you discover that all programming languages are basically the same etc, and you develop a sort "meta-knowledge" about things that allows you to understand problems on a deeper level. Ideally, that is; quite often people simply grow crusty and less willing to go out of their way to do something. When you get old, you either become wise or silly, and it can e quite hard to tell the two apart.
I'm 58 and still coding, I just started a contract this week. I downshifted back to 'code' from more 'senior' roles because I don't need to work all year and I like to code.
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!
On y va, qui mal y pense!
I think the main difference between experienced an not is a better understanding of people.
The fresh student typically thinks programming is only about programs - perhaps smart enough to look at all levels, even design patterns (if you're lucky), but an experienced pro understands people are at least half the issue.
Usually, its possible to tell this just from the speech and demeanor of the pro. If you need to justify it with a question, just ask:
What do you think is the hardest thing about programming? If they say algorithms, beginner. If they say people, expert.
Although the comment about avoiding 23 yr olds is out of place, I think the poster is simply trying to clarify and quantify what makes a good candidate. Hence the question: What are good questions to ask?.. True, age shouldn't matter, but in practice it does. So the best way is to just find really good questions that get at what you're trying to select for..
If you ask "Have you managed a team?".. Most 20 yr olds will answer no. But its not age discrimination. Its a quality test for a management-level position.
Dude. Get over the "age" issue.
I myself am 23 years old. I have 16,000 hours of /commercial/ experience in my field (unix systems administration), and 55,000 hours of unix/linux experience in general (counting my pre-work years, etc). The astute people in the audience will note that 55,000 hours is roughly equivilant to 28 years of 8 hours a day, 5 days a week.
I'm team leader for a team of about 12 UNIX systems administrators, all of which are far older than myself (average age is 50). Why am I the team leader? Because I'm more in touch with the technology of today, and with the business world. In other words, I provide a valuable communication channel between the business and IT. Well, that, and in terms of hours, my experience tends to outweigh theirs.
The young people of today are learning what the older people learnt, but far earlier, and at a time they can really learn it properly - kind of like learning a second language when you are a child.
That said, I must admit that most of the candidates I interview are above 40, and they do tend to have more relevant experience - but do NOT write off the younger generation - before you know it, one of them will be your boss.
So yeah, quit your discrimination - hire based on relevant experience and ability to perform, not based on age.
Experience is the name everyone gives to their mistakes..--Oscar Wilde
Slashdot = Sarcasm
They're also unlikely to do socially inappropriate things in front of customers or do really stupid things with your hardware like yanking good drives on a production machine "to see if the RAID works".
Or start fixing a problem by just installing the latest version of software.
He who said 1,000,000 monkeys on 1,000,000 typewriters would eventually type the great novel, never saw an AOL chat room
such as java? hahahah
In Italy, people with more than 10-12 years of experience are very difficult to find another job if they lose their occupation. :-(
IT is a thing for young peoples, career is only towards management positions and managers are very difficult to relocate
Unfortunately many US corporations saw it as a cynical box-ticking exercise to gain a certification. The Japanese, Koreans, Taiwanese, Germans and Scandinavians saw it as a way to leverage their engineering skills and create product differentiation (like car engines that routinely go 120000-200000 miles with only routine maintenance). Which is one reason why companies with names like Honda, Toyota, Samsung, Hyundai, Acer, Asus, BMW, VW and Nokia make so much of the stuff that today the US cannot make for itself.
The disadvantage of ISO 9001 in a hire and fire environment, or one with a lot of contractors, is that only someone with years of experience across the board really knows enough to pull it all together. If you have implemented ISO 9000 seriously and well, the wise job applicant will know that you are less likely to have major failures like product recalls, you are more likely to handle customer service issues efficiently, and he is less likely to lose nights and weekends fixing other people's mistakes.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
If you want to employ a cabinet maker, you ask them about cabinets they have made. In passing, you may ask what tools they used, but, if they are good, they can easily pick up and use new tools. Far too much emphasis has been laid on which tools you know, e.g. SQLserver vs Oracle, a good db specialist can transfer from on to the other in very little time. Always hire for attitude, you can change skills, changing attitudes is much tougher. Look for a little passion about results and user needs. Jerry
They're also unlikely to do socially inappropriate things in front of customers or do really stupid things with your hardware like yanking good drives on a production machine "to see if the RAID works".
Curious: What is the problem with testing the RAID like this? The first hit on google for 'testing if raid works' says 'pull the drive'. How can you have any confidence in your system if you're not willing to test it like this? If there are any problems better to iron them out when someone's on site and prepared for problems than when you least expect it (which is when it will probably fail anyway). Obviously you need backups as well, but that's a given.
That's actually a good question. I've been interviewing quite a lot for a company in SoCal and I was amazed by the lack of knowledge of younger programmers and, most importantly, by the lack of willingness to learn the basics.
As a sidenote not a single of them could tell the difference between if (a() && b()) and if (a() & b()) while all the old-timers I interviewed could answer that (it's not that much of a big deal, but frankly if you're looking for some "bracket language-fu" you'd rather have some dude at least knowing that working for you).
Usually the younger ones don't know anything about , at random: low-level bit fiddling, hexadecimal, they don't understand how PKCS work (it's just all black magic to them), they don't know their algorithms well (DP and memoization are usually alien concepts to them), quite a lot of them do not know big O notation and they don't understand complexity, they've never written a FSM. Multithreading? locks? Black magic. The list is saddening.
In addition to having huge "software leaks" knowledge-wise, they're also very often lost when it comes to hardware. Due to their lack of basic knowledge, they're not the kind of person to understand how, say, hardware virtualization works in modern Intel/AMD cpus, etc.
In other words, most young programmers know the buzzwords, but they profoundly lack an understanding of the basics and this leads to monstrosity and horrors that make for a good laugh at the daily WTF.
Good programmers/architects often enjoy cooking gourmet meals, so why don't you ask them to cook their favorite dish for you. This will give you insight in how they work, their attention to detail etc.
Actually, I think that has less to do with age and more to do with liking your work. That's exactly my attitude.
When I graduated from college, they had those stupid mock interviews. I kept saying 'I don't want to be a manager, I just want to code' and they kept yelling at me for it. 'That says you don't have any ambition.' No... It says I know what I like and what I'm good at.
Honestly, it probably did have a lot to do with why I couldn't get a job for so long... But the company I'm with now understands me and I fit perfectly with what they want, too. I've been here 3 years already and my yearly reviews are always glowing.
And yes, I tell the boss when I see problems with his plans. I don't usually use words like 'dipstick', but I make it pretty clear how I feel about the plans. And they usually appreciate the input and change things for the better.
Anyhow, the short version: It's not age, it's attitude.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
I agree with the myriad of posters that have suggested to leave age out of the hiring equation - itâ(TM)s just setting yourself up for a lawsuit. Hereâ(TM)s a novel idea... hire candidates based on their qualifications!
Yanking good drive out of a production machine to see whether raid works is one of the first things you SHOULD do. Basic risk management and verifying how far your comfort zone of things running actually go.
Well, certainly better than waiting for it to crash big time and receiving an apology from vendor - "Oh, we fixed that particular issue in the latest product. Do you want to upgrade?"
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.
What a crock of shit.
You sound like your mouth is open and your ears are shut.
I am not a kick in the arse off your age and I am still competing for a good job that pays me the money to support my family and chosen lifestyle. Maybe you don't care where you'll be in 5 years time. But I bet you're in the minority.
It sounds like you have been set in your ways for a long long time.
You can never go wrong hiring the hot flirty chick.
You are just playing games with the interviewees by showing them how clever you are.
IANAL but write like a drunk one.
This sounds like a beginners guide to running the most unflexible, unadaptable, incompetent IT department possible and get away with it.
There are 100 things to mention.
If you want to asses the capabilities of an older candidate the worst place to start is with insinuations about his age (which may be illegal anyway).
IANAL but write like a drunk one.
How you react to a situation is governed mostly by the context.
In a context were you are risking your life if you screw up most likely skydiving expertise may come handy.
99% of IT jobs will never be remotely involved in such a context, thus the experiences from skydiving may not translate at all to what you need for your team.
Hobbies may indicate other interest traits, mostly of social nature, but to imply that they will magically translate in certain traits in an unrelated field is completely ludicrous.
IANAL but write like a drunk one.
That is exactly what this is all about.
Anybody can learn proficiently to program or do any IT task really, it is prioritizing properly what differentiates the good from the bad and the outright ugly.
One can figure out in 10 minutes if somebody is technically proficient or not (hint: one does not need written tests). but it is far more difficult to figure out if somebody understands the needs of your company.
IANAL but write like a drunk one.
What do *you* need?
How can I possible know at this stage what *your priorities* are?
Throw nonsensical open ended questions and there are people out there that will have you for breakfast...
IANAL but write like a drunk one.
Somebody clued up should request further clarification of the context to arrive to a satisfactory answer (C and D seem like jokes any way).
IANAL but write like a drunk one.
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.
"Oh, and GET OFF MY LAWN!"
Fixed that for you!
Last night I played a blank tape at full volume. The mime next door went nuts.
I'm relatively young, but even I have enough sense to know that the interview is over as soon as the word "age" is mentioned. In fact, the very second you mention age you will receive my lawyer's business card and you will then be asked when can I start.
I think the big question for older people is not about how young they started. It's about the ability to keep up with the times. I know people who program in Fortran because they learned it in college and "do not have time to learn another language".
I'm just out of mod points, but I think this is the really important question for older programmers. 25 years of experience is nice, but useless if you're still programming by '80s standards with '80s technology. On the other hand, 25 years of experience ranging from Fortran and C to Java and Ruby means you've got someone who knows the advantages and disadvantages of different languages and paradigms.
It also means you've got someone who is still able to learn new things, and curious enough to do so. And he hasn't gotten stuck in dead-end jobs because his experience with existing tech was more valuable than learning new stuff. Instead, he might have been the prime choice to explore new tech.
Someone like that could be worth gold, and worth more then someone with only a few years of experience and versed in all the latest new technologies.
When you get to such nitty-gritty level of detail you are not evaluating expertise, you are are showing off.
Somebody, regardless of age, may not be familiar with this, but may have all the necessary technical expertise to support your application.
Good interviews avoid such detailed examination while poking about more general topics that give a full understanding of a candidate's abilities.
IANAL but write like a drunk one.
"Don't ask the old guys "about where they want to be in 5 years"" Here here...this is what I heard from every interviewer, who was younger than me when I went on a number of interviews a few years back. In five years I will probably still be with the same company.
So I don't get flamed - younger=less corporate experience, older=more corporate experience.
Interviewees either know a lot about their subject, or do their best to bluff based on what they *do* know.
Whittling the list down to a bunch of peeps that belong to the former is easy - but how do you choose which applicant has the most useful knowledge?
I've found time and again that the younger ones will know an awful lot - but it's all based in their bedroom (as in, what's best for a user on a single machine connected to the internet). Older types will give answers not based on 'what's the best?', but 'what's the best fit?'. One extra word that make a huge difference - sure, the younger ones may have done their MCP/ MCSE and know about Group Policy, but the older ones will be able to tell you what to do with it.
As an example, a bedroom-fanboy will talk you under the ground about how Linux is the best, or Firefox, etc. etc. - but someone with actual experience will not go straight to the best apps, but will discuss how to make the best of IE7/ XP/ Whatever you're using right now.
... young people then to reinvent the wheel.
You need both types in your organization, so simply spec properly your job posts and the right candidates will apply for them, complementing other members of your team.
IANAL but write like a drunk one.
I'll just type this all over again, because 'there was an error'.
If you have a youngster and an oldie in for an interview - here's what counts.
The youngster will probably have knowledge of all the latest s/w - but their advantage ends there. This is because generally, their experience will be limited to what's ideal for a single machine connected to the internet.
The oldie may not have the same knowledge as the youngster, but they'll be able to tell you how to configure IE6/7 to do what you need, as opposed to the youngster who will insist that everyone should be running Firefox simply because he runs it at home and 'everyone knows it's the best'. You can apply this rule to almost any software - the same sort of thing applies to hardware, but that's even more straightforward as there won't be many youngsters who've configured a HP SAN in their bedroom.
You can also apply this to coding - the youngster will know how to code the latest versions, but they won't have enough background to know how to code an older version that you've been saddled with and cannot upgrade.
I've seen this happen in interviews where younger applicants, when asked about what they're into, will go off into long diatribes about Linux/ Apple/ Vista etc. - none of which will be any use to the interviewer (apart from showing aptitude). They won't have any knowledge about running Win2000 apps, Win2000 itself, NT4....and it's the historical stuff that's important, partly because older problems may not have a dozen web pages telling you how to fix them!
How do you measure quality?
And maintainability?
IANAL but write like a drunk one.
What about if you are hiring for repetitive tasks?
You need to hire based on best fit for a position, something wowing you for a position that is menial may not be the best fit for it.
IANAL but write like a drunk one.
Nowadays any clued up person will stand up and leave.
The proposed question is completely out of place.
IANAL but write like a drunk one.
I will give my account name to nobody. It is nobody's business what I do or write in my spare time.
Library? For bunnies sakes, what has this to remotely do with the competence of a person to do a job?
Do you really ask these questions or are you making sure you live up to the reputation of your shown email address?
IANAL but write like a drunk one.
Any person that has gone through more than a pair of interviews can mask motivation all right, even if their real motivator is one of the ones you marked above.
If your starting point is not actual job competence then you are clearly starting with the wrong foot because are basing your decision in entirely subjective parameters (how do you accurately and truthfully measure or evaluate motivation)?
You can fake motivation, you can't fake technical competence.
IANAL but write like a drunk one.
Your numbers and context simply don't add up.
IANAL but write like a drunk one.
Yanking good drive out of a production machine to see whether raid works is one of the first things you SHOULD do. Basic risk management and verifying how far your comfort zone of things running actually go. Want to test RAID? Knock yourself out!
Do it before it goes into production. Not after.
The "old guy" method finds the bad firmware while the problem is only an annoyance. The "I found it on Google" method will get you fired and the company sued (and they'll lose too.)
Lawyer: "So you walked over to a perfectly happy, working production server, and yanked out a drive 'to see what would happen' and took down the airport baggage tracking system for 6 hours?"
Find the people who do this for fun, who pull all-nighters 'cause they were in the zone. Ask: "Tell me about a recent hack of yours that was interesting." Ask: "Tell me about your home network." Ask: "What is the last book you read?" (The actual answer is not all that important, but an indication that s/he reads is.) Ask for opinions: "Which is better, Python or Ruby?" And then whatever the response is, ask "Why?" Those "why" questions are a gold mine of information.
Look at the younger guys who may not have gone to college, but show progression through jobs. When you find one who did not graduate college but went up the ladder on their own you get someone who may need a little more initial guidance but they learn quicker, teach others, does the work of several average IT people, and they are also more flexible in their ways. Put too many older IT people in the same room and you have fireworks
Here is what I ask candidates:
1. What is the hardest problem you (personally) have ever had to solve? What was your approach? Why did it succeed/fail?
2. What is the hardest NON-TECHNICAL problem you have ever had to solve? (Note that most people assume question #1 refers to technical problems, which is not unreasonable). What was your approach? Why did it succeed/fail?
3. If there was only one thing you would like me to know about you, what is it?
4. What question are you dying for me to ask you? (I'm assuming here that it's because you think you have a really great answer for this question -- OK, let's hear it).
In a half-hour I can usually tell who's a maker, who's a faker and who's a taker.
what is this discussion about?
telling him how to conduct interviews? omg - I hope he is not the decision maker.
Age? Experience is the factor, and if that correlates to age, so be it. Apart from that even considering age is plain useless.
clearly the man has no idea what he is talking about. I hope only his hiring skills are this dodgy
having been on both sides of the interviewing process, some of the statements here seriously scare me: What is this discussion about? Support on how to conduct interviews and hire appropriate people? fair enough, bring it on. But hey, does no-one find some of those thoughts at least a little bit strange? "Although I'm very much focused on choosing the right person for the role regardless of age, experience or whatever..." what is this supposed to mean? Of course experience is a major factor. Amongst others. And most likely there is a correlation of some kind between age and maturity and experience. Generally speaking. But lets not focus on age. Focus on experience. But that, of course is far harder to detect. "probably fair to say the more mature applicants will get a more sympathetic hearing from me than they might from most other interviewers" Why should they? That is as saying I give women, Chinese, disabled a more sympathetic hearing. Why? Just treat them all equally. "I ask older applicants to get them to demonstrate the value of their experience?" Why would they have to prove that they are more valuable than younger ones? I dont get it. "What should I be asking of the more experienced applicants, and what responses should I be looking out for?" Ok, this is the only valid question in the entire paragraph. And even this - by the way it is asked - seems to suggest you have no idea what you are talking about. Why this makes me scared is that clearly people who have no idea about recruitment and judging someones fit for a role - in an interview process - are tasked with the role. Can we please educate those people better? For the sake of potential employees and companies. Sorry if I am being hard here, have just seen too many such situations go wrong to mutual disadvantage.
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.
I'm inclined to think that your closed minded attitude is the reason that you've been in IT for 20 years, and are just now getting to a position to make hiring decisions. I'm 26 and I already get to make some of those decisions. You know why? Because I know that sometimes a motivated 23 year old is more valuable than a 55 year old just waiting for retirement. I also know that most of the software in use today wasn't around (at least in it's current form) 20 years ago, so who cares if you were a sys admin for OS2 Warp.
A decade of real world experience may sound good, but you have to determine whether that means 10 years of experience ... or merely six months experience 20 times.
I've been in IT for around 10 years now, and I'm still learning tons of stuff. Outside of troubleshooting and a few other things, hiring straight out of school (IMHO) is not always a good idea. ESPECIALLY when it comes to customer (i.e. end-user) service.
One funny anecdote I like to tell people how experience matters in my job: I used to work for a popular fashion company in NYC. Tons of hot girls. I noticed that every once in a while, one of them would be super nice to me. And then I would do special things for them (find a sound card for their music, etc.) as they asked. I was befuddled why they no longer paid attention to me. Then I figured it out: hot girls use IT guys to get shit. Now, they wait longer. Well, that's not always true, but since I'm married it doesn't matter and I always like the eye candy. But at least I'm aware of it now. :)
My favorite IT question is "vi or emacs?"
If they look at you funny or don't have an answer, they should not be hired.
It doesn't really matter which they prefer, just that they prefer one or the other. I would even accept "BBEdit over NFS or AFS", but if the person can't edit a text file on a remote system, they are all but worthless.
I also like to always ask one question that nobody can answer. If they lie and make up an answer, don't hire them. If they say "I don't know" or "Here's where I'd find the answer to that", they can probably be trusted.
Hi,
we had to filter through a large list of applicats (for a very linux/unix) specific job. In the end we got tired of processing all the queries (everyone claimed they are linux/unix gurus when in reality many did not really know anything about it)...
In the end we asked everyone in the telephone interview as the first 3 question:
"What is the answer to life the universe and everything?"
"Who do the initals RMS belong to?" and
"Who is W. Richard Stevens?"
Those who knew what the answers was, were more likely to provide cunning answers to technical questions that we asked them later.
Here are things I see as relevant, and how they play at different 'ages' in the industry.
1) Problem-solving skills. They can't be taught or learned, but they can be honed over time. The good old guys have better problem solving skills than the good young guys, but both are so far ahead of those with weak problem solving skills (and yes, there are people around who can't rationally approach a problem after 25 years in the industry) that age isn't a determiner.
2) Patience. Old guys have more patience, almost universally. This can drive younger entrants NUTS, when things break and they want to go through endless diagnostics before fixing what is obviously the problem (except when it's not).
3) Cynicism/bitterness vs. eagerness. Part of the patience in #2 comes from eagerness being displaced by cynicism. This can lead to bitterness and mistrust of nearly everything--especially anything new.
4) Current knowledge. As an example, lots of 'old-timers' don't know much or give a rat's ass about Linux. Much of this is because Linux is the 'n'th operating system to come along that fixes everything and makes life easier for users. (until it doesn't). See #3, cynicism.
Both bring stuff to the table, and both are an asset. As a general sweeping statement, you'll probably find that younger staff bring new ideas to light, and get things done faster; whereas experienced people provide robustness, stability, and correctness. They'll also be less blinded by vendor's shiny toys.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Last year we went through hundreds of resumes, and interviewed dozens of people for a position. Only three of them would I say "really knew their stuff". One of them was an old-timer who worked at some prominent places. He had a thorough understanding of the technologies, much more so than almost everyone we talked to. I recommended he be hired (he wasn't). The two deficits he had - one was the boss didn't think he'd like being oncall 24/7/365, having to do off-hours work onsite in the middle of the night and so forth. The second, which I agreed with, is he didn't know all of the latest whiz-bang stuff in the latest version of whatever. I knew though that he could easily learn all of that quickly, while some kid right out of college would probably not have that deep understanding of things that he did.
From an HR/legal perspective, bad idea to mention the age of other applicants during the interview. Especially if you ultimately go with the 23-year old. Another way to get the same answer is to lay out a scenario that requires maturity to deal with and see what the answer is... i.e.:
Suppose you are given a project to complete. You are halfway to your deadline and stuck because you are not getting what you need from members of other departments. How do you handle this situation?
The trend I have come to see is scripting of the interviewer's questions, where the person interviewing has no idea of what they are asking. As someone with a doctorate in physics, that has programmed on more OS's and in more languages than most people have heard of, I've taken to just terminating such a conversation as a waste of my time. More than a few times, I've told the person I'm talking to, to have someone who understands the questions they are asking to call me back if they are serious, otherwise not to waste my time. Positions are a two way street, if the person doing the hiring isn't serious enough to put a qualified person on the hiring line, I figure they aren't serious enough about wanting someone who can actually fix their problems. On the converse side, anyone coming into my company to interview, talks to me directly, and I completely ignore any "certifications" - I want experience and knowledge, and there are no tests for that.
You may want to rethink your questions and talk to your HR department before having candid age conversations. Technically, unless the job requires an age barrier; you cannot as a candidate their age.That can be considered basis for a discrimination case.
Typically HR departments have the "dos" and "don'ts" for your company's interview process.
Just my 2 cents.
...of young and older. For one, the young folks will come in with new ideas. On the other hand, the old hands will be able to say when they *are* new ideas... and when they're not, and have been tried, and are disasters.
For another... back in the mid-nineties, I worked for Ameritech, one of the Baby Bells, I was the sr. technical resource under my director, so over the course of two years, they dragged me in to do the technical part of the interview for all five teams; I interviewed over 40 people. What I was looking for was what they actually knew, and where any might be bs'ing us. One of my questions for right-out-of-school was, "what's the longest program you've ever worked on?" Most were 1200 or 2000 lines. Our system was nearing a million lines of code. It takes real experience to deal with that many files, and that much code: you hand the new folks the smaller things, so that they can learn how to actually do it, not just hacking together whatever it takes to make your grade.
I was just working with a young woman - her second job out of college. I was one of two admins, she a developer. She did a real good job, apparently, to get the first cut of the portal up - enough so that our manager promoted her to team lead on that portal group. I have *never* heard a team lead go around to the rest of the group once, or even twice a day, and spend so much time explaining how things worked (mostly, that she'd written). Several of the other developers who worked on that told me that her code was a nightmare to work on or enhance. Actually, some of them got moved to other portals we were working on, so as to not have to deal with her, or her code.
That's why you need experienced developers. I probably shouldn't say this, since I'm job hunting right now, but one of my standard interview lines is that I try to do elegant, as opposed to clever, code. If I get a phone call at 16:00 on Friday, or 02:00, I do *not* want to spend hours figuring out how I'd been clever a year ago....
Remember, getting it working is the barest beginning. Then there's maintenance, and enhancement, and someone else years down the line doing it.
mark
You better watch that age discrimination, mister. You're on my list. And it's a short one.
I am 43 and have been writing software since I was 13 years old.
During dot-com, I worked at a company along side a 19 year old programmer. And, although this person obviously did not have as much experience as I did, they helped me to remember the enthusiasm I had when I was starting out. We got to work closely together on a project where I could help mentor a little bit and my younger team mate helped show me how much fun programming was.
Amaturs talk about languages, noobs talk about algrothims, pros talk about version control.
In my own place of work, it is against the state labor code to ask different questions to different applicants. Questions can not be framed or tailored to any applicant. This is designed to create a level playing field for all applicants...obviously, it takes away a lot of the flexibility of an interview, but as many others have said...your current thoughts are very bias, and your potential question is completely discriminatory and very likely illegal depending on where you are and what laws are resident over your organization.
I'd personally suggest you step away from this line of thought and re-think how you would interview ALL applicants equally on the basis of skill, ability, or other non-discriminatory factors. Then, design a series of questions that are relevant and pertinent to the needs your business requires to be fulfilled by this new position. The minute you bring in age as a factor, you've already lost the ability to adequately find the right person for the job.
Good luck.
That I don't know everything.
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.
I don't agree with that at all. Just because someone is older and has more experience doesn't mean shit. I've met tons of older people who think they know what they are talking about and it turns out they don't. I'm 22 and I've been working in IT since I was 16 doing help desk and now i'm a Systems Administrator for a very large company. I've been working with computers since I was 9 or 10 and I don't think this is uncommon with people my age. Just because they are "easier to work with" doesn't mean they can do the work or do the work well. Just because someone has 30 years of experience working in IT might mean he knows the business end better, but sure as hell doesn't mean he knows the technical side in and out.
What you should ask are questions about how the person will fit in on your team, and the unique skills that they have to bring to the table. This will help you decide who are the best candidates. Technical aptitude aside, personality issues can be morale/workplace killers. Make sure your team is comfortable with each other first. Most other things can be worked out.
The justification for hiring an older person is "experience." You might state that "candidates with 10 or more years of industry experience are preferred."
However, "experience" can be a double-edged sword. I once worked with someone who was hired to do a job that's normally best suited for someone who's in the middle of their career. The justification for hiring this person was that he had 30 years of industry experience... He was programming when I was in the womb!
When I worked with him, the quality of his work was awful. Lesson learned: Experience can be useful, but too much experience for a mid-level career job can indicate that a candidate rose to his/her "highest level of incompetence"; or couldn't figure out how to plan a proper retirement.
No, I will not work for your startup
Brad Smart wrote a book called TopGrading where he estimated that in a typical company 75% of the hires are mishire. '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 kind of questions alone tell me you are not only a mishire, mis-elevated as well.
I understand that most interviewers do not get training in interviewing and/or hiring but do not at least take things as their face value. If you want effective people look beyond their age, appearance, certifications and especially experience. You want only A-Players in your team. Although if you a B/C player yourself you will not only never hire an A-Player, you won't even recognize them they'll appear as 2-digit-IQ buffoon anyway. My 2c.
You saved past employers. The how, the when, the where, and for who, and may we contact them to verify?
I killed da wabbit -Elmer Fudd
I'm sorry but this hiring manager just doesn't get it. What you want is to hire people that will get along and work as a team. It's all about attitude, young... old... doesn't matter if you have some senior admin that is really good, what if he's a complete a$$ and is a know it all, what good is that? Or a young kid that thinks everything he suggests is correct and isn't open to criticism, what good is that? There has to be a balance, experienced/less experienced/green candidates.
I'd rather be working along side a group of folks that are a tight knit group and all get along.
I am studying this subject in one of my marketing courses right now. Its a generation gap that creates the differences in psychology
Basically generation X (assuming your one of them as I am) grew up in days of layoffs, high interest rates, and economic turmoil. We are not loyal to our companies as they are not loyal to us. We work our asses off because they can send your ass to the street if they do not like you.Its good to jump ship when possible but never burn your bridges. ITs just a job but that job is required for us to survive.
Baby boomers have a mentality from their parents who grew up in the depression to be yes sir men because they should be thankful to just have a job. Many are old fashioned and do not want to spend more time at home as wives typically take care of that.
Kids today are generation Y. They grew up in prosperity in the 1990's and have lots of toys like laptops, ipods, expensive cell phones and watched their parents become rich with internet stocks and housing booms.
This is why the younger generation doesn't want to work hard. They assume they will be fine and its a right to have everything and a good job. Boy they are going to be in for it now when they are laid off due to the current depression and economic crises.
http://saveie6.com/
80 hours per week, every week, for 17 years. Started at age 6. What's the problem? I've doubled up jobs several times. This sounds completely plausible to me. ;) Maybe he's a Twin, then they could have started working 80hrs/week, every week, at age 14 1/2. Definitely sounds like management material to me. :)
Lots of good stuff posted already.
As a geezer currently in the job hunt I can identify with several comments.
I use interviews to learn about my possible employer.
* If the job doesn't sound interesting I won't bother.
* To be interesting, it has to have elements I've not done before.
* Is this a 'tie' shop? Excuse me, I think I left the roast in the oven.
If I were on the hiring side of the desk, I might ask, "What was the most recent language you learned, and how did you go about learning it?" Substitute any concept you wish for language.
Scenarios are good. I like the one response, "And then what..."
What do you know about Foo?, where foo is some aspect about the business the company is in. I interviewed with the Canadian Forest Service as a "Carbon Cycling Technician" I got the job because I had some experience programming, could obviously learn on my own, and also had spent the week before the interview reading up on the carbon cycle in forests. The interview asked me all sorts of questions about indicator species, eutrophication of lakes, reaction rates as a function of particle size. I was also asked if I had any experience snowshoeing, what my tolerance for mosquitoes, and was I afraid of heights. (Turns out that part of the job was taking samples at various times of year and climbing 40 meter towers calibrating CO2 sensors.)
It really helps if the programmers know enough about the business to make intelligent decisions.
Third Career: Tree Farmer Second Career: Computer Geek First Career: Teacher, Outdoor Instructor, Photographer.
I have 10 years (4 -Non-IT and 6 IT) of Job experience. 99 percent of time people fail to play the role due to the Attitude problem. Attitude is very important to be successfule. Big post big responsibility. The person should believe in Win-Win situation. The person should be able to come out of his shell of seniority and respect young talent. Work becomes joy and lead to sucess if you learn to appretiate and start respecting talent irrespective of age and designation. For such post the person should understand the secret of a successful professional - *Never stop Listning*, *Never stop Learning* and *Never stop Training*. You should be wiling to take responsiblity for failure and project team for the success. You can judge these things by giving real life situations and asking how he will handle the siyuation as senior person. Good Luck!!
"Progress doesn't come from early risers - progress is made by lazy men looking for easier ways to do things." Robert Heinlein
The Dunning-Kruger effect I still don't think you should mention age. However experience is a good thing and should be looked for in a candidate.
Ask Scenario Questions like: If you were developing a project that was behind and I assigned you someone to help how would you proceed.
The response could be very telling. From out right resentment and disbelief that it could ever happen to overly enthusiastic acceptance of blatant interference. If someone comes up in the middle with something like: I would advise them on my progress and assign them a meaningful yet redundant task to complete so I could focus on the heavier stuff while still using the additional asset to the fullest advantage. They might be a good choice. You don't want someone who will roll over or refuse help.
"The stupid neither forgive nor forget; the naive forgive and forget; the wise forgive but do not forget." -Thomas Szasz
Lets see.
I never went to school, I was schooled at home - thanks to abusive parents. This means I was never actually schooled, so I spent all my time on my computer as a form of escapism.
That was about 18 hours a day from the time I was at least 9 to the time I started working full-time, at age 15 (I started working early so I could move out and be AWAY from the abuse)
18 hours a day * 7 days a week * 52 weeks a year * 6 years = 39,312 hours before I ever worked.
Then, work experience - I started when I'm 15, I'm now 23:
8 hours a day * 5 days a week * 50 weeks a year * 8 years = 16,000 hours commercially (or thereabouts)
Again, note that the commercial experience does not count the overtime I was working - by my calculation that'd be about 5,200 hours or so.
So, 16,000 + 39,312 = 55,312 or so. You can add another 5,200 hours for overtime and get it to about 60,000 hours, but I generally don't bother adding that into my count.
Next question please.
so from age 9 you never slept more than 6 hours a night, inclusive of eating, washing etc. don't worry, I'm not mocking you, just trying to see how far this is going to stretch...