What to look for in a new hire?
-
An infinite number of gorillas at an infinite number of keyboards? The tigress is here :-D
:laugh: Precisely. They will end up describing [edit]how to hire[/edit] the perfect candidate. Of course, we'll all be dead by then. Jon Sagara When I grow up, I'm changing my name to Joe Kickass! My Site | My Blog | My Articles -- modified at 12:39 Wednesday 19th July, 2006
-
Commitment. The tigress is here :-D
If there's several of them you may have a band. ;P Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
From what I can tell, there is no trait or accomplishment that you can look for in someone to determine if they are actually good at developing software, without hiring the person and evaluating their work. Am I correct about this? Graduating college with a degree in CS is as good an indicator as whether the person can whistle. I've known people, one of them a good friend, who graduated with a CS degree and can't program their way out of a paper bag. So, schooling is not an indicator. Industry experience does not necessarily prove anything, either. There are certainly people in the dev world who plain old suck. They might have been programming since I was riding a tricycle, but they're really not any better now than they were then (perhaps worse). Certifications...too easy to cheat. So, what can you look for in someone to determine if they are any good, without hiring them first? :confused: :josh: My WPF Blog[^]
Ask them to bring the source for some older work (two years? one year). Review the code If you suddenly hears, listen carefully "hmm, what was I thinking..." "uch, I'm an idiot" "oops, that doesn't look good" and the best one "f*ck, I should have done it so-n-so" Then you at least knows that they still are improving. All you have to decide are if you're happy with where they were two years ago... If all you hear are clear explanations, no hesitation what so ever -- They haven't improved or... don't play poker with them... The third case are hesitations, "what's that supposed to do", "hmmmmmmm" -- They haven't improved and they can't read their own old source. This test only tells if they still are improving (and learning). In my book, that's a golden star -- a big one;)
-
From what I can tell, there is no trait or accomplishment that you can look for in someone to determine if they are actually good at developing software, without hiring the person and evaluating their work. Am I correct about this? Graduating college with a degree in CS is as good an indicator as whether the person can whistle. I've known people, one of them a good friend, who graduated with a CS degree and can't program their way out of a paper bag. So, schooling is not an indicator. Industry experience does not necessarily prove anything, either. There are certainly people in the dev world who plain old suck. They might have been programming since I was riding a tricycle, but they're really not any better now than they were then (perhaps worse). Certifications...too easy to cheat. So, what can you look for in someone to determine if they are any good, without hiring them first? :confused: :josh: My WPF Blog[^]
Josh Smith wrote:
So, what can you look for in someone to determine if they are any good, without hiring them first?
i look at their CP member ID. lower = better. Do the chickens have large talons?
-
From what I can tell, there is no trait or accomplishment that you can look for in someone to determine if they are actually good at developing software, without hiring the person and evaluating their work. Am I correct about this? Graduating college with a degree in CS is as good an indicator as whether the person can whistle. I've known people, one of them a good friend, who graduated with a CS degree and can't program their way out of a paper bag. So, schooling is not an indicator. Industry experience does not necessarily prove anything, either. There are certainly people in the dev world who plain old suck. They might have been programming since I was riding a tricycle, but they're really not any better now than they were then (perhaps worse). Certifications...too easy to cheat. So, what can you look for in someone to determine if they are any good, without hiring them first? :confused: :josh: My WPF Blog[^]
Josh Smith wrote:
So, what can you look for in someone to determine if they are any good, without hiring them first? :confused:
CP ID number. Prime is better.
---- Scripts i’ve known... CPhog 1.0.0.0 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Josh Smith wrote:
So, what can you look for in someone to determine if they are any good, without hiring them first? :confused:
CP ID number. Prime is better.
---- Scripts i’ve known... CPhog 1.0.0.0 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Shog9 wrote:
CP ID number. Prime is better.
I would have thought that multiples of 17 were ideal... :josh: My WPF Blog[^]
-
If it's a good looking girl, hire her any way, since she'll help improve the overall morale of the work environment :rolleyes: More seriously though, the Microsoft interview process of multiple interview, 1-2 HR rounds, 1-2 puzzle rounds, 1-2 technical rounds, 1 personal interview etc. might usually work out. It's hard for someone to hide his weaknesses through such an intense process - and you'd also be able to dig out his not-so-obvious talents. You should also consider hiring people on a probation period (say 1 month) after which you decide whether you want to keep them or lose them. In the past, I've once had to tell a probation candidate that we weren't planning on keeping her, and it was pretty awkward for me - so make sure you have someone else to do that job in case it's required. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)Nishant Sivakumar wrote:
If it's a good looking girl, hire her any way, since she'll help improve the overall morale of the work environment
That could be true. I mean some people are known as being a catalyst in a team, they could help people jell in together and bring the team closer...of course if they don't start fighting over her:) But yeah, she doesn't necesarily needs to be gorgeous and it's prererable she could do some coding:doh: regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.
-
From what I can tell, there is no trait or accomplishment that you can look for in someone to determine if they are actually good at developing software, without hiring the person and evaluating their work. Am I correct about this? Graduating college with a degree in CS is as good an indicator as whether the person can whistle. I've known people, one of them a good friend, who graduated with a CS degree and can't program their way out of a paper bag. So, schooling is not an indicator. Industry experience does not necessarily prove anything, either. There are certainly people in the dev world who plain old suck. They might have been programming since I was riding a tricycle, but they're really not any better now than they were then (perhaps worse). Certifications...too easy to cheat. So, what can you look for in someone to determine if they are any good, without hiring them first? :confused: :josh: My WPF Blog[^]
When are you good at software development? A while ago (before dropping out of the rat race) I was dev manager for an ISV. Here are my criteria (if anyone is interested) for a good dev: 1. Ability to read (particularly the #@#)&^ spec document 2. The following of best practice 3. Ability to spell 4. Speak to a client without causing trouble 5. STICK TO THE JOB AT HAND - cool is a distant, poor second to making the deadline 6. The ability to take crticism without causing a labour dispute 7. Readable code (according to the project standards) with comments 8. Debugging instinct 9. Lazy devs work best - use the tools at hand - if you want to write apps in Notepad and compile with csc because it is hardcore - do it on your own time No offense to the publishing guys, but I have only had bad experiences with the article writing guru's - I want someone to do the job at hand, not complicate the project so that you can write about it. Luckily I am back to coding - sorry no articles from me - I have a life AND deadlines! Other tips I have found useful when interviewing: - 1. Have a whiteboard session with the lucky victim - have them present the architecture of a solution to the entire team - this tests resourcefullness and grace under pressure 2. Turn the interview around - let them ask you questions - this catches a lot of guys out. 3. Ask personal questions - such as "what happens when you lose your temper?" - this one always had spectacular results 4. Steer away from the normal questions - you are not a recruiter 5. Do not belittle the victim - embarrassment is OK but you don't want to feel like taking a shower after the interview Good luck - sounds like you need it LOL !
-
Josh Smith wrote:
So, what can you look for in someone to determine if they are any good, without hiring them first?
Their website, their blog, their articles on CP. In other hitech professions, people are often required to publish if they are expected to advance in their careers. At least those interested in advancing. It's funny, I had this discussion just recently with my neighbor. Even a pharmacist is expected to publish if they want to get a job with the FDA, apparently. If I want someone "good", then frankly, to me, that means they are working at being good, and that means they are out there publishing, writing, discussing technology, etc. So, nowadays, that's my criteria. I'm sure it would eliminate a lot of people that are also good, but it also helps weed out the people that are really bad. Marc XPressTier
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
Marc Clifton wrote:
Their website, their blog, their articles on CP.
Just like any other artist, you need a portfolio :)**
xacc.ide-0.2.0 preview - Now in 100% C# goodness
**
-
From what I can tell, there is no trait or accomplishment that you can look for in someone to determine if they are actually good at developing software, without hiring the person and evaluating their work. Am I correct about this? Graduating college with a degree in CS is as good an indicator as whether the person can whistle. I've known people, one of them a good friend, who graduated with a CS degree and can't program their way out of a paper bag. So, schooling is not an indicator. Industry experience does not necessarily prove anything, either. There are certainly people in the dev world who plain old suck. They might have been programming since I was riding a tricycle, but they're really not any better now than they were then (perhaps worse). Certifications...too easy to cheat. So, what can you look for in someone to determine if they are any good, without hiring them first? :confused: :josh: My WPF Blog[^]
I have to disagree with some of my illustrious colleagues. The first thing that you have to ask yourself is what are you after: Someone who can hit the ground running, but might not stick around; Someone who will be an asset over a longer period, but might take a while to get in the groove; someone to supply leadership, creativity and design skills; a codegrinder who can rattle it out without thinking, but needs to be told what to do? I like to ask questions that expose opinions. Are they opinionated with nothing to back it up, have they grasped basic concepts? I find that, as a rule, people with opinions that can back them up are more use to me than a "Yes" man. I like compare and contrast questions, e.g. "Compare the use of Java versus ASP.NET for server side functionality." They might only know one technology really well, but if they don't understand the differences .... BTW, I consider myself a pretty reasonable programmer with oodles of experience. I don't often make posts, I don't have a blog and I don't publish (I might speak to specific audiences that are from my area of business.) I'm too busy and I have a life outside of computing. Just my $2 worth (I'm worth more than 2 cents!) :cool: Phil -- modified at 15:32 Wednesday 19th July, 2006
-
From what I can tell, there is no trait or accomplishment that you can look for in someone to determine if they are actually good at developing software, without hiring the person and evaluating their work. Am I correct about this? Graduating college with a degree in CS is as good an indicator as whether the person can whistle. I've known people, one of them a good friend, who graduated with a CS degree and can't program their way out of a paper bag. So, schooling is not an indicator. Industry experience does not necessarily prove anything, either. There are certainly people in the dev world who plain old suck. They might have been programming since I was riding a tricycle, but they're really not any better now than they were then (perhaps worse). Certifications...too easy to cheat. So, what can you look for in someone to determine if they are any good, without hiring them first? :confused: :josh: My WPF Blog[^]
I do a fair amount of interviewing in our company. We are a small company, and not exactly bleeding edge. We tend to hire more junior developers, and then try skill them up in our methodologies. This is mind, my criteria is usually more personal in nature, and more generic rather than technology specific: can we get on well with them in a small, team environment? Are they willing and keen to learn and expand? Do they understand concepts of design? Are they aware of new technologies and industry news? Can they take instructions when given, even if they conflict with what they think is best? Are they confident enough to question, in that situation? Do they have the passion (don't think the word is too strong at all :) ) and do they look convinced that they are doing what they love? Will they work long hours happily? One of m y favourites: Do they focus on and enjoy the process of solving problems, or the achievement and result of a finished system? (Both answers are acceptible to me, it just determines what role to put them in) Personally, a degree doesn't add a massive amount of weight to an interviewee's case. A "certification" adds absolutely nothing most of the time. My 2c. :) -- modified at 1:45 Thursday 20th July, 2006
-
I would naively believe that people who have personal project are good. Although I would ask them to demo the personal project. You will learn: - that the personal is a self learner. - by viewing the project (s)he is proud of you will get an indicator of h(er)is skills. Also look the way the person talk. There are some sure sign of "passion" (perhaps too strong a word though ;P) for programing or not. Another sure thing you'd like to have in as your programmer. Also ask him how (s)he will solve some of the problem you like to have him(her) solve. If (s)he comes up with solution (s)he's worth hiring! ;)
Having interviewed and hired lots of people of the past few years, I know how hard this can be. I've made a few mistakes, but also got some really good people. One thing I often try is to get the candidate to describe key aspects of a system he or she has worked on. I always have a blank whiteboard, and a bunch of pens visible - but otherwise I don't draw attention to it. As the person describes key components and how they fit into the system, the good ones invariably ask to use the WB to help explain. Now, I'm not after UML here, but simply the ability for a candidate to explain how things he has worked on fit into the bigger picture, what the key processes are, and - if they are on a roll - where the problem areas are. Personally I don't put too much emphasis on code tests - most of the ones I come across tend to be done by current employees trying to show how smart they are, as opposed to be being designed to test whether someone has the knowledge required to be successful in the role. The ones that do have value are those that allow the candidate to explain their answers, and also perhaps to ask for clarification on the questions. This can get into an interesting technical discussion often miles away from the narrow confines of the original question. A lot of hiring is gut-feeling. But you can protect yourself to a certain extent by having a probationary period in the contract. This will only work well, however, if you really think through what tasks the candidate will do during this period, and how success can be measured. Simply adding them to a team and hoping their work will be OK can lead to the probationary period being taken up with trivial easy tasks that still leave you non the wiser on their real potential by the time you have to make a decision. This is a particular trap I fell into once, and I ended up keeping a guy on I should really should have kicked when the contact made it easier. This is in the UK, btw, where employment laws on hiring and firing people are probably tighter than in the US - but at least it's not France!
-
From what I can tell, there is no trait or accomplishment that you can look for in someone to determine if they are actually good at developing software, without hiring the person and evaluating their work. Am I correct about this? Graduating college with a degree in CS is as good an indicator as whether the person can whistle. I've known people, one of them a good friend, who graduated with a CS degree and can't program their way out of a paper bag. So, schooling is not an indicator. Industry experience does not necessarily prove anything, either. There are certainly people in the dev world who plain old suck. They might have been programming since I was riding a tricycle, but they're really not any better now than they were then (perhaps worse). Certifications...too easy to cheat. So, what can you look for in someone to determine if they are any good, without hiring them first? :confused: :josh: My WPF Blog[^]
-
From what I can tell, there is no trait or accomplishment that you can look for in someone to determine if they are actually good at developing software, without hiring the person and evaluating their work. Am I correct about this? Graduating college with a degree in CS is as good an indicator as whether the person can whistle. I've known people, one of them a good friend, who graduated with a CS degree and can't program their way out of a paper bag. So, schooling is not an indicator. Industry experience does not necessarily prove anything, either. There are certainly people in the dev world who plain old suck. They might have been programming since I was riding a tricycle, but they're really not any better now than they were then (perhaps worse). Certifications...too easy to cheat. So, what can you look for in someone to determine if they are any good, without hiring them first? :confused: :josh: My WPF Blog[^]
-
I would naively believe that people who have personal project are good. Although I would ask them to demo the personal project. You will learn: - that the personal is a self learner. - by viewing the project (s)he is proud of you will get an indicator of h(er)is skills. Also look the way the person talk. There are some sure sign of "passion" (perhaps too strong a word though ;P) for programing or not. Another sure thing you'd like to have in as your programmer. Also ask him how (s)he will solve some of the problem you like to have him(her) solve. If (s)he comes up with solution (s)he's worth hiring! ;)
That's interesting... I've had several interviews where when asking for project descriptions specify to exclude personal projects. I always assumed that they had had lots of people claim to have experience that turned out to be only personal (worked with ASP 2.0 but only played with C# at home).
Try code model generation tools at BoneSoft.com.