
Cargo Cults and Interview Questions - raganwald
http://raganwald.posterous.com/bob-and-carol-and-ted-and-alice
======
adrianhoward
This fable reminded me of my favourite, unfortunately all to real, cargo cult
experience.

I gave a client's boss a copy of DeMarco & Lister's "Peopleware" to read. I
was younger and more innocent at the time and thought it would persuade him to
change some of his incredibly damaging management practices. He'd produced an
incredibly adversarial fear-based working environment that was killing
productivity.

For those who've read the book (and if you haven't you should... now...
seriously....) this guy was the poster-boy for the Teamicide chapter.

He came back to me after the weekend telling me how much he _loved_ the book.
Could really see how it could help the organisation. Would be making changes
this week. I walked away feeling smug.

What was the lesson he drew from the book? Of all the lessons that he could
learn?

In one chapter there is a brief section on how to spot jelled teams where they
mention signs like going out for a drink together after work.

So he decided to take the company bowling on Friday nights.

Attendance compulsory.

Correlation. Causation. So easy to confuse.

(At this point I'm less smug.)

Let us say the result of mandating adversarial teams working fifty hours weeks
socialise around a competitive game where alcohol was available was not ideal.
During week 1 there was shouting. Week 2 resulted in a fight. There wasn't a
week 3.

On the bright side it was the final straw the caused some folk to resign :-)

~~~
jbrains
Did this manager spot the causation between compulsory bowling and folks
resigning?

~~~
MartinCron
It sounds like the manager would see the causation between _bowling_ and
resigning and just force a different compulsory activity.

~~~
dunmalg
He hates these cans! Stay away from the cans!

<http://www.imdb.com/title/tt0079367/quotes?qt0271097>

------
dclowd9901
As someone sitting idly in a rather crowded Sunnyvale hotel lobby awaiting my
own interview, I'm prepared for a Bob, but I'm afraid I'll get a Ted.

I'm not a formally schooled developer. I don't know a heap about traditional
computer science. I don't know all the sorting algorithms off hand (but could
throw one together with a little time and reference). I'm not even fluent in
all the jargon, vernacular and glossary terms that devs bat around.

I don't know if I'm the best for this job, but I know only 3 short years ago,
I was doing graphic design and 3 years before that, I was trying to make good
on my degree (and dream) of journalism.

None of us choose how we learn, but I think the best of us just know _how_ to.

~~~
srdev
I don't know how it is with most interviewers, but for interviews that I do:
If you don't know a term, just ask. I'm more interested in whether you're
familiar with the concept and can apply it than whether you know the
appropriate term. Chances are that you're familiar with the concept already
and are just not familiar with the name.

If you're in the interview room, I'm not so concerned about book learning and
knowing facts, but whether you have the correct amount of knowledge to do the
job and the ability to apply it.

~~~
robyn
The best piece of technical interview advice I've ever gotten: It's much more
impressive to NOT know something, ask about it, and then be able to understand
it and apply it to your answer during the course of the interview, than it is
to just already know it.

~~~
daleharvey
agreed, a few weeks ago I was interviewing and the interviewer schooled me on
python generators and cooperative threading (pretty much all my knowledge is
around erlang and message passing / explicit threading)

I got the job, and learned something along the way

------
ryanmolden
Perhaps my terminology is off, but as a minor nitpicking point I have never
heard of this type of constructor refered to as a copy constructor. A copy
constructor is a constructor for type Tthat takes an existing T and
initializes the new T to have the same underlying state. So something like

    
    
      class Foo
      {
      public:
        Foo(const Foo& other) 
        {
          //copy state from other Foo here  
        }
      };
    

What this example is talking about is a normal constructor that can be
(perhaps unintentionaly) used in the context of an implicit conversion, so
something like

    
    
      class Foo
      {
      public:
        Foo(int heyThere)
        {
        }
      };
    

This allows the C++ compiler to create an automatic conversion (in some
instances) from int -> Foo simply by inserting a call to this constructor. So
it can cause code like this to compile even if it was not intended

    
    
      void HandleTheFoo(const Foo& theFoo)
      {
        //Do something here
      }
    
      void SomeMethod()
      {
        Foo intended; //assume there is a default ctor available even though I didn't show it above
    
        int whoops = 5;
    
        HandleTheFoo(whoops);
      }
    

