Programming Questions in an interview or "The Lazy Interviewer Syndrome"
-
Couple of days ago we had a candidate over for a "Junior Developer" role and a couple of my colleagues interviewed him. After an hour and a half they got back and proclaimed that the guy was no good because he couldn't solve a string reversal problem. Now, that's not the only thing that caused his "demise" obviously it was more of other things like not being passionate about software development in general, not having done a job long enough, not having any side projects to speak and appearing to not even try to solve the problem given during the interview. What I find funny is these interviewer colleagues of mine really didn't do any preparation or due diligence to interview the candidate, 10 minutes before the interview they were scrambling on websites trawling for questions they can ask. Now that in my opinion is the failure of the interviewer just as much as that of the candidate to prepare properly. I have been to better interviews than this, where the interview lasts for around as much and longer if needed and they assess a lot of soft skills like communication, attitude etc and then some technical grilling on a whiteboard. The process is more two way than this case, the focus is not on solving a problem that you would never actually need to solve from scratch in real life anyway. Why do you think Google was invented? (not talking about "copy-n-pastable" solutions, just general searching for ideas etc.) What is your opinion on this? Do you think asking "beaten to death" programming questions in an interview is just a lazy interviewing attitude because the interviewer couldn't be bothered to prepare properly? Is asking such questions even a point here?
If someone asked me to reverse a string, I'd rotate the paper/monitor. If they ask me something about the technology they use, I'll think about taking them seriously.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Couple of days ago we had a candidate over for a "Junior Developer" role and a couple of my colleagues interviewed him. After an hour and a half they got back and proclaimed that the guy was no good because he couldn't solve a string reversal problem. Now, that's not the only thing that caused his "demise" obviously it was more of other things like not being passionate about software development in general, not having done a job long enough, not having any side projects to speak and appearing to not even try to solve the problem given during the interview. What I find funny is these interviewer colleagues of mine really didn't do any preparation or due diligence to interview the candidate, 10 minutes before the interview they were scrambling on websites trawling for questions they can ask. Now that in my opinion is the failure of the interviewer just as much as that of the candidate to prepare properly. I have been to better interviews than this, where the interview lasts for around as much and longer if needed and they assess a lot of soft skills like communication, attitude etc and then some technical grilling on a whiteboard. The process is more two way than this case, the focus is not on solving a problem that you would never actually need to solve from scratch in real life anyway. Why do you think Google was invented? (not talking about "copy-n-pastable" solutions, just general searching for ideas etc.) What is your opinion on this? Do you think asking "beaten to death" programming questions in an interview is just a lazy interviewing attitude because the interviewer couldn't be bothered to prepare properly? Is asking such questions even a point here?
My only experience is as interviewee, and I've been interviewed only once - when I've been hired in my current company. The first step was a written questionary with 30 questions to be done in 40 minutes - the questions spaced from generic Computer Science (i.e. calculating a xor between 2 decimal numbers, ginving the result in binary and checking if the given hexadecimal representation of the result was correct), Calculus, Electronics, Signal Theory, C/C++ programming and VB6 (the last 2 were the actual requirements of the job). After that they called me back some day later for the real interview where we only spoke about my past / side projects, ambitions, inclinations and the company business - what and how they do for living. They were impressed by the sincerity in my curriculum, I checked VB6 as good knowledge and got all the related questions right, while I marked most of the skills as academical, meaning I studied them and passed exams but had not any real experience.
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X I use 1TBS
-
Couple of days ago we had a candidate over for a "Junior Developer" role and a couple of my colleagues interviewed him. After an hour and a half they got back and proclaimed that the guy was no good because he couldn't solve a string reversal problem. Now, that's not the only thing that caused his "demise" obviously it was more of other things like not being passionate about software development in general, not having done a job long enough, not having any side projects to speak and appearing to not even try to solve the problem given during the interview. What I find funny is these interviewer colleagues of mine really didn't do any preparation or due diligence to interview the candidate, 10 minutes before the interview they were scrambling on websites trawling for questions they can ask. Now that in my opinion is the failure of the interviewer just as much as that of the candidate to prepare properly. I have been to better interviews than this, where the interview lasts for around as much and longer if needed and they assess a lot of soft skills like communication, attitude etc and then some technical grilling on a whiteboard. The process is more two way than this case, the focus is not on solving a problem that you would never actually need to solve from scratch in real life anyway. Why do you think Google was invented? (not talking about "copy-n-pastable" solutions, just general searching for ideas etc.) What is your opinion on this? Do you think asking "beaten to death" programming questions in an interview is just a lazy interviewing attitude because the interviewer couldn't be bothered to prepare properly? Is asking such questions even a point here?
The thing to bear in mind with this "stock questions" approach is that the candidate's agent will ask the candidate what question they were asked and use that to prep the next candidate through the door.
-
Couple of days ago we had a candidate over for a "Junior Developer" role and a couple of my colleagues interviewed him. After an hour and a half they got back and proclaimed that the guy was no good because he couldn't solve a string reversal problem. Now, that's not the only thing that caused his "demise" obviously it was more of other things like not being passionate about software development in general, not having done a job long enough, not having any side projects to speak and appearing to not even try to solve the problem given during the interview. What I find funny is these interviewer colleagues of mine really didn't do any preparation or due diligence to interview the candidate, 10 minutes before the interview they were scrambling on websites trawling for questions they can ask. Now that in my opinion is the failure of the interviewer just as much as that of the candidate to prepare properly. I have been to better interviews than this, where the interview lasts for around as much and longer if needed and they assess a lot of soft skills like communication, attitude etc and then some technical grilling on a whiteboard. The process is more two way than this case, the focus is not on solving a problem that you would never actually need to solve from scratch in real life anyway. Why do you think Google was invented? (not talking about "copy-n-pastable" solutions, just general searching for ideas etc.) What is your opinion on this? Do you think asking "beaten to death" programming questions in an interview is just a lazy interviewing attitude because the interviewer couldn't be bothered to prepare properly? Is asking such questions even a point here?
I.explore.code wrote:
After an hour and a half
:wtf: If you can't tell within 10 minutes whether a developer knows what they're talking about or not, you've got problems.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
I.explore.code wrote:
After an hour and a half
:wtf: If you can't tell within 10 minutes whether a developer knows what they're talking about or not, you've got problems.
There are only 10 types of people in the world, those who understand binary and those who don't.
I know one guy who specializes in 4 or 6 hour interviews. One interviewee asked for a comfort break after three hours, then called reception from his car to tell them to elephant off.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
I know one guy who specializes in 4 or 6 hour interviews. One interviewee asked for a comfort break after three hours, then called reception from his car to tell them to elephant off.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
I know one guy who specializes in 4 or 6 hour interviews. One interviewee asked for a comfort break after three hours, then called reception from his car to tell them to elephant off.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Couple of days ago we had a candidate over for a "Junior Developer" role and a couple of my colleagues interviewed him. After an hour and a half they got back and proclaimed that the guy was no good because he couldn't solve a string reversal problem. Now, that's not the only thing that caused his "demise" obviously it was more of other things like not being passionate about software development in general, not having done a job long enough, not having any side projects to speak and appearing to not even try to solve the problem given during the interview. What I find funny is these interviewer colleagues of mine really didn't do any preparation or due diligence to interview the candidate, 10 minutes before the interview they were scrambling on websites trawling for questions they can ask. Now that in my opinion is the failure of the interviewer just as much as that of the candidate to prepare properly. I have been to better interviews than this, where the interview lasts for around as much and longer if needed and they assess a lot of soft skills like communication, attitude etc and then some technical grilling on a whiteboard. The process is more two way than this case, the focus is not on solving a problem that you would never actually need to solve from scratch in real life anyway. Why do you think Google was invented? (not talking about "copy-n-pastable" solutions, just general searching for ideas etc.) What is your opinion on this? Do you think asking "beaten to death" programming questions in an interview is just a lazy interviewing attitude because the interviewer couldn't be bothered to prepare properly? Is asking such questions even a point here?
For my last two positions, they were phone interviews. The first was for a position working with FORTRAN and FMS (forms application) on VAX/VMS. I knew the platform and supporting tools, but I was also personable enough to be able to talk to the interviewers and present myself as a good candidate. The interview lasted 2 hours. The next position (current one) was for a niche market product that I had used for 20 years. Again, I knew the product and I could hold my own technically and personally. That interview lasted an hour. For people I've interviewed, I've learned to listen for key phrases: if everything is "we've done this" or "our group did that", the person isn't presenting themselves or their work - they are representing what was done by others. Whether someone can solve a particular problem as a junior should not be as important as do they understand concepts, are they willing to learn, are they willing to be mentored.
-
what do you do for 6 hours, rewrite his website?
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
Hang yourself after about ten minutes, I think...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
OriginalGriff wrote:
I know one guy who specializes in 4 or 6 hour interviews.
Sounds like a guy trying to avoid doing his actual job. :doh:
There are only 10 types of people in the world, those who understand binary and those who don't.
Managing Director, and a total control freak. Still pays employees by cheque (as far as a I know) because that way he can decide if he likes them enough to actually pay them that month. He did / does that with everyone: from the-pack-and-dispatch guy to the sales manager. I managed to avoid it by giving him no choice but to hire me ... and then create a department for me to "be in" afterwards! :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Couple of days ago we had a candidate over for a "Junior Developer" role and a couple of my colleagues interviewed him. After an hour and a half they got back and proclaimed that the guy was no good because he couldn't solve a string reversal problem. Now, that's not the only thing that caused his "demise" obviously it was more of other things like not being passionate about software development in general, not having done a job long enough, not having any side projects to speak and appearing to not even try to solve the problem given during the interview. What I find funny is these interviewer colleagues of mine really didn't do any preparation or due diligence to interview the candidate, 10 minutes before the interview they were scrambling on websites trawling for questions they can ask. Now that in my opinion is the failure of the interviewer just as much as that of the candidate to prepare properly. I have been to better interviews than this, where the interview lasts for around as much and longer if needed and they assess a lot of soft skills like communication, attitude etc and then some technical grilling on a whiteboard. The process is more two way than this case, the focus is not on solving a problem that you would never actually need to solve from scratch in real life anyway. Why do you think Google was invented? (not talking about "copy-n-pastable" solutions, just general searching for ideas etc.) What is your opinion on this? Do you think asking "beaten to death" programming questions in an interview is just a lazy interviewing attitude because the interviewer couldn't be bothered to prepare properly? Is asking such questions even a point here?
I.explore.code wrote:
the guy was no good because he couldn't solve a string reversal problem.
I don't interview with companies that perform these kind of interviews. Ever. I have walked out during an interview. It happens. You guys really need to have a sound interview process in place, and at least (2) well trained individuals to perform the initial interview process (screening).
-
For my last two positions, they were phone interviews. The first was for a position working with FORTRAN and FMS (forms application) on VAX/VMS. I knew the platform and supporting tools, but I was also personable enough to be able to talk to the interviewers and present myself as a good candidate. The interview lasted 2 hours. The next position (current one) was for a niche market product that I had used for 20 years. Again, I knew the product and I could hold my own technically and personally. That interview lasted an hour. For people I've interviewed, I've learned to listen for key phrases: if everything is "we've done this" or "our group did that", the person isn't presenting themselves or their work - they are representing what was done by others. Whether someone can solve a particular problem as a junior should not be as important as do they understand concepts, are they willing to learn, are they willing to be mentored.
Well said.
-
I.explore.code wrote:
After an hour and a half
:wtf: If you can't tell within 10 minutes whether a developer knows what they're talking about or not, you've got problems.
There are only 10 types of people in the world, those who understand binary and those who don't.
I know, but what's worse is that they spent all that time and still couldn't ask a worthy technical question or may be the candidate just took too long to allow them to move on from the lowest of the low questions to more sensible stuff. I still have little to no respect for these stock questions, just because the candidate says Computer Science on their profile doesn't give you a license to ask these ridiculous questions, unless the candidate doesn't have any commercial experience. IMO these ridiculous "technical" questions should be a last ditch resort after the candidate has failed to show enthusiasm, soft skills, side projects.
-
I know, but what's worse is that they spent all that time and still couldn't ask a worthy technical question or may be the candidate just took too long to allow them to move on from the lowest of the low questions to more sensible stuff. I still have little to no respect for these stock questions, just because the candidate says Computer Science on their profile doesn't give you a license to ask these ridiculous questions, unless the candidate doesn't have any commercial experience. IMO these ridiculous "technical" questions should be a last ditch resort after the candidate has failed to show enthusiasm, soft skills, side projects.
I.explore.code wrote:
I still have little to no respect for these stock questions
I agree. I've found the best way to interview anyone is to let them tell me what they've done. It's very clear that way if they know what they're doing.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Couple of days ago we had a candidate over for a "Junior Developer" role and a couple of my colleagues interviewed him. After an hour and a half they got back and proclaimed that the guy was no good because he couldn't solve a string reversal problem. Now, that's not the only thing that caused his "demise" obviously it was more of other things like not being passionate about software development in general, not having done a job long enough, not having any side projects to speak and appearing to not even try to solve the problem given during the interview. What I find funny is these interviewer colleagues of mine really didn't do any preparation or due diligence to interview the candidate, 10 minutes before the interview they were scrambling on websites trawling for questions they can ask. Now that in my opinion is the failure of the interviewer just as much as that of the candidate to prepare properly. I have been to better interviews than this, where the interview lasts for around as much and longer if needed and they assess a lot of soft skills like communication, attitude etc and then some technical grilling on a whiteboard. The process is more two way than this case, the focus is not on solving a problem that you would never actually need to solve from scratch in real life anyway. Why do you think Google was invented? (not talking about "copy-n-pastable" solutions, just general searching for ideas etc.) What is your opinion on this? Do you think asking "beaten to death" programming questions in an interview is just a lazy interviewing attitude because the interviewer couldn't be bothered to prepare properly? Is asking such questions even a point here?
A good interview: 0) Debugging questions need to be asked. A good programmer should be able to jump into unfamiliar code and fix it with relative ease. I've never been asked to fix a problem. 1) Present the programmer with a design challenge within your own code base where a solution was recently implemented, and ask for as many possible solutions as he can think of, and discuss the pros/cons of each approach. 2) Avoid pointless brain teaser questions. 3) Ask to see some of the candidates personal code (projects he works on in his own time). He should already preseume this will be asked and bring his own laptop. All of these things can illustrate his communications ability, problem solving skills, and general coding skills. You can pretty much tell how he will fit in when you start critiquing his code. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I.explore.code wrote:
the guy was no good because he couldn't solve a string reversal problem.
I don't interview with companies that perform these kind of interviews. Ever. I have walked out during an interview. It happens. You guys really need to have a sound interview process in place, and at least (2) well trained individuals to perform the initial interview process (screening).
I am going to do that too if they ever ask me these kinds of questions. No doubt!
-
A good interview: 0) Debugging questions need to be asked. A good programmer should be able to jump into unfamiliar code and fix it with relative ease. I've never been asked to fix a problem. 1) Present the programmer with a design challenge within your own code base where a solution was recently implemented, and ask for as many possible solutions as he can think of, and discuss the pros/cons of each approach. 2) Avoid pointless brain teaser questions. 3) Ask to see some of the candidates personal code (projects he works on in his own time). He should already preseume this will be asked and bring his own laptop. All of these things can illustrate his communications ability, problem solving skills, and general coding skills. You can pretty much tell how he will fit in when you start critiquing his code. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Agreed on all but:
John Simmons / outlaw programmer wrote:
bring his own laptop
I don't have a laptop :), I know I'm weird but I still prefer a desktop way over a laptop :)
Tom
-
Agreed on all but:
John Simmons / outlaw programmer wrote:
bring his own laptop
I don't have a laptop :), I know I'm weird but I still prefer a desktop way over a laptop :)
Tom
The only reason I have a laptop is for interviews. I would go so far as to say that it's an essential tool of any programmer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
The only reason I have a laptop is for interviews. I would go so far as to say that it's an essential tool of any programmer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Well I do have a laptop from work, but I never use it outside off work. And I have like 3 or 4 old one's at home but I'm pretty sure none of them are still booting let alone run VS. I haven't needed a personal laptop in a while, and as long as I don't need it I'm not going to buy it :)
Tom
-
A good interview: 0) Debugging questions need to be asked. A good programmer should be able to jump into unfamiliar code and fix it with relative ease. I've never been asked to fix a problem. 1) Present the programmer with a design challenge within your own code base where a solution was recently implemented, and ask for as many possible solutions as he can think of, and discuss the pros/cons of each approach. 2) Avoid pointless brain teaser questions. 3) Ask to see some of the candidates personal code (projects he works on in his own time). He should already preseume this will be asked and bring his own laptop. All of these things can illustrate his communications ability, problem solving skills, and general coding skills. You can pretty much tell how he will fit in when you start critiquing his code. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Excellent answer. I routinely offer to send/show my personal projects, for the very reason you mentioned. It lets them know how I think and code, and moreover, it tells them that I can analyze problems and design complete solutions - not just write code.
If it's not broken, fix it until it is
