Separating newbies & posers from experienced programmers
This thread shows a question posed by a hiring company. It asks whether the candidate recognizes code to compute GCD. Some people thought any real programmer would recognize the algorithm while others said they'd never seen it before:
http://www.cplusplus.com/forum/general/265118/
So here's my question: how would you separate the newbies/posers from, let's say, people with 3+ years of experience?
We used to give a 45 minute test with questions like "write code to insert an item at the head of a singly linked list." Back when you had to roll your own lists that question was valuable, but today with the STL, I can understand if someone has long since forgotten it. BTW, we used the whole test and an interview to gauge the candidates, not that one question.
To start the conversation, how about showing these pieces of code and asking what they did:
- GCD (yup, to me this is a classic)
- depth-first search in binary tree
- bubble sort
- determine if a number is prime.
If a candidate claiming 3+ years of experience didn't recognize at least 2 of these, I'd be suspicious. Heck, I'd be suspicious if a new grad didn't recognize them.
What would you do to separate them?
Dave
http://www.cplusplus.com/forum/general/265118/
So here's my question: how would you separate the newbies/posers from, let's say, people with 3+ years of experience?
We used to give a 45 minute test with questions like "write code to insert an item at the head of a singly linked list." Back when you had to roll your own lists that question was valuable, but today with the STL, I can understand if someone has long since forgotten it. BTW, we used the whole test and an interview to gauge the candidates, not that one question.
To start the conversation, how about showing these pieces of code and asking what they did:
- GCD (yup, to me this is a classic)
- depth-first search in binary tree
- bubble sort
- determine if a number is prime.
If a candidate claiming 3+ years of experience didn't recognize at least 2 of these, I'd be suspicious. Heck, I'd be suspicious if a new grad didn't recognize them.
What would you do to separate them?
Dave
Depends whether you are interviewing a computer-science graduate or an engineer.
And also for what job: none of them are much use for computational fluid dynamics or finite-element analysis, for example.
I don't know how to do depth-first search in a binary tree (at least I wouldn't recognise it if I did!), so I wouldn't get the job!
And also for what job: none of them are much use for computational fluid dynamics or finite-element analysis, for example.
I don't know how to do depth-first search in a binary tree (at least I wouldn't recognise it if I did!), so I wouldn't get the job!
| lastchance wrote: |
|---|
| I don't know how to do depth-first search in a binary tree (at least I wouldn't recognise it if I did!), so I wouldn't get the job! |
I'd be an even less "qualified" job candidate since my entire knowledge of C++ is self-taught (and hanging out here at CPlusPlus seeing what "the experts" do.)
More often than not the hiring process is driven solely by HR, not the people who need a qualified candidate.
I've been programming for ~17 years and I don't think I'd recognize an implementation of the Euclidean algorithm, and I've implemented ECDSA (which involves implementing, among other things, the extended Euclidean algorithm, and the Tonelli-Shanks algorithm [essentially sqrt() in a modulo p field])!
Hell, every time I want to get the GCD I end up having to look it up, because it's information that just gets washed away in my mind. One of the problems is that's there's multiple ways to do it and they all return correct results; even if someone might recognize it as GCD they might think they're looking at a slightly incorrect implementation, or a function that does something slightly different but related to the GCD.
Rather than a test, maybe just interview them? Ask them what's something interesting they worked on, or something they liked. Unless they worked in a mind-numbing CRUD application, after three years they must have done something that's at least mildly interesting. Try to get a feel for what they know. Obviously it's much more subjective and it'll depend on the ability of the interviewer, but I think it's probably more useful to separate the chaff from the wheat.
Hell, every time I want to get the GCD I end up having to look it up, because it's information that just gets washed away in my mind. One of the problems is that's there's multiple ways to do it and they all return correct results; even if someone might recognize it as GCD they might think they're looking at a slightly incorrect implementation, or a function that does something slightly different but related to the GCD.
Rather than a test, maybe just interview them? Ask them what's something interesting they worked on, or something they liked. Unless they worked in a mind-numbing CRUD application, after three years they must have done something that's at least mildly interesting. Try to get a feel for what they know. Obviously it's much more subjective and it'll depend on the ability of the interviewer, but I think it's probably more useful to separate the chaff from the wheat.
| helios wrote: |
|---|
| I've been programming for ~17 years |
So you learned how to program in C++ back when the standard was C++98. Maybe even earlier.
Now that is positively ancient!
I began self-teaching myself around 2000 with a couple of C++ books written in 1996 and 1998. Half-heartedly.
With the C++11 standard the language finally started to "click" for me.
If you want to hire a walking library, then do these kinds of tests to see who's got the best memory for what amounts to programming trivia.
Tests are easy, because it gives HR dweebs something to do, and it outputs a simple number they can easily understand (they normally know that 10 is less than 20 for example).
I've been doing C for the thick end of 30 years, and I still don't remember which order the size and number of elements parameters are in an fread() call. Nor what all the various fopen modes are beyond the basic "r" and "w". Why? Because they're well documented all over the place.
If you want to find out if someone is any good, you have to have a 1:1 talk and ask how they would approach solving a problem, or have a discussion about problems they've solved in the past.
If you're a good programmer with excellent design skills and good at using resources to find basic information, then HR monkey tests can be a real PITA, because all they really test is factoid memory.
Tests are easy, because it gives HR dweebs something to do, and it outputs a simple number they can easily understand (they normally know that 10 is less than 20 for example).
I've been doing C for the thick end of 30 years, and I still don't remember which order the size and number of elements parameters are in an fread() call. Nor what all the various fopen modes are beyond the basic "r" and "w". Why? Because they're well documented all over the place.
If you want to find out if someone is any good, you have to have a 1:1 talk and ask how they would approach solving a problem, or have a discussion about problems they've solved in the past.
If you're a good programmer with excellent design skills and good at using resources to find basic information, then HR monkey tests can be a real PITA, because all they really test is factoid memory.
I think such questions are not really an indicator of what you are capable of.
whether somebody passes a test or not, he or she will still use documentation and online resources, nobody really knows everything.
a far better question would be to quickly implement some silly algorithm (not necessary useful) for which nobody knows, let's then see how intelligent that questioner is.
but otherwise yes, it's only an indicator or your existing knowledge, but not how good you are at solving problems.
whether somebody passes a test or not, he or she will still use documentation and online resources, nobody really knows everything.
a far better question would be to quickly implement some silly algorithm (not necessary useful) for which nobody knows, let's then see how intelligent that questioner is.
but otherwise yes, it's only an indicator or your existing knowledge, but not how good you are at solving problems.
closed account (2z0kLyTq)
One of the problems with your question is that there is no agreement on the definition of "experienced programmers." I've been paid a pretty good salary to write programs for the last ten years. What I do for a living probably better defined as data analysis. When a new person starts to work for us with programming experience they are often sent to me. When I talk to them they tell me things that make my head spin and I have to tell them that all I do is hack a few scripts together that produces a report.
I'll give them an assignment often and they can't finish it, so they come back to me for help. I'll help them solve their problem. Then they'll review what I did and tell me how I could have done it better.
They may be better programmers than me but they can't solve a problem.
No test or interview will ever work, you need to rely on references. Past experience is always the best predictor of future work.
I'll give them an assignment often and they can't finish it, so they come back to me for help. I'll help them solve their problem. Then they'll review what I did and tell me how I could have done it better.
They may be better programmers than me but they can't solve a problem.
No test or interview will ever work, you need to rely on references. Past experience is always the best predictor of future work.
Now that is positively ancient!
/cry
I learned to program on an apple 2-e and a HP 11-C calculator. C98 was way after I learned C++
--------
This is a hard question. Algorithm knowledge is something you know or you don't and I have always hated the stupid questions like 'swap 2 numbers without a temporary'. Anyone can figure that out if given a few min of relaxed concentration (there are I think 5+ ways to do this) but under pressure, if you did not know it going in, its a frustrating problem to many. It has merits -- if you did not know the answer and can demonstrate cool, collected ability to think it through, you will impress, but its not going to tell anyone if you can do anything useful. And if they knew it going in, you learn nothing at all IMHO, except that they studied common interview questions (a +, but not a useful +, it shows they care about getting a job).
Testing advanced STL and modern tools would be 'better' but we all know that about 3/4 of schools don't teach it. It would be great if you could show one of the 'auto <vector> <algorithm>' 5 line solutions to a common task and ask what that does, but its going to be unreadable to most grads (this is slowly getting better, but still).
If you can't ask about specific algorithms / tricksy problems nor the STL/modern style, what do you do, then?
I haven't got a lot here, but my take on it would be the top 10 recurring problems we see here:
- mixing getline and cin
- reading from a text file correctly
- comparing a double to a value correctly
- basic string manipulations (find, replace, uppercase, etc stuff)
- basic vector stuff (sort, find, push-back, etc)
- some OOP ... inheritance, templates, virtuals
- make them write a small program end to end. Look at their style: comments? Broken into functions? Variable names? Indentations? Basic competence (bugs? Gibberish/cute code? common mistakes? Globals? General peer review of it..). It should exercise their ability to solve a problem, not just be a canned textbook thing, as noted above. People who can't break a problem down and solve something unusual are not useful. Not talking codechef junk, but something practical and in the general scope of what their duties would expect from them.
- ask basic specifics on things your posted position expected them to know (Visual studio? Unix tools? Whatever you asked for in the posting or the tools they will be using?)
/cry
I learned to program on an apple 2-e and a HP 11-C calculator. C98 was way after I learned C++
--------
This is a hard question. Algorithm knowledge is something you know or you don't and I have always hated the stupid questions like 'swap 2 numbers without a temporary'. Anyone can figure that out if given a few min of relaxed concentration (there are I think 5+ ways to do this) but under pressure, if you did not know it going in, its a frustrating problem to many. It has merits -- if you did not know the answer and can demonstrate cool, collected ability to think it through, you will impress, but its not going to tell anyone if you can do anything useful. And if they knew it going in, you learn nothing at all IMHO, except that they studied common interview questions (a +, but not a useful +, it shows they care about getting a job).
Testing advanced STL and modern tools would be 'better' but we all know that about 3/4 of schools don't teach it. It would be great if you could show one of the 'auto <vector> <algorithm>' 5 line solutions to a common task and ask what that does, but its going to be unreadable to most grads (this is slowly getting better, but still).
If you can't ask about specific algorithms / tricksy problems nor the STL/modern style, what do you do, then?
I haven't got a lot here, but my take on it would be the top 10 recurring problems we see here:
- mixing getline and cin
- reading from a text file correctly
- comparing a double to a value correctly
- basic string manipulations (find, replace, uppercase, etc stuff)
- basic vector stuff (sort, find, push-back, etc)
- some OOP ... inheritance, templates, virtuals
- make them write a small program end to end. Look at their style: comments? Broken into functions? Variable names? Indentations? Basic competence (bugs? Gibberish/cute code? common mistakes? Globals? General peer review of it..). It should exercise their ability to solve a problem, not just be a canned textbook thing, as noted above. People who can't break a problem down and solve something unusual are not useful. Not talking codechef junk, but something practical and in the general scope of what their duties would expect from them.
- ask basic specifics on things your posted position expected them to know (Visual studio? Unix tools? Whatever you asked for in the posting or the tools they will be using?)
Last edited on
Thanks for the comments.
I agree that little tests are a bad way to find good programmers. What I'm really asking is how to weed out the really bad ones - the ones who don't actually know C++, the ones who took a boot camp and then claimed to have 5 years of experience, that sort of thing.
I agree that little tests are a bad way to find good programmers. What I'm really asking is how to weed out the really bad ones - the ones who don't actually know C++, the ones who took a boot camp and then claimed to have 5 years of experience, that sort of thing.
There is no one thing that qualifies you for a position. This is the problem that hiring managers deal with. Great references? Got them. Pass a test? Done it. Still can't program out of a paper bag.
Hiring a programmer is a calculated risk.
You mitigate the risk by as many metrics as you can. After all the other things, the best (and common) thing to do is have the candidate speak with a variety of people to pick his brain and see if they can determine that (one) candidate can think his way through several problems and (two) gets along with people and (three) is able to be instructed/directed/corrected/doesn't cause conflict.
Hiring a programmer is an expensive process.
Hiring a programmer is a calculated risk.
You mitigate the risk by as many metrics as you can. After all the other things, the best (and common) thing to do is have the candidate speak with a variety of people to pick his brain and see if they can determine that (one) candidate can think his way through several problems and (two) gets along with people and (three) is able to be instructed/directed/corrected/doesn't cause conflict.
Hiring a programmer is an expensive process.
Last edited on
some of that is on your HR department. If someone claims 5 years, they should have worked for 5 years somewhere, and a phone call to their manager about their duties can verify what they were doing and what tools were in use (unless the manager is willing to lie, there is no fix for that). Beware of 5 years over 5 jobs; that is 3 years of training/onboarding and at most 2 years of coding.
also, if they are on job #8 in a 12 year career, you have a problem. There are some good people that job shop and job hop, but most of the good programmers have at least a couple of long runs at some place. HR should have spotted a job hopper and you can just assume that by the time they know what you are doing and how you do things they will be gone, so you don't hire them.
As for spotting the complete losers, any experienced programmer should be able to pick up on this in a 30 min session with the candidate. That gets costly if you have 1000 people to weed through, but hopefully by the time you grant interviews you have weeded it down to a small #.
also, if they are on job #8 in a 12 year career, you have a problem. There are some good people that job shop and job hop, but most of the good programmers have at least a couple of long runs at some place. HR should have spotted a job hopper and you can just assume that by the time they know what you are doing and how you do things they will be gone, so you don't hire them.
As for spotting the complete losers, any experienced programmer should be able to pick up on this in a 30 min session with the candidate. That gets costly if you have 1000 people to weed through, but hopefully by the time you grant interviews you have weeded it down to a small #.
Last edited on
closed account (E8A4Nwbp)
This topic has not been posted in for almost a month, I'm just resurrecting it to speak to @jonnin who has disabled his PMs
Hi, @jonnin
A while ago you contributed here
http://www.cplusplus.com/forum/lounge/263653/
I have/am traversing into the mathematical side, I'm just here to ask if you have any advice for independently learning about the practical side of mechanical engineering. Where advice could be a resource or habit worth considering.
Hi, @jonnin
A while ago you contributed here
http://www.cplusplus.com/forum/lounge/263653/
I have/am traversing into the mathematical side, I'm just here to ask if you have any advice for independently learning about the practical side of mechanical engineering. Where advice could be a resource or habit worth considering.
Last edited on
the practical side of mechanical engineering is changing your own oil in the car or balancing your lawnmower's blade so it does not vibrate too much.
Statics and dynamics, strengths of materials, basic physics, safety and redundancy, calc up thru differential eqtns would be a starting point if you want to design and build something from scratch, and you need cad skills on top of these.
What sort of things do you want to do?
Statics and dynamics, strengths of materials, basic physics, safety and redundancy, calc up thru differential eqtns would be a starting point if you want to design and build something from scratch, and you need cad skills on top of these.
What sort of things do you want to do?
too broad :) A robot could be a self driving car, a remote control airplane, a little handheld toy, a fixed arm, ... most of robotics is the AI/programming side, the mechanical side is usually either something that you bought and adapted or a common design.
building your own mechanical platform is doable, but you can rough it out without a lot of know-how with those cheap kits, and make a bigger/stronger/better version after playing around.
building your own mechanical platform is doable, but you can rough it out without a lot of know-how with those cheap kits, and make a bigger/stronger/better version after playing around.
closed account (E8A4Nwbp)
Hm, I see. I'll just do the computational area in advanced then. The market seems to have greatly simplified the hardware level, to such an extent that with search results for raspberry PI come results for the same matter dedicated to the younger demographic, it's just not the same a c++
Topic archived. No new replies allowed.