When you see all five questions together, it's obvious they're about Java (edit: or maybe C#, since the terminology is the same.) Taking them one by one in an interview, you'd have no way of knowing, so good luck on providing "accurate" answers.
Imagine if "What is an interface?" was the first question you were asked. That's so vague it's almost philosophical.
Finally, I'm really glad I've done enough Java programming to remember the answers to these questions. Apparently, if my work history had been a little different, I'd be unemployable.
I don't have to imagine; I've received, "What is an interface?" as a first question in three different interviews over the last couple of months. Never mind that Java isn't anywhere on my resume, I made it clear to the recruiter before the interview that I don't know Java (not that I mind learning if necessary for the job, just don't send me to a job interview that requires it), and they were ostensibly interviewing me for a senior non-Java-specific position that required solid math skills.
I'm not quite sure what they're trying to filter for, but when one uses language-specific trivia as a starting point for an interview, it's going to filter out a lot of people that many companies claim they're so desperate to hire.
You called me last year. I was just in a middle of re-painting my lounge room.
One of the first questions from you was "What is polymorphism?" (or polymorphic behaviour)
In my mind - "Oh, crap, one more stupid question from the recruiter who wouldn't understand a word". And I've started with some rubbish trying just to "hit your keywords".
You cut me and told that you are quite technical and I can use technical terms. I got confused (nervous) at that moment and our phone talk finished in a minute.
From my side - "shit! What a rubbish I was telling him". From your side - "another idiot, trying to get a high paid job"
There is something wrong in recruitment process through agents.
ps. CPlatypus - if you read this, you seem to have been hellbanned, for that literally/figuratively jab last week, or possibly belatedly for your anti-VC-patent rant.
Completely undeserved IMO, so I thought I'd let you know (you don't have contact details in your profile).
Utterly worthless. This is just java trivia. Congrats on hiring a bunch of brainless drones who memorized a few facts about one programming language, I'm sure they represent the best talent on the market.
I agree with your overall sentiment, but those concepts are hardly java trivia.
I think the intent of that article is to use those questions as a 0-pass filter. You don't hire based on getting them right, but you damn sure don't let them pass to the next phase if they get them wrong. Like FizzBuzz.
If their blog is to be believed, that bunch of brainless drones represents 0.5% of the applicants. I find it hard to imagine that the best talent in the market would get those questions wrong, though in spirit I agree with you.
It's easy to monday morning quarterback and say "oh, OF COURSE any competent dev. should know all this inside and out, it's basic stuff from 200 series CS courses, if that". But that misses the mark. For one, it's enormously Java specific. For another, some of it isn't very relevant to most coding. How often is it really necessary to code an abstract class in Java? How often is it really necessary to know all the trivia of protected access?
This ranks pretty high on the least useful knowledge that you could probe for in a developer. The only reason it's even remotely successful is probably because there's a general correlation between experienced coders and coders who know these subjects well. But it's nowhere near a perfect correlation, you can be certain of that. It will eliminate people with talent and select for people who know trivia but lack talent.
Imagine it like this, you spend several weeks and thousands of dollars courting potential candidates for the love of your life. And on your ultimate date you ask them what their favorite band is and move on or forward based on their answer. Reality is a lot more complicated than that.
Try this test at your work. Identify your developer coworkers who you look up to, and come up with equivalent topics for their coding platform of choice then randomly ask them about them. For example, drop by and say something like "hey, I always forget, could you explain abstract classes to me?" Or something like that. I'd be curious what the results were.
Let's make some distinctions. I'm not saying this is the ideal way to hire. I also dislike recruiters, and Java for that matter. But I don't find this practice indefensible, because:
1. Whenever you open a position, you get a ton of applicants that simply aren't qualified, and the faster you get rid of them the better.
2. A majority of programming jobs use Java, C# or C++, which all have 4 or 5 of these keywords with similar meaning.
This is a quick and easy filter. Of course, any quick and easy filter is going to have a false negative rate, and it's fair to protest that. Fundamentally, hiring programmers by their programming language competencies is also a very poor idea. But there are a lot of places that simply need a bunch of competent cogs and I don't think it's worth getting too worked up over the unintended negative consequences of their poor decisions. They want a ton of cogs, this is a great way to get a ton of cogs. You're not a cog and neither am I. I don't think either of us would want one of these "supercoder" jobs anyway.
I bet most people get the "protected" one wrong, because it's actually strictly less restrictive than package access in Java. That is, protected members can be accessed by anyone within your same package. Do you reject people for not knowing that any class in the same package can access protected members?
If so, you probably just weeded out a huge percentage of Java programmers.
Is this about Java ? In C# that protected would be accessible from derived class but only trough the derived type, and what you described would be internal, ie. allow access from any class in the assembly. Terminology could be applied to C++ but it doesn't have syntax for interfaces and abstract classes.
Altough I like that answer you gave and this sort of "detailed" questions (I don't think the article had that in mind tough), primarily because if you can answer it I would guess that you know Java enough to be usefull without needing any furhter questions. Someone reading trough a textbook might read that but won't remember it unless he knows the implications, and if he knows that he knows Java. And if you don't know it that cool too, there are other questions like this that demonstrate actual expirience with the language/tools vs. shallow textbook trivia.
>won't even consider job seekers who don't have this stuff down
That's not the point, it means different things to different programming languages, which means there is more than one correct answer unless you get more specific.
Further, it's virtually irrelevant to Python programmers since the OO model there is "we're all consenting adults".
Have what down? You haven't even stated a well-formed question.
Imagine you answered on the phone that your expertise is in python, where all members are virtual and public, visibility is only by convention, duck typing makes interfaces largely unnecessary and abstract classes only exist as a standard library feature to allow isinstance(variable, BaseClass) to work properly. If a recruiter declares that a failed answer then I would question their process, but it can be a good interview question so long as it lets you demonstrate deep understanding of your favorite OO language.
So I really don't want to work in an OO shop. I would far prefer to work in a dynamic or functional shop.
Answers there would look something like this:
Explain public.
N/A
Explain private.
N/A
Explain protected.
N/A
What is an abstract class?
N/A
What is an interface?
Ah, we get to something shared... A list of functions that can be applied to an instance of a type without raising an error.
The times I've used Perl, Python, Javascript, and Common Lisp all do not relate to public/private/protected/abstract base class. They have simply not been required to do the job, and I'm unsure whether they even carry the concepts with them without building an extension into the language. I'm fairly sure a MOP could use it if you really wanted.
So while this test might be great for C++/Java/C# hiring... I don't even bother asking these questions when I'm on a Python/Bash/Perl hiring team. They don't relate.
The questions aren't interesting. They can be Googled, and I would be brutally tempted to think better of someone if they stalled and I heard keys being whacked as they found the answers on Wikipedia or StackOverflow.
But, you know, maybe OO teams need their OO FizzBuzz. I can totally appreciate that, and wish SuperCoders all the best :-)
I don't understand why you want to look for indicators that someone will be a good coder... rather than actually see if they are a good coder (ie. actually look at their code). I understand looking at peoples code takes time... but really that's why companies are paying recruiters, to save them time.
I would guess if there was some magic set of indicators that shows if someone is a good coder or not... we would have worked that out by now. It turns out there isn't... look at code.
If you aren't able to read code and evaluate someone by their code, you shouldn't be hiring software developers. How did we end up in a position where people that understand code, hire people that don't understand code (recruiters) to hire people that can code.... what am I missing here.
We have to watch them write code for some problem they didn't cram for. We can't just read code because we don't know how much trouble they had producing it, or whether it's even theirs. Our recruiter (when we had one) just looked for reasonable fit with the claimed skills, and asked a couple of elementary conceptual questions (not single-language trivia like this), then brought in engineering.
It's worth noting that answers, particularly if you expect accurate ones, would be different depending on the language being considered. For example, private in Ruby is similar to protected in Java. But pedantry aside, those are fair questions for programmers.
I think it's hard to give answers that are both accurate and concise to some of these questions, without appending "in language ______" to them. In some languages, access control is a compiler feature and is actually strictly enforced. Objective-C has access control for instance variables, but not for messages, and the ivar access control can be circumvented via the runtime (to say nothing of -valueForKey:). "Private" messages are typically declared in the implementation file or a second header. Python sort of has private methods through name mangling, but they aren't really private, since we're all adults. In Ruby, those words mean something fairly different.
I think it's fair to say if you can answer clearly and concisely in any language at all, then you have demonstrated a good deal of domain knowledge. Enough to convince a recruiter that there may be a job for you somewhere. The exact language hardly matters.
In my view the interviewer has made biased assumption: IF someone who cannot give concise and clear questions about the concept THEN they don't know about it.
You can consider it a shortcoming on my part or reality for most programmers, but I don't tend to memorize names of concepts, I just know how to use them. i.e. I may be using inheritance or polymorphism in my code, but my brain does not every time thinks about what these terms mean and am I applying them as they are defined. I have been programming for years and OOP has become second nature to me; I know how to apply OOP, but have long forgotten most of the terms.
In my view, when interviewing, the questions should be practical problem so it tests user's ability to program a solution, not about being able to churn out the definition.
Example: If you want to test someone's OOP expertise, give the person a list of classes and ask them to create a UML or how they would structure their classes.
Example 2: Give them a problem like, create 2 classes: Animal and Dog. All animals have a name and a dog can bark. Test to see if the programmer would extend Animal class from Dog class, or maybe he decides to make an Abstract class out of Animal class.
The only downside of these questions is that you would need to have interviews who are competent in the OOP concepts themselves. Continuing to ask dictionary questions is a cop-out solution to not having technical interviewers and it is easier for someone to check if interviewee is able to mention some of the keywords that are in the definition you found on wikipedia.
Unfortunately, you will continue to reject most developer job applications and miss out on lot of great candidates.
Even if you were dumbing yourself down because you were talking to a recruiter, it should be possible to explain those concepts in a way that a non-technical person could understand, especially a non-technical person who has a stock answer in front of them to check keywords off on.
This industry shocks me sometimes, it's akin to accountants claiming that no-one needs to understand economics as they're personally really good at counting US dollar bills and that's all they do all day at their job, so why would anyone need to understand all that fancy theory stuff or be able to explain it to anyone else.
I agree. Unless all you know are functional languages, you should understand all of these concepts.
Of course, we don't know what the recruiter's idea of "clear and concise" answer is.
How many RECRUITERS actually know what "object oriented programming" means? They never seem to be interested in my take on (say) subtyping and the design properties of inheritance... (but that's ok; I am not interested
in the crap positions that they want to shoehorn me into by lying to me and lying to the employer while taking a gigantic cut out of the middle; yet I don't understand who relies on people who are truthfully quite ignorant of programming to assess who would be a good programmer)
Wow, do these recruiters have tickets on themselves or what? Raises the question that if they have such an awesome (text book) knowledge of OO, why are they recruiters and not developers? Unfortunately for Andrew, it takes a lot more than learning your marketing speak back-to-back to be a real dev.
When I'm recruiting I couldn't care less if the candidate can recite 'Intro to OO' verbatim. You can tell weather he has passion in the first five minutes, and that's all that matters.
If somebody would provide accurate, clear and concise answers then my spider sense would inform me that i may dealing with guys with fake experience who memorized the answer.
irrelevant questions. In the coming decade purity is going to prevail. We are going to go back to using pure functions. I will rather answer the question what is a pure function?
So according to this post, companies are only going to hire the top 0.5% of programmers to their entry-level positions. Something is seriously wrong with this employment model if 99.5% of the labour pool can expect to never find work.
Hyperbole aside, I think what they're saying is that the vast majority of people who apply are, in fact, not actually software developers.
Perhaps they are looking for some kind of job, and because they know how to type, that must mean they can code. Since coding is just typing, right? (how many of us had bosses at one time that thought this!)
If you can't answer those 5 questions, then I would wager you've never actually written an OO program, you've never attended a single undergrad COSI course, or you don't speak English.
I don't know about all companies, but most of the companies we work with require strong knowledge of OO. There's probably lots of employers who don't really care much about OO. So I think the 99.5% of people will get jobs at places that are looking for different things to what we look for.
Imagine if "What is an interface?" was the first question you were asked. That's so vague it's almost philosophical.
Finally, I'm really glad I've done enough Java programming to remember the answers to these questions. Apparently, if my work history had been a little different, I'd be unemployable.