
I’m an Engineer, Not a Compiler - Luyt
http://www.numbergrinder.com/2009/02/im-an-engineer-not-a-compiler/
======
edw519
Imagine interviewing carpenters:

Method 1:

    
    
      How many ten penny nails in a pound?
      Who makes better screwdrivers, Craftsman or Snap-on? Why?
      What's your favorite toolbox? Why?
      How can you tell when wood has been treated?
      Why should you measure twice, cut once?
      Which end of the hammer do you hold?
    

Method 2:

    
    
      Show me something you built. Describe what you did.
      Cut this piece of wood according to these specs.
    

If you needed someone to build your house, which method would you choose?

~~~
jiggy2011
Differences between programming languages are much bigger and more important
than differences between different brands of toolboxes or hammers.

If you realise you made a poor choice of screwdriver it is trivial to replace
it with a different one and carry on working almost immediately since it's
operation is basically the same.

Choosing your language or platform poorly and running into issues later once
you have an app close to release or already running in production is going to
cause much more difficult problems.

Essentially our tools end up embedded inside our product itself.

It's close to impossible to reliably compare programming to any other
profession simply because there is nothing else quite like it.

~~~
InclinedPlane
I don't think this is borne out by reality.

Making a general contracting mistake such as accidentally compromising the
structural integrity of a building by making a poor choice on where to run the
plumbing can easily result in a lot of work having to be re-done, at
significant cost.

------
srean

      IDE dependency? Perhaps, but that isn’t necessarily a bad
      thing since that is representative of the tools they will
      be using in the office.
    

Mine is perhaps an unpopular view.

I have come to believe that a decent programmer can and should be able to work
well enough without an IDE. Presence of an IDE should be a sufficient
condition not a necessary condition and I see so much of the latter.

IDEs are a crutch and there is a minimum level of "walking" that I expect from
you without a crutch. If you have to reach for a crutch even for the simplest
tasks you will earn my suspicion that you are not as comfortable as the other
guy in more complicated operations. As for the claim that IDEs are a
representative tool, it need not be true, more for a start up pushing the
envelope. Who knows which new or non mainstream language/technology will be
most suited for the job. There may not be any mature tooling available yet. I
would want my co-hacker to be able to cope.

To give an example, there was this guy who claims he knows scala, but loathes
working on a scala project because apparently there are no mature debugger for
scala in eclipse. For him a eclipse plugin is a necessary condition.

I have seen too many programmers who program in the following mode - let me
type something in the IDE. No errors detected ?, good. Let me test it on a few
cases. Didn't work ? let me bump up the loop bound by one, no cookie ? let me
decrement it by 2, didnt work, let me change the sign of this expression from
positive to negative -...ad infinitum. I am more scared when such a code
passes a few half assed test cases and the author cannot explain why the fix
works.

I am not saying IDE are universally bad, quite the contrary. I advocate IDEs,
but under two scenarios - (i) you are learning a new language (ii) you are an
expert in that language. It is the overly populated middle ground, where it is
used as a substitute for (a) thinking about your code or (b) knowing the
language, that worries me.

~~~
pnathan
If you _have_ to use an IDE to program, you're not programming in the
language, you're programming the IDE.

There are many times I have to log into remote systems and all I have are nano
or vi. Not even emacs. If I have IDE-dependancy, I'm up a creek without a
paddle.

~~~
eropple
If you're hot-patching code in a remote environment, you have much bigger
problems than "I don't have an IDE!".

I use an IDE--and for many languages, ex. Java, Scala, and C#, would say I
_have_ to--because my time is worth something to me.

~~~
kamaal
_I use an IDE--and for many languages, ex. Java, Scala, and C#, would say I
have to--because my time is worth something to me._

For the languages you've mentioned. Java and C# do you really have any other
option, but to use an IDE? Its like, goes without saying and assumed that you
are and every body is programming with an IDE.

In case of Java. You must know eclipse today is nearly a part of the language
and not a separate tool.

~~~
eropple
I can write Java without an IDE. It's not that hard--it just takes additional
time. Valuable time that I could spend writing other code or sleeping or
drinking beer.

The assumption that it would be Eclipse, however, is hilarious.

------
DrJokepu
> My favorite phone interview question? “What’s your favorite language?”
> followed by “What are it’s weaknesses?”

This is also one of my favourite questions to ask when I'm interviewing
someone. Unfortunately most of the time the only response I get is confused
stares. Maybe this is just a UK culture thing but it feels like many people
are not prepared to display critical thinking on a job interview.

~~~
tomp
I have seen so many programming languages that my only answer to the first
question can be, "None".

