
Unfortunately, we'll reject most software developer job applications. - andrewstuart
http://www.supercoders.com.au/blog/wewanttogetyouajob.shtml
======
dkarl
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.

~~~
mrtron
You nailed it with "What is an interface?". Interviewers really mean Java
interface.

Back in the day, I was told in an interview: "While they were a Java shop,
this interview is about general programming concepts."

The first question they asked was "What is an interface?".

------
dimavs
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.

------
anthonyb
This may because most decent developers won't touch a recruiter with a 40 foot
pole unless they absolutely have to.

Hence, you're seeing a somewhat skewed version of the developer population.

~~~
anthonyb
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).

------
InclinedPlane
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.

~~~
fusiongyro
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.

~~~
InclinedPlane
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.

~~~
fusiongyro
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.

------
ootachi
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.

~~~
moonchrome
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.

------
ncarlson
These questions cover language-specific keywords of a specific programming
paradigm.

~~~
andrewstuart
Even so, most employers that we work with won't even consider job seekers who
don't have this stuff down.

~~~
heretohelp
>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.

~~~
sirclueless
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.

~~~
heretohelp
I've given answers similar to that, where I explained the place of each
terminology and why it means nothing in my language(s) of choice.

I've also gotten rejected for either:

(A) Not having enough experience in their language of choice, despite
apparently knowing both.

(B) Not knowing the "answer" to the question.

You assume too much about the typical recruiting process.

tl;dr this is why I work at a startup now.

------
pnathan
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 :-)

------
redguava
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.

~~~
prodigal_erik
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.

------
acangiano
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.

------
natesm
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.

~~~
sirclueless
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.

------
aDemoUzer
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.

------
garethsprice
Abstracts, interfaces, protected, private and public are not Java-specific,
they're fundamental concepts of object orientated theory.

<http://agp.hx0.ru/oop/quarks.pdf> has a handy table summarizing 40 years of
OO research that predates Java by decades.

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.

~~~
syko
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.

------
danbmil99
The questions you pose sound oh so 2006.

------
slurgfest
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)

------
yakov_castov
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.

------
prtamil
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.

------
SoCool
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?

------
Tangaroa
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.

~~~
sirclueless
No, but companies will only hire the top 0.5% of applicants to regional third-
party IT recruiters.

The bottom 99.5% of chronically unemployed tech hopefuls is a very different
group than the bottom 99.5% of software developers.

