11 ms·

The Mother of All Interview Questions

263 points by raganwald 15y ago

llimllib 15y ago
> 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.
- coconutrandom 15y ago
  Your second part is spot on, but the first question is not about the "yes/no" but the "why". Of course we invent, but the question is to find to what extent they are willing to go.
- raganwald 15y ago
  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 15y ago
    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.
- ww520 15y ago
  Exactly. Software design is a matter of tradeoff. Build vs buy is one of them.
- joe_the_user 15y ago
  Yes, All programming is inventing. But not all good programmers see programming as inventing. I'm not sure you wind-up better by weeding out those who don't programming as inventing.
- giardini 15y ago
  > If you're asked this in an interview, you can't respond "no". I don't see why not! It would save lots of time. This is a poor question as phrased. If you want to know about the developer's attitude toward reuse versus DIY, then simply ask that. The common usage of the word "invention" today invokes questions about intellectual property, patent rights, copyright et al - topics most developers would likely rather avoid.
treetrouble 15y ago
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
hsmyers 15y ago
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 15y ago
  Yeah, the language is a little pretentious but I believe that's the sort of invention they're looking for
  - jmilloy 15y ago
    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 15y ago
      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.
DenisM 15y ago
Good idea. You should try using fewer words to describe it though.
- raganwald 15y ago
  Here is a blog post I wrote in seventeen paragraphs over lunch. Had I more time, I would have written it in seven.
ibejoeb 15y ago
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 15y ago
  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 15y ago
    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.
Cushman 15y ago
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.
knowtheory 15y ago
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 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 15y ago
  Thank you, may I quote this?
  - knowtheory 15y ago
    Please do!
- kamaal 15y ago
  I also like Larry Wall's "Waterbed theory of complexity" (http://en.wikipedia.org/wiki/Waterbed_theory http://en.wikipedia.org/wiki/Waterbed_theory) which fundamentally says complexity needs to be handled at layer or the other in a system. Which primarily brings the eternally asking the question of "Using the right tools" for the job. Apart from knowing all the CS know-how behind how things work. Practical software is all about knowing if there are existing off the shelf solutions that can be just plugged into take care of that part of the complexity. I think innovation is more than just code, its also about how you can go about solving a particular business problem in the most practical way. I think in MIT lecture series of Structure and Interpretation of computer programs, the instructor bring about a very point. Its something like this "A part of understanding and building large complex systems is to know what parts to neglect". We often test people with knowing about the granular details. But we never see if they know how to build powerful abstractions. Which is basically the core any large complex system.
invalidOrTaken 15y ago
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.
troels 15y ago
That blog post is less about interviewing than the title suggests. It's an interesting dichotomy.
- raganwald 15y ago
  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 15y ago
    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.
lambda_cube 15y ago
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 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.)
fendabender 15y ago
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 15y ago
  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.
barce 15y ago
A great follow up question, or daughter question, would be: "What tools do you think best contribute to the process of invention?"
- andrewcooke 15y ago
  really? what kind of answer were you expecting and what would it tell you?
  - barce 15y ago
    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.
kreek 15y ago
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 http://www.tik.ee.ethz.ch/~lubichh/extdoc/jokes/cs-ee.html
joejohnson 15y ago
Does anyone know the answer to the problem posed in the XKCD comic? http://xkcd.com/356/ http://xkcd.com/356/
- pornel 15y ago
  http://pgraycode.wordpress.com/2011/02/23/solving-xkcds-nerd-snipping-problem/ http://pgraycode.wordpress.com/2011/02/23/solving-xkcds-nerd...
  - dagw 15y ago
    While certainly a nicely written and interesting post, it's not a solution, it's a rough numeric approximation.
- ronnix 15y ago
  Google knows: http://www.mathpages.com/home/kmath668/kmath668.htm http://www.mathpages.com/home/kmath668/kmath668.htm
kstenerud 15y ago
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 15y ago
  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!
bambax 15y ago
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.)
- llimllib 15y ago
  Start a blog and write it out!
- daemin 15y ago
  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.
JackDanger 15y ago
It reminds me of Zed's excellent distinction between invention and implementation: http://zedshaw.com/essays/c2i2_hypothesis.html http://zedshaw.com/essays/c2i2_hypothesis.html
bugsy 15y ago
> 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.
- deleted 15y ago
  [deleted]
- llimllib 15y ago
  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 15y ago
    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.
    - Volpe 15y ago
      No, it was combative, regardless how true and factual. True and factual != polite and neutral. (Do you let every overweight person you see, know that they are fat? It's true and factual, so if they take issue with it, it's because they have a problem!?). In fact, your response to the parent was fairly combative as well. Instead of pointing out a problem in the parents point you have instead tried to find fault in the parents character.