Haskell is too restrictive, OCaml too verbose and inflexible, Java lacks
closures, Javascript has weird equality semantics, C lacks garbage collection,
Python lacks static typing, Clojure has too many `)))`s, Ruby is inconsistent,
... I could go on.

In the end, I just settled on a language that I have to use at work (currently
Python), but I'm wishing for something better to come along...

~~~
Yrlec
You should try C#. It's like Java with closures (and some other nice features:
[http://stackoverflow.com/questions/610199/the-art-of-
program...](http://stackoverflow.com/questions/610199/the-art-of-programming-
java-vs-c-sharp) )

~~~
tomp
C# is one of the most interesting languages, really. It's been developing
really fast, and along with F#, it shows that MS is really putting an effort
into programming language progress. However, my main concern with C# is not
the language, but the libraries/ecosystem. It's so tightly bound to Windows
that it hurts. There are no good cross-platform implementations, poor IDE
support, and I'm pretty concerned developing for a runtime that might go
away...

Now, if only MS would open-source their implementation, most of these
arguments would become void.

~~~
silverlake
Mono is pretty good. F# also runs on the Mono runtime.

~~~
eropple
Mono is a _great_ attempt done by great people (I did Google Summer of Code
for Mono and it was a blast). However, its utility is hit-or-miss; performance
is a concern relative to Java-on-Unix or .NET-on-Windows and I'm starting to
find that a lot of the cross-platform usefulness claimed by stuff like
MonoTouch to be a lot less than I originally bought into. I can get most of
the same out of C++ (and most of the same, iOS excepted, from Java), and I
know it'll be there in the next few years.

Couple that with the future of .NET itself not looking terribly bright thanks
to WinRT _, and I'm personally getting more and more concerned about the
viability of .NET, and implicitly Mono. I'd dearly love to be wrong, but I
don't think I am.

_ \- This is one of the things about Microsoft that infuriates me. I've heard
from people in Microsoft that "developers have told us they want C++"--well no
shit, really, when you've jerked around .NET as much as you have, people are
going to assume there's little future for the platform. Self-fulfilling
prophecy.

~~~
pnathan
Back around 2000 I was studying graphics programming as a hobby, and the
DirectX APIs were moving pretty quickly at that time. It seemed as if a new
version was dropping every 6 months. I got tired of playing catch-up to
Microsoft and switched to OpenGL. Much better experience; got code running
much faster.

I saw the same pattern begin with .NET; you had to keep playing catchup and
buying into the New Hotness. I realized that this seemed to be a Microsoft
strategy: obsolete the old knowledge and watch the developers pay money for
the new hotness. I'm not saying that MS needs to be static, but there appears
to _me_ to be a deep seated instability in their approach, which implies
pretty heavy retraining every five years. Contrast this against C++, which has
been more or less standard since the mid-90s, _especially_ for the common
cases.

I get tired of running on a tech treadmill. Learning how to crap out the same
concept in yet another language (much the same as the ones I already have
used) has nil interest for me. I am tired of wasting my life figuring out the
subtleties of a Java clone, or a C++ clone, or a Perl clone, or... etc.

I look for a stable, long-term language, on fairly stable core technologies,
so I can build really _amazing_ new technology without throwing it out and
restarting due to the New Hotness. I personally have picked Common Lisp for my
long-term code and projects. Others might pick C++, Perl 5, or Fortran. I look
over new languages and technologies as they come out and see if they have
something meaningfully innovative that really merits learning and/or
switching. Some do. Most don't. Haskell looks like it has a good future right
now.

~~~
eropple
That sounds about right. I've gone back to Java and C++ for most of my own
projects because of the uncertainty factor.

(OpenGL is a festering mess, though. DirectX is a wonderful API in
comparison.)

------
trustfundbaby
This story is a bit embarrassing to me, but I'll tell it anyway, I went for an
interview a while ago, where I got asked a basic Javascript question ...
problem is, I haven't actually written actual javascript in almost 3-4 years
(not simple, but not really that hard either) ... I've been writing jQuery,
which is supposed to be javascript, but I digress ...

I know how Javascript works, scoping, hoisting blah blah blah, but I haven't
written a for loop, or used an actual getByTagName or whatever in a long long
time ... I told the interviewer this, and they seemed cool with that, they
asked me to write in pseudo code and I did that, then they asked me to convert
it to javascript ... hunh?

Well, I started going through line by line and started doing just that, asking
them to refresh my memory about the syntax of stuff, even how to write a for
loop (yup, its amazing what spending years using jQuery.each or $.each will do
to you :P). Anyway, we concluded and though I was annoyed at how out of
practice I was, I thought I did okay.