Marking the constructor explicit prevents the compiler from using it in an
implicit conversion context.

~~~
raganwald
I’ve heard it that implicit conversion is a specialization of copy
construction. So you can still use explicit Foo (const Foo& other) if you wish
to force all construction of Foos to use the new keyword and not to be passed
by value. But I’m certainly willing to accept the suggestion that the two are
distinct, in which case my understanding is that the explicit keyword blocks
implicit conversion (as described in the story and in your example) and I
understand that it also blocks implicit copy construction.

~~~
ryanmolden
Ah, that makes sense. Though technically you don't have to use the new keyword
unless you want a heap allocated instance, something like

    
    
      HandleTheFoo(Foo(5));
    

or even

    
    
      HandleTheFoo(Foo(otherFoo));
    

is perfectly cromulent with the constructor being marked explicit. But that is
just me engaging in terminological quibbling, I get what you meant/said in
spirit and don't disagree that people asking questions they don't have a deep
understanding of themselves can only lead to fail.

~~~
raganwald
Thanks for the kind words. And the reminder about stack variables!!!

I wasn’t trying to suggest that Ted didn’t have deep knowledge of C++, as we
can see his fictional knowledge is far better than my distant memories. I was
trying to suggest that he was engaging in copy-and-paste interviewing, and
that it’s a bad idea for all of the same reasons copy-and-paste coding is a
bad idea :-)

------
nextstep
So we're doing this thread again? Stock interview questions don't test real
knowledge, they test knowledge of stock interview questions.

In my experience, the most accurate interview processes is to ask a candidate
to solve a short (but non-trivial) problem in the language of their choosing
(or pseudocode). Ideally, candidates could be interviewed by a few people
independently to ensure an accurate sample of that interviewee's knowledge.
This isn't always possible (due to time and other constraints) but this
process better guarantees that a smart candidate isn't tripped up by a very
unusual question, or that a weak candidate doesn't memorize common interview
answers.

~~~
slurgfest
Surely the most accurate would be to ask them to solve a problem closely tied
to the sort of job they will be doing (doing variations on FizzBuzz under time
pressure does give information, but that information may not be entirely
relevant to the job).

And the objective should be to establish a level of capability which is
acceptable for business purposes, not to try to optimize on intelligence.

Be truthful with yourself about whether you really want the smartest guy
possible. The smartest guy sees the boss's (or company's) bullshit and is more
likely to say something about it. This makes trouble. The smartest guy may be
a "bipolar" type. The smartest guy, with the mind that needs meat to chew, is
more liable to implement things in a clever way than one which average joes
will be able to maintain and extend easily. You probably don't want the
smartest guy because he probably isn't as good on some other dimensions.

What I see in this industry is that we project intelligence onto the people
with traits which satisfy our prejudices (typically people with high
class/status). Then we filter on this perceived-intelligence with the
rationale that we want a company with people who are as smart as possible. The
actual effect is at least as much to favor people with high social status and
self-promotion ability and physical attractiveness as it is to favor smart
people.

Hiring processes are irrational not because nobody can ever work out the right
processes, but because we work backwards from unexamined pictures of "the
right candidate" to the processes which will select that candidate.

~~~
lusr
This is pretty much what I've always done - describe the sort of problems
they're likely to encounter in the role they're being hired for, perhaps
mentioning a few challenges we've had (and possibly already solved), and ask
them to explain how they would solve the problem. It's pretty difficult to
bullshit your way out of answering a real problem.

Other than adding in some rudimentary skills tests (say, FizzBuzz +
walkthrough writing the code with them), and checking if they've developed
anything out of their own initiative, I can't see why you'd bother asking
anything else.

~~~
sanderjd
I really like the theory of this, but in practice I have a hell of a hard time
figuring out "real problems" for which the explanation and solution would
occupy less than an afternoon.

