Hiring/Interviewing/Questions
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
It is possible to find someone who can "talk the talk and walk the walk " and still not perform well on the job. Some, while otherwise very talented and intelligent, have other problems, such as an uncaring or lazy attitude. Others may not be motivated to perform on tasks that don't challenge them in one way or another. I'm not sure how you weed those people out. Correct answers to tech questions won't do it. In the old days those types of people tended to bounce around from job to job. Now everyone does. My 2 cents worth....good luck. I have interviewed some in the past and it is not as easy as it looks. Gary Kirkham A working Program is one that has only unobserved bugs I thought I wanted a career, turns out I just wanted paychecks
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
When I used to interview people, I did not believe in setting short programming tasks, I just asked enough questions to make sure they knew what they claimed they did. I was more interested in how they would solve a problem they did not know the answer to. Also make sure they are team players, if you company is say in the graphics industry and as I used to be and we worked with 240 MB images, if you ask the guy how would you rotate the image by 90 deg? The answer is simple, use one of your existing companies libraries, you afer all have some. i.e. you want someone who will use existing libraries and not re invent the wheel everytime, someone who will ask before hacking the code! Also check references, not really that good, but check with their previous employers. Also state they will have a 4 week trial, and if there was someone else with good skills don't reject them, tell them you will leave their name on file. In my experience you can just about get it right in judging someones skills. But if they are no good admit you were wrong and re advertise. Best of all get someone via CP!
Hell, there are no rules here-- we're trying to accomplish something. - Thomas A. Edison
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
I think you are being overconfident. Hiring isn't a complete crap shoot, but nobody can hire with a 99% success rate. Frankly, I think you'd be doing good to break even. I, and most people here, can tell you of many experiences where the perspective employee looked great, but just didn't work out. In some cases, they went on to great success elsewhere and in others they just went nutty. (Two years ago my brother got a new boss who was a guy I had worked with eight years before. Somewhere in those eight years, he turned from a barely competent developer and nice guy into a raving incompetent lunatic, yet he still got jobs.) Joe Woodbury When all else fails, there's always delusion. - Conan O'Brien
-
I think you are being overconfident. Hiring isn't a complete crap shoot, but nobody can hire with a 99% success rate. Frankly, I think you'd be doing good to break even. I, and most people here, can tell you of many experiences where the perspective employee looked great, but just didn't work out. In some cases, they went on to great success elsewhere and in others they just went nutty. (Two years ago my brother got a new boss who was a guy I had worked with eight years before. Somewhere in those eight years, he turned from a barely competent developer and nice guy into a raving incompetent lunatic, yet he still got jobs.) Joe Woodbury When all else fails, there's always delusion. - Conan O'Brien
I have to agree with Ted, we are also a relatively new/small company (3 years trading now) and got badly burned. Like you, I would probably claim to talk the talk etc but the chap we hired knew his stuff and had some good experience. Trouble was that when we gave him a problem to solve he would make a start and then quickly get lost and give up with it ending up me holding his hand. It happened time and time again, wasting my time and his time. In the end he decided to go but I think the moral of the story is that even if someone can program it doesn't mean they can problem solve "wider world" problems. I am now all for doing an Apollo 13 "round peg in the square hole" test! :-D
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
I've done a lot of hiring and interviewing, and I can assure you that there is no way to get 100% yield out of the process. You can greatly improve your results, though, by including technical people (you) in the interview chain. Using tests and such is useless - you'll lose more good people than you'll hire simply because talented people don't always have the same talents, or code in the same way. But an experienced programmer will quickly learn new skills, and a good team member will adapt to the company style of doing things. General discussions among the applicant's future peers will bring out a sense of how well the applicant will fit in and adapt, something which interviews with management or, God forbid, HR people will never reveal. If the applicant is to be part of a team, then the best interview results will come from interviews by the team members, not tests of coding ability, and your point about evaluating the applicant's problem solving approach is valid. It's more about how a person thinks/reasons, than what languages and libraries he/she has memorized. "Some people are like Slinkies... not really good for anything,
but you still can't help but smile when you see one
tumble down the stairs." -
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
I would like to add my experience: Remeber the first piece software you wrote? Now, this is how your first interview is going to be. And, BTW, you can make two mistakes when hiring someone: hiring the wrong guy because he talked what you want to hear or letting the right guy go because he thinks different and you hated him. Being overconfident is the first step to make both mistakes.
Help me dominate the world - click this link and my army will grow
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
I've done a fair amount of interviewing (8 contracts in 5 years) and still not very good predicting future personalities of people from even the first week or 2 on the job much less 1-2 hours during interview. People have different levels of schmoozing skills just like they have different levels of technical ability. on to the psychology stuff... The Psychology of Computer Programming: by Gerald M. Weinberg The Mythical Man-Month Essays on Software Engineering: by Frederick Phillips Brooks and all those intelligence & emotional tests are cool too !!! www.allthetests.com[^] www.queendom.com[^]
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
Whatever tests you give, whatever questions you ask, make very sure that the offer letter stipulates a 6-month probationary period, during which you can throw the person out the window.
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
Thanks for everyone's replies. I've read the books mentioned like Mythical Man Month and Psychology of Comp. Programming. They were indeed interesting and thought provoking. My main reason for starting this thread was because I think (arrogantly perhaps, I'll admit) that it's not as hard as everyone says it is to find top-quality developers. The reason I think that is mostly because of what I keep hearing from various places that say they know all the tricks to only hiring people who are the real deal. Maybe they're exaggerating, I can't really say I know for sure.:~ Jason
-
Thanks for everyone's replies. I've read the books mentioned like Mythical Man Month and Psychology of Comp. Programming. They were indeed interesting and thought provoking. My main reason for starting this thread was because I think (arrogantly perhaps, I'll admit) that it's not as hard as everyone says it is to find top-quality developers. The reason I think that is mostly because of what I keep hearing from various places that say they know all the tricks to only hiring people who are the real deal. Maybe they're exaggerating, I can't really say I know for sure.:~ Jason
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
jamauss wrote: I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. I agree with you 100%, Jason. That's the policy we've followed at our (small, young and successful) company, and with good success. Suggest to your manager that although he peruses reviews and test reports ("resumes") before buying a new car, in the end he's going to test drive the thing before writing out a check. Test driving a potential hire is crucial, especially given that you've been burned once before. When I ask candidates questions, they are specific and direct, and have very few right answers. I always interview in the presence of a whiteboard and encourage the interviewee to draw any code related thoughts they might have difficulty in expressing verbally. This offers valuable insight into the person's thinking process (or lack thereof). At our organization, resumes are used to filter not judge. During the interview process, we make an extra effort to put the candidate at ease, but are quick to end the interview if we feel (s)he doesn't appear to know his/her stuff. /ravi Let's put "civil" back in "civilization" Home | Articles | Freeware | Music ravib@ravib.com
-
Whatever tests you give, whatever questions you ask, make very sure that the offer letter stipulates a 6-month probationary period, during which you can throw the person out the window.
Most employers in Mass (USA) specify a 3 month period. /ravi Let's put "civil" back in "civilization" Home | Articles | Freeware | Music ravib@ravib.com
-
The hiring process is a lot like sex, everyone thinks they are a lot better at it than they really are. Tim Smith I'm going to patent thought. I have yet to see any prior art.
That's a great line, Tim! :rose: /ravi Let's put "civil" back in "civilization" Home | Articles | Freeware | Music ravib@ravib.com
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
-
I have to agree with Ted, we are also a relatively new/small company (3 years trading now) and got badly burned. Like you, I would probably claim to talk the talk etc but the chap we hired knew his stuff and had some good experience. Trouble was that when we gave him a problem to solve he would make a start and then quickly get lost and give up with it ending up me holding his hand. It happened time and time again, wasting my time and his time. In the end he decided to go but I think the moral of the story is that even if someone can program it doesn't mean they can problem solve "wider world" problems. I am now all for doing an Apollo 13 "round peg in the square hole" test! :-D
I have been severly burnt, we were desperately short of people so I hired someone who had years of skill programming in XXX ( I don't want a flame war!) to be a junior programmer using C++. I had my doubts but the individual was the the best of a bad bunch. I assumed with years of experience they should adapt to C++ easily, but the person had no clue about problem solving, eventually we had to sack them, not a pleasnt task. Unfortunatley we were so short staffed even when we noticed how bad the individual was we did not take action. Sorry about the tortuous grammer I don't want to name their skills or gender, it is just a true example.
Hell, there are no rules here-- we're trying to accomplish something. - Thomas A. Edison
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
Hello, I thought I'd add my tuppenny-worth to the debate. I've done a few interviews earlier this year while I was looking for a new job, and I've also sat on the interviewer's side. One of the best programmers I've ever met was so quiet during the interview. We had the HR guy do the personality kind of stuff first and his answers were very quietly one or two words at most. We were all thinking that this was going nowhere. However, as soon as we got to the technical part of the interview he shone like a star. We hired him and prayed that we made the right descision - we were a small company and this was the first programmer we'd hired. Luckly we had and once he settled in he was very pleasant and social and a good team player- he was just incredibly shy to start with. The interviews I did this year as a job-hunter were quite varied. One company was so aggressive in the process that I almost walked out - I still (6 months later) get emails from recruitment agencies trying to fill this role. The better techniques, in my opion, are: * Doing a maths test - okay very basic, but there is a lot of basic maths needed in programming. * Correcting a document - Checks abilities to detect small errors in text. * Write a paragraph or two on some subject - written skills, programmers will have to document stuff, so other people need to read it. * A logic test - to test unseen problem solving or patter matching. * Asking the candidate to perform a number of tests in a short time period so that it is impossible to finish all of them in the time given - This tests prioritising skills, a candidate should show the interviewer a little of everything and spend all the time on one area. * A technical test to determine at least some understanding in the technologies to be used. Techniques that are bad, in my opinion, are: * Putting in a technical question that you only just learned - are you are saying that a week a go you wouldn't have hired youself? (I got a couple of these and it was so obvious - one was a multiple choice and I had to answer none of the above SQL queries will work - and this was after the interviewer proudly proclaiming one of his newly made MCADs put the technical questions together) * Putting in technical questions that have absolutely nothing to do with the job - I was hit with a Java question for a C#.NET job once! * Not taking into consideration that candidates come from different backgrounds and sometimes call one thing something else. - I got asked by the Technical Director about s
-
Hello, I thought I'd add my tuppenny-worth to the debate. I've done a few interviews earlier this year while I was looking for a new job, and I've also sat on the interviewer's side. One of the best programmers I've ever met was so quiet during the interview. We had the HR guy do the personality kind of stuff first and his answers were very quietly one or two words at most. We were all thinking that this was going nowhere. However, as soon as we got to the technical part of the interview he shone like a star. We hired him and prayed that we made the right descision - we were a small company and this was the first programmer we'd hired. Luckly we had and once he settled in he was very pleasant and social and a good team player- he was just incredibly shy to start with. The interviews I did this year as a job-hunter were quite varied. One company was so aggressive in the process that I almost walked out - I still (6 months later) get emails from recruitment agencies trying to fill this role. The better techniques, in my opion, are: * Doing a maths test - okay very basic, but there is a lot of basic maths needed in programming. * Correcting a document - Checks abilities to detect small errors in text. * Write a paragraph or two on some subject - written skills, programmers will have to document stuff, so other people need to read it. * A logic test - to test unseen problem solving or patter matching. * Asking the candidate to perform a number of tests in a short time period so that it is impossible to finish all of them in the time given - This tests prioritising skills, a candidate should show the interviewer a little of everything and spend all the time on one area. * A technical test to determine at least some understanding in the technologies to be used. Techniques that are bad, in my opinion, are: * Putting in a technical question that you only just learned - are you are saying that a week a go you wouldn't have hired youself? (I got a couple of these and it was so obvious - one was a multiple choice and I had to answer none of the above SQL queries will work - and this was after the interviewer proudly proclaiming one of his newly made MCADs put the technical questions together) * Putting in technical questions that have absolutely nothing to do with the job - I was hit with a Java question for a C#.NET job once! * Not taking into consideration that candidates come from different backgrounds and sometimes call one thing something else. - I got asked by the Technical Director about s
Oops! I must need my eyes testing. There are quite a few typos in there... The most important correction is: * Asking the candidate to perform a number of tests in a short time period so that it is impossible to finish all of them in the time given - This tests prioritising skills, a candidate should show the interviewer a little of everything and spend all the time on one area. The last bit should be: a candidate should show the interviewer a little of everything and not spend all the time on one area. And (in the spirit of Columbo) one other thing: A good question to ask is how would the candidate go about solving a problem in an area they've never touched before. e.g. Lookup MSDN, search Code Project, ask peers, search (other less respectable ;) ) websites, etc. If they get stuck on this then worry. --Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
-
So I was having an IM chat w/ a colleague ("boss" if you will) this morning about the hiring/interview process. We're a small outfit and I'm the only one with real advanced development experience. As the company was starting out, we got burned by a guy who said he knew what he was doing but, ended up doing quite a crappy job, which left the company hurting pretty badly since we're not even 2 years old yet. The thing is, I wasn't responsible for assessing this guys skills. We were both hired at roughly the same time and he got placed as the "lead"...effectively becoming who I reported to. We both did the same work, it's just that he was supposed to be making the decisions (architecting the app, etc.) when he had no business doing so (based on how things ended up):sigh: Now after he's been let go we're almost in the position where we are going to need to get another Developer to help us. Here's where the disagreement/argument starts. From my point of view: 1. I don't think there are many Developers out there that could fool me into thinking their skills are better than they actually are. I talk the talk, walk the walk, and think I just have an inherent ability to know when someone is blowing smoke or not. 2. Over the years I've read a lot about tech interviews (Joel On Software, etc.) and about what kinds of questions to ask, and what personality traits to look for in good developers. I'm aware that the ways to tell whether someone is really talented is to discover things like how the person thinks/solves problems, not how many tech answers they can dish out. Now, my colleague perceives this as arrogance, not confidence, and says that it's impossible to never get burned by someone. He's been in business for quite a while (20 years or so) and seems to be set in this thinking. While I can agree it's impossible not to EVER get burned, I argue that if you are experienced and know what you're doing, you can reduce your chances of getting burned by a smoke blower down to almost nothing. Like only a 1 in 100 chance. I'm not really looking for a "who's right, who's wrong?" discussion, just your thoughts. Would anyone like to add their experiences? Jason
The truth of the matter is, an hour interview (or one that lasts all day), isn't sufficient time to judge whether someone will work out or not. You can have someone with a good resume and they interview well. Your tech folks talk to them, and think they know what they're doing. In the end, all you've got is someone who knows how to present themselves. You have no idea what they will be like to work with.
Software Zen:
delete this;