Interviewing Experienced IT People? 835
thricenightly writes "After more than 20 years in IT I've learned that the most valuable people in a team are frequently the old timers. Young pups straight out of college might (think they) know all the latest buzzwords and techniques, but in the real world, where getting working products delivered on time and on budget is of paramount importance, people who have been doing the job for a decade or two tend to be the people I'd rather be working alongside. I've recently been elevated to a position where I get to interview and choose those who get hired in my department. Although I'm very much focused on choosing the right person for the role regardless of age, experience or whatever, it's probably fair to say the more mature applicants will get a more sympathetic hearing from me than they might from most other interviewers for IT roles. The question is, what do I ask older applicants to get them to demonstrate the value of their experience? My current gambit is something like 'IT is seen as a young man's game. My next applicant after you is 23 years old. What do you know that he doesn't?' This gets responses ranging from the vague to the truly enlightened. All next week I'm interviewing for a number of senior software designer and developer roles. What should I be asking of the more experienced applicants, and what responses should I be looking out for?"
Here's your answer.. (Score:1, Insightful)
I don't get it (Score:5, Insightful)
What mistakes have you made? (Score:3, Insightful)
And what have you learned from them?
Re:What they bring (Score:4, Insightful)
Passion is critical (Score:5, Insightful)
Ask about their mistakes (Score:5, Insightful)
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.
no! (Score:5, Insightful)
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 young engineer comes to you at 5pm" (Score:4, Insightful)
... 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.
Interview the person like you actually care, oh an (Score:5, Insightful)
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.
Im young (Score:1, Insightful)
Experience (Score:3, Insightful)
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.
Re:Passion is critical (Score:3, Insightful)
Passion is good. But the ability to learn and problem solve is better.
Passionate people go all out on everything. Successes are huge successes and mistakes are huge mistakes.
Re:What mistakes have you made? (Score:5, Insightful)
That good GPA indicates you passed up a lot of opportunities that you'll regret later.
Re:Slashdot ID (Score:5, Insightful)
I was fortunate enough to be thrown in to it and gain the experience in the Air Force, and how anyone "gets their foot in the door" blows my mind. I have some very smart friends who are very capable, but in an actual work environment, they'd be completely lost, and that goes for most everyone fresh out of college with a computer science degree. Experience is what makes you useful. An experienced programmer doesn't need experience in a particular language to be at least servicable, but a hotshot young gun could know a language like the back of his hand and be worthless.
I'm not saying I don't think you are capable or even that I don't think you have the experience. But whereas you (I'm assuming semi-jokingly) refer to how long you've been on slashdot as evidence that you know what you're doing, I would refer to the projects I've worked on and not only the work I've done, but how I've affected the team working on them as a whole and how they've affected me.
Which brings me to the OP's question. Some of the important things I listen for in interviews is how people have dealt with adversity. Name a problem you had on a project and how it was overcome. Name a time your solution was wrong and how you dealt with it. Tell me about a time you had a problem with someone on your team and how you overcame it. The technical stuff is a given -- look at their resume. I want to know how this guy will make us successful.
Re:I don't get it (Score:3, Insightful)
A lawsuit? (Score:5, Insightful)
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?
Experience Ageism (Score:4, Insightful)
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.
Re:I don't get it (Score:5, Insightful)
There was a trend to hire young IT people because certifications were the thing to have, and younger people work longer hours for less money. The problems with those types of qualifications are starting to bite the IT industry on it's collective ass.
If you want qualified personnel, ask questions that quantify them as a good technical and social fit. Pick some script language they don't know. Ask them if they would take a few minutes to create a 'hello world' script. If all they know is one programming language as seen via one particular IDE... well, it's something you want to know.
It's odd, but hobbies can tell you a lot or nothing about an individual. If they skydive twice a month on average, it says something. If they are working on an OSS project and can show you the sourceforge page... that says something.
There are other considerations; There are not many young Cobol programmers. If an applicant was invovled with the team that implemented X.25 for a large IT company back in the 90s, he's probably a better fit for X.25 network systems than a 23 year old would be.
If all you need is a [name your language here] monkey... you can find that in any age.
Look at your requirements, find a good match to that. Age does not dictate value, but experience can. Anyone of any age 'can' have the right experience, but statistically, it usually works out a bit lopsided.
Re:What they bring (Score:5, Insightful)
What you want is not so much an employee that is necessarily older but an employee with predictable skills, attitude, and way of thinking (or at least tolerable) in your eyes. As a bonus, you end up with the most compatible person for the role, regardless of age.
Re:Interview the person like you actually care, oh (Score:5, Insightful)
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.
Re:Here's your answer.. (Score:5, Insightful)
You don't get rights just because you're young, old, black, white, yellow, pink, blue, male, female, etc...
Yes, all people are created equal, that does not imply that all people ARE equal.
Experience matters, as does intelligence, attitude and aptitude.
If you can say you have the experience that someone older has, as well as the attitude and aptitude of the older applicant, then you are equal, if you don't have that experience, attitude or aptitude, then you aren't, it's as simple as that.
It's not age discrimination, it's making a decision weighted on key factors that mean more than any education.
I'd rather hire someone with years of experience, a can-do attitude and the technical aptitude that enables them to almost intuitively understand a system or troubleshoot a problem, than someone with only a few years of experience, a PHD and a "I'm too good for your job" attitude any day.
Way To Get Sued (Score:5, Insightful)
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.
Re:True nerds start young (Score:3, Insightful)
Try this one: "if we paid for additional training, or gave on-the-job support for it, what skills would you pursue"? And since you want experience, but you won't want to hire people who've reached their level of incompetence, ask them how much higher up the skills list they think they can go, and what they're doing to pursue that.
And do ask "what documentation you've written is still in use, and where"? Then go read it, if you can.
Re:Wrong idea! (Score:2, Insightful)
Best people learn - and not just tech stuff ! (Score:2, Insightful)
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.
Most IT shops want Bit Flippers (Score:3, Insightful)
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.
How is your age helping you in your current task? (Score:2, Insightful)
Re:Ask about priorities (Score:2, Insightful)
Follow the bouncing ball (Score:4, Insightful)
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.
Re:Experience (Score:3, Insightful)
Re:Questions about Experience (Score:2, Insightful)
Especially when the candidate says with a smile "These things must be done carefully or you hurt the spell".
Yes, it actually happened in a job interview in the early 90's for a programming manager position. I expressed concern that I've never managed people, only coded. They took that to heart and hired a manager.
Then again, a friend asked a company what they use for their code repository. The interviewer was mystified when my friend excused himself from the interview after the interviewer replied "Clearcase". My friend's position was that any company who's been sold useless crap at the CIO level rather than using ones that actually work isn't a place where he'd want to work. Seems he's had to deal with 30-minute Clearcase check-in times over VPN. Subversion and CVS "just work" but they weren't the corporate standard in the newly acquired company.
Yes, I've been around for 20+ years but that doesn't give me the edge on a 20-somthing kid who will work long hours and weekends. Been there. Done that. Lost a couple toes. Hire for the job. If you want people to swap war stories with, go to the bar at a LISA meeting.
Always make interviewees answer why (Score:2, Insightful)
The Question (Score:5, Insightful)
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.
There really is no such thing as "falling behind" (Score:5, Insightful)
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.
Re:Here's your answer.. (Score:5, Insightful)
I've been writing software for nearly 15 years and real world stuff for almost 10 and I was supporting friends and relatives with IT stuff long before that. On my resume you see 5 years professional employment. Plenty of kids getting out of school now have been writing stuff since I started, have no "professional" experience, but have been cutting their teeth on open source for years.
Re:Interesting question ... (Score:4, Insightful)
Funnily enough, I've had the opposite experience: people who are younger, in terms of experience or age, are a lot more positive in their opinions and close-minded than older or more experienced people. I don't have a lot of theory around this, except that a more experienced person has had a lot more opportunity to be proven wrong about their preconceptions.
This matches my own personal experience. I can really only compare my "old" self with my "young" self, but I would say that the young me was more confrontational and irritatingly positive (you can use Perl for everything!), and more willing to do a lot of pointless after-hours work and be oncall. He was a lot less reflective and somewhat less rational regarding his decisionmaking. He had little broad perspective and familiarity with a few technologies that looked to him like all there was to know.
The older me is more knowledgeable, certainly, and more familiar with lots of "allied" tasks associated with programming. I'm a lot better at handling people. I'm a lot more willing to experiment or investigate new technologies for something rather than relay what's already in my toolbox.
This might seem paradoxical, but it makes sense to me. An inexperienced person has probably had few revelations like the hg example you give or using a functional programming language on a real project. An experienced person has a good feel for what kinds of tasks are no big deal and what takes a lot of time.
All that said, I dislike very much the idea that programmers are characterizable by their languages, their age or experience or their domain. Frankly I would leave that out of it and just do a straight interview (though you may be interested in analyzing differences after the fact).
Re:Here's your answer.. (Score:5, Insightful)
You are creating a false dichotomy there.. of COURSE you would prefer the a can-do experienced person over someone with an "I'm too good for your job" attitude. You are absolutely wrong, however, to categorize all old people in the first group and all young people in the second group. There are many young people who are experienced and have a can-do attitude, while there are older workers who feel they are too good for their job.
Re:Questions about Experience (Score:2, Insightful)
I would drop unimportant items from my inventory on the floor as I go from room to room. I would not assume that the maze layout made any sense whatsoever. And I would pay careful attention to any variances in the textual descriptions.
As for the punch-cards the sieve of Erastothenes method sounds like a great way to solve the problem. Do I get a hole-punch? A computer? Or the bits to make my own computer? Since those are the items YOU have could I not just write a short program on my RPN calculator instead?
Given that I'm only two and a half decades old either: (a) these screening questions aren't hard enough; or (b) I know more than the average for my age.
If I was interviewing I would want to know that the person understands version control. I would expect them to demonstrate that they could understand the user's needs (e.g. interface design). And I would want to know that they weren't hostile to development processes (e.g. code reviews).
Lots of problems in the question (Score:4, Insightful)
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.
Re:Experience (Score:3, Insightful)
The question's not bad but the evaluation is busted. What you want is someone who can have an intelligent conversation on the subject, and who understands that what type you need for a zip code is a more subtle question than it might seem at first.
For one thing, it's certainly a compound type: the zip and the +4, even just in the USA; and I can't imagine an application that stores addresses that would never need to store an international one. About this time I'd be online looking around for post code standards.
I can tell more experienced people a lot by their reactions to things like time zone handling or unicode. If you grimace and start mentally listing a lot of thorny complications and considerations, then it's something you have probably thought about before. If you start saying something glib that starts with "All you need to do is..." then you haven't.
Re:Wrong idea! (Score:1, Insightful)
I agree to an extent. I've found the younger ones are quicker to learn something new and more motivated to do so. On the other hand, the older people have the experience to anticipate the bumps in the road, which can be invaluable.
I've seen allot of young developers write great projects that just were not sustainable/maintainable. I've also seen the old guys write solid projects that feel like using an abacus.
If you are saying one is better than the other, I think that's just wrong either way - you definitely need a balance of both.
Don't mention age at all (Score:5, Insightful)
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!
Re:Experience (Score:1, Insightful)
This is one of those crazy "gotcha" questions that has no relevance. You're just testing people on their knowledge of zip codes, not on their knowledge of DB design. If your "newbie" said to use an integer, and then you said, "Did you know some zip codes have a leading zero?" He would say, "No, I didn't. I guess it doesn't make since to use an integer in that case."
It would be like if you knew of a city in Alaska that had the zipcode 3.1415 and asked the same question.
Re:Old goats vs young whipper snappers (Score:2, Insightful)
Re:What they bring (Score:3, Insightful)
True, but the solution is simple:
'IT is seen as a young man's game. My next applicant after you is straight out of a top 5 university CS program. What do you know that he doesn't?'
Re:Slashdot ID (Score:3, Insightful)
Don't forget that coding consists of 80% programming and 80% troubleshooting. You don't learn that at school. Sure, you learn how to use a debugger, but that won't help you figure out why good code doesn't work in an environment. Experience will allow people to home in on the area where the problem really is, and apply workarounds that are too rare to make it to textbooks.
What I see time and time again are young people who don't know why something is done a particular way, so they do what to them seems obvious. And break things by doing so. They may not make the same mistake a second time, but they will make it the first time. The oldtimers have already made most of their blunders, and learned the hard way why you don't do things like renaming a library to avoid it from being loaded, or putting echo/stty/tset statements in /etc/profile, or any of the pitfalls too numerous to make it into a school book.
Yes, you pay for that experience. As you should.
If you have a micro-managed environment where you can make sure that no-one is given enough rope to hang themselves (and the company) with, young IT people can be just what you need, because they are cheaper and often work hard. But if you need to give some responsibility, you might want someone who has already burnt himself and learned from it, every time.
There is no fast-track to experience or wisdom. Knowledge, yes, but that's not always a viable substitute.
Re:Here's your answer.. (Score:4, Insightful)
Perhaps I was going too far to imply that you were categorizing all young people into the one group and older people into the other. However, both your original post and your response to my post are clearly meant to make an association between youth and a poor work ethic.
Now what is your purpose in making this association? In the given context, it is clearly indicating that you believe it is a good practice to use age as a proxy for easily judging a person's work ethic. I believe this is wrong to do, and by assuming that a young prospect is going to have a poor work ethic because of their youth is unfair, unwise, and discriminatory, even if you are granting the possibility of exceptions.
Re:Here's your answer.. (Score:5, Insightful)
I'm curious what your definition of "often" is in this case. While I find people across age groups that are lazy, I'm finding it far more likely with younger people these days being the worst in that they want things handed to them and want to minimize what they actually put into the job. I've gotten to the point where I'll take a person with base knowledge and a drive (and ability) to learn over someone with a wealth of knowledge and no such drive any day.
I see this especially with fresh out of college grads and my teen aged sister's kids (and their friends). These people have, basically out of the gate, access to vast amounts of knowledge and great search tools that I would've killed for when I was starting out in computers and barely calling BBSes.. but so many of them aren't even willing to take 2 seconds to search google for an answer and want others to hand them the solution.
I've found that in the last few years, apparently the definition of the word "help" has changed to mean "do this entire thing for me and hand it back so I can take credit." Not to mention that "training" seems to mean "Give the final steps without explaining why any of this is required."
Though one of the worst offenders for both of the above ideas was a couple years older then me. Thankfully he's gone now.
I agree completely.
I've known plenty that just have no drive to learn.. and if you want to work in IT and don't like continually learning the new stuff, leave the field now, you're in the wrong one. But I have known a few that just can't get beyond a very basic level. They're just as bad in the long run and have no read future career path.
Re:Here's your answer.. (Score:5, Insightful)
1) Common Sense - It goes so much further than anything else.
2) Ability to comprehend tasks - I don't want to have to explain things over and over for one. Secondly, if they understand what they are doing, there is a good chance they might have a good input to make it even better.
3) Communication skills - If they can't talk, articulate and be precise in asking questions or listening to answers, they won't do point 2 well.
4) Programming ability - Yes, it's way down on the list. Most programmers can program well enough. The value in good software/development isn't purely in scratching two seconds off an operation that takes three minutes. It's in making an application/solution that the customer wants to have - which isn't always exactly what they ask for.
As developers I look for people that COULD possibly be in the business role that they are developing for had they wanted to, but chose developing instead. People who can understand what the business/customer is doing will ALWAYS make better software than people who follow requirements to the letter. The four points above in that order will help you find people who will do the best work.
Re:What they bring (Score:2, Insightful)
I second this. I was told by my HR dept not to ask age or bring it up at all (not that I ever intended to)
Just figure out what job role you're trying to fill and dig deep into the answers you're given. Ask them their processes for debugging problems, think of issues you've had to undertake that were difficult and pose them hypothetically to figure out what the candidate would do.
Ask them a couple personality questions 'What would you old co-workers say about you?', and give them a very difficult or impossible problem to solve and see how quickly they flip out (or hopefully, not at all)
I'm 33 and I definitely think that I've got an 'edge on the younger guys who don't have the experience I do, but I know lots of people my age who shouldn't have ever been hired in IT, yet, there they are, drawing a paycheck and being worthless.
I also have known some brilliant younger people who will likely be my bosses in the future if I'm lucky.
If you start basing your decision on age, you might as well pick something just as arbitrary like skin color.
Re:Here's your answer.. (Score:5, Insightful)
I've met plenty of people that are unwilling to listen to a good answer from a young person because the young person is young and by extension inexperienced.
That is the killer right there. Most older successful people know that everyone is a resource, and LISTEN to everything. Anyone that refuses to listen to someone because of some preconceived notion fails the test.
Usually what older folks bring to the team is the experience of their own mistakes, not just in their chosen field, but in life. People skills that successful people develop over time are super-valuable and can be the glue that holds a team together.
well (Score:3, Insightful)
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.
Re:Oldster (anti-)bias (Score:3, Insightful)
They want time off to be with their families.
But they potentially compensate for that by being more "loyal" employees. People who have dependents tend to be less likely to quit their job to go looking for something else on a whim. A single twenty-something with minimal expenses might not bat an eye at jumping between jobs every year or so.
They want more time off because they've been around longer (2 weeks for new hires don't cut it).
Wow. I wouldn't take a job fresh out of college that only gave 2 weeks of vacation. When I started, 3 weeks was standard, and I thought that was merely 'acceptable'.
Re:Here's your answer.. (Score:3, Insightful)
That's all good and fine. The problem is that the OP expressed all of this in terms of age, not experience:
Replace that with "more experienced", "more experienced applicants", and "has 15 years less experience than you", and we're fine. But the repeated emphasis on age is illegal, and immoral.
Honestly, I think the OP has his heart in the right place, he just needs to mentally divorce the concepts of experience and age.
Re:What they bring (Score:3, Insightful)
'IT is seen as a young man's game.
Good job not bringing up age. Might I suggest, "IT is a field that requires constant learning to remain effective. My next applicant after you is straight out of a top 5 university CS program. What do you know that he doesn't?"
Re:Here's your answer.. (Score:4, Insightful)
I'm sorry you feel that way, as nothing could be further from the truth, as I myself started working professionally in the field at the ripe young age of 16, while still in high-school.
There was no *age* context given. There was, however, an experience context. It's unfortunate that the only way to get 'n' years of experience is to be 'n' years older than you were when you started.
Currently, there's no way to time-compress experience, if there were, it would be wonderful for all.
Re:Old goats vs young whipper snappers (Score:2, Insightful)
Wow! There are a lot of us old bastards around! 8-)
It's hard to get into a monoculture shop (like head to the grindstone ), however the good part is that I no longer want to work in those places. The really interesting jobs are actually pretty easy to get when no matter what they ask about, you can say "Yeah, I did " to almost anything they want (and not be lying).
Another advantage is that even if you pay a guy twice what you could get a grad for, if he understands a half-dozen or more of your systems, and you can skip hiring more warm bodies, you're still money ahead.
Re:Ask about their mistakes (Score:1, Insightful)
That's an interesting notion. I've been directly involved with a project that's been running for several months and which will be running for at least two more (probably quite a bit longer). It is, by pretty much every measure, a total failure; it's vastly over time, moderately over budget (but, of course, we're nowhere near done yet, so just give it time), is suffering from a nasty case of scope creep, and will ultimately result in a substandard customer experience, while failing to achieve most of its stated goals. So yes, I'd call it an abject failure.
Now, since the project began (or, rather, before it began), I've been trying to advise the people who are actually making the decisions, and by and large my suggestions are falling on deaf ears. In that sense, the project failure is very much *not* my fault (I have no problem taking blame when I screw up).
I'm neither stupid nor lying; in an interview, shouldn't I be given credit for being able to accurately analyze the project's architects' failures (poor, late or no planning; failure to elicit user requirements; inadequate investigation of possible equipment vendors; the list goes on)? Isn't that the sort of person you want on your team--one who can recognize and learn from failures in order to prevent them from happening again? Or, more specifically, what I would've done differently in order to have a successful project? I know that comes off as 'well, they screwed up and here's how *I* would've done it because I'm so much smarter'...but what if that's true?
Re:well (Score:3, Insightful)
Actually, I think you're close, but there's a part you missed: people who have been in the job for awhile and are happy where they are. Clearly you're not going to be interviewing such people as they're not out there looking.
I know of quite a few people here where I work that have a decade+ as sysadmins, are very smart and driven, and have zero desire to move elsewhere because they're very happy here. I'm in that boat myself. Sure, there're gripes now and then, but nothing near enough to drive one to leave. There are even a subset in this group that left at some point and then came back when they found that other places were far worse.
A lot of time at a company can mean you've risen up in the ranks (and pay scales) and getting a position in another company that isn't a step down (in either or both) or a big change in career, might not be worth it at this point.
There's also the built up trust and ability to do a lot more remote work and less office time.
Re:Here's your answer.. (Score:5, Insightful)
Re:Here's your answer.. (Score:5, Insightful)
When I graduated college 10 years ago, I was one of those ambitious people... I often stayed at work till 10pm to insure our products/projects met their milestones etc... Recently we hired new hires that are of the new generation. So far, many of these people are out the door as soon as the clock hits 5, regardless the status of their projects and when the milestones were... Even when I'm travelling on business and am halfway across the world, they don't want to take any personal time to give me a hand (even if it's to upload a project they are past due on). They didn't even bother taking their work laptops home, because they don't want to "work" outside of work.
I happen to be one of those people - I don't mind helping out with a few reasonable things and putting in a few extra hours on rare occasions, but many companies expect you to work 60+ hours a week, and if you don't you are not a "team player". Well I say fuck that. You pay me - I work. When you don't pay me - I don't work.
I don't consider my life goal to help some company achieve X business goals. I know the company is not loyal to me - they will fire me if they need to - so how can they expect loyalty from me??
Re:Here's your answer.. (Score:5, Insightful)
Mod parent up? please? Why haven't you done it yet?
Seriously, there's a REASON the older folks don't tend to show the drive and ambition that the younger folks do. You can only work through so many nights without sleep before you finally realize you're not compensated enough (in pay, recognition, or even lack of complaints -- which == recognition in our field often). Sorry to be a whiny IT wonk, but pay alone doesn't cut it. You watch the person you made that app for take all the credit for it and you might get a ** mention in the fine print. They get promoted over and over and you get... another project. Let's face it, people good in IT are not often good with people, and there's not a lot of vertical headroom in tech-only positions in most companies.
Re:I don't get it (Score:3, Insightful)
Trust me, the REAL world is nothing like those annoying tests. If you can pick up a scripting language or other and write a hello world program and keep going, there is nothing lacking in your qualities, only in your experience... if that.
The tests they do seem to often have nothing to do with reality, even if slightly related to the job applied for. The truth of the matter is that most people do not know how to interview. A great candidate knows how to run the interview if the interviewer is failing. Resume's only get you on the short list, and unfortunately that is often a poor way to make the list.
I have interviewed several hundred people for technical and IT related positions in my career. It is the hands-on tests that actually tell you what skill levels a candidate has. Everything else is just talk. I've done the 'hello world' test and an electronics equivalent of it. For one IT position, I handed them a pot of coffee and all the parts needed to build a PC and timed applicants on build/install of OS. That hands on part saves lots of questions that have dodgey answers.
Re:Here's your answer.. (Score:3, Insightful)
You learned something applicable to actual programming in school? All I learned about was Turing machines...While I was in college, I learned that everything I knew about programming was wrong, that I was an idiot for using BASIC, and that everything I really needed to know was in Maths...I graduated with less applicable programming knowledge than when I went in, couldn't get a programming job anywhere, and I've actually applied my college knowledge exactly once in the last eight years since.
Two points: the first is that a computer science degree isn't a "programming" degree. It doesn't take four years of school to be a programmer, it's just not that challenging.
The second is that it takes a computer science degree to manage a programming team and DESIGN efficient algorithms. So you're not using your theory knowledge in your work. Either someone above you is making the decisions, or the place you work for is creating half-assed garage quality software.
Re:Here's your answer.. (Score:5, Insightful)
Sorry you were so stupid when you were younger.
I'm paid to work a 40 hour week. I work a 40 hour week, and I do good work in that time. If you want me to work more, there's a method for that- it's called paying me overtime. Offer it and I'll consider it. Probably not though- I don't really need the money.
Life is short. Free time is far too valuable to be wasted by doing extra work. When you're older you'll never hear any of your coworkers say "Damn I wish I had spent more time at the office". You will hear them say more time with the kids, wife, etc. My father's passed on, and if I could trade a year I spent working for a year flipping burgers for minimum wage but spending time with him, I'd do it in a fucking heartbeat. We're just smart enough in this generation to know this now, rather than waiting til we have a stress related breakdown in our middle age.
Re:Get the popcorn out...! (Score:3, Insightful)
Re:Here's your answer.. (Score:1, Insightful)
well a will give you a compiler error if you only type
if(true=$variable)
but b is more readable
I usually do a so that I get a compiler error if I cock up.
You are not assessing competence with that. (Score:5, Insightful)
You are just playing games with the interviewees by showing them how clever you are.
Re:Here's your answer.. (Score:3, Insightful)
I've met plenty of people that are unwilling to listen to a good answer from a young person because the young person is young and by extension inexperienced.
There are such people around, and yes, they are fools.
But that young person is closer to school, meaning they learned from not just your mistakes but the mistakes of the industry over the past 30 years and very likely the youngsters were playing with real-world code long before they ever could have counted it experience. [...] Plenty of kids getting out of school now have been writing stuff since I started, have no "professional" experience, but have been cutting their teeth on open source for years.
You've made several interesting (but bad) assumptions there. You have assumed that theoretical knowledge from school is more valuable than practical knowledge from industry; this is not necessarily so, particularly in a field such as programming. You also implicitly assume that the youngsters had real-world experience playing with code from before their formal careers started — but for some reason the older, more experienced programmers didn't? Finally, you have assumed that experience gained working on an OSS project directly translates to value in a workplace, though each requires different skills beyond the basic programming stuff. Ironically, as someone who was like you a few years ago but is older and hopefully a little wiser now, I would say these sorts of assumptions are typical of the mistakes caused by a lack of professional experience. :-)
See also the psychology of assessing your own ability: almost everyone would think they are better than they really are in the absence of more objective data from other sources, and worse, the more confident you are in your own superiority, the more likely it is that you are mistaken. You might also like to look up the old paper from IBM about how productive software developers of certain ages typically are when considered on merit. It makes painful reading, whatever your age, but it's an eye-opener.
Re:Here's your answer.. (Score:5, Insightful)
If a person isn't willing to work with the team then you don't want them on your team. I've met plenty of people that are unwilling to listen to a good answer from a young person because the young person is young and by extension inexperienced.
Conversely, I've met plenty of young people who aren't willing to listen to someone older because someone older can't possibly have an understanding of all these fresh, new ideas that they're bringing to the table. (Hell, just a few years ago, I was /one/ of those young people - back before I lacked the experience to know that there are things I don't know. ) Nevermind that the 'fresh new ideas' are variations on the same themes that have been playing through the industry for decades.
The point I'm trying to make is that it's just as easy to get a young recruit with a bad attitude than an older recruit. That's part of what the interview process is for, to weed out the people not compatible with your organization. INterviewing people with the assumption that "older = stuck in their ways" and "younger = innovative and yet willing to learn" is a mistake that can cost you some potentially good hires.
Re:Here's your answer.. (Score:3, Insightful)
You don't need to be old to do that.
I'm an engineer almost right out of school, and it's a little crazy how often a task can be automated for insane time savings. In the time I've been in industry, I've probably saved a man-year of time by taking a task involving a billion little tasks and asking myself "How can I automate this? What decisions do I personally need to make?"
They pay me because I've got the skills to solve problems and design solutions to effectively make use of company resources. Why would I assume they want me to stop doing that when it comes to doing my own work?
Re:Here's your answer.. (Score:3, Insightful)
Of course, YMMV. This is more of a personal preference thing, and strikes me as only slightly more relevant than asking to justify the ideal tab length.
this scares me (Score:2, Insightful)
Re:Questions about Experience (Score:3, Insightful)
"You are in a maze of twisty little passages, all alike...what do you do?"
My answer to that is: Take off all my clothes and start doing jumping jacks while singing Barry Manilow.
If someone else comes along, they're going to take one look at that and run for the exit. All I need to do is follow the scent of fear.
vi or emacs? (Score:2, Insightful)
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.
How to tell... (Score:2, Insightful)
Amaturs talk about languages, noobs talk about algrothims, pros talk about version control.
Re:Here's your answer.. (Score:2, Insightful)
Let A = "All dogs are mammals."
Let B = "Golden Retriever is a dog."
Let C = "Golden Retriever is a mammal."
If A is true and B is true, then C is true.
Or would you rather phrase that as:
If true is A and true is B, then true is C.
What was that about dyslexia? Which English speaking, left-to-right reading culture are you from where the second is preferred?