Well the recruiter who set it up, called me back (very nicely I might add) and
gave me the feedback on the interview. The interviewer, (who had been very
nice to me too btw), had eviscerated me, writing that I displayed a lack of
Javascript fundamentals ... saying I didn't even know how to write a for loop.

I don't blame them, because we clearly shouldn't have been talking in the
first place, they were obviously looking for a hard core Javascript guy ...
and not person who could just build complex front end UIs & interactions using
backbone/ember/spine/jquery/whatever, which is what I was more interested in.

But it also got me thinking about how some engineers fixate on syntax, and use
it in judging other programmers, and I realized that in some circumstances it
is pretty appropriate.

For example, if you're looking for a specialized dev, then that kind of stuff
probably does matter; in that, it can help you spot a star very quickly ...
but I also think that over reliance on it could let you miss out on people who
could easily specialize to the level you want, but might not have that
immediate level of familiarity with the language. But when you have to go
through 100's of candidates, is that something you're willing to take the time
to look out for? Should you?

Sorry for the rambling, just been thinking about it for a long time now.

~~~
barrkel
You have your specialization / generalization axis the wrong way around, I
think. Knowing what a for-loop looks like in a C-derived language is
correlated with broad experience; once you know it in C, you know it in Java,
JavaScript, C++, C#, etc. But someone who knows primarily jQuery / backbone /
ember / spine etc. is much more of a specialist, not a generalist. They have
deep specific knowledge of a narrow toolset, rather than broad general
knowledge of a wide toolset.

That is, knowledge of language over libraries indicates generality (if you
know the language and its idioms well, you should pick up most libraries
fairly easily); knowledge of libraries over language indicates specialisms,
because you end up a little out of your depth when not wading through the
library's DSLs.

~~~
DavidWoof
I assumed he meant a _for(obj in list)_ , not _for(int x = 0; i < foo..._.

It's pretty natural to forget the first syntax if you haven't used it in a
while because there's no real standard for it across languages.

~~~
trustfundbaby
Actually its the latter ... I do a lot of python, ruby and jquery (almost
exclusively), so I really can't even remember the last time I had to do a for
loop.

I've done, C, C++, C# & Java so the syntax wasn't unfamiliar to me at all, and
I probably could have recalled it if I had taken 2 minutes to do it, I just
didn't think it would be a big deal to ask so I could get on with the code.

------
staktrace
I disagree with some parts of the post. I think good engineers have to be able
to work effectively at a high "system" level of abstraction as well as at a
low "compilation" level of abstraction. If you can't look at a chunk of code
and know enough about the language to know that it could throw a
ClassCastException, then it is quite likely that you will fall prey to other
language gotchas which can bubble up and destroy the entire design of the
system you're trying to build.

I don't think the current state of the art in software development has yet
advanced to the point where we can just black-box away all of the entire
"compilation" stuff such that it never affects the "system" stuff. I really
would like that to be the case, because it would eliminate a lot of
unnecessary complexity in software development.

I think asking a limited number of compiler-level questions (less than 5) in
an interview doesn't take up a lot of time, and can allow you to get an idea
of how much actual experience the candidate has with the language as well as
dealing with nitty-gritty problems that come up while you're coding. The value
and time spent are both small, so the value/time ratio is probably in the same
ballpark as any other question you might ask.

~~~
ajuc
I don't know. I remember problems with different classloaders, old versions of
classes being deserialized, different versions of classes being sent over RMI,
etc. Some of these probably resulted in ClassCastException. Some had thrown
more specific Exceptions, am I supposed to remember the exact Exception that
was thrown in each case? I'll probably know if you show me stacktrace. But I
only know because I've encountered such problems. People working on the other
end of our system would recognize different set of problems that results in
this Exception or similiar.

Nano questions are bad, because you are really asking if candidate has had the
exact same experience that you had. Some did, some didn't, it doesn't matter.
Anybody will solve the problem within minutes, most probably googling the most
promising lines of the stacktrace, and ctrl+clicking around in Eclipse (or
grepping the source tree, whatever).

Even auto-importing packages in IDE can cause problems - sometimes it imports
from the wrong package. Is it enough reason to ask questions about "which
package contains Hibernate Session class?" or even "which package contains
ArrayList class?". I don't think so. Being aware of the problems good
abstractions can cause (there's always a few problems) is IMHO enough, no need
to remember everything you can google in 5 seconds.

EDIT: or maybe you meant that you just check if people know casting can throw
ClassCastException, with that I'm OK.

------
slavak
I for one would be grateful if an interviewer asked me this kind of question.
It gives me an instant and unambiguous indication that this is _not_ a place I
want to work, saving me a lot of wasted time - and God forbid if I'd otherwise
actually ended up accepting a job there.

~~~
hashbo
It’s usually a bad sign about the interviewer’s interviewing skills, not
always them as a person or the team.

I have worked for some nice, amiable smart folk who interview like crazy
people. It’s the whole > IT skills < social skills thing.

But I empathise - I really don’t like interviews which are like that,
especially when they’re usually a game to try and make the interviewer seem
smarter than the interviewee.

------
phatbyte
To me, a perfect interview would be:

"Here's a coding challenge, go home, write the code to solve this, come back
tomorrow and tell me three things: \- How you did it, - Why you pick this
solution, - How it could be improved"

by doing this I could see how he writes code, if he's just a google
copy&paster, and what's his skills in algorithm optimization etc...and
specially, how he/she thinks.

Quite frankly I don't care if someone doesn't know what Polymorphism is right
from his head. I didn't knew what polymorphism was until a few months ago, and
yet I was applying the same principles in a lot places in my code. That's the
downside of being a self-taught you don't get to know a lot of theory, but on
my work I know I'm doing it right. (Also because polymorphism is a very
abstract thing to be honest....)

In a nutshell, get developers who can show you their code and can it explain
it, don't rely on theory, you are not hiring a college professor.

------
gbvb
I believe Any senior engineer worth his salt should be able to do lint style
verification of someone else's code quickly. When I am expecting someone to be
a senior enough engineer, they should be able to look at someone's code during
Code reviews and find the issues in it that can lead to problems without
resorting to IDE/debugging.

I do agree that nano-questions are not useful _except_ in situations where you
get a resume with keyword bonanza: You know the kind, ones with every
language,OS in the first page listed so that they will pass through the
corporate recruiter filter. For those, nano-questions trip up but that will
give me an indication to dig a little deeper into their IDE usage pattern. If
they show some proficiency in it, (for e.g., tell me the command in Eclipse to
find all the references to a particular method, if the answer is search in
files, .. :)).

