
The Mother of All Interview Questions - raganwald
http://raganwald.posterous.com/the-mother-of-all-interview-questions
======
llimllib
> Does your process involve invention? If so, please describe the three most
> recent things you have invented and why it was necessary to invent something
> new.

If you're asked this in an interview, you can't respond "no". If I were being
interviewed, I'd hear it as somewhat like "Do you like unicorns, which are
awesome? If so, describe your three favorite awesome activities with
unicorns."

Which is fine, if you're on one of the teams that likes to innovate, but I'd
just suggest that there's probably a more neutral phrasing that might allow a
candidate to respond "I prefer to use existing solutions to problems, and
here's why". Maybe:

> The last three times you faced a "build or buy (/use open source)"
> situation, which did you choose, and why?

Which may give you a better grasp of how the employee understands the
economics of the situation, rather than just asking him to talk about the last
three times he chose "build" given that choice.

~~~
raganwald
The question of bias is an excellent one to ponder. I agree that my phrasing
is biased, but so is:

    
    
      The last three times you faced a "build or buy (/use open source)”
      situation, which did you choose, and why?
    

...in a way, as it only covers places where there is a perception that there
was a straight-up choice.

One of the things I am interested in is places where the invetion-oriented
folks didn’t perceive there was a buy/borrow option, because they had bought
into a requirement that seemed to necessitate invention.

~~~
ChuckMcM
When I was at Google I wished they had a few 'uncoders', people who made it
their goal in life to leave the source tree with fewer lines of source than
they found it.

True story: I went to a talk given by one of the 'engineering elders' (these
were low Emp# engineers who were considered quite successful and were to be
emulated by the workers :-) This person stated when they came to work at
Google they were given the XYZ system to work on (sadly I'm prevented from
disclosing the actual system). They remarked how they spent a couple of days
looking over the system which was complicated and creaky, they couldn't figure
it out so _they wrote a new system._ Yup, and they committed that. This person
is a _coding God_ are they not? (sarcasm) I asked what happened to the old
system (I knew but was interested on their perspective) and they said it was
still around because a few things still used it, but (quite proudly) _nearly
everything else_ had moved to their new system.

So if you were reading carefully, this person created a new system to
'replace' an existing system which they didn't understand and got _nearly
everyone_ to move to the new system. That made them uber because they got
something big to put on their internal resume, and a whole crapload of folks
had to write new code to adapt from the old system to this new system, which
imperfectly recreated the old system (remember they didn't understand the
original), such that those parts of the system that relied on the more obscure
bits had yet to be converted (because nobody undersood either the dependent
code or the old system apparently).

Was this person smart? Blindingly brilliant according to some of their peers.
Did they get things done? Hell yes, they wrote the replacement for the XYZ
system from scratch! One person? Can you imagine? Would I hire them? Not
unless they were the last qualified person in my pool and I was out of time.

That anecdote encapsulates the dangerous side of smart people who get things
done. Sometimes they are too smart and do too much. So when the question of
'invention' comes up I like to wrap it around discovery. Sort of 'Tell me
about a time where you built something that you had no idea how to build it
when you started.' Things I look for are how did you go about discovering the
path? What resources did you engage? What options did you consider? When did
you 'call the vote'[1] ? My experience has been that things built by two or
three people, working as peers, are often much 'better' (meet the needs
better, cover more cases, have a more consistent model) than things built by
one person.

[1] 'call the vote' - in parlimentary terms when continuing debate will not
help you make a better decision, it is time to stop debate and to vote on the
decsion. Good leaders look for this point, and move forward once all the
voices have been heard.

~~~
tmp43522
I hate to depart from the group think, but there's another explanation aside
from a smart engineer getting carried away with their own brilliance:

    
    
        They remarked how they spent a couple of days looking over the system which was complicated and creaky, they couldn't figure it out
    

Now it may be the case that they didn't really try to fix it and are just
using that as an excuse, but OTOH, they may actually have been stumped despite
best efforts.

If the system really did defeat this smart engineer's days of study, then in
my opinion, and the opinion of at least one discussion I've seen on HN, the
software should have been rewritten. (IMO) this really needs more
clarification before scorn is passed.

~~~
Mikushi
Indeed. If i cannot understand a system (in my field) in a couple of days
(depending on the size), and have been asked to work on it, chance is i'll ask
for a rewrite, with documentation and readable code.