------
xsmasher
Spot on. Asking questions about esoterica (defined as any language feature
that's >0 levels above their current level of knowledge!) is useless.

I'd rather get a candidate to write some (relatively simple) code using what
they _do_ know about the language, and then we can dive into the code and see
if they really understand what it does, and what happens if I poke this or
prod that. I don't even care what language they use - although if they pick
one I don't know it may be _harder_ for them because I'm going to ask pointed
questions about how parameters and equality work in that language.

The interview "question" is just a starting point for a conversation. Trick
questions and minutia don't serve that purpose at all.

~~~
DannoHung
I don't think esoterica is entirely useless in an interviewing context. I've
interviewed a few people for language centric positions before and one thing I
liked to ask was, "What feature or piece of this language do you find
interesting or frustrating?" Someone who's worked a lot with a particular
technology is bound to have something meaningful to say. I suppose they could
just not be particularly thoughtful about their tools, but I like working with
thoughtful people.

~~~
dalke
I've found that I don't think about languages that way. I think of things more
like "I want to achieve goal X; what are the interesting or frustrating
aspects with respect to that goal?"

For example, someone asked me once about the warts in Python. I started
thinking about complaints I've heard others say, like Python 2.x's "print
>>fileobj" syntax. I understand the reasons for and against it, but I nearly
only use print statements for debugging, so it's not one that I want to bring
up. Or there's the lack of block syntax, which Smalltalk/Ruby developers love,
but Python has different ways to handle most of the underlying requirements.

So there I'm thinking about the different aspect of Python, trying to figure
out which ones I want to bring up, but I hadn't fully considered the other
issues with the language, in order to figure out which is the most relevant,
but then, I don't know how to rank the relevancy because the question was
structured without any rank preference.

Now if you had asked "... when used for systems programming ..." or "... as a
programming language for scientists ..." or "... compared with Perl ..." then
I would find it much easier to give the thoughtful answer you're looking for.

I had the same problem a couple of years back at our monthly Python meetings.
We did a code refactoring exercise: given code, make it better. I had a really
tough time because I couldn't figure out what "better" meant. The exercise
code worked, although it mixed business logic, database interface, and
presentation into a single file. But without an idea of the direction the code
was supposed to go for the future, I couldn't figure out why anyone would want
to modify working code.

~~~
DannoHung
Okay, so you go on my no-hire list because you paralyze yourself with
questions :P

~~~
dalke
That's okay - I've been a self-employed consultant for 15 years, since that
way I can ask people "what's your goal?" and get away with it. ;)

------
geebee
This was an interesting story. Sounds like an astute interviewer, the kind who
can really get at the core of technical knowledge. And of course, people have
every right to set whatever standard they like in their hiring.

But every time I read about someone like Alice, it does cause me to reflect on
the "hiring troubles" companies are experiencing, the "shortage" of top
candidates.

She has contributed to open source, shown the ability to learn and write small
apps in new languages. She can code, definitely, but she shows some
weakness... NO HIRE. Not only no hire, she's a faker, a cargo cult-er, she
"pulled the wool over your eyes." She's not just unqualified (by high
standards, in my opinion), she's _insincere_.

Please, understand that I'm not saying that hiring standards shouldn't be
high, or that weak team members don't do more damage than good. I get all
these things. But the bar is high enough that it should be utterly
unsurprising that there's a shortage of "qualified" people, and that a lot of
people (who might have become good programmers) bail out, get forced out, or
want nothing to do with it after their first taste.

I'm ok with these high standards, but I think we celebrate it a little too
much.

EDIT: raganwald, jbooth, peter...

thanks for replying rather than just downmodding - unfortunately (for me),
yeah, you're right, I misread this.

I'd like to take it down, but once someone has responded, I leave it up with
an EDIT...

~~~
raganwald
I may have done a poor job of conveying why the story is related to Cargo Cult
religions.

 _The term cargo cult programmer may also apply when an unskilled or novice
computer programmer (or one not experienced with the problem at hand) copies
some program code from one place and pastes it into another place, with little
or no understanding of how the code works, or whether it is required in its
new position._

<https://en.wikipedia.org/wiki/Cargo_cult_programming>

I don’t know if this term can be applied to Alice, but I am pretty certain
that the story describes Ted blindly copying the surface form of something Bob
did in an interview with Carol into Ted’s interview with Alice with little or
no understanding of how Bob's conversation worked, or whether it was required
in Ted’s conversation with Alice.

~~~
Alex3917
The message was clear, some people just see what they want to though.