~~~
wladimir
If you want to someone to do lint, why not just run lint and save on an
expensive hire?

Code reviews are there to find problems with the code that are not found by
trivial static verifiers and/or IDEs. This requires a level of understanding
of the language and experience in reading (instead of writing) code, but has
nothing to do with regurgitating keyword definitions.

Better in that case to just give a code fragment and make them spot the
(algorithmic, logic, security, not spelling) errors.

~~~
gbvb
Ok. I was making a point but I guess you are right about lint. I

was trying to point out that it is easy have developers write code that can
easily be O(n2) vs O(n log n) because this did not use the right kind of the
maps when they were initially building the code. Or I can see developers using
HashTables vs HashMaps interchangeably and not see the threading impact. In
these cases, some basic questions about their understanding of the classes
seem to be a good indicator. Would you consider that a nano-question? I was..

------
dmitrykoval
If you happen to be asked such questions it might be a good indication that
the type they are looking for is code monkey. Or they are just not good enough
to assess engineering skills. In both cases it's a red flag.

~~~
jimbobimbo
Yeah, basically one should always remember that interview with a company
always works both ways. It's OK to ask questions or just listen to your
internal BS-o-meter while talking with company reps.

------
dhotson
I'm kind of on the fence on this.

These questions might seem pretty lame, but as an interviewer it does tell you
something about the candidate's level of experience with a language.

If you've worked with a language for any decent amount of time. There are
things that you really should know without having to look it up all the time.

This is especially true if you mention on your resume that you're an expert at
something. I'm definitely going to ask you a difficult question about it and
I'll expect you to answer in some depth.

If you mention you're a Java pro but can't tell me what the 'synchronized'
keyword does for example. I'd be concerned.

~~~
zeru
If you are trying to hire an "expert" and ask him questions like that, you are
doing it really wrong, unless you are trying to scare him away. If anything
you want to actually talk to him about what he has done, about the languages,
his thoughts and passion in the subject... not ask him first programming
classes in college questions.

However if you are trying to hire some kind of junior-like engineer who has
never had a job before, i can see why questions like this could be asked, but
i still dont think it's the best way to gather knowledge about the person you
are interviewings level of expertise.

~~~
dhotson
Don't get me wrong. I ask all those other questions as well.

The problem is: people lie.

It's the old thing where if you want to hire a juggler, don't you want to see
them juggle?

~~~
ohyes
So ask the programmer to program or debug something, give him a decent IDE and
access to Google. Don't ask him to answer trivia. 'Can you fix this simple 10
line function' is much less insulting.

