Probabilistic AI can't be AI - <AUTHOR> http://refaktorlabs.blogspot.com/2014/02/probabilistic-ai-cant-be-ai.html

<comment><USER2> _then people would be naturally great at probability_

Where do you get that conclusion? Think of a baseball player with exceptional hand-eye coordination, who also knows absolutely nothing about any of the math or calculus behind it. There is a vast chasm between conscious and subconscious thought (where the latter might be viewed as the underlying "intelligence model"). I don't agree that a (partially) probabilistic model would necessarily imply a proficiency at the conscious, communicable level.

 _we wouldn 't benefit from learning about and consciously using probability to solve problems, as our brain would already do it on a lower level._

Don't understand this one either. Back to the baseball player - there is a lot of value we gain from our brains "naturally" solving e.g. inverse kinematics problems on the fly. But, there is also a lot we gain from understanding these mathematical concepts at the conscious level. Totally different realms, both useful.

 _Statistical methods generally need a big learning set to learn anything._

Ok, that's a limitation of the current AI models. They're not smart enough to infer the essential characteristics of an elephant from a small set (it's also a very narrow approach...you don't start a child off by showing them pictures of elephants, first they have to spend a long time acquiring basic fundamentals of knowledge and perception). I don't see how that implies a more deterministic nature of organic intelligence.

Even the child might think something is an elephant and be wrong. But (IMO) it's the same process of using the bits of knowledge you have to make a guess (and an estimated degree of certainty). "It could be this thing or it could be that thing, and my model says it has the greatest probability of being this one, so that's what I'm going with."

<comment><AUTHOR> Ok, based on yours and many other similar comments below I only now see where my argument isn't understood as I wanted it to be. Not that I think that now you and others will agree with me, but just to make this clear.

I do not think that people would "then be consciously good at probability" (I said naturally / later added instinctively), but that the results of their unconscious processes / intuition, would then be better matching the probability-wise view of the problem. While I think that exactly the intuition seems to fail the most at probability (planes, terror attacks, ...).

</comment></comment><comment><USER3> _...people would be naturally great at probability, and we know we suck at probability_

Human bodies are based on molecules, it doesn't imply that people understand chemistry.

Computer chips are based on transistors, it doesn't imply that computers understand electronics.

Sorry, but your assumption that knowledge is inherited by foundations would imply that everything understands the Universe.

<comment><AUTHOR> I see now that I probably didn't express myself well. I am not saying we should understand probability but the result of our instincts should be in tune with probabilistic results on the problem. For example: We would not naturally fear airplanes, terror, etc. or..

If human body is made from molecules it does mean that we function as blobs of molecules.

If computer chips are based on transistors, the output of computer chips is transistor like.

</comment></comment><comment><USER4> First off, the title is terribly imprecise, you're not arguing that probabilistic AI can't be AI, you're arguing that animal intelligence is not probabilistic.

Second off, I personally find your theses unconvincing because the simple statements are easily refuted, and there's not enough supporting information to make them into tighter arguments.

For example, for your first bullet point, the underlying mechanism could be highly probabilistic, without our consciousness having access to the probabilities as they are executed. We do not have conscious knowledge of neuron potentials, or of any other internal state of the physical mechanisms of our consciousness, but that does not mean that they don't exist.

Further, people are bad at reasoning period, and have to be taught how to do it in school. It's only through much training that we learn reasoning from certainties, and reasoning with uncertainty will similarly require training.

Finally, I don't think that anybody is saying that our brains operate SVMs or RBMs or anything like that, they are merely computational mechanisms to replicate the behavior of complex networks of neurons; there may be direct analogs to computation in how neurons integrate chemical, electrical, and epigenetic signals, but it's not clear that they're exactly the same thing; and that doesn't mean that even if it's completely different, that a probabilistic AI can't be an Intelligence.

These are heady matters that people put a lot of careful thought into, and while there's definitely room for light discussion among friends, I'm not sure that this is the right material for HN.

<comment><AUTHOR> you are right about the title, sorry.

is there a consensus/definition on what is AI without relying on what animal/human intell. looks like/functions?

<comment><USER5> I offer one crude definition: intelligence is a requirement for an agent that can solve a wid range of problems, without being specifically designed for these problems.

</comment></comment></comment><comment><USER6> The argument itself is flawed as pointed out by others.

As for the subject of probabilistic AI there's quite a lot of evidence that natural language grammar to a large extent is probabilistic. In fact I'd say that most natural language grammar rules are just surface representations of probabilistic models such as Hidden Markov models.

</comment><comment><USER7> This article is deeply flawed. First of all, it's premise is flawed; secondly, it's supporting evidence is flawed.

Example from supporting evidence:

"then people would be naturally great at probability, and we know we suck at probability"

No, this does not follow at all. There is absolutely no reason to assume that a probabilistic algorithm would somehow lead to better results when dealing with probabilities at a much higher level.

Example from premise:

\- No argument for why "if real intelligences aren't probabilistic, therefore probabilistic intelligences can't work" is given.

\- Just because your models come from statistical learning (such as SVMs or Bayesian methods, as the author names) does not mean your resulting algorithm is probabilistic.

Flagging.

<comment><AUTHOR> so you think that we use probability (and are good at it) on a low level but that doesn't translate to being sufficient in probability on a higher level. Where is the border between low and high?

I am not saying any probabilistic intelligence can't work. Please define any "intelligence" or link to definition. I said I think "we" or organic intelligence doesn't with use of probability.

I am also not saying probabilistic models are useless / bad / or not worth exploring further for making better programs or anything, I just don't think human intelligence uses them as a basis.

</comment></comment><comment><USER8> \- SVMs aren't really probabilistic models. They don't need to be thought of in a way that assumes underlying statistical properties of what they're measuring. Many machine learning methods (decision trees for one) are similarly agnostic.

\- Reality is a probabilistic process. Brains work probabilistically at least in the sense that the underlying biomechanics have some statistical distribution.

I have the feeling the author doesn't really understand what "probability" means, as he more or less admits.

<comment><USER9> > Brains work probabilistically at least in the sense that the underlying > biomechanics have some statistical distribution.

No, it's us that use these distribution to model them. Reality _might_ be deterministic after all (no proof of the contrary), and then brains are not working probabilistic at all.

<comment><USER5> I would think even entirely deterministic systems need to be treated probabilistically if you don't have perfect information.

</comment></comment></comment><comment><USER10> The argument is fundamentally and fatally flawed by a lack of understanding of how the "mind" works.

The basic flaw in the argument is that there is only one "mind" and that all its workings are available to us.

But as much recent research shows, especially that of Tversky and Kahneman, we have at least two "minds", the so-called "fast" and "slow" systems, and the "fast" system is not directly accessible to "us" \- and "us", what we recognize as "us", is the working of "slow", the deliberate, conscious, effortful problem solver, often called upon to cook up a "good enough story" to explain an exception "fast" couldn't make sense of.

"Fast" might be terrifically good at probability, with some survival heuristics favouring particular conclusions - better to always conclude that those weird pattens in the bush are a tiger than to be wrong once.

Since "fast" is not really accessible to "slow", it matters not how good "fast" is at probability - and "fast" could be 100% probabilistic AI and we'd never know it...

...not without detailed neurophychological study, at least. It certainly wouldn't "just be evident".

<comment><AUTHOR> My argument doesn't assume that we don't have unconscious processes. Maybe I didn't express well what I think. I do think we have multiple "minds" (I even wrote a blogpost on this subject on another blog once).

Maybe my "then people would be naturally great at probability" came out as if we would then consciously know about probability, know the formulas etc without the need to learn about them.

No. I tried to say that if so then results of our "fast" mind would be very well attuned to probabilistic study of the problem. For example, you wouldn't become scared when boarding a plane.

I will try to write another blogpost being more precise. Not that it's worth anything, more for myself. I won't post it here, not because of opposing comments, but because many think this is not a HN material and I don't want to spam.

Not that it matters, obviously. But I don't think there is no probability processing anywhere in the system (we do conscious probability if not else). My thoughts were that it can't be the main or important driver behind it all. I think the memory itself (storage and "soft" retrieval of information .. my theory on models that we make) plays much more important role in our function than any special or complex algorithm. Again, not that it matters what I think.

</comment></comment><comment><USER11> I originally intended to make a comment about how wrong this is because almost all approaches to AI and ML are deeply rooted in probability and statistics. The entire problem of intelligence is based on making accurate predictions and then acting on them. But there is some truth in this. Humans _are_ terrible at probability and that's something I wouldn't have expected if I didn't already know it. It is a clue as to what kind of algorithm the brain is using.

I still disagree that the brain doesn't use probability at all or that we shouldn't focus on it in AI research.

>There are more external signs that we don't do probability. Statistical methods generally need a big learning set to learn anything. A small child doesn't have to see a set of 500 cartoon elephants in different poses to recognize elephants from then on in various different cartoons and in real life __*)

No but they do see hundreds of hours of visual feed from their eyes from which they learn high level features. Learning an elephant from one example wouldn't be possible without first learning thousands of other concepts such as how to detect edges, shapes, 3d objects, the properties of animals, etc.

<comment><AUTHOR> I am not saying that it doesn't use something that efectively is a probability calculation anywhere in the system, but that that isn't the main or the most important "engine".

I agree with your comment on "first learning thousands of other concepts". But that is a ton of (hierarchical) concepts that have to bo stored somehow and isn't then the storage/retrieval itself maybe more cruicial to the whole function than any special algo we just haven't figured out yet? (I mention this in my "wild" speculation on "models") :)

<comment><USER11> Perhaps but my understanding is that, at least for vision, the brain learns by trying to predict nearby neurons as well as the future, thus learning an internal model of the world.