------
msg
I agree with the story. To interview, you don't turn little details into big
questions. You turn big questions into little details.

Interviews are lossy compression of a career, experience, and brain shape,
over a noisy channel of whiteboards and human speech. The best you can hope is
that your interviewer will recognize the larger pattern.

BUT. There is limited time in an interview, so we try to scry nuances like a
soothsayer with a pile of sheep guts. Every detail gets magnified.

Examples:

"You chose to return an error code instead of throwing an exception." Is this
an optimization, or have you spent a lot of time on system programming?

"I see a couple of fenceposting errors." Is it nerves or do you not have the
right shape of the problem in your head?

"You passed some bookkeeping information in a recursive call that should take
care of itself." Do you not understand recursion, or are you misremembering
something cool about accumulators and tail recursion?

"You chose to use inheritance instead of composition." Have you ever had to
extend or maintain such a design, or did you read about it in a book?

"You used template metaprogramming." Are you a misunderstood genius or do you
delight in writing unmaintainable constructs from the dark corners of C++ into
production?

"You chose to use Perl but don't know what a hash is." Do you have any
questions for me?

~~~
ben1040
>"You chose to use Perl but don't know what a hash is." Do you have any
questions for me?

This reminds me of someone who once told me they knew C and were proficient at
it, but they just "didn't get pointers and I don't use them."

~~~
JoeAltmaier
Scoff if you like, but I hired that guy. He's a fellow at Adobe now. They
bought his startup.

We interviewed a Busuness school Finance senior to help on our COMSTOCK
satellite feed parsing project.'Do you know C++?" we asked. "Yes" he lied,
then "Can I come in over the weekend to get started?" How enthusiastic! Sure!

Turns out he spent the weekend studying code, learned to program C++. I didn't
see him for a few weeks, then consulting on his code over something I
mentioned "This would be better allocated". "Yeah, I wondered what the pointer
stuff was about". I was astonished he'd come so far on guts and smarts. I
explained malloc, pointers, he was off again.

~~~
DavidWoof
Put another way, you had (have?) astonishingly poor interview techniques but
this one time you got lucky?

~~~
JoeAltmaier
You could pretend that. Or you could say, we valued his intelligence and
readily-apparent ability to learn over 'fizz-buzz' nonsense questions and
cargo-cult interview style.

------
romey
How do you strike a fair balance between ridiculous interview questions (such
as the example here, write code interfacing with some library from memory) and
actually finding out a candidate's chops (assuming they don't have an open
source history / github account). I think requiring candidates to have
contributed to open source to be an unacceptable solution (although I can
certainly see lending some weight to candidates with such credentials)

Anecdotally: We had a guy in for interviews a few months ago. In the phone
interview prep by HR, it was mentioned that there would be some written
“tests,” and the guy was extremely resistant. We had him in anyway and he did
very poorly. The test was pretty simple: some stuff about magic methods in
php, a fizzbuzz type question, and a few jquery selector questions (it was for
a front- and back-end position), etc. Were we to granular with the questions?
Did we fall into the same trap as Ted here?

~~~
bithive123
Simple tests (what is this jquery doing? why is this ruby script failing?) are
great as bogofilters as long as you actually use jquery and ruby on the job.

I interviewed somewhere a few months ago and had a former programmer turned
product manager grill me about b-trees (this was a Ruby on Rails position). I
was not surprised to hear later that he was the one who gave me the final
thumbs-down, I assume he thought I wasn't worth it because I didn't work at
the same level of abstraction that he did when he was a coder.

~~~
spitfire
He was seeing if you had a depth of understanding. I do that too.

I want to see that people are aware of what's going on below them. Not that
it's just "magic" to some keyboard basher. ruby on rails attracts an extreme
number of keyboard bashers, so they get extra scrutiny.

~~~
scarmig
That's very different from grilling someone about b-trees, though. B-trees are
fairly irrelevant to Rails development; it'd be like grilling the interviewee
on assembly.