It is a huge turn off for a lot of people and indicates that the interviewer
is either too lazy to make the question interesting, or not technical enough
to generate an actual good question. Either way it is a red flag.

------
raganwald
I’m going to take the incredibly unpopular stance that nano-questions are
_not_ considered harmful. It’s true that only asking nano-questions, or
emphasizing them, or thinking that a good engineer must necessarily be able to
answer all of the nano-questions perfectly are all broken ways of thinking.

But I look upon them as a kind of FizzBuzz. I know for a fact that while you
_can_ look them up in Google in 500 nanoseconds, experienced people doing
hands-on work are going to be able to answer 2/3 nano-questions instantly. A
few such questions sprinkled in the opening part of the interview are useful
for weeding out the AbstractArchitectureAstronautFactoryFactories from the
Programmers.

I’m not talking about esoterica, e.g. “What is protected inheritance in C++?”
Lots of practitioners might say, correctly, that they never use it and can
easily look it up if you need to know how it works. And sometimes answering
esoterica correctly has negative correlation: You end up hiring people who are
SmartButTooBusyPlayingWithCoolIdeasToGetStuffDone (I’m a prize example of
this). But if a programmer says he’s working with jQuery and I ask him to
explain the difference between $(‘.foo.bar’), $(‘.foo,.bar’) and $(‘.foo
.bar’), I don’t want to hear from him that he can look it up on the Internet,
a jQuery programmer _knows_ the answer.

It’s acceptable for someone to say, “I don’t know jQuery, but I’m a smart guy,
I can figure it out on the job by looking stuff up,” but if he says he’s been
using it to build awesome HTML5 applications, I want to ask a _few_ of these
questions to make sure that I’m interviewing the person described on the
resumé. A working programmer will know the answer to all of them, they
shouldn’t be hard. Interview pressure will cause some fuzz, so I don’t expect
perfect, maybe get 2/3 or 3/5 right and then we can talk about composition vs.
inheritance or whatever other pet “Start a conversation with a smart person”
question.

I want to be incredibly clear about this: I don’t think that there is some
strong correlation between memorizing things and being a good programmer. I
don’t think programmers should rush out and memorize trivia just to “pass” an
interview. I look stuff up all the time in my job. But I do think that if the
questions are easy and obvious to the working programmer, a few of them are an
appropriate FizzBuzz for weeding out the folks who have falsified their hands-
on experience.

By and large, interview questions are a touchy subject because they serve as a
kind of metric for valuing people. So when I say I think it’s cool to ask a
few of these questions, some folks are going to think that I say that I
measure their worth by whether they know a handful of bits of information.
That’s not the case. I’m not saying you’re unworthy if you don’t memorize
things. But I am saying that if you claim to have a certain type of
experience, there are some questions that are going to be dead easy for you to
answer, and those questions are going to help us get to the good part of the
interview very quickly.

p.s. List vs Set is a funny question. I can’t imagine anyone with a degree
being ignorant of the difference regardless of the programming language! It’s
also a good lead-in to a more experiential question: “Okay, can you describe a
time you’ve used a set of some kind? What were you trying to accomplish? ..."

~~~
bermanoid
_List vs Set is a funny question. I can’t imagine anyone with a degree being
ignorant of the difference regardless of the programming language!_

That's not what he's complaining about, though, he said that question was
perfectly fair game. Because it _is_ something that, as a Java programmer, you
actually need to know to do your job. Similarly, the difference between the
jQuery selectors _is_ relevant, because those things actually do different
things. I'd argue that even your joke example, "What is protected inheritance
in C++?" is still relevant, if esoteric, because it's knowledge that could
potentially be relevant to how code works and what it does.

You truly never need to know what package List or File is in, though, in the
real world. If you're programming Java like 99% of the other people out there
(i.e. you're not the type of masochist that thinks they can be productive in a
boilerplate-heavy language like Java with nothing but a text editor), your IDE
will fill in those blanks, and quite literally hide the import statements from
you so you never need to think about them again (unless you mis-selected the
class, in which case the fast solution is _still_ not to remember the actual
package name, but to delete the offending import statement and "Optimize
imports" again, this time picking more carefully rather than mindlessly
selecting the first one in the list...).

