Sorry for a second comment, but I have to address something directly.
A senior developer has, most-likely, already heard of OOP by now!!!
Not necessarily! Here's a few people we might encounter:
The guy that majorly padded his résumé,
The gal who worked in COBOL for 25 years, but hasn't ever used an OOP language,
The guy whose knowledge is 90% skimming StackOverflow answers and blog posts.
In hiring, you never everEVER take "most-likely" as a reason not to ask a question. If OOP is part of the job, you have to make sure they actually know it!
Jason, let me tell you about the guy who fools you and all those HR managers and team leads who think like you, no matter how "smart and tried" your procedures you think they are.
This guy has worked in over 8 companies in less than 10 years. This is what he does: he is a C# .NET developer, so he learned all the important concepts of it and then decided to teach it, so he can learn everything it is possible to learn. After teaching .NET for a while, he started going to interviews. Hell, even I interviewed him when he came to our company. He knows his stuff. He studied well.
After a couple of months of working for us, we realized that he was spending more time smoking outside than writing code! And when our team lead checked his code, it was crap! Soon after, I believe that our management gave him like 3 months to go, because in the last 3 months he was with us he was not given a single task. He didn't care though. He was getting paid and smoking all day long.
Then one day, 2 weeks before he leaves us, he says that he got an offer from the biggest company in Armenia, even bigger than ours. More money. He aced yet another interview.
He worked there for a year and a half. Then he went to another company. We know a girl who works in that "biggest company" who told us that while reviewing his code, which is a standard procedure there, she saw coding mistakes that even a junior developer wouldn't make.
Since then, he changed his job even one more time. All good companies.
So HOOOOOOOOW, with your awesome "procedures" and POKER NON-SMILING faces, you are letting such GARBAGE get into the company, but when it comes to someone who knows whatever he knows you reject them? This guy is clearly fooling the hell out of you guys (please don't say that he wouldn't fool you personally, HR and Team Leads here follow the example that you set in USA or Europe).
Jason, all I am asking for is FAIRNESS. Don't let people like that guy FOOL YOU, and don't let people like Burdette refuse to do a task because they feel it is foolish, because YES, OOP concepts for a senior is a FOOLISH question.
And when it comes to Stack Overflow, EVERY RESPECTED DEVELOPER IN THE WORLD uses it! Please don't panic if you see your staff using it! Our team lead copy/paste from Stack Overflow, should we fire his ass?
And most importantly, PLEASE REMOVE THAT STRESS FACTOR FROM THE WORKPLACE! "if you don't deliver this app in 2 minutes we will all DIE!!!" No one is going to die! Even the biggest companies in the world delay a software or hardware for MONTHS sometimes, no one gets killed or anything!
All I am asking for is an OPEN-MINDED approach to the interview procedure, because the old ones are CLEARLY failing.
Exactly. Some people who aren't good at programming are excellent at interviewing. The best way I've found to expose those that have trained themselves to interview well for the aggressive Trivial Pursuit interviews is to have a "let's-have-coffee-and-chat-about-code" interview. A few "That's interesting. Tell me more about how you implemented a facade pattern in your web service project." type questions and you'll know if they're just reciting Wikipedia or really done the work. (Bonus if you can ask those questions with a Wonka-esque smile rather than a poker face.)
What's more, this kind of question will let you gain some insight into their personality and coding style. For example, a while back I interviewed a senior level C# programmer who would have probably aced a by-the-book OOP, design patterns and Fibonacci-on-a-whiteboard type interview. However, after a simple discussion, it was clear his coding style was radically different from the rest of the team, was rather egotistical and thus he wouldn't be a good fit.
BTW, I have worked at a programming job in medical monitoring where someone might actually die if there was a problem. It was actually less stressful and more enjoyable workplace than most run-of-the-mill business app teams since people put aside their egos to get the job done because it was really important that it be done right.
Although I probably didn't make it clear, I actually purge from my list any questions that job websites recommend people prepare for. I do prefer very open ended questions.
I don't work in any place where we have looming "we're all going to die" deadlines, but I've known a few. If you're running a major website, and a security problem slips into production, there's no denying that is super-urgent.
Hey, calm down. I'm not attacking you. You asked for input and feedback, and that's what I provided, calmly and speaking from several years experience. I am curious what your work experience in hiring has been, as I haven't seen you mentioned actually working HR before.
To address a couple of your concerns directly.
1) I never said our method is perfect - none is - but it demonstrates a documentably lower "bad hire" rate. It is still possible to make a bad hire.
2) Not every respected developer in the world uses OOP. It's one of six major paradigms, and it is perfectly possible not to fully grasp it at many different experience levels. That's speaking from factual observation, not just grasping at straws.
3) Pushing code under a stressful deadline isn't a management decision, it's a naturally occurring circumstance with some projects.
I was present in many interviews along with HR to ask technical questions. That's all. Our whole team participates in the interview process; sometimes its our team lead and me, sometimes it's the team lead and one or two others.
Although, I had some interview experience from a past job which is not related to IT.
In this world today, we have standards almost for anything. I am just asking for one more standard for job interviews (particularly for IT). That's all what I am asking for. You might be a great interviewer, but certainly others are not. An interview standard would make things much professional for both interviewers and interviewees.
As a developer/interviewee, I really do not know what kind of knowledge I should memorize and carry with me in my head to the interview.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sorry for a second comment, but I have to address something directly.
Not necessarily! Here's a few people we might encounter:
The guy that majorly padded his résumé,
The gal who worked in COBOL for 25 years, but hasn't ever used an OOP language,
The guy whose knowledge is 90% skimming StackOverflow answers and blog posts.
In hiring, you never ever EVER take "most-likely" as a reason not to ask a question. If OOP is part of the job, you have to make sure they actually know it!
Jason, let me tell you about the guy who fools you and all those HR managers and team leads who think like you, no matter how "smart and tried" your procedures you think they are.
This guy has worked in over 8 companies in less than 10 years. This is what he does: he is a C# .NET developer, so he learned all the important concepts of it and then decided to teach it, so he can learn everything it is possible to learn. After teaching .NET for a while, he started going to interviews. Hell, even I interviewed him when he came to our company. He knows his stuff. He studied well.
After a couple of months of working for us, we realized that he was spending more time smoking outside than writing code! And when our team lead checked his code, it was crap! Soon after, I believe that our management gave him like 3 months to go, because in the last 3 months he was with us he was not given a single task. He didn't care though. He was getting paid and smoking all day long.
Then one day, 2 weeks before he leaves us, he says that he got an offer from the biggest company in Armenia, even bigger than ours. More money. He aced yet another interview.
He worked there for a year and a half. Then he went to another company. We know a girl who works in that "biggest company" who told us that while reviewing his code, which is a standard procedure there, she saw coding mistakes that even a junior developer wouldn't make.
Since then, he changed his job even one more time. All good companies.
So HOOOOOOOOW, with your awesome "procedures" and POKER NON-SMILING faces, you are letting such GARBAGE get into the company, but when it comes to someone who knows whatever he knows you reject them? This guy is clearly fooling the hell out of you guys (please don't say that he wouldn't fool you personally, HR and Team Leads here follow the example that you set in USA or Europe).
Jason, all I am asking for is FAIRNESS. Don't let people like that guy FOOL YOU, and don't let people like Burdette refuse to do a task because they feel it is foolish, because YES, OOP concepts for a senior is a FOOLISH question.
And when it comes to Stack Overflow, EVERY RESPECTED DEVELOPER IN THE WORLD uses it! Please don't panic if you see your staff using it! Our team lead copy/paste from Stack Overflow, should we fire his ass?
And most importantly, PLEASE REMOVE THAT STRESS FACTOR FROM THE WORKPLACE! "if you don't deliver this app in 2 minutes we will all DIE!!!" No one is going to die! Even the biggest companies in the world delay a software or hardware for MONTHS sometimes, no one gets killed or anything!
All I am asking for is an OPEN-MINDED approach to the interview procedure, because the old ones are CLEARLY failing.
Exactly. Some people who aren't good at programming are excellent at interviewing. The best way I've found to expose those that have trained themselves to interview well for the aggressive Trivial Pursuit interviews is to have a "let's-have-coffee-and-chat-about-code" interview. A few "That's interesting. Tell me more about how you implemented a facade pattern in your web service project." type questions and you'll know if they're just reciting Wikipedia or really done the work. (Bonus if you can ask those questions with a Wonka-esque smile rather than a poker face.)
What's more, this kind of question will let you gain some insight into their personality and coding style. For example, a while back I interviewed a senior level C# programmer who would have probably aced a by-the-book OOP, design patterns and Fibonacci-on-a-whiteboard type interview. However, after a simple discussion, it was clear his coding style was radically different from the rest of the team, was rather egotistical and thus he wouldn't be a good fit.
BTW, I have worked at a programming job in medical monitoring where someone might actually die if there was a problem. It was actually less stressful and more enjoyable workplace than most run-of-the-mill business app teams since people put aside their egos to get the job done because it was really important that it be done right.
Although I probably didn't make it clear, I actually purge from my list any questions that job websites recommend people prepare for. I do prefer very open ended questions.
I don't work in any place where we have looming "we're all going to die" deadlines, but I've known a few. If you're running a major website, and a security problem slips into production, there's no denying that is super-urgent.
Hey, calm down. I'm not attacking you. You asked for input and feedback, and that's what I provided, calmly and speaking from several years experience. I am curious what your work experience in hiring has been, as I haven't seen you mentioned actually working HR before.
To address a couple of your concerns directly.
1) I never said our method is perfect - none is - but it demonstrates a documentably lower "bad hire" rate. It is still possible to make a bad hire.
2) Not every respected developer in the world uses OOP. It's one of six major paradigms, and it is perfectly possible not to fully grasp it at many different experience levels. That's speaking from factual observation, not just grasping at straws.
3) Pushing code under a stressful deadline isn't a management decision, it's a naturally occurring circumstance with some projects.
I am calm :D and I appreciate your opinion.
I was present in many interviews along with HR to ask technical questions. That's all. Our whole team participates in the interview process; sometimes its our team lead and me, sometimes it's the team lead and one or two others.
Although, I had some interview experience from a past job which is not related to IT.
In this world today, we have standards almost for anything. I am just asking for one more standard for job interviews (particularly for IT). That's all what I am asking for. You might be a great interviewer, but certainly others are not. An interview standard would make things much professional for both interviewers and interviewees.
As a developer/interviewee, I really do not know what kind of knowledge I should memorize and carry with me in my head to the interview.