That's not to say that you don't need to weed out the people who only know how
to recite various incantations to make magic happen; a knowledge of what's
actually happening is very important. But at this level of abstraction, the
correct focus should be on different, more relevant things: HTTP, caching,
security, etc, which Rails (I'm guessing) handles for you but you should still
know.

------
option_greek
Not really related but I wonder about this all the time. Most of well known
companies (Microsoft, Amazon, Yahoo, Google, Facebook etc) have a lot of data
structures and sorting algorithm related problems as part of their interviews.
They might require you to explain the algorithm or write code for a given data
structure problem. Do these companies use data structures like binary trees
(with all the variations) and sorting algorithms a lot ?

I'm asking this because, the companies I work for are mostly tier-2 companies
which hardly use any of this stuff and generally get away by using proper
libraries. So when ever I have to prepare for attending interviews of the
tier-1 companies, I'm forced to re-learn most of this stuff - because
knowledge fades when you don't use it.

~~~
potatolicious
I used to work for Amazon, and used to interview a _lot_ while I was there.

The answer is: it varies, but generally no. There are some roles where you're
going to be spinning mad data structures & algorithms day in and day out...
but for the most part you write code that isn't overly dissimilar from what's
written everywhere else.

This is my own observation and hypothesis: "tier 1" companies have very
algorithm and data structures heavy interviews because their signal to noise
ratio is _horrific_. Being household names, you have _tons_ of people applying
who can't even Fizzbuzz. In this environment the natural reaction is to check,
first and foremost, for CS fundamentals, because you can't assume that it
exists and is just rusty.

I now work in startup-land, where hiring is _so_ much easier, since people who
find their way to your doorstep are overall much more qualified by default.

I'll admit, when I interviewed for Amazon, I _always_ hit with algorithms and
data structures questions first, because by my own unscientific estimates, at
least 50% of applicants at the phone interview stage do not even understand
what a tree is, much less how they might go about crawling one or representing
it in data. I'd reckon about 10-15% cannot pass Fizzbuzz.

------
glenntzke
No decent company should allow a single interviewer to shut down a candidate.
I am a regular interviewer (phone and in-person) and I've got a few pet
problems that I throw at all candidates who pass the simple introduction. I
would never can someone on and 1 type of question, but I think it's fair to
say that missing 2 or more conceptual questions will pretty much end the
interview for me. That's why we have at least 2 2-person teams interview in-
house -- if they passed the phone screen and make it in our doors they deserve
it.

------
kenrikm
Great example and a great follow up to "I don't hire unlucky people" As always
a pleasure to read your blog.

------
strlen
I entirely agree with raganwald's point point: language trivia is useless. I'd
go further and say if someone knows actually knows C, and has a grasp of using
OO in a way that's not painful for others working with them (prefer
composition over inheritance, etc...), they can learn C++ on the job. If they
know all C++ trivia, but lack a strong knowledge of either C, or good OO, they
can do harm to a code base.

However, this isn't to distract from importance of using explicit and copy
assignment. Here's a public service announcement: really, if your C++ class
has a constructor that takes one argument, _please_ use explicit.

Additionally, please disable copy constructor and assignment operator, unless
you actually implement them yourself. Here's a free macro for you, courtesy of
Google's C++ style guide:

    
    
      #define DISALLOW_COPY_AND_ASSIGN(TypeName) \
        TypeName(const TypeName&);               \
        void operator=(const TypeName&)
    
      class MyClass {
    
      private:
        DISALLOW_COPY_AND_ASSIGN(MyClass);
      };
    
    

I will thank you for this.

~~~
SomeCallMeTim
I doubt anyone knows _all_ C++ trivia, and that if someone even knew most of
it, they could be that clueless about OO design.

I work on libraries more than apps. When I want to hire someone to work with
me on libraries, you better believe I'm going to look for a C++ expert. And
the explicit keyword is crucial in a lot of cases -- sometimes it can mean the
difference between code compiling or not, but even worse is the bug where a
parameter is missing and an int is converted to be some class it shouldn't be.

Using existing libraries and just assembling bits into apps? Sure, learning on
the job can be OK (though honestly I wouldn't trust C++ written by anyone
using it for less than a year full time). Though _even then_ if you don't
understand C++ well you're likely to shoot yourself in the foot with the
language.

But there are some times that I really, really want someone to know the
explicit keyword, at a minimum. Your example of DISALLOW_COPY_AND_ASSIGN is
also good to know -- and it's likely in the Google style guide so that people
don't have to be experts.

