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!
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.
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.
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.
... 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.
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.
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
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?
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.
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.
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.
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.
Who is general failure, and why is he reading my hard drive?
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.
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."
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.
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."
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.
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.
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.
Apparently a 236 UID doesn't get you troll resistant armor.
Guess I'll have to re-roll my character.
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
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..."
True story (but from the world of finance) - my great uncle, back in the 80s, went for lunch with his broker in the city (London) - he noticed all these young people flapping about, making deals, making money. He didn't like what he saw one bit so he decided to move all his money out of the stock market that day. This was some time in August/September 1987. He's dead now, but I still believe he's grinning. Any how - this true story really highlights the difference between age, people who have seen it all before, and youthful exuberance.
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.
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.
Yep experience matters and some times in a bad way. A can-do attitude? Yes. Technical aptitude? Yes. Experience? Maybe. 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. 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. Not that that is all there is to experience but don't ignore the youngsters.
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.
Older workers might be more experienced, but also have more time to develop bad habits. Instead of asking questions like the one you listed, think up a few scenarios and ask them what they would do in the situation.
I don't think this is stressed enough. Age/experience has a very goldilocks approach in IT. It can be too hot and too cold. You can get the old dogs stuck in their tricks that want to port your entire system over to what they've been doing, or you'll get the ones that are so jaded in the civil war against management and marketing that they are nothing but a poison thorn in your IT department. You can also get masters of their craft that are seeking new ways to expand themselves, but may get bored with the tasks you have for them and leave just as quickly as they came. You'll probably get something inbetween.
These are all different cogs for different machines. Maybe you just need a human appliance in your IT department that you can rely on like a laborador to get his job done. Maybe you need someone who's unafraid to stick up for the IT in front of marketing/management (because lack of competent project managers?). Maybe you need a magnanimous whirlwind to roll through your department and get the engines greased and running on the right track within a short amount of time.
For your money, unless they're pursuing IT as a post-retirement hobby, the older ones will typically cost you more for their output compared to the younger ones, but they'll typically be more reliable as well -- as an imprecise generalization.
I am the richest astronaut ever to win the superbowl.
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.
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.
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
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;
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.
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!
By the same token, young people often have things older people lack. Drive, ambition, flexibility, curiosity, and a lot more hours they're willing to work on salary.
Not every older person lacks those. Heck, I've been posting on /. since I was "the young IT worker", and now I'm approaching the time I'm supposed to be put out to pasture.
The real issue, I think, is that too many people suck at learning on their own. They come out of school with Java, and if they can't do that, they fail.
I interviewed an older coder in the past year. He was over 40 for sure, maybe 50, but was playing with RoR, knew python, but still had his C and bash under his belt. The *only* reason I didn't hire him on the spot was he was very expensive and it was early on in the interview cycle. (In retrospect, I'd have pulled the trigger; it turned out to be much, much harder to find good people than I had expected.)
I haven't got 20 years of experience, but I've never been in charge of other developers. I don't think it's a question of trust, but of scope; the work I do is something that really doesn't require additional people.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
What is the most fascinating technical problem you've ever solved?
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 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
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.
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.
- My favorite error message: xscreensaver, running on an old Sparc 5 w/ 8bit color: bsod: Couldn't allocate color Blue
In my experience, age itself doesn't matter. I have dealt with young people who are hopeless and old people who are hopeless. I have also dealt with amazing older folks, and just as amazing younger "fresh" kids. The skills/traits that I look for in people these days are (Pretty much in order):
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.
Moved to http://soylentnews.org/. You are invited to join us too!
I like that last one.
I actually wrote code that was self-modifying, managed to crank a four page pyramid of nested if-then-else blocks of code into one amazing twelve line chunk of code that modified itself at runtime based on the evolution of the data as it was being processed.
When I was young.
And stupid.
Glonoinha the MebiByte Slayer
But that young person is closer to school, meaning they learned from not just your mistakes but the mistakes of the industry over the past 30 years and very likely the youngsters were playing with real-world code long before they ever could have counted it experience.
You learned something applicable to actual programming in school? All I learned about was Turing machines.
I coded a lot of useful programs before I ever hit college, up to some fairly sophisticated character generators for my gaming group. While I was in college, I learned that everything I knew about programming was wrong, that I was an idiot for using BASIC, and that everything I really needed to know was in Maths. I graduated with less applicable programming knowledge than when I went in, couldn't get a programming job anywhere, and I've actually applied my college knowledge exactly once in the last eight years since.
College and universities aren't teaching you about the mistakes of the industry over the past 30 years. They're teaching you about the mistakes of the industry made before the last 30 years. Forget about the degrees. Ask them for an example of code that they've written, or ask them to write a simple function for you right there. You'll learn far more about their skill as a programmer than age or resume will tell you.
Problems from Project Euler seem to be a popular choice.
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.
Chuck
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.
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.
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'.
Xfce: Lighter than some, heavier than others. Just right.
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.
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.
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.
Who is general failure, and why is he reading my hard drive?
So you worked really hard, beyond expectations, etc. Where did that get you? I mean in terms of eventual success with work, accomplishments, happiness with life, etc. I'm not trying to be cynical, it's just that I'm in grad school (biomed. not CS so not quite the same but still) and have been coming across alot of different attitudes towards how much time/effort one's job needs to take up in order to do something that contributes to society and leaves you satisfied with your effort without wasting your life away working for someone who benefits more from your effort than you do yourself.
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??
Control is an illusion, order our comforting lie. From chaos, through chaos, into chaos we fly
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.
You could just ask them...
Which is better and why?
a.)if(true==$variable)
or
b.)if($variable==true)
Beer! It's what's for breakfast!
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.
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.
I'm 46 and recently got recruited from a mechanical engineering position (~25 years in the business) to a more of an IT support-type role.
As the least experienced team member (but most experienced, engineering-wise) I was given what I perceived to be a busywork task, i.e., I "felt I was too good for the job" which was essentially data entry. After a bit of poking around on the internet and phone calls to contacts I was able to automate the process and document it, reducing manual input hours for future projects.
If I hadn't said to myself, "Myself, doing this repetitive work in this age is silly and beneath me, so I'm going to find a better solution" I'd be entering that data still.
Neither.
if ($variable) ...
Why doesn't Slashdot ever get slashdotted?
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.
I still have more fans than freaks. WTF is wrong with you people?
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....
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!
You can never go wrong hiring the hot flirty chick.
There must be, or why do you see job adverts requiring 4 years experience in something that's only been around for 2?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
You are just playing games with the interviewees by showing them how clever you are.
IANAL but write like a drunk one.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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?
It's been a long time.
b, because you can get a compiler or checking tool to warn you about assignments in if statements, and a is harder to read.
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.
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.
In a more general IT sense, you're not too far off the mark.
The question isn't meant to test the technical ability of a candidate - though is certainly can be used that way. It is more effective as a method by which the interviewer forces the interviewee to display critical thinking skills. Even if the interviewee answers incorrectly, the interviewer will likely have some insight in to their thought process - an important factor when evaluating specific experience.
At a previous employer I worked for, the team prepared a list of 10 very difficult technical questions (both related to the position and not) just for this purpose. One of the goals was to get the interviewee to say, "I don't know." Bonus 'points' were given if they added, "...but I'd like to know." The point of getting the candidate to say that was to see if they're smart enough to admit their lack of knowledge/experience and seek assistance when they really don't know the answer to a problem.
My sources are unreliable, but their information is fascinating. -- Ashleigh Brilliant
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.
This is what I call 'Positive Laziness'. Intelligent lazy people think first if there's a way to shorten/ease an otherwise work-intensive (and often monotonous) task and come up with a nice, (semi-)automated solution.
Whereas real lazy people think of how they can avoid the work at all.
Amaturs talk about languages, noobs talk about algrothims, pros talk about version control.
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.
An article I read in Scientific American Mind basically suggests that the key to above-average or genius level intelligence is that sort of laziness.
It suggested that in mental tests given by researchers among two groups; one group of people with average intelligence and one group of people with above average or genius level intelligence, the difference seemed to be maximizing the resources we're all born with by minimizing the things they had to do in order to come to a solution.
It's been a long time.
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?