Programming Questions in an interview or "The Lazy Interviewer Syndrome"
-
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
-
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 had that sort of interview for my first job out of school. About 50 programming questions and an hour to do them, it reminded me of a test in Comp Sci 101. Breezed through those and then had a short face to face interview with the team manager. The guy had been a DBA back when he started so had an idea of what questions to ask and what the reason and concept was behind the answer he wanted. They could have skipped the entire first bit and just go with the interview. Would have saved everyone's time. I can teach someone the syntax of a language. I cannot teach someone how to approach a problem or think for themselves. After a number of years in, I tend to be able to get a better feel for someone's ability by asking questions about how they would approach a problem instead of what is the solution for that same problem. If your solution is overly complex, your code tends to be as well and will be a beast to maintain once you are gone. If you won't even attempt to solve think about it then you will be here on CodeProject and other various boards asking people how to do your work. In my mind, how a developer thinks and learns is much more important than what they already claim to know.
-
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?
This is a very important topic. One of my first IT interviews for an entry level position, I was asked the same question and didn't know that answer and no I didn't get the job. But subsequent interviews, I was ready for the Reverse String question. An interview says a lot about the company. Today, if someone interviews me and have nonsense or irrelevant questions pertaining to my level or the level of the job, then I will not take the job. Additionally, it makes the company look bad. Why would I want to work for a backwards company?
-
Excellent 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
-
I am going to do that too if they ever ask me these kinds of questions. No doubt!
And, if enough people did that, they'd change their evil interviewing ways. I had an interview last year. I stopped the interviewer at the first question, told him never mind, and left.
We won't sit down. We won't shut up. We won't go quietly away. YouTube and My Mu[sic], Films and Windows Programs, etc.
-
This is a very important topic. One of my first IT interviews for an entry level position, I was asked the same question and didn't know that answer and no I didn't get the job. But subsequent interviews, I was ready for the Reverse String question. An interview says a lot about the company. Today, if someone interviews me and have nonsense or irrelevant questions pertaining to my level or the level of the job, then I will not take the job. Additionally, it makes the company look bad. Why would I want to work for a backwards company?
Oh well, our interview process is pretty shambles, the senior developer that we had for the last 12 years (he's recently quit) was hired because back then he was the only one who turned up for the "interview" and he was interviewed by, shall we say, less than a programmer person. That's no blinkin' way to interview someone for a highly involved and skilled job! This guy had an air of hollow superiority over every one else and was extremely condescending but he ended up working for 12 years and built a system that only he had any clue about. He had a horrible programming style and was routinely in habit of creating 100 line methods. May maintainability rest in peace! Its clearly a proof of severely flawed hiring process that we have, funnily enough, prior to my interview at my current workplace more than 4 years ago, I was given a programming assignment that I had to complete and bring in and then walk the devs through my thinking process and understanding that eventually led to a solution. The focus wasn't on if I can solve the problem correctly but whether or not I can come up with approaches to solve the problem and convey my ideas to others. Why couldn't we have done something similar with this guy? I agree interviewing is hard but asking these stock questions is just plain lazy and condescending IMO.
-
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 ask 5 (non-technical) questions. If they can't get through those then I know I wouldn't hire them as, no matter how good they may well be, they are not a cultural fit and are unlikely to fir into the team or stay very long. You can be the moist brilliant developer in the world but if you don't fit on with the company culture, you won't last and that is a waste of everyone's time.
-
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:
we had a candidate over for a "Junior Developer"...What is your opinion on this?
Depends on exactly what "junior developer" means. A developer with no experience should not be expected to know anything about professional programming. A non-senior level developer, say with an expectation of 2-4 years of experience, should know something about programming.
I.explore.code wrote:
not having done a job long enough,
Say what? You asked a candidate in for an interview knowing that they did have enough professional experience for the minimum job requirement? That is unprofessional on the companies part.
I.explore.code wrote:
Now that in my opinion is the failure of the interviewer
Sort of. Fact of the matter is to correctly prepare to give an interview in a way that objective criteria can be met it takes quite a bit of preparation. Anything other than that is just developers deluding themselves into thinking that they can actually evaluate technical merit in a short interval of time. Moreover any individual might overall provide benefit to a team while in some technical way being less than proficient.
I.explore.code wrote:
Is asking such questions even a point here?
My only goal is to get them talking about any technical matter merely to see if it appears that we will be able to communicate in a reasonable way.
-
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...
-
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, 2013John Simmons / outlaw programmer wrote:
Ask to see some of the candidates personal code (projects he works on in his own time).
I work for a living and have always done so. The last time I did code for myself I had never been paid to program. Since then the code I throw has always belonged to someone else. Which mean I have absolutely no right to show it to anyone else.
-
OriginalGriff wrote:
I know one guy who specializes in 4 or 6 hour interviews.
Is he arrogant, ignorant or both?
-
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 had an interview lasted 2 hours, then on the way out was asked to do one of those Psychotic tests, or whatever they're called. I was about to refuse (they told me it would take between 30 mins and an hour) but they said no test, no job, so I thought waht the heck! As it was gone 5pm they then buggered off, leaving me in the room to do the test & told me to put the paper on reception on my way out (there was a button to unlock the door) so I was left in this little room behind reception, alone in the building, to do a Psych test! Fortunately for me, I was totally pissed off at this point, so I ran through the multiple choice questions (they were questions like: You are at a party when someone spills a drink down your new suit; how do you react? a) Punch them in the face b) Apologise to them c) such the drink out of the cloth d) Laugh Stupid bloody questions, this type - I mean, who was it? was it deliberate? am I drunk? was it a cheap suit? had he just shagged my wife in the toilets? Move information needed. So. I answered them entirely randomly on the answer sheet, finished in all fo three minutes, hung around to make sure the interviewer had time to get out the car park, and buggered off. The agent phoned me a few days later (they sent the tests out to a company that rips people off about this sort of thing) and told me I had got the best results they'd ever had! Got the job. It was crap (they used vi to edit Cobol, in the mid-1990's!)
PooperPig - Coming Soon
-
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.
FORTRAN and FMS? Brings back memories. FYI: I love legacy code.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
John Simmons / outlaw programmer wrote:
Ask to see some of the candidates personal code (projects he works on in his own time).
I work for a living and have always done so. The last time I did code for myself I had never been paid to program. Since then the code I throw has always belonged to someone else. Which mean I have absolutely no right to show it to anyone else.
I have also always worked for a living, but I spend a lot of time writing my own stuff. Occasionally, I develop some code for an employer and after getting permission, write an article about the techniques I developed in pursuit of the final code. I've found that most employers are fine with technology sharing unless the code in question is highly proprietary (exposes trade secrets, or is so unique and innovative as to expose the company to competitive loss). I am honestly amazed at the number of programmers I've personally encountered that DON'T write code as a hobby at home. IMHO, it shows a lack of commitment to the art of development, but I also understand the necessity to separate private life from vocational pursuits. I'll always be more interested in hiring people that have a demonstrable passion for the act of writing code. For my current job, I was interviewed by a PM who had no idea what to ask. No programming questions at all, just explanations of the code I worked on in the past. It was kind of a strange interview.
".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