That said, most Java experienced programmers would probably know that stuff
like List is somewhere in java.util, and stuff like File is going to be in
java.io, just from having auto-completed them so many times, so it could be a
very weak filter against people that are lying about their experience. But I
still don't think it's a useful question, at all - if they get it right, it
_very weakly_ confirms that they're not lying, and if they get it wrong it's
nothing more than a minor eyebrow-raiser, suggesting that possibly they've
exaggerated their familiarity (though again, any practicing Java programmer
could be very good but still be weak at the "Name That Package!" game, because
it's 100% irrelevant to the job). The thing is, you'd get far more information
either way by just having them rant about Java in general, or asking them to
talk about what pieces of the standard library they use the most, etc.

~~~
aboodman
I program Java in emacs. I work with many people who do. Of course, it's hard
for me to say _objectively_ that I'm productive, but my peers seem happy with
my work.

~~~
kamaal
I think you deserve appreciation for showing such patience and bravery to be
programming Java in Emacs.

On any other day, if the choice of eclipse or equivalents(IntelliJ etc) is not
available it practically makes zero sense to deal with monstrosity and
needless complexity Java has with a ordinary text editor. Even if that is
Emacs. Emacs is still a text editor.

On any given day Java development makes sense only if done on a IDE. And
that's nearly every Java programmer works. Exceptions exist, but they only
prove the rule.

Having said all that, These days eclipse really does 90% of the coding. You
job is only to tell eclipse what needs to be auto completed.

~~~
gcp
I'm in a similar position as the grandparent - Java coding in Emacs. For
various reasons using a smart Java IDE is a pain in our environment
(multilanguage code with Java parts). Emacs just works.

Emacs has working autocomplete from Java, especially with Semantic. It's far
away from being as smart as something like IntelliJ, but it works well enough.
Most functions and arguments you remember after a while. I can type much
faster than I can think, so less autocomplete doesn't slow down. In fact, not
having to watch if the autocomplete gets it right frees the brain to think
ahead more. Maybe it's because I'm used to this.

Import statements are one of those things where you have to switch to Google,
though.

~~~
kamaal
I do most of my other stuff Perl/Python and any other stuff apart from Java on
Emacs. Some times on Sublime Text 2.

I am now planning to shift to ST2.

Even on an editor like ST2 which is awesome anyway. You get to see what an
editor is designed for. Its supposed to make 'Text' manipulation easy. So that
is what it is, after everything.

So Emacs with all its power is still a Text editor, albeit a very powerful
one.

Every time I work on Text editor I focus on reading manuals and understanding
stuff no matter which editor that is. But with Java,IntelliJ and Eclipse its
different, I just throw in whatever little is there on my mind and just wait
for the autocomplete to do the magic.

Some of my colleagues go a step far. They just can't write any Java code
without an IDE and I see that's the case with nearly every Java programmer
I've met so far! Even in interviews. Its sort of like if you are talking of
Java development its taken for granted that its is happening on an IDE. You
never know, a few days from now the Java language specification my include a
IDE specification.

According to me tools and languages must enable you think more than you write.
Unfortunately in case of Java(and now growingly Python) you just can't work
without an IDE.

------
shimfish
I had a company that was ready to give me a job make me take a PHP test on
<http://www.123assess.com>

After the 10th question asking me to debug 30 lines of obfuscated code in my
head while a 3 minute countdown ticked away, I called it a day and decided
these were people I didn't want to work for.

------
robomartin
"A good engineer thinks abstractly in terms of designing and building systems,
they think in terms of algorithms, components, and engineering design. They do
not necessarily know all of the details of syntax of a given language"

Precisely. I'll take someone who can think this way before someone who can
rattle-off all of the minutiae about a particular language. I've run across
too many programmers who don't have a clue about project organization, MVC,
data representation, optimization, etc. Yet, they can pass minutiae-filled
tests about a particular language.

Unless you've been programming in a single language for an extended period of
time you will not have encyclopedic knowledge about that language and its
libraries.

Get 15 to 20 languages under your belt and the effect is more pronounced.

I know exactly what it takes to write a number of sort algorithms, genetic
solvers, neural networks, real-time embedded OS and more. No, I can't rattle
off exactly how to write it in the language of the day. When switching to a
language I haven't touched for a while it takes me two to four weeks to "task
switch". I surround myself with reference books, use the IDE and any available
online resource. Somewhere during that period I start to rock. I get the job
done and produce clean and efficient code, fast.

I would probably fail the kind of questioning the article describes. Yet I've
been solely responsible for large projects using languages spanning from
assembler to Forth, C, C++, Verilog, Lisp and, lately, Objective-C.

Bad programmer! No doughnut!

------
chimeracoder
The real problem is what knowledge the question is supposed to test - is it
testing whether you know the answer to the question, or is it testing
something else altogether?

Put another way, the problem is less the specificity of the questions and more
the ease with which you can expect to earn them.

I haven't used Swing/AWT in two years, and I couldn't really tell you what
inherits from what. But after a weekend of breaking through the rust, I'd get
back into it, so it's of no consequence to any potential employer.

However, some language-specific questions are very telling. For example:

    
    
        How many arguments does type() take in Python?[1]
    

If you answer '1' or 'either 1 or 3', that tells me two very different things
about you. The latter tells me that you may understand that Python uses
prototypical inheritance, rather than 'pure' class inheritance, and it tells
me that you may have done a non-trivial amount of Python metaprogramming
before. If you understand Python's inheritance structure in this way, you're a
much more valuable candidate to some companies than you are for simply knowing
syntax errors and interpreter-specific quirks... and the opposite may be true
at another company).