If your system is not readable and undocumented, don't blame the guy who will
come and decide to rewrite it.

~~~
gideons
So you have a legacy system that is being used by other systems, you're the
new super genius and can't understand the system, so you rewrite? Discounting
the potential release iterations and bug fixes that are in the legacy system?
Your "improved" version can't include that knowledge since you didn't
understand the legacy system. Also discounting the company wide knowledge of
the legacy system, warts and all that exists? Also having two identical
systems isn't fantastic. Rewriting a system because someone can't understand
it is rarely the correct solution. It most likely means the rewriter doesn't
understand the problems that are being solved by the legacy system either.

------
knowtheory
I like Larry Wall's conceptual framework for this.

The chapter of Programming Perl regarding software libraries starts out with a
discussion of Laziness, Impatience, and Hubris
(<http://c2.com/cgi/wiki?LazinessImpatienceHubris> ), but more importantly, it
also explicitly mentions the ideas of False Laziness, False Impatience, and
False Hubris, which each in turn lead software developers from making poor
choices as to whether they should build a new software library, reuse an
existing library, or just get on with their damn job, and write something
easy.

But this essay gets right to the same core here. How is it that we do our jobs
as software developers? What is the right way to approach a particular
problem? These are hard questions to answer in abstract, but thinking about
the nature of invention is a pretty good proxy.

~~~
raganwald
Thank you, may I quote this?

~~~
knowtheory
Please do!

------
bambax
The word "invention" is ambiguous. I invent what I don't know, therefore, the
less I know, the more I invent. Incompetence is the mother of invention.

IMHO, creativity is a better word: creativity builds on previous knowledge.

(I'd like to expand on this but after many rewrites of this comment I can't
phrase properly what I want to say so I'll just leave it at that.)

~~~
daemin
I'm a bit confused with what the word invention means in this context. Does it
mean truly inventing some new algorithm (not in Knuth) as a normal part of
your work. Or does it mean just writing new code from scratch rather thanh
using a library?

I've written a lot of code in my career (and as a hobby), but I doubt that
I've truly invented something new.

------
lambda_cube
Thank you Reginald. You always make me think, more reliably than any other
writer about software. You pose interesting questions and have interesting
viewpoints and discussion related to those questions. I hope you feel proud
about this ability, because you should.

I also appreciate that you have chosen to publish your writing more in a blog
format just like on <http://weblog.raganwald.com> instead of the GitHub
experiment, I never really got into reading your stuff there.

As for the question posed, I believe I'm biased towards invention. I would
prefer to work in a research department in a company or in a small company
that have a business idea (partly) based on research. I hope I'm wise enough
to avoid NIH, that is not really inventing anyway, so it's not as much fun as
real inventing. (Working in a university seems to come with too much
bureaucracy for my taste, but I do like the teaching part.)

------
ibejoeb
That is a pretty cool question. Aside from ferreting out the mentality of the
candidate or team (like are you bio-sciences and _need_ to invent, or are you
a CRM software maker and have NIH?), it probably tells a lot about the kinds
of problem you're dealing with.

It turns out that I don't invent anything. I _discover_ things that I never
realized and perhaps nobody else has realized. Things like commonalities in
seemingly different problems, generalized approaches to solving those
problems, and other things that are intrinsic to the domain but not
necessarily apparent. This is distinct from creating something new in that
domain, and I think it's important to recognize that.

update: based on this, I'm going to start asking "Have you ever discovered
something?" It really doesn't matter if it's original, but I want to work with
the kinds of people who are capable of making discoveries for themselves.

~~~
hackinthebochs
The problem with this is that its just too damn ambiguous. What does
"discover" mean in the context of software development? You have your own idea
(which is a good one), but communicating that to a candidate so you're on the
same page might take more time than its worth.

~~~
ibejoeb
It has nothing specifically to do with software development, but toward that,
I remember discovering many things. I discovered that I could keep track of an
arbitrary sequence of dynamically created objects, but I didn't invent linked
lists. I also discovered that I could sort things without comparing each item
to every other item, and that it was "obviously" more efficient, but I didn't
invent merge sort or Big O.

If I'm talking to a razorblade salesman who figured that he can make recurring
sales of razorblades when gives away handle to hold it with, I don't conclude
that he invented the loss leader. I think it's fascinating to have arrived
there not by way of rote.

Surely you've made an independent discovery in whatever it was you were
interested in at one time or another...

This is just editorial now, and it's deviating from OP's concept. I find that
I like to work with people that have strong ties to their crafts, whatever
they are, and those people tend to have made discoveries, not necessarily
inventions.

Back to the point: really, how many individuals can say that he truly invented
something? Great question, but "yes" to that would raise a flag for me.

~~~
raganwald
The question as written is highly imperfect. I’m very ok with the idea that
perhaps one asks a series of questions getting atthe underlying ideas even if
the words you use would differ from mine, or if the questions in one interview
might differ from the questions in another.

~~~
ibejoeb
I think it's inspiring. Thanks for getting my wheels turning.

------
hsmyers
Most of my work in the last 8 years or so involves 'glue' or 'connections'.
That is take two (or more) boxes and hook them together into a pipeline. Not
sure if that qualifies one way or the other. The work certainly didn't exist
before but I'm not entirely sure I'd call it 'invention'. I suppose in the
interview suggested, I'd probably answer yes and then go on to describe as
much as my NDAs allow...

~~~
treetrouble
Yeah, the language is a little pretentious but I believe that's the sort of
invention they're looking for

~~~
jmilloy
No, I don't think so. I don't think the question presumes that inventing is a
good thing and not inventing is a bad thing. In fact, here, you would probably
say that the current work does _not_ involve inventing things, but rather
putting existing things together. That's supposed to be a valid answer, as
well, and a useful one.

~~~
drcube
What sort of invention is NOT putting existing things together? In fact, to me
that sounds like as good a definition of "invention" as any.

------
kstenerud
Invention vs re-use. Unless the candidate is willing to take an honest,
logical approach to this decision (involving defendable reasoning), I'd be
wary.

Is it a solved problem? No? Invent it.

Is the solution available to you within your constraints? No? Make your own
implementation (unless there's a way to acceptably compromise in the design).

Is the solution cost-effective to use (performance, ease-of-use, bugginess,
support, etc)? No? Make a better implementation.

Otherwise just re-use an existing solution.

~~~
raganwald

      Is it a solved problem? No? Invent it.
    

Something to consider: Sometimes we can change the rules. If given
requirements A, B, and C, and we discover that “A” is not a solved probloem,
we could go ahead and invent a solution. Then again, perhaps we can push back
and ask if some lesser requirement A’ (which _is_ a solved problem) is
sufficient for success.

The converse is possible as well. Given requirements X, Y, and Z, all of which
are solved problems, sometimes we can raise our hands and say “Will we really
be successful implementing another Me-Too thingummy? If we take a chance and
try to add feature W—which is not a solved problem—we will have a competitive
advantage.”

I agree with your basic premise, but want to point out that given a certain
bias, we can sometimes fark around with the requirements to suit ourselves. So
a candidate in an interview could easily convince you that he _had_ to invent
a way to synchronize documents while supporting offline editing, but aother
candidate in the same situation might have avoided the requirement
necessitating invention in the first place. Or the reverse!

------
bugsy
> please describe the three most recent things you have invented

The "most recent" qualifier makes this a short answer, which would be:

Of the last three of my inventions, two are trade secrets and the third has
not completed the patent application process. I am not able to discuss any of
these. Would you rather discuss some of the patents I hold that are public
instead? While you are considering I would like to know what your company's
exact policy is regarding the projects and things I will be inventing outside
work hours using my own equipment. Obviously the policy will have a major
impact on whether I decide to consider accepting an offer to work here.

~~~
llimllib
Why would you be so combative? Wouldn't you grant the interviewer the benefit
of the doubt and describe the most recent three things you can talk about? Is
the question somehow offensive?

~~~
bugsy
There's nothing at all combative in what I said. If you see it as such, the
problem is with the way you relate to people.

If someone asks me today specifically for the most recent three things I have
invented, I am not going to lie in my answer. I am going to explain why I can
not disclose any of those three and ask if they would rather hear about ones I
can disclose. That you see this response, which is correct, true and factual,
as "combative" shows that you have a problem.

~~~
Robin_Message
I don't want to be an ass, please take this as friendly advice. You are
obviously smart and good at what you do, but I really feel you are not coming
across as well as you think you are. Your answer was quite combative, and I
can illustrate how. Obviously it was terse, but I assume that was merely for
illustration and not how you would actually speak.

Firstly, your first answer is a direct _parry_ to the question. Whilst
factual, it doesn't assume good faith of the interviewer, that they would be
happy to hear about three recent things that you can talk about. I think you
are on the wrong side of the line between the principle of quality and the
principle of quantity -- you mention it would be lying not to talk about the
literal three most recent, but I don't think most people would interpret it
that way.

You then make what could easily be interpreted as a boast in relation to the
multiple patents you hold. This is not a directly aggressive statement, but it
is an offensive move in the status game you are playing with the interviewer.
I wouldn't say it is the wrong thing to say; but it might be the wrong time to
say it.

You then _riposte_ with a reasonable question, but given you just slammed
their question and asked them to clarify, it is unfortunate to then ask
another question, basically forcing them to decide whether to mollify you or
continue their own questioning.

Finally, you make another powerful status signalling move. Think of it this
way -- if the people are impressed by these signals, they want to hire you
already so why are you even having an interview? Therefore, chances are this
interview is for someone else's benefit (HR or management) and neither of
those groups will respond well to your attempt to take high status.

It's not a bad answer, it could certainly work well in some circumstances,
obviously it could come across differently in actual conversation, but as it
appeared it is combative.

I recommend reading <http://en.wikipedia.org/wiki/Cooperative_principle> and
<http://en.wikipedia.org/wiki/Gricean_maxims>.

------
JackDanger
It reminds me of Zed's excellent distinction between invention and
implementation: <http://zedshaw.com/essays/c2i2_hypothesis.html>

------
invalidOrTaken
This is definitely a great question, although llimllib is spot-on about a
needed neutralizing of the question.

I think it's most useful when you can: a)present both options in a positive
light ("I am a github/mashable-whisperer and can string libraries and API's
together at ridiculous speed!" for instance) and b) it's clear that there is
no wrong answer.

I'm not saying there _shouldn't_ be a wrong answer _for your organization_ ,
but I am saying that the question will become less useful if there is, because
your candidate will be tempted to fudge.

------
Cushman
Man, just reading that question makes me a little giddy. I'd be pretty excited
to hear that in an interview.

Also, a punny title which is actually a pun on the subject of the article? I
think I might be in love.

------
robjohnson
I think that a throttled balancing act between total-invention and mild-
integration is probably the best outlook to take at 90% of issues right from
the start. There are exceptions to all rules, and the interviewer will have a
better grasp on where in this spectrum they need the candidate to fall, but
this "describe something you've built/hacked" seems to be a fairly common
question that shouldn't come as a surprise to anyone interviewing.

------
xilun0
Once you start calling anything an invention, the next logical step is to
allow to patent it. OK it's too late for the US, but we still have some hope
in Europe, so unless you are writing stuffs using concepts and algorithms
never used before, and not even appearing in TAOCP, which i highly doubt, stop
calling your shit an invention. Also don't do it because that is very probably
insulting to Knuth, Dijkstra, et al.

~~~
raganwald
_Once you start calling anything an invention, the next logical step is to
allow to patent it._

“Invention” and “Patent-worthy Discovery” are not synonymous:

    
    
      An invention is a better or more effective composition,
      device, or process. An invention may be derived from a
      pre-existing model or idea, or it could be independently
      conceived in which case it may be a radical breakthrough...
    
      An invention that is novel and not obvious to others
      skilled in the same field may be able to obtain the legal
      protection of a patent.
    

<https://secure.wikimedia.org/wikipedia/en/wiki/Invention>

It is possible and normal to invent things that are not novel, or may be
obvious to others skilled in the same field. It’s still invention, it just
isn’t “Big I” Invention, it’s a more modest creative process.

Think of it this way: We have the expression “re-inventing the wheel.” If it
wasn’t possible to invent things that already exist, it wouldn’t be possible
to “re-invent” anything, would it?

------
kreek
Once upon a time, in a kingdom not far from here, a king summoned two of his
advisors for a test. He showed them both a shiny metal box with two slots in
the top, a control knob, and a lever. "What do you think this is?"

One advisor, an engineer, answered first. "It is a toaster," he said. The king
asked, "How would you design an embedded computer for it?" The engineer
replied, "Using a four-bit microcontroller, I would write a simple program
that reads the darkness knob and quantizes its position to one of 16 shades of
darkness, from snow white to coal black. The program would use that darkness
level as the index to a 16-element table of initial timer values. Then it
would turn on the heating elements and start the timer with the initial value
selected from the table. At the end of the time delay, it would turn off the
heat and pop up the toast. Come back next week, and I'll show you a working
prototype."

The second advisor, a computer scientist, immediately recognized the danger of
such short-sighted thinking. He said, "Toasters don't just turn bread into
toast, they are also used to warm frozen waffles. What you see before you is
really a breakfast food cooker. As the subjects of your kingdom become more
sophisticated, they will demand more capabilities. They will need a breakfast
food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A
toaster that only makes toast will soon be obsolete. If we don't look to the
future, we will have to completely redesign the toaster in just a few years."

"With this in mind, we can formulate a more intelligent solution to the
problem. First, create a class of breakfast foods. Specialize this class into
subclasses: grains, pork, and poultry. The specialization process should be
repeated with grains divided into toast, muffins, pancakes, and waffles; pork
divided into sausage, links, and bacon; and poultry divided into scrambled
eggs, hard- boiled eggs, poached eggs, fried eggs, and various omelet
classes."

"The ham and cheese omelet class is worth special attention because it must
inherit characteristics from the pork, dairy, and poultry classes. Thus, we
see that the problem cannot be properly solved without multiple inheritance.
At run time, the program must create the proper object and send a message to
the object that says, 'Cook yourself.' The semantics of this message depend,
of course, on the kind of object, so they have a different meaning to a piece
of toast than to scrambled eggs."

"Reviewing the process so far, we see that the analysis phase has revealed
that the primary requirement is to cook any kind of breakfast food. In the
design phase, we have discovered some derived requirements. Specifically, we
need an object-oriented language with multiple inheritance. Of course, users
don't want the eggs to get cold while the bacon is frying, so concurrent
processing is required, too."

"We must not forget the user interface. The lever that lowers the food lacks
versatility, and the darkness knob is confusing. Users won't buy the product
unless it has a user-friendly, graphical interface. When the breakfast cooker
is plugged in, users should see a cowboy boot on the screen. Users click on
it, and the message 'Booting UNIX v.8.3' appears on the screen. (UNIX 8.3
should be out by the time the product gets to the market.) Users can pull down
a menu and click on the foods they want to cook."

"Having made the wise decision of specifying the software first in the design
phase, all that remains is to pick an adequate hardware platform for the
implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk, and
a VGA monitor should be sufficient. If you select a multitasking, object
oriented language that supports multiple inheritance and has a built-in GUI,
writing the program will be a snap. (Imagine the difficulty we would have had
if we had foolishly allowed a hardware-first design strategy to lock us into a
four-bit microcontroller!)."

The king wisely had the computer scientist beheaded, and they all lived
happily ever after.

\---

<http://www.tik.ee.ethz.ch/~lubichh/extdoc/jokes/cs-ee.html>

~~~
CamperBob
(Shrug) I'd use a knob, a bimetallic strip, and a pair of tungsten contacts,
but I'm weird that way.

~~~
danvet
The problem with that approach is that tuning it is hard, i.e. it's rather
harder to ensure that the knob somewhat linearly adjust from "not toasted" to
"black" and the useable control range isn't just a tiny part at one end of the
full range.

Luckily changing software doesn't (usually) require a solder iron.

------
buro9
I'm not sure I buy "invention", the creation of something new.

I prefer to ask questions that determine whether people are able to mine their
own experience and apply solutions from one domain to another entirely
different domain.

It seems to me, that most invention is finding novel approaches to existing
problems, and that most problems already have solutions that just need to be
discovered and matched up with their problem. The harder part is that it is
usually the case that the solution is in a different problem domain than the
problem at hand.

The most inventive people I know are the ones who are open to learning
everything, who consume all knowledge and are always listening. These people
store solutions in a problem-domain invariant way, such that when they
encounter a problem they already know the solution even though it's non-
trivial for everyone else.

------
fendabender
There's probably nothing truly new in the context as 'new' in the question
needs qualification. Following on does invent mean, bring to the table [as
they've done something similar elsewhere] or something innovative. Some
questions might sound great, but they have to placed within context and not
just thought up as being clever, but they actually have a YARDSTICK to measure
the candidate.

I'm not a programmer, I just do mark-up but I do like the question as it's a
development of personal and business aspects of the candidate.

With interview it will show:

Does the candidate show initiative, problem solving and application. Finally,
it ought to involve an answer of business acumen: Does spending 6 months
developing it vs. returns of a version update. This ought to show a right fit
and if the candidate can 'fit' to the business and process aims of the
company.

~~~
barce
This question is a great yardstick. If you are at a startup and want to swing
for the fences, this question makes very clear your intentions.

------
treetrouble
This is a great question that requires an answer that is both philosophically
and technologically deep

Most articles I've read with a headline like this, the question posed involves
an impractical show of technical prowess

------
kragen
Here's a metaphor about a special case where invention is justified.

Suppose you have no cell phone and you need to get to your mad science lab
before your apprentice does so that you can lock up the monster you created
the night before — otherwise it will eat him. You spot him ten cars ahead of
you on the two-lane highway, but he doesn't notice you.

It is 100% guaranteed that he will arrive at the lab before you if you stay
behind him on the highway. Then the monster will eat him.

There's a shortcut to the mad science lab through the back roads. Usually the
highway is faster, but every once in a while the highway has a traffic jam and
the back roads don't. If you take the back roads, you have a 30% chance of
reaching the lab before your apprentice.

30% is better than 0%, so that's what you should do. _Even though the back
roads are probably slower_ , they're your only possible way to win the race.

In a business context, you may find yourself competing against an incumbent
strictly on the basis of their core competency. If you have no way out of that
situation, one possible strategy is to pursue an angle of development that is
simply _different_ from theirs — even if your best knowledge suggests that
their angle is probably the best one. Your only hope is that they run into an
unexpected traffic jam on the road they're taking, _and that you're on a
different road_.

My reading is that this is basically the story of AMD64. As I understand it,
mainstream opinion in the late 90s and early 2000s was that we were going to
have to import some version of VLIW's explicit ILP into CPU design in order to
keep getting single-threaded performance improvements, so that was what Intel
went with for their 64-bit CPU architecture. AMD announced their alternative
path, hobbling themselves with backward compatibility, in _1999_.

They got lucky: Intel's "Itanium" turned out to be an Itanic; it hit a
performance iceberg and sank, and since 1999, AMD64 has become the mainstream
CPU architecture, displacing not only i386, but also PowerPC, SPARC, Alpha,
MIPS (except in the very low-end), PA-RISC, POWER, System 360, AS/400, and
half a dozen vector supercomputer architectures. (Alpha, PA-RISC, and the
AS/400 aren't even on the market any more. SPARC, POWER, System 360, and
vector supercomputers are still available, but most of their uses have been
replaced with AMD64, running Linux.)

~~~
vl
>Alpha, PA-RISC, and the AS/400 aren't even on the market any more

Strictly speaking it's not correct: AS/400 was rebranded, but you still can
buy hardware with OS/400 running on it. Also, it never was replaced by AMD64 -
it's using CPU-independent byte-code and happily migrated over different CPU
architectures few times.

~~~
kragen
You're right — I misread <http://en.wikipedia.org/wiki/AS/400> to be saying
that AS/400 was killed in 2008, but the replacement hardware still runs
OS/400. Thank you!

> In April 2008, IBM announced its integration with the System p platform. The
> unified product line is called IBM Power Systems and features support for
> the IBM i (previously known as i5/OS or OS/400), AIX and Linux operating
> systems. Power4 or older hardware ran OS/400 exclusively.

------
troels
That blog post is less about interviewing than the title suggests. It's an
interesting dichotomy.

~~~
raganwald
One of the reasons that discussions about interview questions/techniques
generate such heated discussions is because they cut right to the core of our
self-image and mercilessly strip naked our views about software development.

~~~
troels
On a related note, job interviews (some times) have a special quality that you
rarely meet in other situations. I think for those exact reasons.

Of course another explanation could be that I'm narcissistic and it's the
perfect setting to talk about my self. But then I equally enjoy interviewing
candidates, so perhaps not.

------
DenisM
Good idea. You should try using fewer words to describe it though.

~~~
raganwald
Here is a blog post I wrote in seventeen paragraphs over lunch. Had I more
time, I would have written it in seven.

------
joejohnson
Does anyone know the answer to the problem posed in the XKCD comic?
<http://xkcd.com/356/>

~~~
pornel
[http://pgraycode.wordpress.com/2011/02/23/solving-xkcds-
nerd...](http://pgraycode.wordpress.com/2011/02/23/solving-xkcds-nerd-
snipping-problem/)

~~~
dagw
While certainly a nicely written and interesting post, it's not a solution,
it's a rough numeric approximation.

------
KennethLStein
DANGER - BAD QUESTION - asking this question is asking a candidate (currently
employed or otherwise) to violate the terms of the Confidentiality Agreement
with their previous employer. Asking prospective employer this question is
doing the same thing.

THE CORRECT ANSWER TO THIS QUESTION - "Answering this question necessitates
that I violate my duty of confidentiality.

~~~
raganwald
I really think you’re getting a little over-enthusiastic here, Kenneth. Not
everyobody has signed a rigorous confidentiality agreement. Not all such
agreements prevent someone from discussing technical inventions in general
terms. And if someone is prevented from answering, well, they will say so and
the interviewer can decide what to do next.

If this is a “bad question,” are there _any_ good questions?

~~~
KennethLStein
Appreciate your reply. This question likely places candidates in a difficult
situation, especially younger candidates who are excited about the
opportunity, or those needing the job.

If the interviewer plans on asking this question, they ought to have conducted
a patent search prior to the interview.

If patents or applications are found - ask the candidate about the problem
that was solved by the claimed invention. Ask if the candidate was the one who
noted the problem, and ask further questions based upon the answer.

If no patents/published applications naming the candidate are found, don't ask
the question.

If the interviewer doesn't want to take the 5 minutes to search, or HR doesn't
provide these materials to interviewers as a routine part of the interviewing
process then they ought to ask "Are you listed as an inventor on any issued
patents or published patent applications?" and then they ought to suggest that
in the future HR conduct a quick patent and published application search and
distribute the results to those interviewing a candidate.

A candidate ought to conduct a patent search prior to interviewing and use
that information to ask a variety of questions and point out noted
intersections between tech development and the candidates knowledge and
experience.

~~~
raganwald
_If no patents/published applications naming the candidate are found, don't
ask the question._

We can’t possibly be conducting the same kinds of interviews with the same
kinds of candidates. Or possibly you are talking a very narrow view of the
word “invention.” Or you work in a phenomenally litigious sector.

For my purposes, “Describe a technical problem you encountered at XYZCorp and
how you solved it” is a standard interviewing question. I suspect that if you
don’t allow the question I posed in this blog post, you wouldn’t allow this
one either.

~~~
KennethLStein
search for patents and published applications at:

<http://appft1.uspto.gov/netahtml/PTO/search-adv.html>
<http://patft.uspto.gov/netahtml/PTO/search-adv.htm>

the query to use is:

in/lastname-firstname

If you don't find any references, then asking the candidate to describe a
technical problem and means by which they solved it is less likely to be
received as a request for confidential information.

Hope you find the above links and search query useful!

Best.

------
barce
A great follow up question, or daughter question, would be: "What tools do you
think best contribute to the process of invention?"

~~~
andrewcooke
really? what kind of answer were you expecting and what would it tell you?

~~~
barce
Personally, I'd like to hear something along the lines of "tools that best fit
the team and the problem." Languages come and go but algorithms are forever.

------
CamperBob
That's a tough one, but I'd still rather field that question than the one that
I had to answer when I interviewed at Dell in the early 90s: "What will happen
to your current employer (a ~12-person company) when you leave?"

------
NY_Entrepreneur
I don't 'get it'. Sounds like an easy question and not "The Mother of All
Interview Questions".

But, for me, part of the answer is that the "process" has involved solving
practical problems only in part with software, and some of the "invention" has
been not really in the software.

Do the following examples count?

(1) A prof wrote a package for statistics for students and in the testing
found that one of the operations was too slow and another one gave numerically
poor results.

For the slow operation, looking, there were two loops, each that ran in time
proportional to n^2. Using the existing storage in a tricky way, I converted
the loops to (n)ln(n) which was then plenty fast.

For the bad numerical result, I used some orthogonal polynomials instead of
statistics normal equations, and that solved the numerical accuracy problem.

(2) At a growing company, the Board wanted some revenue projections. There
wasn't much for ideas, so I got involved. We knew the current revenue. We knew
the maximum long term revenue because of the capacity we had in mind. Revenue
growth was to be 'viral'. So, let t denote time in days with t = 0 the current
time. Let the revenue at time t be y(t). So, y(0) is the current revenue. Let
b be the maximum revenue.

From virality, the growth rate in revenue should be proportional to (i) the
revenue from current customers y(t) and (ii) the revenue from the customers
not yet served (b - y(t)).

The growth rate in revenue is dy(t)/dt = y'(t), that is, the calculus first
derivative of y(t). So for some constant k,

    
    
         y'(t) = k y(t) (b - y(t))
    

Solve for y(t) in closed form, select a reasonable k, and done.

(3) A company had a cute marketing opportunity and wanted to allocate
marketing resources the best way. They formulated the problem as a 0-1 integer
linear program (ILP) maximization problem with, for a first test case, 40,000
constraints and 600,000 variables. Seeing that no ILP package would take that
problem as it was, they tried a genetic heuristic, ran for days, and quit.

I looked at the problem, saw an approach via non-linear duality theory and
Lagrange multipliers. So, the dual problem was to minimize a convex function
approximated by some hyperplanes.

I wrote the software, and after 500 hyperplanes had a good approximation to
the dual and a feasible solution to the original problem within 0.025% of the
optimal answer.

(4) Another company had another cute marketing problem and wanted to allocate
resources to maximize results. The problem was integer linear programming
again, but I saw that it was also a problem in least cost network flows on a
network with integers for arc capacities. So, use the network simplex
algorithm and get an optimal answer quickly with the integer constraints
honored for free.

(5) A software project was to analyze some data collected at sea. I looked at
the specification for estimating the power spectra and saw some problems: For
the low frequency resolution they wanted, they needed too much data. To
illustrate, I wrote some software to generate a sample path of a second order
stochastic process with a known power spectrum, accumulate the sample power
spectrum, and showed how slowly the sample power spectrum converged to the
spectrum of the process. This work surprised and pleased the customer, and we
got the competitive software contract.

(6) In a project, needed to look at a few million numbers and end up with the,
say, 100 largest. So, go to classic heap sort, and start with an ascending
heap of 100 locations that has the 100 largest so far and with the smallest at
the root of the implicit tree of the heap. So, given the next one of the 100
million numbers, one comparison with that root value says if that next number
is among the 100 largest so far; if so, then replace the root value with the
next value and 'sift' to rebuild the heap.

The worst case would be given the 100 million numbers in ascending order in
which case the computational time complexity should be proportional to
(n)ln(n) for n = 100 million. Otherwise for large n the execution time should
be only slightly slower than proportional to n (exercise: for n independent,
identically distributed numbers with a distribution absolutely continuous with
respect to Lebesgue measure so that the probability of ties is zero, find the
actual expected running time up to a constant of proportionality).

(7) A server reports numerical data on each of 10 variables at 20 a second.
You have data from three months when, from that data and more evidence, the
server seemed to be 'healthy'.

Your mission, should you decide to accept it, is to implement real time
monitoring for this server that uses the data from the three months and also
real time data. Your solution will be a statistical hypothesis test with
known, adjustable Type I error (false alarm rate). Your work will necessarily
be the world's first class of statistical hypothesis tests that are both
multi-variate and distribution-free. You need to show that your test is not
'trivial', and for that consider the classic S. Ulam result on 'tightness'.
You should also show that in a powerful sense, asymptotically the test is best
possible in a sense similar to the classic Neyman-Pearson result.

Also, design and implement a fast algorithm for the computations.

Do such examples count?

~~~
vl
You lost me at (6):

Shouldn't it be proportional to O(n log 100) ~ 0(n) aka linear time?

~~~
NY_Entrepreneur
Yup! I typed too fast! You are correct. I was thinking the right thing but
typing the wrong thing! I'm too used to typine (n)ln(n)!. So, sure, worst
case, n times have to do a heap 'sift' which is time proportional to ln(100)
as you said.

Short answer: I blew it!

But for the exercise, that is, when there are no ties among the n numbers and
all permutations are equally probable, for 100 < m < n, the probability that
number m is among the 100 largest so far and, thus, causes a heap 'sift',
seems to be 100/m. So, the expected work on number m is proportional to just
(m - 100)/m + ln(100) (100/m), first cut, wild guess, don't hold me to it! So,
sum this on m and get the expected work (computational time complexity) up to
a constant of proportionality. Maybe! That is, so far, first cut, the exercise
looks simple! When do the sum, I smell a ln(n) term!