But I'd rather have people _know_ why it's important and how it works than
people who are just trusting to the compiler and luck to make everything work
right.

I've seen C programmers clear a class that contained a std::string with
memset(&foo,0,sizeof(foo)), which happened to work on one implementation but
failed badly on another. I've seen people take the raw pointer out of a smart
pointer and attempt to manage it themselves -- including trying to wrap
ANOTHER smart pointer container around it later. I've seen people fight with a
bug for weeks because they didn't bother to initialize all their class members
(fixed that bug in about 10 minutes on code I'd never seen before).

The list goes on, and the list of "coding standards" we created to try to
enable people who weren't good enough at C++ to work effectively with our C++
library got to be so large that no one could remember it all, rendering it
useless. [1]

So yes, if I'm going to have someone work on C++ for me, I either want them to
have _at least_ a solid year of real experience, or I'm going to want to code
review every line before it gets committed to main. Maybe I'll still hire
them, but I've seen _so_ many examples of people misusing C++ (and then having
to fix their bugs later) that I've been more than a little burned by it.

Even more esoteric than _explicit_ is the _mutable_ keyword. Major bonus
points for anyone I'm interviewing to know what that one means and when it's
used. But no major negative if they don't know -- it has very few compelling
use cases, after all, so I can imagine people not remembering it.

[1] <https://developer.playfirst.com/standards>

~~~
kragen
Huh, your comment makes me wonder if I should look for contract work doing C++
development. I haven't done it seriously since the last millennium, and
basically I've learned to program since then [0], but I know all the stuff
you're talking about cold. (Except _mutable_ , which took me a few seconds to
remember, and then I looked it up to be sure.)

It's just that I feel like higher-level languages like Ruby, Python, or JS are
so much more productive for most things, most of the time, despite things like
Rachelbythebay's interesting set of posts about hacking together stuff in C++
[1].

But, aside from things like that, I guess there are some domains where C++ is
a viable option and Lua or whatever still isn't. And it sounds to me like the
average quality of C++ has gone up since I was doing it, to the point that
most people have read Alexandrescu and never call delete explicitly, so it
might not be quite so painful?

Should I be taking advantage of being one of the Fat Guys Who Know C++? [2]

[0]: [http://lists.canonical.org/pipermail/kragen-
tol/2007-March/0...](http://lists.canonical.org/pipermail/kragen-
tol/2007-March/000849.html) [1]:
<http://rachelbythebay.com/w/2012/01/14/blort/> [2]:
[http://medriscoll.com/post/9117396231/the-guild-of-
silicon-v...](http://medriscoll.com/post/9117396231/the-guild-of-silicon-
valley)

~~~
SomeCallMeTim
Great links. I've certainly made a habit of hanging out with those Fat Guys,
though at this point I'm in Boulder, so while they still have neck beards
here, they tend to be pretty thin. Though honestly we stopped playing Settlers
years ago, and have moved on to games like San Juan and Dominion. ;)

To tell the truth, I have a love/hate relationship with C++. Yes, I know it
really well at this point. I've learned everything I know because it (at the
time) was the only tool reasonable to get the job done. Now I actually avoid
using it as much as possible.

The perfect combo for me (in games) is C++ for performant code combined with
tight integration with Lua. I hear you on higher-level languages being more
productive, which is why most of my game code ends up written in Lua. (I'm far
from alone in using this combo -- most major iOS games seem to use the same
combo, as do a lot of games in general.)

Why not use one of the three you mentioned? Size and speed both.

LuaJIT is pretty much the fastest dynamic language around, and the overhead of
linking into a program is _tiny_ compared to Ruby, Python, or JavaScript. The
language itself gives you advanced features like coroutines with upvalues and
operator overrides, but at the same time it's super-simple -- to the point
where non-programmers _can_ use it to script behaviors.

If you're doing server code you can afford to have things be a bit slower
and/or huge (relatively speaking). If you're doing games downloaded OTA on a
phone, and you've got a 20Mb limit before they have to use WiFi...well, size
is critical (an extra megabyte or two means a lot of assets won't fit any
more) and phones are far more processor-bound than most server tasks you'd use
a scripting language for. On the other hand, with distributions like OpenResty
[1] that hand you an extremely fast server and LuaJIT all bound up together,
allowing me to create a cheap server that can handle 3000+ requests per second
without barely breaking a sweat...well, since I know Lua ANYWAY, I use it on
the server as well.