(Of course, it's possible that you know that and have simply forgotten, or
were confused by the phrasing, etc. - no question is perfect, but after enough
of these, you start to piece together a picture of the candidate).

The point is, the former question is something that you can reasonably learn
during a training period and which asks little more than face value. As for
the latter question - you all know that now, so you can also learn it during a
reasonable training period. But actually applying that knowledge (which comes
with the followup questions) is something that would require a significant
level of familiarity with the subject in question, which is what they are
really trying to get at.

[1]This may not be the best wording for the question, since it tips the
interviewee off to the trick beforehand, but I can imagine a way to present
this question so that it wouldn't.

~~~
nachtrabe
My standard approach to the "determining their depth" problem is to give them
a problem where detailed knowledge provides an obvious (or perhaps more
elegant) answer, but there are other possible answers.

For example, "how would you implement a least recently used cache in Java" can
provide a wide array of answers and tells me a lot about the person's
knowledge of the SDK and overall algorithm design. The details of their
solution and the ensuing discussion tells me a lot more, no matter what their
level, than whether they simply know that LinkedHashMap.removeEldestEntry
exists.

------
jussij
This is why as a 20 year veteran of Windows C/C++ programmer I no longer
bother applying for C/C++ software development contracts.

I really don't give a stuff that your Boost/STL trick question is missing a
semi colon, which in reality would result in pages and pages of false compiler
error messages.

I really don't want to try an second guess the compiler and tell you where the
missing semi colon should go.

I use the compiler to detect my mistakes. I read the compiler output error
messages, understand the message and fix my mistakes.

But I don't pretend to be a compiler. I'm a software developer. I use the
tools available to me to write software.

------
phamilton
I think it is important for questions to be within the scope of the resume. If
the applicant claims 20 years of Java only experience, throwing in a few of
those questions is just a sanity check for that claim, especially if that
claim is one of the reasons you are hiring them.

A sportswriter who claimed an expertise in basketball wouldn't feel it unfair
to be asked a few trivia questions in an interview. If he didn't know how may
winning seasons the Chicago Bulls had with Michael Jordan then maybe he isn't
as expert in basketball as he claims.

Where these questions are unfair is when the applicant is more of a
generalist. They have worked on very diverse projects in multiple paradigms
and multiple languages. Their skill lies not in knowing how to use their
tools, but in approaching new tools and quickly understanding how to use them.
If you are a Java shop and someone comes into the interview with little Java
experience then asking questions about Java specific type enforcement is going
to leave them a little flustered.

Cater the interview to the applicant, not necessarily to the position. Then
evaluate your understanding of the applicant with respect to the position and
see how well they fit.

------
burke
I'm coming at this from the perspective of someone with a pretty good memory
for things like this, but those particular "nano questions" seem pretty damn
fair to me. They're fundamental enough that it's not really relying on random
trivia; they're testing things that you need to know 90% of the time to write
a program, no?

~~~
kevingadd
You don't need to 'know' them because you can literally find them out in 500
milliseconds. There's no value whatsoever in memorizing it. It's a useless
factoid.

I use C# almost every day and if you quizzed me about what namespaces certain
types are in, I'd probably get it wrong. That's not because I haven't been
using it regularly for years (I have), it's because that shit isn't worth
wasting brain cells on.

Even worse, though, the modern programmer ends up using a lot of languages. I
have, in the past few years, had cause to write C#, Python, C++, C, Perl,
JavaScript, ActionScript, PHP, SQL, Lua, Objective C, and Ruby. All for work.
Each one has its own syntax, semantic quirks, standard library, etc. Out of
all of the important things for someone to understand about a language - why
would you care about something as unimportant as the exact namespace/package
path of a particular type? Does that matter? Would you rather know whether I
know the exact namespace Adobe's JSON parser lives in, or would you like to
find out whether I'm familiar with the ins and outs of the ActionScript
runtime?

Honestly, if you think the kind of minutiae this article mentions is a good
interview question, there's no way I'd want to work for you, because you don't
care about things that matter - culture, candidates' desire and ability to
learn, candidates' willingness to teach others, etc.

