Forgot your password?
typodupeerror
Businesses IT

Interviewing Experienced IT People? 835

Posted by timothy
from the experience-is-not-just-a-euphemism dept.
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?"
This discussion has been archived. No new comments can be posted.

Interviewing Experienced IT People?

Comments Filter:
  • by hedronist (233240) * on Wednesday November 19, 2008 @05:26PM (#25823801)

    Definitely an interesting question.

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

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

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

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

  • Ask about priorities (Score:5, Interesting)

    by Toe, The (545098) on Wednesday November 19, 2008 @05:28PM (#25823839)

    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.

  • by hal9000(jr) (316943) on Wednesday November 19, 2008 @05:29PM (#25823853)
    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.
  • Experience vs Time (Score:4, Interesting)

    by COMON$ (806135) * on Wednesday November 19, 2008 @05:29PM (#25823855) Journal
    The question is, what do I ask older applicants to get them to demonstrate the value of their experience? A resounding YES. There is a VAST difference between the guy who has been doing the same job for 20 years riding on the coattails of consultants or fear of change, and the guy who has been doing the job for 20 years and has had 5 jobs in that time learning different networks and systems.

    I have about 7 years full time experience under my belt not counting college or any small jobs through high school. I have a lot to learn and seek out people to learn it from. I have met truly ignorant individuals, age has no preference here. Wisdom comes with the right kind of experience. I have learned more this last year bouncing around different jobs than I did at the job I sat at the previous 5 years.

    So yes, ask the question, and make sure you get an answer from the younger and older individuals, you will find that a couple of your kids with 10 years of experience will far outshine the older guys with 25 years doing a repetitive job. Same for a 5 year vs a 10 year.

    Wisdom is what I look for, not knowledge.

  • Real-world scenarios (Score:2, Interesting)

    by dedazo (737510) on Wednesday November 19, 2008 @05:32PM (#25823915) Journal

    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.

  • by Petersko (564140) on Wednesday November 19, 2008 @05:33PM (#25823947)
    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.
  • Re:no! (Score:2, Interesting)

    by Xerolooper (1247258) on Wednesday November 19, 2008 @05:44PM (#25824133)

    Don't mention age!

    I agree with Lord Ender bad idea.
    Might as well let applicants browse the floor and take whatever equipment they want/burn the company down.
    Focus on what you really want instead.

    ...the people I'd rather be working alongside...

    Ask yourself why do you really prefer them. Are they more stable and knowledgeable. Look for those qualities in your applicants. Open your mind to the possibilities. You may find some younger candidates that surprise you. Also you wont be wasting time with irrelevant questions when you should be getting to know your applicants.

    Ask: You have a project that is on time but just under deadline. A new technology comes out that could potentially cut development and cost in half. How do you proceed?

  • by King_TJ (85913) on Wednesday November 19, 2008 @05:53PM (#25824307) Journal

    Wish I could mod you up at the moment.

    I think this is more important than many people realize. You do want to see evidence of experience and a grasp of concepts. (Some people, while eager, are simply trying to "bite off more than they can chew" by interviewing for too complicated a position for their current skills.)

    But overall, yes! The person who "lives and breathes I.T." will be FAR superior to the person who views it as "just a way to get a paycheck every couple weeks".

  • by LifesABeach (234436) on Wednesday November 19, 2008 @05:57PM (#25824381)

    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."

  • by unix guy (163468) on Wednesday November 19, 2008 @06:05PM (#25824545) Homepage

    If you want to get information on how your older geeks think, just ask them, "Of what project you've worked on are you most proud - and why?"

    If their eyes light up and you get enthusiastic responses then you know they do this job for the love of the project - the thrill of the chase... And that means they'll be an enthusiastic and contributing member to your team. If you get dull responses then they are in it for the money - or are burned out and might not be the asset you want..

  • Re:Im young (Score:5, Interesting)

    by symes (835608) on Wednesday November 19, 2008 @06:06PM (#25824555) Journal
    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.
  • Re:What they bring (Score:2, Interesting)

    by Profane MuthaFucka (574406) <busheatskok@gmail.com> on Wednesday November 19, 2008 @06:09PM (#25824613) Homepage Journal

    If we rephrase this into different terms, the problem becomes clearer:

    Sir, the next candidate is a hot woman. Can you tell me what advantage a cock has over two lovely boobs in a low cut blouse?

    Asking an old guy what his age brings over a younger candidate is similar and you should probably just judge candidates on their relevant capabilities rather than how many times they've had a chance to blow out a birthday candle.

  • Re:uh.. (Score:5, Interesting)

    by CorporateSuit (1319461) on Wednesday November 19, 2008 @06:12PM (#25824649)

    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.

  • by wolfguru (913659) on Wednesday November 19, 2008 @06:13PM (#25824679)
    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.
  • Re:I don't get it (Score:5, Interesting)

    by zappepcs (820751) on Wednesday November 19, 2008 @06:14PM (#25824691) Journal

    A skydiver would know. Ever panic and make a mistake? Skydivers don't do that often. Those who do are often not around to tell you what happened or went wrong. Staying calm under pressure is a skill, not just an attitude. Taking risks is a good thing in moderation. Repeatedly taking the same risk creates skills. Crossing the street is a skill you learned long ago, but it takes practice and always involves risk. Risk taking has many forms. It's more of a strength than weakness.

    Translated: Yeah, ok, I don't know language xyz or have not used ABC IDE, but lets go for it if that is the management decision. A skydiver (as an example) will also know that if you are asking for something that will probably cause an accident, the time to speak is before getting on the plane, not as you jump out of the doorway. There are other things I could relate to skydiving... or other hobbies. The point is that personal activities tell you more than many certification papers will if you understand what you are looking at.

    Certs are like the Md after someone's name.
    Q: Know what they call a doctor that graduated 800th out of 800 in their class?
    A: Doctor.

    Do you care where your doctor graduated in their class if they have performed dozens of operations just like you're about to undergo with 100% success rate? A walking breathing skydiver that jumps twice a month is like that.

    Character is worth a lot. You can glean what a person's character is like from a lot of things. These were just examples. Some might not want a risk taker on their team.

  • On mentoring. (Score:3, Interesting)

    by khasim (1285) <brandioch.conner@gmail.com> on Wednesday November 19, 2008 @06:25PM (#25824877)

    Personally, if I was in an organization where we had the wherewithal to mentor someone on their way up, show them how to learn things on their own, give them the latitude to make potentially-costly mistakes in a sandbox, I'd have no problem hiring inexperienced people.

    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.

  • by cowtamer (311087) on Wednesday November 19, 2008 @06:32PM (#25825003) Journal

    What is the most fascinating technical problem you've ever solved?

  • by mevets (322601) on Wednesday November 19, 2008 @06:44PM (#25825223)

    I'm 44 and guessed "righty tighty lefty loosy" was about the sexual habits of republicans and democrats. Wish someone had asked me that in an interview.

    I find, as an interviewee, I am way less tolerant of bs companies and psychotic hr people in interviews. I'm probably a prima-donna, but I'm not going to brown nose some clown just to get a new gig. That is an attitude you are unlikely to find in a 20-something, with crushing college loans and a desperation to find out if they can do the job or not.

    The biggest problem with old geeks is getting them to shut up. If the OP has problems getting old geeks to talk, there may be a reason for it - you might not be that interesting to them, and they are either being polite, or waiting for the good bit.

    You might start with a gambit like 'if at any time during this interview you wished you hadn't come, just tell us, we won't be offended'. If that doesn't work, offer them a beer; either way, you'll at least get some respect from them.

  • by Anonymous Coward on Wednesday November 19, 2008 @06:58PM (#25825471)

    It looks like crap and it doesn't even validate [w3.org] (94 errors).

  • by Kjella (173770) on Wednesday November 19, 2008 @07:05PM (#25825591) Homepage

    Well, after the same generic blah-blah that it's unique to every application, I'd try to draw up three classes that could be at starting point at least.

    For any project where the users choose your service:

    1. User experience. Else nobody uses it anyway.
    2. Fault Tolerance. They don't ask support, they're gone.
    3. Security. You'll be under constant attack once you have a user base.
    4. Uptime. You bet they expect the service to be there when they want it.
    5. Backup, as a followup on security.
    6. Customer Service. If they they ask at all.
    7. Documentation. Nobody reads it, they drop out at #2 or #6.

    If it's forced upon them like employees:

    1. Fault tolerance. A system you must use and doesn't work is hell.
    2. User experience. Not because you care but poor software waste employee time.
    3. Documentation. A lot of employees do learning by rote memorization.
    4. Customer support. Employees expect support and call it early.
    5. Uptime. Systems down cost very big bucks.
    6. Backup. Lost employee time is again usually big bucks
    7. Security. Might be much higher, but usually protected intranet.

    Backend systems:

    1. Fault tolerance, if the backend dies everything dies
    2. Uptime, it usually needs high availability to feed other systems.
    3. Backup, otten the backend holds all the master data.
    4. Security, again it holds the master data.
    5. Documentation, make sure noone breaks this thing.
    6. Customer Support, no direct users and the backend shouldn't have problems.
    7. User experience doesn't really apply as we don't have users.

    Best Practices

    This one I don't count in the list - it's a means to achieving everything else and not a priority in itself and you use as much as is beneficial.

    Of course, this can be *completely* wrong if it doesn't fit my idea of a typical project. But anyone should at least figure that there's some general differences between an internet-facing public service and a typical corporate intranet application.

  • by savanik (1090193) on Wednesday November 19, 2008 @07:32PM (#25825987)

    But that young person is closer to school, meaning they learned from not just your mistakes but the mistakes of the industry over the past 30 years and very likely the youngsters were playing with real-world code long before they ever could have counted it experience.

    You learned something applicable to actual programming in school? All I learned about was Turing machines.

    I coded a lot of useful programs before I ever hit college, up to some fairly sophisticated character generators for my gaming group. While I was in college, I learned that everything I knew about programming was wrong, that I was an idiot for using BASIC, and that everything I really needed to know was in Maths. I graduated with less applicable programming knowledge than when I went in, couldn't get a programming job anywhere, and I've actually applied my college knowledge exactly once in the last eight years since.

    College and universities aren't teaching you about the mistakes of the industry over the past 30 years. They're teaching you about the mistakes of the industry made before the last 30 years. Forget about the degrees. Ask them for an example of code that they've written, or ask them to write a simple function for you right there. You'll learn far more about their skill as a programmer than age or resume will tell you.

    Problems from Project Euler [projecteuler.net] seem to be a popular choice.

  • Re:What they bring (Score:3, Interesting)

    by ucblockhead (63650) on Wednesday November 19, 2008 @08:07PM (#25826437) Homepage Journal

    Sadly, having interviewed people straight out of top 5 university CS programs, the answer might be "what a hash table is".

  • by EmbeddedJanitor (597831) on Wednesday November 19, 2008 @08:09PM (#25826483)
    Older people end up in programming jobs for one of two reasons:

    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.

  • by _avs_007 (459738) on Wednesday November 19, 2008 @08:55PM (#25826925)

    I'm curious what your definition of "often" is in this case. While I find people across age groups that are lazy, I'm finding it far more likely with younger people these days being the worst in that they want things handed to them and want to minimize what they actually put into the job.

    I noticed the same thing... Young Gen-X people seem to be the ambitious type, but the young Gen-Z people tend to expect things handed to them... I noticed that a lot, and even heard of books being published to help employers deal with these new breed of workers...

    When I graduated college 10 years ago, I was one of those ambitious people... I often stayed at work till 10pm to insure our products/projects met their milestones etc...

    Recently we hired new hires that are of the new generation. So far, many of these people are out the door as soon as the clock hits 5, regardless the status of their projects and when the milestones were... Even when I'm travelling on business and am halfway across the world, they don't want to take any personal time to give me a hand (even if it's to upload a project they are past due on). They didn't even bother taking their work laptops home, because they don't want to "work" outside of work.

    They told me they'll upload it when they get in the office. (I called 3pm their time, so they should have been IN THE OFFICE, but they left early). I asked for it at 7am their time, but they said no. Said they'll do it when they come in at 9:30am. Of course that was useless because of the timezone difference, because the meetings would have been over by that time. Had they been in the office at 3pm, or logged in, or whatever, I would've had a full day to get the project/kinks worked out at the client site... But because of their lack of team-spirit, we had to waste the opportunity of being in Europe to test the integration on-site. The next opportunity for on-site integration testing at a different client location was 4 months away. You can guess what that did to schedules...

    Especially considering the project was supposedly already done, but this person never bothered to check in their code to the source code repository so I had no access to it. The only copy was on this person's notebook, which was not with her, and not powered on, so it wasn't on the network.

    When I was their age, there were times when I would log in, or be in the office from 1am to 7am just to make sure I was aligned on the same time-zone so I could work with the team remotely (budget restraints on travel)

    Very frustrating...

  • by Missing_dc (1074809) on Wednesday November 19, 2008 @09:06PM (#25827045)

    forgive my ignorance, but if you are in a closed loop, would you not end up at the same point if you followed left vs right?

  • Re:Slashdot ID (Score:3, Interesting)

    by Greyfox (87712) on Wednesday November 19, 2008 @09:27PM (#25827225) Homepage Journal
    I actually like the "Write a function that does X" questions. I'm not really looking to see if they can write a function that does X. I'm looking to see how enthusiastic my prospective employee is about the problem. I'm looking to see if he engages me to find out more about X prior to starting. I'm looking to see if he sketches out what's supposed to be happening prior to starting. By the time he's starting to write a function that does X, I already know everything about him that the question was supposed to show. That holds true whether he does everything I'm looking for or he goes up to the board and immediately starts writing code.

    I have rejected potential employees on their reaction to this one question, and I've been hired to positions myself based entirely on my reaction to it.

  • by lpcustom (579886) on Wednesday November 19, 2008 @11:10PM (#25828077)
    You could just ask them...

    Which is better and why?
    a.)if(true==$variable)
    or
    b.)if($variable==true)
  • by pipingguy (566974) * on Thursday November 20, 2008 @12:57AM (#25828773) Homepage
    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.
  • by hughbar (579555) on Thursday November 20, 2008 @03:34AM (#25829643) Homepage
    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!
  • Re:No. (Score:2, Interesting)

    by Yert (25874) <mmgarland3 AT gmail DOT com> on Thursday November 20, 2008 @05:13AM (#25830031)

    Yes, I understand the Worker's Party accomplished many things, especially in the 1930's....Volkswagen, for instance. (Don't invoke Godwin's Law on me here, dammit! It's relevant!)

    Don't assume. Unions did accomplish much, but now they're rife with corruption, greed, and sloth. It's time for a reboot. Oddly, you still managed to think that is was my hubris being served, when I was the one talking about new unions, new movements... the UAW aren't the only ones, either. I see Teamsters making $25/hr, and they get to go home at night, when the "common man" still gets paid $0.28/mile, they short him 10% of the miles he runs, and he spends 2 weeks at home, unpaid, in a year. The other 50 weeks, he's on the road, getting cussed at for driving a slow rig that tears up the roads and pollutes the air, while soccer moms are cutting him off in traffic on the way to Wal-Mart to buy the very freight he's carrying.

    Honestly, where's this "soar free" crap you're spouting out the side of your neck? I would like to see modern unions fight for the "common man" instead of serving their own special interests. I understand things are different on the other side of the pond, but until you've been herded like cattle through a security gate and metal detector because your employer is worried you'll steal a $1 DVD from him while you've been packing boxes in a 105F warehouse for $7/hr for the last 12 hours with a 30 minute lunch and 2 15 minute breaks, I'll thank you to shut the fuck up.

  • by namoom (926916) on Thursday November 20, 2008 @10:14AM (#25831647)
    Look at the younger guys who may not have gone to college, but show progression through jobs. When you find one who did not graduate college but went up the ladder on their own you get someone who may need a little more initial guidance but they learn quicker, teach others, does the work of several average IT people, and they are also more flexible in their ways. Put too many older IT people in the same room and you have fireworks
  • by jerunamuck (714985) on Thursday November 20, 2008 @11:11AM (#25832257)

    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.

  • by racermd (314140) on Thursday November 20, 2008 @11:40AM (#25832649)

    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.

  • by Dodder (1410959) on Thursday November 20, 2008 @02:24PM (#25835153)

    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.

  • by Dodder (1410959) on Thursday November 20, 2008 @02:40PM (#25835413)
    Have to agree. My preferences as a tenured developer is to write code that matches the format and style the organization and team prefer. I could care less. You tell me how you want to code style. Putting your own personal signature on applications is arrogant and confusing. K.I.S.S. Likewise, I don't try to impose my own idea of what their design docs, requirements specs, release management process should be. I will definitely suggest alternatives that I think would be more effective and efficient and I will definitely assist and provide insight into process improvement, but at the end of the day, that call is management's decision not mine. And I have to respect that because I have no intention of working for that same company for the next 30 years.

"Trust me. I know what I'm doing." -- Sledge Hammer

Working...