YMMV. :)

Addressing what you asked: C++ development is in reasonably high demand
compared to the number of Fat Guys, so it tends to pay well. Having experience
in a niche can also be handy -- by virtue of knowing Android C++/NDK
development I've had random people contacting me to ask if I want to work for
them, with no real promotion on my part. I don't even want to say what my rate
was publicly, though I will say that I expected him to turn me down when I
said how much I wanted.

~~~
kragen
Android C++/NDK by itself counts as a niche? That's kind of surprising! I
would have thought a profitable niche would have to be a bit more specialized
by now... I guess the NDK hasn't been out all that long.

I imagine gzipped Lua bytecode would be quite a bit more compact than gzipped
compiled C++; does it work out that way in real life?

Does OpenResty work well with LuaJIT?

[1]: <http://openresty.org/>

~~~
SomeCallMeTim
OpenResty ships with LuaJIT 2.0 beta. You have to add a ./configure parameter
to get it to use it, but it works well, yes.

As to bytecode...I think it probably does end up more compact than compiled
C++, and it seems like it would have properties that would allow it to
compress more tightly, but I don't have any numbers on that.

I tend to strip the source and compress and encrypt it; I could convert it to
bytecode first, but the last time I tried that it ended up bigger than the
compressed text.

>Android C++/NDK by itself counts as a niche? That's kind of surprising! I
would have thought a profitable niche would have to be a bit more specialized
by now... I guess the NDK hasn't been out all that long.

A lot of "Android" developers are actually Java developers who are trying to
cash in on mobile. Serious game developers almost all use the NDK, but serious
game developers are in high demand (myself included). So yes, NDK is itself a
niche, in that the number of jobs seems to exceed the number of developers
available.

On the other hand, by being able to do games in NDK I'm even better off, but
just being good at NDK development is pretty powerful. Keep in mind that you
also have to deal with Java and the Android stack -- you can't do everything
in the NDK. So you need to be someone good at C++ who also can get around in
Java.

~~~
kragen
That's really fascinating information, thanks! Who's a "serious game
developer"? I'd think that things like Angry Birds and Bubble Bobble would
work just about as well in Jython as in C++, but I guess they're not
"serious"?

~~~
SomeCallMeTim
Angry Birds uses C++ and Lua. Haven't looked at Bubble Bobble.

Not saying you COULDN'T write games in other languages. MineCraft is written
in Java, for instance. But my statement still predominantly holds true: Most
serious game developers use C++, and many use Lua.

For some definitions of serious, anyway. I guess I mean "ones that have been
doing it for any length of time professionally." Or maybe I just mean "almost
every one I know." Something like that anyway.

------
eshvk
Some perennial favorite "interview questions" of mine:

1\. Tell me the difference between final, finally and finalize in Java. (Of
course it was completely irrelevant to the discussion that my resume at that
time never claimed that I knew Java; The only mention of Java was a library
that I had used as a black box)

2\. This is a fairly new one but most software engineers must have seen
equivalents over the years :).

Rate yourself on a scale of 1-10 on the following:

\-- Machine Learning

\-- Convex Optimization

\-- Linear Algebra