------
hef19898
Fully agree with this post, even not being a programmer 8I'm slowly asking
myself why anyway...) I'm not thrilled by the prospect of answering detail
questions out of my head. Things like, I already hated them back in
university. Nice to check if the candidat can remember the basics, but I'd
actually prefer a guy who can not only remeber them but actually use them in
context. Coming more from the classical engineering fields, you don't want a
guy who can write in norm script on hand written drawings, you want a guy who
can use Catia (or what ever) AND can actually design good, working parts. And
that actually has nothing to do with Catia skills. Nothing different to my
current field in Supply Chain Management, but there I'd strongly suggest using
some basic nano questions, sad as it is.

------
lrobb
On the list vs. set... This is an "easy" one if you just stick to the standard
CS def, or you just know a language that has a clearly defined library
offering that... But in PHP, there's technically _no difference_ between a
list and a set: _An array in PHP is actually an ordered map. A map is a type
that associates values to keys. This type is optimized for several different
uses; it can be treated as an array, list (vector), hash table (an
implementation of a map), dictionary, collection, stack, queue, and probably
more. As array values can be other arrays, trees and multidimensional arrays
are also possible._

~~~
icebraining
_But in PHP, there's technically no difference between a list and a set_

Sure there is. In a set, you can't have repeated values. PHP arrays can. Of
course, you can implement a set using a PHP array.

~~~
lrobb
I'm well aware of the difference between a set and a list.

My point, which was apparently lost, is that _the underlying implementation_
of these structures is the same in PHP.

------
parvinsingh
I wonder, how would someone interview a doctor. Asking him more of theoritical
questions ? Or asking him to do practicals, which I believe might be
completely off the books depending on the situtation :). Anyways, there are 1)
people who pass the interview very well, and cannot perform the duty on the
job. 2) people who do fair on the interview, but are very well executors of
the duty. 3) People who really become the backbone of the feature, and become
the go to guy for everything and anything, they may or may not perform at the
interview.

------
spiralpolitik
There seems to be trend toward ever increasing absurdity when it comes to
interviewing for Software Engineers. In fact some of the recent HN posting
about interview techniques are verging on being a parody of the Knights who
say Ni from Monty Python and the Holy Grail ("We want you to cut down the
largest tree in the forest...with a Herring !!").

As the post says find the Person who is the best fit for your team/company.
Everything else can and will be learned on the job if you get the right
candidate.

------
XcodeNoob
So an interviewer asked dumb questions, and sometimes they get my orders wrong
at McDonalds. NEXT.

------
IanDrake
I usually open with some nano questions. Sorry, but if you say you have 5
years of experience with C# but can't tell me which namespace List<T> or
Stream or SQLDataReader is in, then we're done, because you're lying.

~~~
henrikschroder
I have eight years of C# experience, and I don't really know. I think the
generic list is in System.Collections.Generic or something, but no clue on the
SQLDataReader. ADO something something?

I don't think I've ever written an import statement by hand, it really, really
isn't important to know.

~~~
IanDrake
And ya' know, that would be a fine answer, "I use resharper and haven't even
had to think about that in years". I would also accept "System.Collections" as
a reasonable answer. You should here some of the responses I get:

What's a namespace? Uhmmm, HashTable? I don't use collections.

Also, if they can't name some namespaces I'll usually ask them what classes
they're familiar with for accessing a database or opening a file. If you can't
name parts of the framework you use on a daily basis by namespace of class
name, you're not going to be a very _productive_ programmer.

If knowing this stuff isn't important, than I'm an expert Java programmer too.
I just can't name any of the packages or classes, but I can tell you all about
inheritance.

~~~
henrikschroder
Fair enough. :)

------
blahblahhhhhh
Great post. I felt the same way recently in a few interviews.

------
jebblue
Excellent article, totally relevant, thanks.

------
funkah
> Basically: Any question that takes 5 seconds to answer with Google is not a
> good question.

Can't argue there. I haven't done a ton of interviewing in my career so far,
but it is important to me to find out how the other person thinks. Being able
to cite function names and package identifiers from rote is not important, at
all.

~~~
Turing_Machine
From another POV, I would argue that being able to use Google-searchable
resources effectively is a very important skill that should be explored more
thoroughly in the modern interview process. The examples and code snippets
available on the web (e.g., Stack Overflow) can save hours and hours of time
(= money), particularly when the official documentation is crappy.

Coupled with that, maybe some questions would be in order about how and when
you're legally allowed to use the stuff you find using Google (MIT license?
GPL? Creative Commons? How do I have to attribute this stuff? Do I have to
release the source?).

------
ExpiredLink
I guess it's hopeless.