KennethLStein 15y ago
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 15y ago
  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 15y ago
    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.
    - 15y ago
deleted 15y ago
[deleted]
NY_Entrepreneur 15y ago
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?
xilun0 15y ago
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 15y ago
  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 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?
CamperBob 15y ago
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?"
buro9 15y ago
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.
robjohnson 15y ago
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.
kragen 15y ago
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 15y ago
  >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.

263 points by raganwald 15y ago

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

coconutrandom 15y ago
Your second part is spot on, but the first question is not about the "yes/no" but the "why". Of course we invent, but the question is to find to what extent they are willing to go.
raganwald 15y ago
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 15y ago
  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.
ww520 15y ago
Exactly. Software design is a matter of tradeoff. Build vs buy is one of them.
joe_the_user 15y ago
Yes, All programming is inventing. But not all good programmers see programming as inventing. I'm not sure you wind-up better by weeding out those who don't programming as inventing.
giardini 15y ago
> If you're asked this in an interview, you can't respond "no". I don't see why not! It would save lots of time. This is a poor question as phrased. If you want to know about the developer's attitude toward reuse versus DIY, then simply ask that. The common usage of the word "invention" today invokes questions about intellectual property, patent rights, copyright et al - topics most developers would likely rather avoid.

treetrouble 15y ago

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

hsmyers 15y ago

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 15y ago
Yeah, the language is a little pretentious but I believe that's the sort of invention they're looking for
- jmilloy 15y ago
  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 15y ago
    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.

DenisM 15y ago

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

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

ibejoeb 15y ago

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 15y ago
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 15y ago
  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.

Cushman 15y ago

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.

knowtheory 15y ago

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 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 15y ago
Thank you, may I quote this?
- knowtheory 15y ago
  Please do!
kamaal 15y ago
I also like Larry Wall's "Waterbed theory of complexity" (http://en.wikipedia.org/wiki/Waterbed_theory http://en.wikipedia.org/wiki/Waterbed_theory) which fundamentally says complexity needs to be handled at layer or the other in a system. Which primarily brings the eternally asking the question of "Using the right tools" for the job. Apart from knowing all the CS know-how behind how things work. Practical software is all about knowing if there are existing off the shelf solutions that can be just plugged into take care of that part of the complexity. I think innovation is more than just code, its also about how you can go about solving a particular business problem in the most practical way. I think in MIT lecture series of Structure and Interpretation of computer programs, the instructor bring about a very point. Its something like this "A part of understanding and building large complex systems is to know what parts to neglect". We often test people with knowing about the granular details. But we never see if they know how to build powerful abstractions. Which is basically the core any large complex system.

invalidOrTaken 15y ago

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.

troels 15y ago

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

raganwald 15y ago
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 15y ago
  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.

lambda_cube 15y ago

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

fendabender 15y ago

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 15y ago
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.

barce 15y ago

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

andrewcooke 15y ago
really? what kind of answer were you expecting and what would it tell you?
- barce 15y ago
  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.

kreek 15y ago

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 http://www.tik.ee.ethz.ch/~lubichh/extdoc/jokes/cs-ee.html

joejohnson 15y ago

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

pornel 15y ago
http://pgraycode.wordpress.com/2011/02/23/solving-xkcds-nerd-snipping-problem/ http://pgraycode.wordpress.com/2011/02/23/solving-xkcds-nerd...
- dagw 15y ago
  While certainly a nicely written and interesting post, it's not a solution, it's a rough numeric approximation.
ronnix 15y ago
Google knows: http://www.mathpages.com/home/kmath668/kmath668.htm http://www.mathpages.com/home/kmath668/kmath668.htm

kstenerud 15y ago

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 15y ago
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!

bambax 15y ago

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

llimllib 15y ago
Start a blog and write it out!
daemin 15y ago
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.

JackDanger 15y ago

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

bugsy 15y ago

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

deleted 15y ago
[deleted]
llimllib 15y ago
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 15y ago
  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.
  - Volpe 15y ago
    No, it was combative, regardless how true and factual. True and factual != polite and neutral. (Do you let every overweight person you see, know that they are fat? It's true and factual, so if they take issue with it, it's because they have a problem!?). In fact, your response to the parent was fairly combative as well. Instead of pointing out a problem in the parents point you have instead tried to find fault in the parents character.

KennethLStein 15y ago

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 15y ago
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 15y ago
  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.
  - 15y ago

deleted 15y ago

[deleted]

NY_Entrepreneur 15y ago

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?

xilun0 15y ago

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 15y ago
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 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?

CamperBob 15y ago

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

buro9 15y ago

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.

robjohnson 15y ago

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.

kragen 15y ago

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 15y ago
>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.