You know what was really disappointing? The second question was asked to me
first by the recruiter (whom I don't blame for asking me the question) and
then again by an engineer (after we had just concluded a long discussion on my
projects touching upon those topics).

------
jchonphoenix
I generally believe interview questions aren't a terrible way to screen
people. There are, however, stupid questions and good ones. Ones that test how
people think or how good they are at designing/accomplishing tasks are good.
Ones that test stupid syntactic knowledge or language specific things are
dumb.

------
minikomi
How about.. The interviewee gets to know what languages, libraries, components
of the stack you are using a week in advance. They then can implement whatever
they like using those technologies. Then, they present what they made to a
technical member who can ask them questions which would show they have
developed familiarity with at least some parts of what they use. The more
specific the position, the more in depth the questions.. The interviewee can
also ask questions back to the interviewer from a more level position.

~~~
lawnchair_larry
In this field, this will probably get you lower quality applicants or kids
right out of school. High quality applicants have recruiters banging down
their doors, and there are always several other options on the table that
won't waste a week of their time.

------
noduerme
The point, as always, is that intelligent people find other intelligent people
to hire by asking questions that aren't uniform or one-size-fits-all, or which
only require regurgitation of facts, but rather by probing how and why a
candidate thinks a certain way.

This should be obvious by now. Standard CV reviews, colleges and references
say nothing about how efficiently a candidate is able to think through new
problems or how elegant their solutions will be. Nor does that mean that
formal training and real-world skill exist in an inverse relationship as a lot
of self-taught coders (myself included) like to pretend it does. They simply
aren't co-related, at least not as far as we can tell from most leading posts
about hiring on HN.

So if the goal is efficiency, why not just hire people based on their IQ? What
else is there that qualifies people for positions where their bosses 2 levels
up have no idea how they're actually executing the work that's put in front of
them, and rely completely on them to come to the best logical solutions to new
problems creatively, quickly and every single time? The only other standard
you might want to look for is trustworthiness, but you can't measure that in
an interview.

Anyway, it doesn't matter if someone with 140+ IQ has ever coded before. It's
probably worth paying to train them. So let's just cut to the chase. You need
people with brains and integrity, and the rest of it is just huff and puff
nonsense from HR people who don't have a clue, and couldn't do the job their
hirees do.

~~~
npc
firstly, there's legal issues with IQ tests in job interviews in the US at
least

secondly, IQ testing covers a number of areas, many of which are not
necessarily related to the kind of thinking needed for programming. i think
most of the verbal stuff in IQ tests wouldn't relate that much

thirdly, even if someone aces the IQ test, there's still no indication that
they would actually enjoy programming if they've never done it before. It's
kind of pointless to train someone to code if they're just going to get sick
of it and quit in 6 months.

and fourth, an IQ test doesn't say anything about a person's ability to work
with other people or prioritize things properly. an IQ test provides no
protection against ending up with a prima donna who obsesses over brace style
at the expense of getting useful things done.

really, i think the best way to find out if someone can code is to look at
something they've coded

~~~
noduerme
Is it actually illegal to hire in the US based on IQ? I mean how is that
discriminatory more than any other test for employment? Race, religion,
political affiliation, disability are obviously all irrelevant in an IQ
test... so in a way, isn't it more equitable?

You make a good point about primadonnas and other potentially toxic
personality types with high IQs, but you can screen that too. And I mean, I
don't care about IQ. To me, pretty much anybody with talent should be able to
come in with something awesome and say "look what I did", and if it's great,
then who cares? Hire them. Obviously this isn't an argument for creating a new
narrow-minded structure to replace the current one; I'm just talking about
prioritizing along the essential lines instead of dancing around the real
question. Isn't someone who codes and who can give you a fibonacci sequence in
realtime more valuable than someone who codes, but can't? I can't do it, but
I'd hire that guy.

~~~
burgerbrain
Interestingly, rejecting candidates because they score _too well_ on IQ tests
seems to be totally kosher in the US.

Who would do such a thing? Cops.

~~~
starwed
Give me a source for that which would allow for corroboration.

Because pretty much everything I can find on it has the whiff of urban legend,
which folk like you repeat because it feed into their worldview.

~~~
burgerbrain
_"Some US police departments have set a maximum IQ score for new officers (for
example: 125, in New London, CT), under the argument that those with overly-
high IQs will become bored and exhibit high turnover in the job. This policy
has been challenged as discriminatory, but upheld by at least one US District
court. "_

<http://en.wikipedia.org/wiki/Intelligence_quotient>

If there are factual inaccuracies there, please point them out. However just
going by the "whiff" of something seems like you're opening _yourself_ up to
rejecting parts of reality that do not fit _your_ worldview.

Edit: better source: <http://www.aele.org/apa/jordan-newlondon.html> and here
is an interview of the man by CNN:
[http://www.postroad.com/news/2000/20000912-new-london-
police...](http://www.postroad.com/news/2000/20000912-new-london-police-
robert-jordan.html)

------
Zaheer
Hey everyone, I just created a new service that sends you a new technical
interview question every other day! Check it out at: www.InterTechTion.com