Algorithms that do something like this are called Deep Learning and have recently proven extremely effective at machine vision and other tasks. They don't all work by prediction _per se_ but they do learn to compress the input down to a smaller representation of features that can be used to recreate it and are very related to prediction.

</comment></comment></comment><comment><USER12> TL;DR: "I'm not an AI/ML anything by any stretch of imagination"

<comment><AUTHOR> good one, I accept it :)

edit: so you think human intelligence is mainly a probability machine?

<comment><USER13> Something to read:

Hierarchical Bayesian Modeling of Human Decision-Making Using Wiener Diffusion [http://gandalf.psych.umn.edu/users/schrater/schrater_lab/cou...](http://gandalf.psych.umn.edu/users/schrater/schrater_lab/courses/Labmeeting/LeeEtAl_2007.pdf)

Decision Theory and Human Behavior [http://www.umass.edu/preferen/Class%20Material/Bounds%20of%2...](http://www.umass.edu/preferen/Class%20Material/Bounds%20of%20Reason/BOR%20Decision%20Theory%20and%20Human%20Behavior.pdf)

Beyond Accuracy: How Models of Decision Making Compare to Human Decision Making [http://fileadmin.cs.lth.se/cs/Personal/Carl_Christian_Rolf/c...](http://fileadmin.cs.lth.se/cs/Personal/Carl_Christian_Rolf/ccr- msccog.pdf)

Forgetful Bayes and myopic planning: Human learning and decision-making in a bandit setting [http://papers.nips.cc/paper/5180-forgetful-bayes-and- myopic-...](http://papers.nips.cc/paper/5180-forgetful-bayes-and-myopic- planning-human-learning-and-decision-making-in-a-bandit-setting.pdf)

>Our result shows that subjects' choices, on a trial-to- trial basis, are best captured by a "forgetful" Bayesian iterative learning model [21] in combination with a partially myopic decision policy known as Knowledge Gradient [7].

</comment></comment></comment><comment><USER14> The problem with this assumption is that one doesn't have to be aware of how their own brains work in order for them to work.

The fact that people seem to be universally bad at assessing probabilities means only that however their brains work, that mechanism doesn't produce intelligences that are finely adapted at assessing probabilities. The machinery that is producing that intelligence could still be completely probabilistic itself.

Humans are fantastic at pattern recognition, but that doesn't mean that our intelligence must have been _created_ by a pattern recognition algorithm.

<comment> guard-of-terra We can't say that humans are fantastic at pattern recognition either. We may only be sure that our built-in pattern recognition is better than our ability to create pattern recognition algorithms.

</comment></comment><comment><USER15> I disagree with some of the premises.

We are great at probability, we compute it unconsciously. Every person knows the approximate probability of flipping a coin to show heads, pulling a card from a stack, or being rejected/successful when asking a date out (we always say our 'chances' are good/bad, depending on factors we think are important).

In our day to day lives, many decisions are driven by what we think the 'odds' are of our endeavor being successful.

<comment><AUTHOR> I am not sure if I intuitively know it or do we have to consciously compute / infer it? (the coin/card example).

I guess I have some aprox feeling, but it's highly susceptible to being skewed.</comment></comment>


Coming Soon - The I2 Instance Type - High I/O Performance Via SSD - <AUTHOR> http://aws.typepad.com/aws/2013/11/coming-soon-the-i2-instance-type-high-io-performance-via-ssd.html

<comment><USER2> Of particular note for distributed operational data stores is the focus on "significantly higher [network] performance (in terms of packets per second)". This (and High I/O instance pricing) has been a major obstacles to getting great results for these type of systems on AWS.</comment>


Farmers and Apple Fight Over the Toolbox - <AUTHOR> http://time.com/4828099/farmers-and-apple-fight-over-the-toolbox/ <comment><USER2> I needed to replace the battery in my MacBook Air. My local authorized Apple repair shop said it would take a week. I couldn't do without my laptop for a week so I bought the battery online and replaced it myself in 5 minutes. Apple is obviously not making laptops for professionals if it thinks users can be without their laptops for a week. It might be quicker in countries that have an Apple store and not just a European headquarters.</comment>


Fix the PhD - <AUTHOR> http://www.nature.com/nature/journal/v472/n7343/full/472259b.html

<comment><USER2> When I saw this article, I briefly thought that the editorial board of the Chronicle of Higher Education had taken over Nature. Depressing articles of this sort are published in there on a regular basis.</comment>


Show HN: libRmath.js – A port of R's Nmath numeric library to JavaScript - <AUTHOR> https://github.com/jacobbogers/libRmath.js <comment><USER2> JS can be a serious language in the data science and scientific computation fields, but one of the biggest ecosystem weaknesses is the lack of numeric libraries. This library is very promising!

<comment><USER3> Unfortunately it is impossible to implement efficient numeric libraries in JavaScript due to the lack of SIMD and GPGPU.

<comment><USER4> I assume you're talking about in the web browser/pure js? Because otherwise you can just bind to the native CUDA etc. libraries like most other languages do.

And even on the browser side SIMD is being implemented in WebAssembly and (limited) GPGPU will be possible via WebGL 2.0 compute shaders. So as such I don't see any reason why JavaScript couldn't at the very least match python/numpy in performance if someone put their mind to it.

<comment><USER3> About 5 years ago, SIMD.js has been announced, was implemented and then scrapped in favor of SIMD in WebAssembly, which does not exist until today. It has been announced, but I would not hold my breath for it. Presumably we'll only get 128-bit wide SIMD anyway, so another 2x to 4x waste of computing power there.

Additionally, 4 years ago, WebCL was announced and implemented in some browsers, but then it was scrapped in favor of compute shaders in WebGL 2.0. When WebGL 2.0 finally arrived, it did not have compute shaders. Instead, they have been delayed to be implemented as an extension at some indefinite point in the future.

Sorry if this sounds a bit grumpy, but I have been disappointed too often to be enthusiastic about this.

There are also issues like floating point rounding modes in JS and floating point precision in WebGL that have to be addressed. Should not be too hard, but who knows.

</comment></comment></comment></comment><comment><AUTHOR> I Want to put this here as a first level comment, some people (well actually only one) are making up stuff that JavaScript "fudges" floating point numbers.

Some ppl are going to make up drame to "sound interesting" but i dont see how that is FACTUAL.

The README contains over 8900 lines of 200+ well documented standalone code examples samples comparing JS and R code ,side by side for every function call.

THE RESULTS ARE EXACTLY THE SAME!!

Name dropping like web

</comment><comment><USER5> I am really suspect of this being actually useful for highly technical work. Why? Because I work with R, and the math that is done has very specific results that fudging floating point numbers may be a concern. I don't know enough about Javascript to be certain, but I feel like (from memory) that it does not maintain numeric accuracy at a certain level.

I am not the R nerd, my friend with the PhD is, I just do the coding around it and help clean up his brainy coding. (ie, he can code ok, so he creates the initial R code, and I clean it up so I don't go mad having to work with it) But he explained that even Excel (which I will bet is more accurate than JS) will put out inaccurate results because of number fudging at some level. (again beyond my nerd level to grok)

All of this is too bad, because R syntax is just plain rotten icky stuff. (but I may be seeing things with some of the examples looking like awful R syntax... maybe I need sleep)

Edit: Here's a comment on JS number accuracy, basically what I recalled. (this is a quick search, so take some salt with it). The issue being how JS decided to "fix" the numbers for me, felt like the magic semi colons, only not as predictable.

 _" In JavaScript all numbers are IEEE 754 floating point numbers.[1] Due to the binary nature of their encoding, some decimal numbers cannot be represented with perfect accuracy. This is analagous to how the fraction 1/3 cannot be accurately represented with a decimal number with a finite number of digits. Once you hit the limit of your storage you'll need to round the last digit up or down."_

[0] [http://adripofjavascript.com/blog/drips/avoiding-problems- wi...](http://adripofjavascript.com/blog/drips/avoiding-problems-with-decimal- math-in-javascript.html)

[1] [https://en.wikipedia.org/wiki/IEEE_754](https://en.wikipedia.org/wiki/IEEE_754)

<comment><USER6> That problem is normal and expected behaviour for finite precision floating point: it appears with any scheme for floating point (IEEE-754 or not), as computers are finite. A significant chunk of the field of numerical analysis is about controlling the error introduced by floating point.

And, anyway, R uses IEEE-754 for 'numeric' too[0], and will do the same "fudging":

 _> All R platforms are required to work with values conforming to the IEC 60559 (also known as IEEE 754) standard_

There's fair criticisms that JS may not offer the required control over rounding modes that R (or the C libs underlying R) provide or the necessary instructions to minimise error accumulation, but general handwavings about "fudging" of floating point don't apply: floating point is unavoidably imprecise, and R and JS even use the same basic format.

[0]: [https://stat.ethz.ch/R-manual/R-devel/library/base/html/doub...](https://stat.ethz.ch/R-manual/R-devel/library/base/html/double.html)

<comment><USER5> > _...general handwavings about "fudging" of floating point don't apply..._

Handwaving is all I can do, I am just the tech taking orders.

I just talked with my statistician friend on the phone, here's one issue my friend just showed me. (integer error, not even floating point)

111,111,111 * 111,111,111 = 12,345,678,987,654,321

(I did this by hand to confirm, he made me the big meany)

Excel, Libre Office, my calculator, Javascript, etc.. all get this number wrong. But with R there's a library that can add support for numbers this big. (I guess this is a well known issue)

Edit: _All_ numbers in JS are floating point numbers, there are no integers... <hmmm>

 _" In JavaScript, all numbers are implemented in double-precision [...] There is no specific type for integers."_

Edit 2: (for fun) This is from R:

      > library(gmp)
      > bignum <- as.bigz(111111111)
      > mul.bigz(bignum, bignum)
      Big Integer ('bigz') :
      [1] 12345678987654321

[0] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Guid...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Guide/Numbers_and_dates)

<comment><USER6> _> Handwaving is all I can do, I am just the tech taking orders._

Even "the tech" can have some understanding of finite precision integers and floats, and how they behave, given they're building blocks of the trade. It seems somewhat relevant to knowing what changes are valid to code. [http://floating-point-gui.de/](http://floating-point-gui.de/) is a great place to start if you're interested in learning more. :)

 _> Edit: _All_ numbers in JS are floating point numbers, there are no integers... <hmmm>_

Not having any native integers is unfortunate and annoying, but there are various tricks to ensure numbers are integers (e.g. floats exactly represent integers up to 2^53) plus various tricks to convince the JS engines that things are guaranteed to be integers for optimizations. These are clunky and ugly hacks, but they're _possible_ and even more possible when using JS as a compilation target from a different language (e.g. asm.js in the extreme).

 _> I guess this is a well known issue_

Indeed, it very much is. As you demonstrate, even R doesn't allow doing your example calculation natively, you need to import a library... something that can be done just fine in JS too: for arbitrary size integers [https://github.com/Yaffle/BigInteger](https://github.com/Yaffle/BigInteger) and for arbitrary precision floats [https://github.com/charto/bigfloat](https://github.com/charto/bigfloat) (among many examples). It's true that these won't approach the performance of GMP due to lack of access to the specialized instructions it uses, but they offer the same basic functionality.

That said, I agree with the general sentiment that JS is suboptimal for scientific computing, but mostly because of performance (although R's performance falls off _very_ quickly when using anything other than vector operations) rather than inaccurate concerns about precision.

<comment><USER5> > _Even "the tech" can have some understanding of finite precision integers > and floats, and how they behave, given they're building blocks of the > trade._

I do have "some understanding". But not enough to processing millions of records and notice that one or two numbers of output, out of hundreds, aren't correct. That's the PhD's job.

<comment><USER6> Concepts like finite integer sizes (aka integer overflow) and finite floating point precision (1/3+1/3+1/3 != 1) aren't PhD-level concerns. :)

</comment></comment></comment></comment></comment></comment><comment><USER7> I sometimes wish I had launched a similar porting effort with SageMath...

</comment><comment><USER8> Perfect timing. Author if you're reading this thanks for sharing/porting this, was just on github looking for a solution yesterday.

<comment><AUTHOR> Thanks, Note, JS is breaking benchmarks if compared to Python!

</comment></comment><comment><USER9> Great work. Thanks!</comment>


Exploiting MySQL arbitrary file read: a honeypot that kicks - <AUTHOR> http://www.abclinuxu.cz/blog/jenda/2019/2/exploiting-mysql-arbitrary-file-read-a-honeypot-that-kicks <comment><USER2> > Okay, so what to do with this when I don't want to do any harm? I have > contacted abuse@ for the given addresses, but unsurprisingly received no > reply.

shutdown -h now

</comment><comment><USER3> OK this is is fun but can anyone describe a scenario where this is actually dangerous...?

<comment><USER4> My immediate thought is if an attacker gains control of your MySQL server they could use this to help propagate across the network (and of course grab arbitrary data from everything that connects).

<comment><USER5> No actual MySQL server is involved in this...

</comment></comment></comment><comment><USER5> Retrieving the keys and other interesting bits under ~/.ssh might have a higher success rate, and no hash cracking needed.

</comment><comment><USER6> my first thought is, no surprise this is being described by someone with a visibly non-American domain, as this would be a fairly textbook breach of CFAA, right?

<comment><USER7> The connection is initiated by someone who isn't authorized for _your_ server. Don't see anything fraudulent in requesting a file they are free to ignore.

<comment><USER6> Tell that to weev. His case was only overturned on a technicality. His conviction was for enumerating an unsecured API by sending requests that the server was free to ignore.

[https://www.washingtonpost.com/news/the- switch/wp/2014/04/11...](https://www.washingtonpost.com/news/the- switch/wp/2014/04/11/hackertroll-weev-will-walk-free-but-the-court-didnt-rule- on-the-main-issue/)

<comment><USER8> There is a technical difference here though.

weev was actively initiating that connection to somebody else's server. In this case, the honeypot is sitting idly, and _responding_ to someone else's connection (in a manner that's clearly unauthorised), and it's responding with something valid but unexpected.

Not that I'd want my lawyer having to explain that difference to a jury...</comment></comment></comment></comment>


Patents on Software: A Nobel Laureate's View - <AUTHOR> http://www.nytimes.com/2012/10/15/opinion/patents-on-software-a-nobel-laureates-view.html?_r=2& <comment><USER2> The argument made is not unique to software or computer algorithms. Chemical process patents are identical to computer algorithm patents in this respect, just replace bits with molecules, and are among the oldest patentable subject matters. Long, complex sequential algorithms are a feature of many engineering disciplines.

Chemical engineering, to use that example, designs elaborate and complex dynamic systems by chaining together abstract chemical algorithms. Each one of those little algorithms is subject to both patent and copyright. Like with software most of the commonly used algorithms and clever hacks were either never patented or the patents have long expired. It is only on the bleeding edge that some chemical algorithms are under patent; as with computer algorithms there are an unbounded number of potential algorithms but some are more efficient than others. Specific implementations are still covered by copyright and are widely licensed (as libraries).

Most of the nominal specialness attributed to software as a domain for intellectual property does not really exist. Yet the rarely questioned assertion that computer software is special in some way has created a dearth of comparative studies that would likely be valuable from both a theoretical standpoint as well as a practical policy standpoint. Either these other areas, like chemical processes, are equally broken at a fundamental level and the scope should be extended beyond software, or there are differences in implementation across otherwise equivalent domains and we should borrowing from the better implementation. It seems like an oversight that no one is attempting to do either.

<comment><USER3> One thing that seems to be missing from the interpretation of the article is whether or not the temporary monopoly granted by patents is necessary in software patents. When answering this question, one should definitely look at the speed of both innovation and obsolescence, combined with strength of competition.

There have been a large number of good papers published all coming to this one conclusion - speed to market in current software markets is the ultimate strategic advantage and source of reward. Most other things can be copied quickly enough, but the landscape is evolving fast enough that innovators can constantly one-up the competition, reaping greatest rewards.

By contrast, in capital-intensive, slower industries, these "guard rails" make a lot of sense - if it takes me years to make a breakthrough on the drug, but means of copying it a re super straightforward because I am required to publish the recipe for all to see, it makes sense to restrict the use of the recipe.

I don't see anyone publishing Google search algorithms for all to see. In fact there is an entire industry that focuses on guessing what it is - SEO.

To me personally, it boils down to this - if we make it super easy for competitors to ride your coat-tails by forcing you to disclose your secrete sauce, then it's fair to try and give you some protection. If we leave you to compete without that interference, than we should not extend the extra protection... (this is just strictly a personal view, grounded more in my ethical views than anything else).

<comment><USER4> Its a fun exercise to try to imagine what the medical/drug industry would look like sans patents. If it was infeasible for a corporation to spend many years and (m|b)illions of dollars to develop a drug because as soon as you did a competitor would copy it, would we still have drugs? If we did who would make them?

In the future advances in science and computer modeling should make drug development much more rapid than it is today. This could vastly lower the cost to bring drugs to market and put drug development easily within the grasp of a large non-profit organization.

Imagine that instead granting a private company the exclusive right to sell a drug, that instead everyone invested in its development and upon its discovery its formula was shared freely. For most drugs, the synthesis is not a major component of the cost. This would lead to rapid deployment of the drug at very low cost to those who need it.

If there was no copyright law, you can be sure there would still be drugs! And perhaps health insurance companies would be interested in drug development. Fewer sick people and cheaper medicine should lead to greater profits.

</comment></comment></comment><comment><USER5> Note there's a flip side to this -- the timescale of software patents is completely wrong from the viewpoint of a company that wants to use patents honestly.

I was looking at a face recognition patent that was filed by the US by a Japanese company in 1998 that was finally issued in 2006. Eight years is a very long time in the fast moving software industry -- even if you get lucky and your patent granted in two years, it's quite possible that your invention is obsolete by the time you get your patent.

Given that software is so fast paced, most organizations that expect to be "practicing entities" find the patent application to be a distraction from the task of getting a competitive product in the marketplace. This is a very different situation from other fields where you really can get a patent for a mechanical or electronic thing and then have the patent as a tool for negotiation w/ manufacturers.

<comment><USER6> Yes. We probably need a brand new category for software; something that grants protection faster, expires sooner, makes it easy to other people to implement after expiration, and has independent invention as a positive defense.

<comment><USER7> Or, you know, we could just get rid of software patents entirely. Less paperwork for all, and we can get back to shipping code without worrying.

<comment><USER8> If only it were that simple: one of the first, pragmatic challenges to this process would be to define a software patent. Remember that algorithms are not supposed to be patentable, so most of these "software" patents actually include elements of hardware, however broad.

</comment></comment></comment></comment><comment><USER9> The whole "protecting intellectual property" thing could work if it was possible to issue patents in an unbiased and consistent way but patent examiners are human beings and they do some research on the issue, read the arguments from the patent lawyers and come to a (usually biased) decision. You even see cases where a patent is rejected 9 times and get accepted the 10th time. It is extremely difficult to come up with an unbiased, consistent and all-knowing (past work) way to issue patents, I'm not even sure if it's possible at all. And that's another reason why there should be no patents issued at least in the software industry.

</comment><comment><USER10> Doesn't the problem with imaginary things like gods, beliefs or intellectual property begin when someone tries to claim they are real and you must obey them?</comment>


The Economics of Knowledge Sharing - <AUTHOR> http://blogs.hbr.org/2014/10/the-economics-of-knowledge-sharing/

<comment><USER2> For anyone interested, here is a direct link[1] to the scientific background to Tirole's 'Market Power and Regulation' ideas, which were kindly compiled by the committee. Open source is first mentioned on page 27 (out of 54).

[1]: [http://www.nobelprize.org/nobel_prizes/economic- sciences/lau...](http://www.nobelprize.org/nobel_prizes/economic- sciences/laureates/2014/advanced-economicsciences2014.pdf)

From the paper:

Open-source software: The literature on patent races assumes that R&D investments are driven by the traditional profit-motive. However, economists are increasingly realizing that not all new technologies originate in this way. An important example is Open Source Software (OSS), where programmers at many different locations and organizations share code to develop new software. This process was important in the development of the Internet, contributing such software as TCP/IP, BIND, Perl, Sendmail, Linux, Mozilla and Apache. What initially baffled economists was that OSS developers did not seem to benefit financially from their efforts. OSS is, in effect, a public good, which raises the question why OSS programmers contribute voluntarily, without pay, to the public good. Lerner and Tirole (2002) argued that economic theory may, in fact, be able to answer this question. Their main hypothesis is that software developers have career concerns. Contributing to the OSS may be a credible signal of one's programming ability, which may lead to job offers, shares in commercial open source-based companies, or access to the venture-capital market.35 Drawing on a previous literature on career concerns (e.g., Holmstrom, 1982), they argue that the signaling motive is stronger the more visible is performance, the higher the impact of effort on performance, and the more informative performance is about talent. They find support for the signaling motive in four case studies (Apache, Linux, Perl and Sendmail). Subsequent research also found support for Lerner and Tirole's (2002) signaling theory, at least for some OSS projects (e.g., Hann, Roberts and Slaughter, 2013, for Apache). However, programmers seem to contribute to OSS for a variety of reasons, perhaps including altruism. A satisfactory explanation of OSS development may require a mixture of signaling theory and insights, like those of 2009 Economics Laureate Elinor Ostrom, into how cooperative behavior can be supported by norms and other social mechanisms (O'Mahony, 2003).

<comment><USER2> Having read the paper, and taking the time to think about the whole 'signaling' explanation for open source, I'd say that in addition to ego and joy, signaling is a major motivator for contributing to open source software. While many programmers may contribute to any arbitrary project because of their interest or dependence on the software, the most effective way to signal your skill as a developer would be to contribute to software that is either a) used by the prospective employer to support their business, or b) developed by the employer himself (likely to support their business).

However, this theory doesn't take into account that one may contribute to an OSS project, because an employer is paying them to do this in the first place. Both employers and employees participate in OSS. Employees want to demonstrate their skill so that they would get employed, while employers want to demonstrate their organization's engineering talent to attract even more talent. The paper seems to assume that OSS signaling is simplex, whereas it is actually duplex. But beyond signalling, an organization open sourcing software can be seen as a way to encourage standardization of that software (Android, WebKit, V8, and in the future maybe Dart) instead of a competitor's potentially closed alternative (which might be more expensive to deploy/port/debug and so on).

Sun Microsystems' open sourcing of Solars and JVM can be seen as an attempt attract more talent to the company (which at that time was fairly unpopular, especially when compared to Google which was an open source darling).</comment></comment>


Show HN: Parkgene ICO, which brings parking on the blockchain, is now live - <AUTHOR> https://parkgene.io <comment><USER2> Alot of uber type parking apps failed.

curious why a blockchain will work?</comment>


Daily SnapShots Of Hacker News - <AUTHOR> http://www.kirubakaran.com/phr0zen/ I wrote a simple python program to make daily snap-shots of the front page stories and comments and post it in reverse chronological order. I wanted this tool as I didn't want to miss out on anything on the days that I couldn't spend much time here. Regular RSS reader didn't fit. Any suggestions welcome. <comment><USER2> Awesome. I had been thinking about building something like this for a while. Here is a tip (I am handing over the rest of my idea to you now): Index the content of the actual articles (follow the links). This would offer a perfect way to search for stuff you once read on ycnews. I usually remember what I read, not what the ycnews title was. It could also be easily extended to index reddit, digg, or any other link driven site.

<comment><AUTHOR> Thanks! I'll build that.

</comment></comment><comment><AUTHOR> I wrote a simple python program to make daily snap-shots of the front page stories and comments and post it in reverse chronological order. I wanted this tool as I didn't want to miss out on anything on the days that I couldn't spend much time here. Regular RSS reader didn't fit. Any suggestions welcome.

<comment><USER3> Nice! Of course, now you have a feed that would be useful for news aggregators if you provided RSS. Here's some quick suggestions:

Front page isn't the ultimate snapshot. If you wanted that, wouldn't you rather take the 20 submissions from the last 24 hours that got the most up- votes? If I understand correctly what you're doing, you get some 1 and 2-point submissions that just happen to be on the front page at the time.

Returning more to your use scenario, an alternative that gave you more control on how much to read would be to take the time you last read HN and use that to filter the list at <http://news.ycombinator.com/best>

<comment><AUTHOR> Thanks :-)

I wrote it so that it saves front page because that is how I personally read HN. On the days that I am not able to check HN (like it happened to me last weekend), I don't know what made it to the front page. You are correct that this is certainly not the best way to do it. As bootload mentioned, the 'best' page is limited to 180 links and if the points gained a new post is less than that of the 180th post in 'best', then it won't make it to that list. May be we should collect links from front and front+1 page that are more than a day old and sort them in descending order of points? Your thoughts welcome.

<comment><USER3> Indeed, I wasn't considering such implementation issues as the link limit of 180. Collecting links from some of the /news pages should be a good approximation. For longer times away, the collected links could be stored periodically and upon return sorted by points, descending.

</comment></comment></comment></comment><comment><USER4> _"... I wrote a simple python program to make daily snap-shots of the front page stories and comments and post ..."_

I'm doing 15 minute snapshots in xml format from the news feed /news (meaning score threshold is >=2). You can find the feed here ~ [http://goonmail.customer.netspace.net.au/hackerid/xml/hacker...](http://goonmail.customer.netspace.net.au/hackerid/xml/hackerid.xml)

I capture posts from /news including ...

      <user>iamyoohoo</user>
      <inception>118 days ago</inception>
      <karma>60</karma>
      <item>60759</item>
      <title>
      What nine of the world's largest websites are running on
      </title>
      <url>http://royal.pingdom.com/?p=173</url>
      <points>23</points>
      <comments>9</comments>
      <posted>11 hours</posted>

Q's

\- Are you going to sort them by anything date, score, user or just date order?

\- Supply a data feed? \- identify user

\- are you archiving them?

Like yourself I wanted to grab stuff so I wouldn't miss it. Another was to capture metadata and add some useful extra stuff like

\- identify users by various metrics

\- graphing of data

\- capture relationships b/w users, data

You can only do this with raw data. I'm thinking about archiving the data at least at some time.

Good stuff btw. I like this because the more resources we have like this the more fun you can have and more value you can add. If I have one request that would be to add a data feed that anyone can pull and use.

You can read how here ~ <http://goonmail.customer.netspace.net.au/hackerid/colophon/>

<comment><AUTHOR> Wow! Your HackerID tool is impressive. (I was wondering how I missed that and realized that I was vacationing in LA when you posted that... the very reason I wrote 'phr0zen news')

At the moment, I am just grabbing the front page RSS and posting it like a blog. I would like to do the following too:

1\. Deep Search - Index target webpage, comments, weighted by points gained by post/comment itself and submitter/commenter-karma. For example, I was to be able to search and read everything ever said here about EC2. This will be very useful for me personally, so I have good selfish reasons to do this.

2\. Relationship between users (as you mentioned) - a graphical representation... what we uncover might be interesting. ( Users that pg replied to will have a 'knighted' symbol next to them ;-) )

I will supply a feed as soon as I figure that out. Is there a way to grab ALL the data from HackerID? BTW, when I read 'name the best hacker news contributers', I thought it is a contest :-)

<comment><USER4> _"... Is there a way to grab ALL the data from HackerID? ..."_

Yes.

I've been saving the individual files since I've run the system as ISO8602 filename ".xml" since it started. I'm going to now write some code to store it in a db beats the 4Mb of text files I have. Also I want to write a quick script to add the archived files to the db.

_"... Users that pg replied to will have a 'knighted' symbol next to them ;-) ..."_

Nice touch. What I'm doing is checking if users on the leader board top 30 or top10 or number 1 and adding a star with 10, 30 or 1. Im also working on filters for 'pg' meaning he's off the board.

I tell you what would be nice is to synchronise the snapshot captures (by ISO-8602 time stamps set to Zulu time ie: 2007-09-30T00:16:42Z or now). This means you can at some later time import any data into a db and do a query by time.

 _"... when I read 'name the best hacker news contributers', I thought it is a contest :-) ..."_

Yeah good point. Might have to change/tweak this it a bit. Maybe add a question mark.

My objectives at the moment are to

\- do deep search on hacker by article in _"new/"_ and extract WHO is making comments and build some sort of heirarchy of user interaction with link to comments

\- do some stats on the hacker data

\- " a graphical representation." I'll be using grahpviz ~ <http://www.graphviz.org/Gallery.php> You can see here some initial testing I've done (with static data) ~ <http://flickr.com/photos/bootload/1291043939/>

On the last one I'm finding a lot of variation b/w karma, comments. points and time. Interesting to see. The real objective is to release this as data rather than just pages so users can use the data (not sure about RT) to look at things on a particular day.

My objectives are different from yours keep up the good work and plz try to make the data free for use by others to use.</comment></comment></comment>


Privilege Escalation with Kill(-1, SIGKILL) in XNU Kernel of MacOS High Sierra - <AUTHOR> http://www.openwall.com/lists/oss-security/2017/10/12/1 <comment><USER2> One follow-up for the discussion on if this is a DoS or privilege escalation, in the logs we saw:

        Service exited due to signal: Killed: 9 sent by nix-daemon[54108]

and were able to (inconsistently) reproduce this with other unprivileged users.

This indicated to us that we hadn't tripped just a crashing bug, but actually escalated beyond the normal access control protections of kill.

</comment><comment><USER3> This breaks the Nix package manager. And we have no other way to reliable kill processes on macOS unlike Linux, where we can use cgroups.</comment>


Rescuing Resque again (2015) - <AUTHOR> http://words.steveklabnik.com/rescuing-resque-again?hn <comment><USER2> In my opinion, Resque so far failed because like a lot of OSS projects (and unlike Sidekiq), it isn't built on sustainable economical grounds - from the maintainer POV.

Bringing outside "funding" can work for a while (see JRuby), but when the funding stops, it only underlines that the financial engine should really be carefully "designed" at the core of the OSS project, for things to be maintainable on the very long run. Otherwise history is bound to repeat itself.

Large projects can enjoy a large pool of contributors, sometimes with less risks of burn-out (often seen on small OSS projects around me at least), each contributing marginally, with a few paid core members (either directly or indirectly via by-products of a well paid activity), but for smaller projects like Resque, it's more likely a single individual full-time, paid by the project.

Again Sidekiq is really a great inspiration here for me (disclaimer: I plan to launch a "pro" offering for an OSS project I manage at [http://kiba- etl.org/](http://kiba-etl.org/), and maintained another open-source for a while before which ultimately went to the cesspit).

<comment><USER3> Yup, this is exactly it. The only reason I was able to do all the open source work I did was because of my job at Jumpstart Labs, and once that ended, well...

That said, as you mentioned, this is pretty much the default state for the large, large part of open source projects. Something's got to give somewhere, eventually.

<comment><USER2> What is your take on the Sidekiq model? I'm really curious to hear more about that :-)

I see a number of people around me currently thinking about putting a "fair salary" at the core of their future open-source work. Often it completely changes what the delivered value should ultimately be etc (something I think Mike did think about - I believe).

Do you have thoughts on that approach?

<comment><USER3> My thoughts are mostly "I'm glad it's working out for Mike, and I hope others can follow his path." I personally have taken pursued the patron model, but that also is because with Rust, that's the only real way to do it.

<comment><USER2> By patron model, to clarify, you mean a single large company paying most of the bills and bringing funding, right? (either because they want to promote innovation, or this generates financial gains, etc etc)?

I would also think that for a language, this is probably the best model (even if it failed with IronRuby, or if JRuby funding sources moved over time etc).

This is a fairly large endeavour, so it makes sense (at least I believe it!).

<comment><USER3> Yes. Though I mean me personally, not the language itself. I wanted to work on Rust full time, Mozilla wanted to hire someone to work on Rust full time, it fits.

<comment><USER2> It's great that it works for you one on one, sincerely! I hope though that we will see more occurrences of OSS projects where N customers are sending money to directly finance the sustainability of the OSS product, just because it delivers value for them (not a moral obligation or PR etc - note that I'm not stating that Mozilla is doing this!).

I feel for libraries & components (unlike languages maybe, as we said), at that specific scale, it can work very well.

<comment><USER3> I do too.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> Hi all! Happy to answer any questions about this effort. I'm targeting 1.26.0 sometime in the next couple of weeks.

<comment><USER4> Thanks for all your hard work on this over the years!

Something I've wondered for awhile: what are the benefits of continuing Resque development, rather than focusing on making the migration path to Sidekiq as painless as possible? Put another way, what do you hear from users of Resque (like Shopify, as you mentioned in another comment) as the reason that they don't want to migrate off of it?

I was curious about this way back in 2012 when you announced work on Resque 2.0, and I had already made the switch to Sidekiq. I thought there must be a good reason to keep working on it, but I wasn't sure what it was, and I'm still not sure, so I figured I'd just ask.

<comment><USER3> Sidekiq has a lot of attention amongst new developers, but has at least an order of magnitude less users, at least, if gem downloads are something to go by. So from my standpoint, those people deserve bugfixes, and "throw away what works just to transition to something new" isn't really a great response.

Threading vs process-based jobs is a tradeoff. Threads are not universally better.

<comment><USER5> As of today, Resque has 6,308,611 downloads. Sidekiq has 5,669,265 downloads. Can you explain why you think "order of magnitude"?

<comment><USER3> Hey Mike! Sorry, I 1) mis-read that number, 2) when we used to release more often, the download counts for latest versions used to be 10x yours. I don't think that's true at this point. I will update that cache in my brain and not say this again, I apologize.

<comment><USER5> No worries, I just wanted to make sure you didn't have access to super secret Ruby usage numbers that I didn't!

<comment><USER3> I wish. :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I have to be honest here. My initial thought when reading this a couple of weeks back was that some things are better left to dead.

Resque has been an example of how not to run an open source project for a while now. (3+ years).

We were working with Resque for a long while and had a lot of issues with performance.

Sidekiq is awesome and it's being well managed and releases are frequent.

But, after thinking about it, I think that Resque has it's place in the community, I definitely think that more than a single project doing this task is needed.

Many people are already familiar with Resque and trust it, those people should be taken care of.

I wish everyone involved a lot of luck with it.

<comment><USER4> This is another good answer to the question[0] I just posed to Steve. You're right that competition is generally good. On the other hand, it would (arguably?) be much more "Rails-y" to have a single conventional solution that works well and gets a lot of eyeballs. Neither Resque nor Sidekiq are that thing though. It has always struck me as a bit odd that Rails outsources the decision on this component, which nearly every Rails project needs. I think previously it was probably to avoid an external dependency (on Redis), but perhaps that could be reconsidered now that >5.0 has eschewed that avoidance.

Having said all that, one of the things that is most exciting to me about Elixir/Phoenix is that this sort of thing doesn't even come up, because a great and mature solution is built directly into the runtime.

[0]: [https://news.ycombinator.com/item?id=10911600](https://news.ycombinator.com/item?id=10911600)

<comment><USER3> Newer Rails has ActiveJob: [https://github.com/rails/rails/tree/master/activejob](https://github.com/rails/rails/tree/master/activejob)

</comment></comment></comment><comment><USER7> When i started my project, I used Resque but almost immediately switched to Sidekiq a few months later. I understand it's almost impossible to run into thread safety issues with Resque, but if you're doing anything CPU intensive, Sidekiq really offers much higher performance. The maintainer also makes a living off Sidekiq, selling it to businesses and enterprises too so you can expect more frequent updates.

<comment><USER8> > but if you're doing anything CPU intensive, Sidekiq really offers much > higher performance

The threading model (LWPs vs. forking) should have no impact whatsoever on how quickly a CPU-intensive task completes.

<comment><USER9> Unless it's a short-lived CPU intensive task, in which case in matters a great deal.

<comment><USER8> The overhead of fork() is negligible, well under 0.1ms.

<comment><USER9> There's also the issue, in ruby, that CoW doesn't really work due to the fact that the GC dirties all pages.

<comment><USER5> This was fixed in Ruby 2.0.

</comment></comment></comment></comment></comment></comment><comment><USER10> The "again" in the title confused me. I knew that I read an article along these lines a while back so I thought this is yet another one. Turns out it was this post, which is dated October 23, 2015.

<comment><AUTHOR> Aw poo...missed the date when I read it, and haven't seen it before. I'll update the title.

</comment></comment><comment><USER11> I almost alway use Que [1] now. It uses postgres advisory locks instead of Redis so one less dependency to worry about. You probably only need Redis if you're running a tonne of jobs.

[1] [https://github.com/chanks/que](https://github.com/chanks/que)

<comment><USER12> Rails 5 will require Redis so in the future it will be a dependency anyway ...

<comment><USER13> Rails 5 does not require Redis unless you want to use Action Cable.

</comment></comment></comment><comment><USER14> Interesting to note that the current stable branch has commits a couple of days old.

<comment><USER3> Yes, I've been doing some work, and so have some other contributors. Shopify is upstreaming some patches so they can get back on master.</comment></comment>


NYC Tech Boom: Not Just Mini Silicon Valley East - <AUTHOR> http://m.cnbc.com//id/100553792

<comment><USER2> Not the first time I have read about this, but I am always curious about the costs. NYC has some significant tax burdens, and property is difficult to find and costs are high, correct? Does the professional population density offset these costs?

 _Disclaimer: I love NY_</comment>


If someone asks if you have any questions, ask a question - <AUTHOR> https://kevin.burke.dev/kevin/ask-questions-during-interviews/?hn <comment><USER3> > Even asking "what did you have for lunch" is better than asking nothing; the > interviewer might start talking about whether the company pays for lunch, > whether it's any good.

No, it's not. I'm pretty sure anyone who asked that in an interview would be bottom of the list, regardless of how I felt about their interview otherwise. It's flippant and shows a lack of care about what's going on.

Iv'e never been upset with someone for not asking questions. Interviews are tense and we _do_ try to answer the most common questions before they are asked. If they have no questions, we extend and offer to email us later and we'll answer any questions they come up with later.

Stupid question affect the interview. Lack of questions doesn't.

<comment><USER4> Haha, wow. No sense of humor? As a hiring manager I've run somewhere north of a hundred interviews, and honestly they get so boring and repetitive. I love it when people have questions because it shows you something about them which wasn't on the script.

If someone's question was "what did you have for lunch?" and they asked with a smile, I would laugh out loud and then tell them about my lunch, and probably write something like "likeable candidate, has good people skills," in my review.

<comment><USER5> > As a hiring manager I've run somewhere north of a hundred interviews, and > honestly they get so boring and repetitive.

What an insane thing to say. As if on top of everything else, you also want us to entertain you? Does anybody really believe someone would laugh at that?

<comment><USER6> This response doesn't seem warranted. GP didn't say you're his monkey. He said the job gets boring. Candidates with good people skills get hired more often because they bring a little more joy to the workplace. And, all other things being equal, that decision makes perfect sense.

</comment></comment></comment></comment><comment><USER7> When I'm in an interview I always end up turning the interview around and interview the the interviewer.

Interviews are a two way street. They want to make sure you suite a role but you also need to make sure the role is suitable for you, you are going to enjoy it and get something from it. I go in with the mental view they need to sell the job to me.

Doing consultancy I've been at many companies, some great some bad. I go straight to the questions trying to dig up as many warts as possible to figure out what I'm letting myself in for as I've seen how much different companies can differ.

What are you working on this week?

What's a typical day?

What's the current tough problems you have?

Do you do much out of hours work?

Why do you use the tech stack / tools you do?

How do you manage work, do you do scrum/Kanban/x/y/z. How's your backlog? What are the upcoming releases, are they on schedule? Who manages features, who and how is the product owner?

How's the team?

What's been your favourite part of your job so far?

How's the business make money? How much funding do they have and what happens when that runs out? How's the current projections will my job be here in 12 months?

Why are you recruiting for this role? How is staff turnover?

Any bad things I should know?

Etc etc

<comment><USER8> As a long time interviewer, I've heard most of these, but never all together. I'd love to get all these questions, and my opinion of the candidate would go up if these were asked. The worst is when the candidate has no questions for me.

<comment><USER9> It would be easy to overshoot and then be perceived as this arrogant know-it- all. There are warts everywhere.

You should strike some balance between the impressing the employer and attempting to dig up the warts.

Sure, if the employer has accepted that they are in over their heads, it's a valid strategy to try to find all of the warts up front. Think about a home owner vs a specialized contractor who performs a brutally honest and (seemingly) credible analysis on the spot. How often does this scenario play out in the extremely vague world of software?

(In this subthread we're talking about consultant interaction with a potential employer, which is a bit different from a regular job interview, or from a scholarship interview)

<comment><USER10> > You should strike some balance between the impressing the employer and > attempting to dig up the warts.

Very true. I feel like a few comments have said the same thing, but it's worth saying a few different ways.

I remember from "How To Win Friends and Influence People", the author describes how he simply asked someone a lot of questions at a party, and let them do all the talking. Later he heard that person thought he was an excellent "conversationalist", even though all he did is ask questions.

Don't be too adversarial in you questions. Simply asking some friendly questions that give the interviewer a chance to talk about their achievements and interests will cause them to like you more.

</comment></comment></comment></comment><comment><USER11> This reads as an extended justification for how the author could possibly have failed. He writes as though it _must_ be as simple as 'just should have asked a question'. It's an odd conclusion which communicates its own set of assumptions. It reminds me of people who claim, in all seriousness, that they can always spot X intangible characteristic — without any justification for how they determine their false positive/negative rate in that judgment. This undoubtedly reflects my bias, but I find many (bordering or even definitely including most) 'humble' blog posts to do this; and that is perhaps a further riff on the kind of canned advice we see here. They tend to read, to me, like answers to the interview questions, "Tell me about a time you failed," or, "What is your greatest weakness?" In this case, all the author really reports is that he did extremely poorly relative to his expectations — but he manages to spin it into a maxim. If even someone as qualified as he could be unseated by this tactical error, it surely bears memorializing as advice worth living by.

<comment><AUTHOR> OP here - please trust that I have given this a lot of thought, both through hours and hours of examining the conversation and introspecting my answers, and (months) later, in a long phone call with the director of the program, who very generously walked me through why they made the decision they did.

I alluded to this in the post - this wasn't the only thing I did wrong, not at all, but it was by far the easiest to change and the clearest signal to the interviewers that I was overconfident and incurious, and the other stuff would just detract from the message that's already there.

<comment><USER11> Thanks for the response. It's valuable that they gave you detailed feedback. The post would be strengthened by enough specifics grounded in that actual feedback to have preempted my response. In any case, I appreciate the conversation.

My comment here should not be read as a personal judgment. It's more of a literary critique of your article as instance of a genre—with an extra helping of editorial critique of that genre.

</comment></comment></comment><comment><USER12> The "what did you have for lunch" question strikes me as a _bad idea_.

If I am interviewing someone and that is their only question, it is an immediate "weirdo-flag" if it gets to the stage where we are making our minds up and aren't sure - I can imagine the feedback now: "asked a weird, pointless and irrelevant question during an important situation" is a _negative_ thing and could be a decider. Would this person do something equally odd and inappropriate in an important client meeting for example?

If you've had a really fun, jovial and friendly conversation with the interviewer then 100% sure go for it, but I find most interviews are a bit from stilted and fraught and it does not feel that this sort of thing would be appropriate.

My favourite sort of question for this when you have no other questions is something like "What is a typically day like for you?" or "What is a day-in- the-life of this role like?" It is useful for understanding if the role really is what you think it is, and from there you can branch out to get a bit more into the details ("ah - what SCM do you use?" "oh right - how are code reviews done?" "interesting - how do you track work to be done?" "I see - is there dedicated UX people?" etc etc)

Won't always work since the person interviewing you might not be in the team/role you are applying for, but I think it shows interest in what you will actually be doing if you got the role, re-inforces that you have relevant experience (if you ask appropriate follow-up questions), and that you are curious.

</comment><comment><USER13> Here's the thing: interviews are stressful and unnatural and they provoke anxiety and a fight-or-flight response in a lot of people. That fight-or- flight response shuts down parts of the brain that evolution considers unnecessary in an emergency situation, including the pre-frontal cortex - <USER2> part of the brain that you need to perform reasoning and to think of questions that you might want to ask. A good interviewer will know this.

I've interviewed a lot of people who were obviously nervous and who didn't have any questions to ask me at the end but whom we hired and who ended up doing really well in the job.

That said, if you do want to have something to ask the interviewer and you're worried that your mind will go blank, write down some questions ahead of time in a notebook that you take to the interview and refer to it if necessary. An added bonus is that you can ask about things that you actually care about, rather than just asking asking the first thing that comes into your head.

</comment><comment><USER14> When I'm interviewing people, I usually don't consider the questions they ask (or don't) as part of the evaluation, and if they are nervous, I tell them so.

If you evaluate their questions, then they might not ask what they actually want to know, for fear they'll be judged for it. That helps no one.

<comment><USER15> While I agree you need to be careful about mistaking someones nervousness for lack of qualification for the job, that's going to be an issue throughout the interview, not just when they ask questions, and you need to work to get them comfortable throughout.

I find the questions from the interviewee to be among the most useful part of the interview, for _both_ sides. As an interviewer, it's great insight into the things they care about, what caught their attention during our discussion and want to dig into some more, etc.

I'd also say it's exceedingly difficult to set aside their questions, even if you truly mean that you try to. If someone asks something like "How closely are the office supplies tracked, would anyone notice if stuff went missing?" I doubt you can totally ignore that. Similarly, if someone has a mediocre interview but asks a some absolutely great questions that lead to an amazing discussion are you really going to say "well, I think they'd be a great fit, but I did say I'd not consider their questions as part of evaluation, so guess it's a No from me"?

The hardest one for me is where someone otherwise good asks something like "When can I get my first raise and how much is it?" as their first question. I mean, it's a valid question, but it's hard to ignore that it's the _first_ question.

As an interviewee, it's a great time to figure out what you're getting into. This is a potential future co-worker you're talking to, so if they get upset that you've asked a tough question or even respond with a hint of "psh, that's a stupid question" that's a massive red flag about what taking this job would be like.

</comment></comment><comment><USER16> When I interview someone, I personally am interested in a "conversation" with the candidate and not just where I ask questions, they provide an answer. So by the time we are done, the candidate should already have asked a few things since I run the interview as a conversation where they talk to me, ask questions as part of the discussions we are having and of course, answer specific questions that I ask.

At the end, I always ask: do you have any other questions for me. I don't care if they ask me a question for the heck of it but I do care overall whether they were engaged with me through the interview or not. This specially matters as you interview more senior candidates than entry level or junior even though I welcome anyone to ask me anything.

So I would say that go to an interview where you should not have to necessarily ask questions at the end but it should ideally be more of a conversation throughout. It also depends on how much information is revealed by the interviewer upfront. I always talk about the company, the team structure and the specific role before I start getting into details. That gives them an opportunity to later on ask for more clarification etc.

<comment><USER17> This. An interview where I only get to answer feels like an interrogation. However at the end I ALWAYS ask one more question: was there anything in this interview that made you have second thoughts about hiring me? If so, it gives me a chance to correct it and it gives me the feedback you never get in a rejection letter. Also it shows them I'm open to feedback. If not, there is little chance this person won't hire me.

</comment></comment><comment><USER18> Since the comments have shifted focus to hiring/interviewing:

Make sure that your company's interview process leaves enough time at the end of each interview to allow the candidate to ask questions. Don't assume the candidate is OK with emailing questions later because you only left the candidate 3 minutes to talk. The candidate pledged a day of their life to interview as they are interested in your company. If they leave your company at the end of the day without being able to ask all the questions they have, there's a chance they will never bring them up later.

<comment><USER19> > there's a chance they will never bring them up later

If by that you mean that they will look for another company instead, then I agree. That's what I always do. I am not explaining anything, I just simply ghost the companies who behave like that. I ALWAYS found a more caring company by doing this.

</comment></comment><comment><USER20> My interviewee style is to ask questions during the interview. I feel like it makes it more conversational and pleasant.

I ask so many questions/clarifications during an interview that even if I have a big list going into it, by the time the interviewer asks if I have any questions, I pause, and then most of the time I'll respond something like: "I think we've covered everything I was curious about" and then do a quick recap of my understanding to clarify and uncover any bad assumptions.

My interview to next stage/offer rate is quite high, so I think my interviewee style is reasonably good.

<comment><USER21> This, plus recently I've had a lot of experiences where the interviewer asks me just 1 or 2 simple questions, then invites me to ask them questions.

</comment></comment><comment><USER22> It's always really obvious when someone asks a question just to hear themself speak or to feel like they made a mark on the meeting or whatnot. To me it comes off as mildly irritating and a waste of everyone's time. I personally won't be taking this advice, sorry.

<comment><USER23> YMMV I guess. But the article talks about asking questions _during a (hiring) interview._ I don't see it the same as asking a question during a meeting.

<comment><USER22> Don't waste the interviewers' time, especially.

</comment></comment></comment><comment><USER24> I agree with this, I can pinpoint the one question I didn't answer correctly in one interview once. I was doing well and passed through everything until it came to hr asking about a 5 month break and why I left a company without another job. The hr lady prompted me with what to say "was it so you could do some travelling?" And I replied that I just needed a break and took some time off. She prompted that I must have done some studying, again I just said no and that was it.

My answer didn't fit the social norms so I was canned.

</comment><comment><USER25> I think if y'all are trying to apply this to tech interviews at big companies you will be sadly disappointed. I did interviews for a company that has interviewers write feedback for a hiring committee, and I never included anything about the questions the candidate had. 100% of my feedback was about the interview questions that I asked and the candidate's answers to them. The people making the hiring decision has no way of knowing that you wore a suit, or asked me what I had for lunch, or anything like that. The information is simply not available to them. (We even tried to write feedback like "the candidate did X" so that there was no "he" or "she" to bias things.)

</comment><comment><USER26> I've never cared when a candidate doesn't have questions questions for me. I've done ~100-200 interviews at FAANG companies and never heard a single complaint in the debriefing about "The candidate didn't have any questions for me."

I feel like once you've done a few interviews you realize that "What's a typical day like?" Isn't really a signal of a candidate's genuine interest, it's the obvious reply to your "Any questions for me?" gambit.

Personally, I wouldn't even ask for questions from the candidate if I didn't know some rare people do genuinely want to ask questions.

<comment><USER27> FAANG is a little bit different, because you're not really evaluating people as much on "how much do they want to be here", because the answer is essentially the same for most people. For smaller companies, this matters a lot more, and a couple of key hires can really elevate or drag down the office culture.

<comment><USER28> > For smaller companies, this matters a lot more, and a couple of key hires > can really elevate or drag down the office culture.

Is that really a thing between global tech company vs small company or rather big vs small? In a 10 people company, everybody makes up 10% of the people, so they have much more impact on everything than in a company of 10000.

<comment><USER27> I would say that culture matters a lot more in the hiring/interview process when you expect each individual you're hiring to be a multiplicative force. For smaller startups that are growing, this tends to be true. For larger companies, they tend to grow more linearly, so an individual that only contributes raw units of work is usually sufficient. So I don't think it's purely the percentage of the company that each hire represents, but more so what you expect out of each individual.

</comment></comment></comment></comment><comment><USER29> While one should always prepare a question in such situation, the proposed standby questions are definitely worse than not asking a question. "What did you have for lunch" or "what did you do yesterday" are highly personal, and irrelevant to the interview.

It is a worse way of saying "I don't have a real question for you".

Work environment, atmosphere, infrastructures... There are endless relevant topics that an interviewee could ask about. Anything would be better than "what did you do yesterday".

<comment><AUTHOR> For what it's worth I (OP) have been asking this question for a decade now and have gotten a good response, as well as fodder for follow ups. At least when I look back at the (few) times I have been rejected there were obvious other reasons that were _not_ this.

When you ask people what they value they talk in generalities like "good team communication is important to us," when you ask what they did yesterday you learn that feature development has stalled because everything is being rewritten in Clojure, or whatever, then you can follow up and ask about that.

</comment></comment><comment><USER30> While the "what did you have for lunch" question may do a bit to surprise the interviewer, there is probably a more valuable go-to question that can be fairly generic in any sort of interview type experience.

"If you were me, what would you improve on (work on, learn next, etc etc)?"

This is beneficial both for the interviewer and you as an interviewee. It lets the interviewer consider you specifically in the context of "are you missing something", and gives them a good opportunity of letting you know where they see your holes/flaws. It also let's them know that you are willing to learn, and trying to understand how to grow and change.

The interviewer will be asking themselves these sorts of questions after the interview anyway, so why not try to get their feedback right then and there, with a potential opportunity for you to correct them, if they think you are missing something that you actually have.

<comment><AUTHOR> I provide a more valuable, generic go-to question in the sentence after the one you quoted

</comment></comment><comment><USER31> This also helps in projecting an image that you have options and you're not desperate. And even if you are desperate, it's good to ask questions so you don't land in a bad situation. I think about some jobs I quit, and in retrospect I could have saved everyone some time if I had thought of certain things that were important to me and asked questions ahead of time.

</comment><comment><USER32> > Finally, "person fails interview because interviewer expects to see cultural > signal and interviewee does not broadcast cultural signal" is a common > failure mode. Think about someone who wears a suit to a tech interview.

Honest curious question: Is it really considered that much of a faux-pas to wear a suit to a tech interview nowadays?

<comment><USER33> As with all such things, it depends on the company and the person doing the interview. There certainly used to be a very strong idea of "cultural fit", coupled with appearance cargo-culting, that made guessing what to wear at some places a minefield. On the one hand, if a company is putting their hiring decisions in the hands of insecure stereotype-wannabees who idolise a fantasy vision of the valley, do you want to work there anyway? On the other hand, we all need to pay the rent and sometimes if you can get past the "cultural fit" gatekeepers the rest of the company is pretty solid.

On a personal note, I always wear a suit to inteviews. I don't have many suits, but they're bespoke and tailored to fit. When I put one on, it's like a mode switch; lookin' sharp, feelin' sharp. Sometimes it's even a talking point when an interview notices (although, to be fair, at least once one interviewer appeared to have slept in his clothes and looked a complete mess, and me lookin' sharp just emphasised it). I do live and work principally in the UK, though, where wearing a shirt with buttons is not seen as dressy.

<comment><USER34> I also dress up for interviews even if the place is casual, and I even usually dress nicely for the first day of work. You're normally introduced to 100 people on your first day, and I like to make a good impression. I've never had a problem with negative feedback from this. I think you can tell someone's cultural fit better by a conversation than their clothing.

</comment></comment></comment><comment><USER35> This advice might apply to written applications too. In college I was applying for a scholarship, in its first year, in which they picked one recipient from each state. It was a long application. The very last page was the question, "Is there any other information about you or your family you would like to share?". I thought this was an odd question. Maybe they wanted some information about special hardships or something. I instead wrote a table that had the height and weight of every member of my family.

I told my parents about the application and my mother was so mad at me. She told me I threw away my chance at the scholarship. It turns out however that I got the scholarship. Not only that, some of the recipients were invited to the capitol building in DC if they lived relatively close. A senator came up to me at the luncheon and told me she loved my answer. It also turned out that they gave some extra scholarships beyond one per state. It turns out my state got one of those extra scholarships. I suspect maybe I got the scholarship only because of my smart ass answer at the end.

</comment><comment><USER36> > they asked "do you have any questions for us?" By this point I'd done so > much preparation that I couldn't think of anything, and said "No."

I'd argue his preparation was inadequate. Part of my interview preparation process is to come up with a list of questions to ask based on the research I've done about the company and position.

<comment><AUTHOR> OP here - this kinda feels like telling someone who missed a game winning shot that they should have made the shot. Had I included this in my preparation and gotten the scholarship I would not have written the blog post about how failure to prepare in one key way led to me not getting a scholarship.

In any case I've updated the wording to make my intent more clear.

<comment><USER36> Not exactly. I think a more apt analogy is a person who missed the game winning three point shot who only practiced inside shots. You'd want to tell the person they should probably round out their practice routine with outside shots as well.

</comment></comment></comment><comment><USER37> I was going through the new-student induction at UTIAS and one researcher asked if we had any questions. Everyone else was silent, and I got the feeling the guy was feeling bad about it so I asked a question about his research.

I fumbled the question, he made me look like an idiot.

One anecdote isn't everything, but "just force a question" is not a foolproof strategy.

<comment><USER38> I have a similar story. It was first day in a machine learning class in a computer science majors (not real ml, baby ml class) and the professor made a point to tell us to ask questions and how there are no stupid questions Bla bla. Just about fifteen minutes later, he was deriving an expression or something but my calculus was rusty so I asked him to elaborate how he went from one step to the next. I vividly remember him saying that is the most stupid question he had ever heard. I don't think any student asked him any subject matter question all semester (only administrative questions like what's on the test, project grading, and so on).

</comment></comment><comment><USER39> "What did you do yesterday", from the article, is a great open-ended question that tells you a lot about someone.

I've always enjoyed a diff-question, like, what do you wish people knew about xyz, or what surprised you about xyz. Those answers are usually very information dense

</comment><comment><USER40> I interviewed a lot of candidates (technical interviews for software engineers) and in my experience great candidates ask great questions. Don't ask any question, ask interesting questions. There are 2 reasons why this is important:

\- Asking good questions is part of the job IMO, I'm not sure why we wouldn't test it, so it absolutely makes sense to ask candidates to ask questions.

\- Even if you really prepared well and know everything there is to know about the team and the company you are applying, there has to be something an insider can tell you that would be interesting for you if you really want to join this company/ this team. So it clearly shows lake of interest / motivation if you ask no question

<comment><USER41> What have been some questions that stood out for you?

</comment></comment><comment><USER42> > Fast forward a week and I got an email that I was not going to be offered a > scholarship. Only two other students out of 25 were rejected. I was > dumbfounded.

High stakes selection often comes down to random chance. It's entirely possible the author could have asked the perfect question and still missed out, because from the selection committee's perspective all candidates appear equally strong. It's a good position to be in as a hiring manager, but as a candidate it can be difficult to refrain from overfitting the situation.

Probably the best advice, in any situation, is to seek out more options. Apply to more jobs, more scholarships, and more fellowships. Write down more ideas, todo items and bugs.

</comment><comment><USER43> Right, asking the question is another stress issue with interviews, during the interview you are essentially hunting around for questions to ask this representative of a company that is pretty much like every other company in the tech space for all they like to pretend that they are not. Because at the end of the interview they are going to ask if you have any questions for them, and despite everything being pretty clear cut and boring you should try to find some question that makes you sound insightful and makes an impression but at the same time is not aggressive.

</comment><comment><USER44> The author ASSUMES that not asking questions was the reason he got rejected. That may not be true and it is likely the rejection had much more profound reasons. Yet he proceeds to write a blog post about that.

</comment><comment><USER45> " While apes can learn sign language and communicate using it, they have never attempted to learn new knowledge by asking humans or other apes. They don't seem to realize that other entities can know things they don't. It's a concept that separates mankind from apes"

[https://en.m.wikipedia.org/wiki/Primate_cognition#Asking_que...](https://en.m.wikipedia.org/wiki/Primate_cognition#Asking_questions_and_giving_negative_answers)

<comment><USER46> This is something you see in reverse with toddlers, they think you know everything they do (or at least that's been my experience with my own kids) so if they saw something cool then they assume that you saw it too. My kids have gone through stages of assuming they now know everyhing, too. Fun.

</comment></comment><comment><USER47> Maybe it's the wrong approach, but I treat an entire interview as back-and- forth conversation… especially for a specific position.

Questions demonstrate curiosity in the role you're being hired for and give you an opportunity to demonstrate knowledge about and empathy for your ultimate end-users… not to mention allowing you to get a feel for the culture of the team and company you're about to spend a large amount of your time working at.

<comment> t-shaped I've always appreciated people who interview like this and on the rare chance that I'm interviewing someone, I focus on maintaining a conversation too.

Really draws the line between a conglomerate firm and a company that actually cares at a personal (sort of) level.

</comment></comment><comment><USER48> In my opinion you learn a ton about candidate in this stage. Firs and foremost, are the curious. Generic questions are fine, but specific questions that respond to the discussion show you've both been paying attention and are actually thinking about the job.

It may be a personal pet peeve, but I sometimes get 'I asked all my questions in the other interviews'. So what, ask them again! The question will be the same, the answer will be different.

<comment><USER49> I feel the need to disagree with you here, it's absolutely possible a candidate just doesn't have any questions, maybe they've done their research up front, or all their questions were asked during the interview, I wouldn't necessary correlate that with curiosity. I've been in interviews where I had some questions up front, but they all got answered during the interview itself, either through natural conversation, or because the person interviewing touched on those topics.

> The question will be the same, the answer will be different.

Personally, especially when I know I'm having different interviews with different people, I ask the same question twice, just to evaluate their answers. If the answer to a question (e.g. Do engineers have a lot of input regarding technical decisions) is different between one of the engineers and the dev lead / CTO, then you know there's something wrong.

Especially at bigger companies, where I know the final interview will be with HR, it's interesting to ask questions regarding company policies or culture. You usually get very different answers.

</comment></comment><comment><USER50> If I'm going into an interview, I'll usually prepare some questions in advance.

But I'm terrible at coming up with questions during dynamic meetings. I find that I need time to reflect on topics before I can form a clear idea of what I need to ask.

This has backfired several times, usually in meetings with sharp businesspeople (who are _so_ good at asking pointed questions!). Does anyone have tips on how to get better at this?

<comment><USER27> You already gave the answer yourself. You need to reflect on the topic beforehand. Something that is truly brand-new, you probably got some notification ahead of time that would have allowed you to do thinking prep. Things that are much more relevant to what you're working on or your business might be much more ad-hoc, so then that means you need to be always trying to think deeply about the work that you do and understand and evaluating all the potentials that are available.

</comment></comment><comment><USER51> > But if your goal is to cast a wide net [...], maybe make a list of every > reason you've used to reject a nontraditional candidate in the past and then > email that to the candidate in advance of the interview

Such a list would be a huge legal burden and no sane corporation would send it.

</comment><comment><USER52> This is life 101 advice for everyone, I think. I've turned down plenty of people on interviews because of this. The tests I create always contain one or two questions I doubt anyone would ever answer. And that's the reason I always put them there - give them a simple opportunity to ask a question. When I ask someone if they have questions and they reply with "no", then it's clear they are not suitable for a position where they would have to ask a lot of questions. I've had experience with several such developers, who never asked questions. What I've learned is that those can only create a universe of anti patterns and code which is just as hard to maintain as cracking rsa 4096 without a key.

</comment><comment><USER53> I can't agree with author's point. I'm doing lots of job interviews as employer and also taking some interviews as an employee once a year to remember how it feels on the other side. It is plain difficult to switch context from answering someone's hard and potentially life-changing questions to asking my own. When candidate hears "do you have any questions?" their first reaction is "Wow, I've made it, it's over!". So I'm giving my candidates extra minutes to relax and remember what is it that they want to know about company and working conditions.

Good tactic is to have a prepared list with you, but it is a knowledge acquired with tens of interviews, not something any high-schooler doing every day.

</comment><comment><USER54> > what did you have for lunch? > what did you do yesterday?

please don't ask made up questions. or else we complete the whole cycle. ask when you really want to know something. else it's just stupid.

</comment><comment><USER55> A personal favorite response of mine if I don't have any questions left is "no, I think I injected most questions I had as we went along. I was going to ask <thing>, but I think we covered that well already."

This is helpful if you're like me and turn interviews into discussions instead of Q&A sessions. It shows you've considered you might not have the full context just from prior correspondence, while resurfacing a discussion topic for them to expand on if they wish.

</comment><comment><USER56> Yes. File this alongside "if somebody offers you a breath mint, take it"

</comment><comment><USER57> Is this an example of "cultural bias"? That would mean the behavior doesn't predict job performance, but is used to filter out candidates from different cultures.

</comment><comment><USER58> This essay leaves me confused and unable to follow the train of logic from an already unclear correlation/observation to lesson learned (?).

How did it leap from, ask a question if you have the opportunity because I think I was denied a scholarship because I didn't, to "show your commitment to diversity and non-traditional backgrounds, by emailing a list of every cultural-related reason you've used to reject people"?

</comment><comment><USER59> It's quite simple: any conversation is a two-way street. Teacher and pupil, interviewer and job seeker, parent and child -- every conversational partner should be curious and thoughtful about the other person.

Just extrapolate the above advice to a first date. Should you ask your date questions? Obviously you should! So why not your interviewer?

Tennis isn't exciting when one player plays against a wall, conversation is a collaboration.

</comment><comment><USER60> I always go into interviews with a prepared list of thoughtful and insightful questions to ask for this moment. Not because I care about the answers but because it's part of the script.

In real life, if I have questions I'll ask them and if I don't I won't. Making the fact of asking of questions relevant for important decisions is a preposterous charade, one that I am used to playing along with by now.

</comment><comment><USER61> As my parting question I like to ask if there's any reason they wouldn't recommend me for the job.

I've found this question tends to stun the interviewer, puts them back on their heels to think a bit.

Then, they either tell me about any lingering concern (giving me a chance to address it while still in the room) OR they tell me that the interview went well / what they appreciated from the discussion.

</comment><comment><USER62> Painful. I think I'm at the end of my tolerance for spending my life predicting and managing other people's emotions.

</comment><comment><USER63> It's also helpful as an interviewer to ask "What questions do you have?"

</comment><comment><USER64> It is good advice but should not be exagerrated. On one interview i was the one asking most of the questions. And i didn't give myself a job :)

</comment><comment><USER65> "If a developer like me were to leave your company right now, what's the reason they would quit?"

</comment><comment><USER66> Often my response is...i don't know enough to ask yet

</comment><comment><USER67> If u have questions, ask them. If you dont have questions, you cannot ask them by definition.

People reading anymore into this are not the kind of people you want to have to work with.

<comment><USER67> Additional: Asking a question just for the sake of it, or for the sake of appearances, is what some idiot does at the end of a meeting, making it go on for another half an hour and wasting _everyone_ presents time.

<comment><USER62> Somebody didn't bring a present for everybody so nobody asked a question to waste everybody presents time before anybody left.

Who's on first.</comment></comment></comment>