R1  (N)  R2
  [VDD]-^^^^--*--^^^^----|

This works surprisingly well as a negative hiring filter. It's not intended to be a trick question at all: it can be solved with Ohm's Law:

  I = VDD / (R1 + R2)
  Vn = VDD - R1 * I

  Vn = VDD * R2 / (R1 + R2).

...Wat? That's like, one of the easiest questions you could ever be asked. As a senior undergrad in his final semester for EE (Computer Engineering specialization), could you give me an idea of some of the more difficult questions you would ask?

The most annoying thing was, I was not expecting any gates related question so my optimizations were very... adhoc.

Ouch! :)

I'd say it's even simpler than a regular FizzBuzz.

Once an item has more than 40 comments, if the number of comments is more than the number of points, there is a ranking penalty applied. This is because it's a good proxy fr an item being a flame-war.

So if you're interested in seeing more answers to this question, or carrying on the discussion, it's worth making sure you up-vote the item to try to avoid tripping the flame-war detector.

Of course, it may already be too late ...

I'll see if I can find it.

  A jar has 1000 coins, of which 999 are fair and 1 is double
  headed. Pick a coin at random, and toss it 10 times. Given
  that you see 10 heads, what is the probability that the next
  toss of that coin is also a head?

- the prior odds that you picked the double-headed coin are 1/999.

- after seeing ten heads, the posterior odds that you picked the double-headed coin are (2^10)/999 - let's approximate this as 1. (Bayes' theorem usually gets expressed in terms of probabilities, but it's so much simpler in terms of odds.)

- so it's roughly equally likely that you have the double-headed coin or any non-double-headed coin; the probability of flipping an eleventh head is then approximate (1/2)(1) + (1/2)(1/2) = 3/4.

http://yudkowsky.net/rational/bayes

Useful if you want to know (or need a good way to explain) what a posterior probability is and how it's different from a prior probability

I like a "factor label" style approach where you can see the prior probability (Fair: Biased), the information about the flips, and the posterior probability (the revised chances after the new information is taken into account):

Prior * Information = Posterior

so

(Fair : Biased) * (10 Fair heads : Fair ) : (10 Biased heads : Biased) = 10 Fair Heads : 10 Biased Heads

Plugging in, we'd have:

(999 / 1) * (1 / 1024 ) / (1 / 1) = 999 / 1024

The odds are ever-slightly in favor of a biased coin. So we can mentally guess ever-slightly above 3/4 for the chance of another heads. We could write (999/2 + 1024) / (999 + 1024) on the whiteboard to be exact.

(Note 1. The odds of a thing are the ratio Pr(thing) : Pr(not thing). You can generalize this to any mutually exclusive and exhaustive set of things: the odds are the ratio of the probabilities. The fact that there may therefore be more than 2 such things is the reason why I prefer not to turn odds into fractions as above.)

(Note 2. Bayes' theorem is, as others have mentioned, much nicer when you work with odds rather than probabilities for your prior and posterior probabilities. If you're comfortable with logarithms, it's nicer still when you work with logarithms of odds. Now you're just adding the vector of log-likelihoods to the prior odds vector to get the posterior odds vector. Which is how I think of the question above, at least if I'm allowed to be sloppy and imprecise. You start with almost exactly 10 bits of prior prejudice for "fair" over "two-headed", then you get exactly 10 bits of evidence for "two-headed" over "fair", at which point those cancel out almost exactly so you should assign almost equal probabilities to those two possibilities.)

(posterior odds) = (prior odds) * (likelihood ratio)

The prior odds are 1/999, so we need to show that the likelihood ratio is 2^10.

The likelihood ratio is the probability of seeing 10 heads from a double-headed coin divided by the probability of seeing 10 heads from a fair coin, which is 1/((1/2)^10) or 2^10.

A the beginning, there's a 1/1000 chance that you pick a double-headed, and a 999/1000 chance you pick a fair coin.

A fair coin would act the way you've observed 1/1024 times. A double-headed coin would act that way 100% of the time.

(This is where I get fuzzy): Given what you've observed, there is a (1000+1024)/1024 = 0.506 chance that the coin is double-headed. There is a 0.494 chance that it's fair.

A double-headed coin would come up heads next 100% of the time. A fair coin would come up heads 50% of the time. So, 0.506 x 1 + 0.494 x 0.5 = 0.753.

How far off am I?

Anyway--assume I think all that aloud in an interview. What does that tell you about the candidate?

I would give points for just asking that question, because many people bound by conventional thinking wouldn't dare to ask it, accepting default assumption that you can't. I'm not saying this says anything about your ability to solve the problem, but asking the question is a good sign of a supple mind.

There's a .999 chance you have a fair coin and a .001 chance you have the rigged coin.

(0.999 * 0.5) + (0.001 * 1) = 0.5005.

Seems too simple, but a coin is a coin, right?

So figure the p(heads) for the coin and ignore the previous history. Overthinking it is why this makes a good FizzBuzz problem.

Suppose that the jar contains 500 double-head coins and 500 double-tail coins. You pull a coin from the jar, flip it 10 times, and get 10 heads. What is the probability it will come up heads next time?

Let's also say that every time you flip the coin and it comes up tails, you win $5. And every time you flip the coin and it comes up heads, you lose $1.

Clearly, this would be a great game to have the opportunity to play, if the coin is fair. Every time you flip you either win $5 or lose $1, so your profit, on average, is $4 per flip.

You've flipped it 10 times so far, and it's come up heads every time, and you've lost $10.

After you're $10, $100, $1000, or $10e100 in the red, without ever seeing a win, when do you change your mind about playing this game?

What is the most common answer? Typically, I get either blank stares or a gut answer of just a little over 50%. I find that physics people are pretty good at solving the problem.

I would also REALLY hope that somebody who is applying for a job in finance understands the bond prices and interest rates, but I suppose that does make it a good fizz buzz type question.

You'd be surprised at how many people can't answer instantly. Or how many people can't give a convincing description of what a share is, and what rights it gives you.

These are all easy questions, which to my mind is the point. The fact that someone can answer them doesn't tell you much, but if someone can't answer them then you need to think very hard about whether to hire them.

Basically (if they get stuck), ask them how they would choose if there were actually a 100 doors, but the same rules apply. Obviously, everyone switches. What about 99? 98? ... turns out, 3 doors is the smallest number where the strategy is optimal. But when the number is large, the answer is much more obvious.

If they don't know it, then ask to solve.

The early controversy with the Monty Hall problem was that explanations left loopholes, or weren't compelling enough, and even people who who should have known better didn't understand the solution clearly enough.

The problem with asking trick questions in an interview is that, although they may make the interviewer look smart, they are orthogonal to the ability to do the job. It's better to ask how to solve a current, pressing problem and see what questions the candidate asks. It's the questions that elucidate thinking style. Also, it's crowdsourcing and you can attribute or blame the candidate as the case maybe.

The other part is getting along, so if an interview doesn't include something fun, it's all boring formality that doesn't allow anyone to get to know each other. Take them to a normal lunch if possible, because much more is learned by how people eat.

For instance ask "What if the showman didn't know which door the car was behind?"

IIRC even if you exclude instances where the showman shows a car, it evens out the odds.

The mistake that most people seem to be making is using P(biased) and P(fair) instead of P(biased|10 heads) and P(fair|10 heads).

Spoiler: The answer is ~0.75.

On the flip side, you could probably unintentionally trip up someone with a generally competent grasp of economics/stats but a lack of specific interest in bonds over terminology if your followup questions start asking them to distinguish between types of yield.

Same with exchange rates (although I do remember back in school in a competitive presentation being complemented on my confident and plausible sounding explanation of the effect of an interest rate rise on exchange rates that also happened to be the reverse of the correct answer :-) )

a population has a 10% incidence of condition X. A test exists that is 90% accurate.

1) What is the expected percentage of positive test results? 2) if a person tests positive, what is the probability that they actually have the condition? 3) if a person tests negative, what is the probability that they are actually free of the condition?

1024/1025 * 1/1024 = 1/1025 (probability of unbiased coin, 10 heads) 1/1025 (probability of biased coin & 10 heads) relative probability = .5 the answer is then precisely 3/4

The chance of picking the biased coin is 1/1000. The chance of seeing 10 heads from a fair coin is (1/2)^10 = 1/1024. These are nearly equal, so given that you've seen 10 heads, there is a 50/50 chance of having a biased coin. So the probability the next flip shows a head is

  P(H) = P(biased) * P(H|biased) + P(fair) * P(H|fair)
       = 0.75

Yo want to figure out P(biased | 10H). Using Bayes rule this is

  P(biased | 10H) = P(10H | biased) * P(biased) / P(10H)
                  = P(10H | biased) * P(biased) / (P(10H|biased) * P(biased) + P(10H|fair) * P(fair))
                  = 1 * (1/1000) / (1 * 1/1000 + 1/1024 * 999/1000)
                  ~ 0.5

The OP is only asking what the outcome of the NEXT flip is, not the probability of flipping 11 heads in a row. Or did I read this wrong?

Here is perhaps a more visceral example: On any given day, your car has a 10% chance of having blown a wheel the previous night. If it has blown a wheel, every bump will feel jarring. If it hasn't blown a wheel, any given bump will feel jarring with 10% probability. You drive over a hundred bumps, and all feel jarring. Do you think the next bump will also feel jarring?

Yes, right? Because the fact that the last hundred bumps have been jarring means you probably blew a wheel last night. Even though 'previous history has no effect on future outcomes', previous history does give you information about the state of the world.

Edit: Or a better example, for this community. You're on a slightly flakey wifi connection, which sometimes drops a packet at random. Any given packet is dropped with probability 1/100. Also, any given time you connect to the router, the modem is down with probability 1/10, and all of your packets will get dropped. You connect, and the first hundred packets you send are dropped. What is the probability the next packet will get dropped? Very high, because now you know that the modem is probably down. The history of the connection gives you information about the state of the connection. Similarly, the history of coin toss results gives you information about the state of the coin.

(Why is this different from roulette? Because there the previous history doesn't give you information.)

Explaining the bit you quoted: if you had perfect knowledge of the wind conditions, how hard the person flipped the coin, and so on, you would know precisely which side it would land on. That fact is determined. It's just because you are missing information that there's 50% probability of heads (for an unbiased coin). The probability comes out of your imperfect knowledge, and changes depending on your knowledge: for example, if you have some reason to believe the coin is biased, then you no longer think it's going to land on heads 50% of the time. Since one of the coins is biased, getting a long string of heads is reason to think that the coin they drew and are flipping is the biased coin. This information affects the probability you assign to the coin coming up heads.

  def choose_coin
    rand < 0.001 ? 1 : 0.5
  end
   
  def flip_coin(coin)
    rand < coin ? :heads : :tails
  end
   
  def all_10_heads?(coin)
    10.times { return false if flip_coin(coin) == :tails }
    true
  end
   
  next_flip = { :heads => 0, :tails => 0 }
   
  1000000.times do
    coin = choose_coin
    next unless all_10_heads? coin
    next_flip[flip_coin(coin)] += 1
  end
   
  puts next_flip[:heads].to_f / (next_flip[:heads] + next_flip[:tails])

http://en.wikipedia.org/wiki/Probabilistic_programming_langu...

https://github.com/chris-taylor/hs-probability

The code that solves this problem is:

  solve = do
    coin   <- choose (999/1000) fair biased
    tosses <- replicateM 10 coin
    condition (tosses == replicate 10 Head)
    nextToss <- coin
    return nextToss
   where
    fair   = choose (1/2) Head Tail
    biased = certainly Head

Try thinking about it in a more brute force way: imagine literally all possible outcomes of performing this experiment. In other words, create a list like this (each coin in the jar is numbered from 000 to 999 with 999 being the only biased coin, and coin flips are represented by 0 being heads and 1 being tails):

    Picked fair coin #000, flipped 00000000000 (eleven flips)
    Picked fair coin #000, flipped 00000000001
    Picked fair coin #000, flipped 00000000010 ...
    Picked fair coin #000, flipped 11111111111
    ....
    Picked biased coin #999, flipped 11111111111

  00000 00000 0
  00000 00000 1

1000 of which has 11. flip 0

So 1000/1999 ~ 50%

    00000 00000 0
    00000 00000 1

And 2^11 instances of 00000 00000 0 for the biased coin = 2048.

That's 1998 + 2048 = 4046 equally likely outcomes that begin with ten heads. Of those, only 1998 / 2 = 999 outcomes feature an eleventh tails. So the odds of getting an eleventh heads after seeing ten heads is (4046 - 999) / 4046 =~ 0.753.

That's not the reason. It's because the fake coin also has two sides and therefore also 2^11 different outcomes. It just happens they all look the same.

Otherwise I agree with your argument.

    0.999*0.5 + 0.001*1 = 0.5005

You hit the nail on the head here - a fair coin would. But if there are unfair coins, things start to change. If we know there's an unfair coin, and we see an unusual run, we should consider that it may be that coin.

Think of this: increase the flips to 1000, and you're still getting heads each time. Would you bet on the next being heads or tails?

"The OP is only asking what the outcome of the NEXT flip is, not the probability of flipping 11 heads in a row"

This is correct, however the history of flips gives us an information on the type of coin we have in our hands

Would be interesting to see the probabilities if we had gotten 11 heads, 15 heads or 20 heads in a row.

"Given that you see 10 heads, what is the probability that the next toss of that coin is also a head?"

He didn't ask you to identify the coin. He just wants to know if the flip is going to be heads.

It makes no difference what you do to it after the pick. Hold it in your hand for a day, flip it 10 times, sit on it, whatever - the end result is that p(heads) for that particular coin has not changed. p(heads) will be either 0.5 for a real coin or 1.0 for the rigged one.

The probability then comes down to what coin you picked at the start of the trial. There's a 0.999 chance you have a real one, and 0.001 chance that you have the rigged one.

Now if you pick a random coin from the jar, and you randomly observe one of the sides of the coin 1 billion times and every time you see heads, is the probability that this is the coin with both sides heads still 0.001? No, the probability that this is the coin with double heads is very close to 100%.

Now if you pick a random coin from the jar, and you flip the coin 1 billion times, and every time it comes up heads, is the probability that this is the coin with both sides heads still 0.001? No, the probability that this is the coin with double heads is very close to 100%.

How about if you flipped it 10 times and it came up heads 10 times? Turns out the probability that it is the coin with double heads is about 51%.

Probability quantifies the degree of uncertainty YOU have about the world. This can change even when the world doesn't change, namely when you observe something about the world.

According to the methodology you are advocating, the probability would be 50%, because you are only considering the initial probability of selecting a coin from the jar. But using the methodology I suggested in another comment, you would list out every possible outcome and conclude that there is a 100% chance of getting another heads.

http://en.wikipedia.org/wiki/Probability_interpretations

When we have the double heads coin, the probability of getting 10 heads is 1: P(10 heads|fake) = 1. When we have a normal coin, the probability of getting 10 heads is P(10 heads|fair) = 0.5^10.

The quantity we want to compute is

    P(heads|10 heads) = P(fair|10 heads)*0.5 + P(fake|10 heads)*1 
                      = P(fair|10 heads)*0.5 + (1-P(fair|10 heads)) 
                      = 1 - P(fair|10 heads)*0.5.

    P(fair|10 heads) = P(10 heads|fair) * P(fair)/P(10 heads)

    P(10 heads) = P(10 heads|fake)*P(fake) + P(10 heads|fair)*P(fair) 
                = 1*0.001 + 0.5^10*0.999.

    P(fair|10 heads) = 0.5^10 * 0.999 / (1*0.001 + 0.5^10*0.999)

    P(heads|10 heads) = 1 - 0.5^10 * 0.999 / (1*0.001 + 0.5^10*0.999) * 0.5 
                      = 0.75308947108

Why? Because my brain just doesn't seem to work in the way people expect "experts" brains to work in our world of tests/qualifications.

Now for context, I don't consider my self some wishy washy "Oh I have a different KIND of intelligence" making-excuses dumb as nails nancy. I've worked several years now for my nation's statistics agency. I've written programs to calculate things professional statisticians couldn't (indeed that seems to be one of the reasons I get to keep my job :P) and just about every useless bloody stat there is, I've written my own probabilistic data linking software, finished in the top 10% of unrelated competitions on kaggle, and my formal qualifications are in economics. I don't think I'm the greatest thing ever, but if i might be so blunt, I feel I'm at the stage where I can confidently claim to have "proven my capabilities".

But I haven't memorized Bayes theorem (or any other probability or math-formulas), despite having applied it about 100 gazillion times. And despite being an economist, I haven't memorized "the relationship between bond prices and interest rates". Now, I could try to reason these things out from scratch in front of you, but I imagine most people in our world would see that as a "weakness" or trying to hide the fact that I couldn't answer the question.

With the probability one, I'd start going down the various interpretations of probability and whether your notion of probability is internally consistent/justified, etc etc etc. I doubt I could write the math on the white board of the top of my head in an interview (and i know several statisticians who couldn't also), but I could probably outperform most of the candidates who could in its application in the real world (speaking from experience), or be able to question whether there is a better tool for the job in the real world.

With the bond one, I know there's an answer that you expect me to give from rote during my education. But i won't. I haven't memorized it (because from experience, memorising these types of things is bad form, conditions you into erroneous thinking when they eventually turn out not to be universally true, and is far worse than reasoning, questioning or thinking about problems). So i'll ask you to describe your idea of a bond to me. I'll ask you to describe your idea of interest rates. Why are the interest rates rising? Maybe then, depending on what answers YOU give, I'll say "well then obviously bond prices must move inversely to interest rate movements", but there's just as much chance i'll pick up on some mistake you've made and never reach that point.

Now I'm not attacking you specifically. I don't know you, or what we think of each other, or how we'd interview each other. But from my experience, most people/recruiters/employers/interviewers would take my behaviour as a negative sign. A sign of "stalling" or "evading the question". Questioning, or reasoning, or skeptically interrogating things or mulling over questions for long periods of time, especially if they consider the answer "known", is a "bad sign".

And the rote learner, who'd just happened to memorise a particular formula or spent most of their time in one particular context, or bought the book on interview questions for said industry will get a big fat tick.

Moral of the story: Please don't use "interview questions" :P

* The person suggesting the question says that this is trivial for people suited to the job in mind;

* You say you couldn't do this question;

* You also say that you would be suitable to do the job.

Given that the proposer of the question is the one that understands the job, I'm having a hard time understanding why you claim you would be suitable for it, given that you couldn't do the question. Please understand that I'm not attacking you specifically, I'm just having a hard time understanding your reasoning.

I am genuinely skeptical about whether people who don't know what they're talking about can actually hide that fact from people who do know what they're talking about in such a situation. The secret of course is to basically ignore qualifications/status and do it as a conversation. Perhaps in such a scenario, five minutes in me and the original poster would be getting onto ridiculous questions of trading/probability with great big smiles on our faces and forgetting all about whether one can remember bayes off the top of their head.

The second part: Assessing the technical ability of the candidate at hand. And for this I think current interview culture is horribly toxic.

I do not work for Facebook, nor do I believe that such techniques are not without their flaws, and are difficult/expensive to implement, but I think techniques aimed at "actually get the candidate to do the task involved in the job, and see how they go" has merit. Forget your preconceptions about what is required. Give them a real world task you'd expect them to do in the job, the time it would be expected of someone in the job. The resources of the job. See how they go.: See http://www.kaggle.com/c/facebook-recruiting-iii-keyword-extr... for example.

Not perfect, but better than 5 minute "interviewer questions of the year".

Funnily enough, I got into my current organisation answering questions in the interview on analyzing health statistics. Something I knew nothing about. A senior executive then snatched/let me move across to his area in the more technical side of things without a subsequent interview after I made it known I'd be interested, and after working with their guys for a bit on another project. Swings and roundabouts :P

The negative sign is your stubborn conviction about the lack of value of rote memorization.

The stereotypical "rote learner" you describe in your before-last paragraph is just as one-sided as the opposite.

Of course neither extremes really exist and you probably have rote-memorized more things than you realize. You don't work out everything from scratch every time you encounter a medium hard problem.

Unless you actually do, in which case someone reasonably clever who does not stubbornly refuse to learn a few formulas will beat you by speed. Which is a reason to hire them over you.

That's the the point. You may be very smart and capable doing it this way, but learning a few basics (such as Bayes, in the context of statistics) doesn't really cost you anything. Memorizing a few things isn't hard. You won't actually run into problems like "erroneous thinking" because you're smart enough and knowing the conditions under which something holds is easy enough when you understand the thing. Additionally you get the knowledge when a particular important theorem does not hold, which is higher level knowledge that you just can't get when you reason from scratch every time (positive vs negative knowledge).

Memorizing a few of the basic important theorems and formulas in your field is such low-hanging fruit to improve yourself that a potential employer might ask why you're not doing it, even if you're so very capable without doing it.

Finally, there's communication with your peers. Maybe you can figure that stuff out by yourself easily, but when your colleagues say "ah, so we just use Bayes and poof", you'll be lagging behind figuring that out, and in reverse when you do these things from scratch, I'm assuming you'll be doing them much quicker, speeding through your ad hoc methods, leaving your team mates confused and wondering "why don't he just use Bayes?" (which may or may not be what you are in fact doing, but you lack the knowledge to tell them as much).

I'm sure you do a very good job at what you're doing now, the way you're doing it. I'm just pointing out that there are various well-justified reasons why employers can be wary of your refusal to memorize some basic field-knowledge, even when you're perfectly capable figuring out that stuff when you need it.

    An equivalence relation is reflexive, symmetric, and
    transitive.  If E is an equivalence relation, and we
    know E(x,y) but we know !E(y,z), what do we know
    about E(x,z), and why?

Edited in response to lmm's perfectly reasonable question. In context I would see if they just assumed they knew what I meant, or asked for clarification. If they assumed they knew what I meant, it would be interesting to see what interpretation they used. This is like FizzBuzz - it shouldn't stop with the first draft of the code - it's an opening for discussion.

    =======
    | x y |
    =======

    =======    =====
    | x y |    | z |
    =======    =====

You pass.

    E(x,y) & E(y,z) => E(x,z)

(I'm not a logician, either, so I hope you'll excuse what may be imprecise phrasing on my part.)

  A = "It's Raining"
  B = "Water is falling from the sky"

You can probably invent your own, somewhat more humorous examples.

So you can't conclude that because you don't have A or B you don't have C.

It's like saying "Going down the A20 and the M20 (roads in the UK) gets you to Rochester (I've no idea if it does). I've not been down the A20 or the M20, thus I'm not in Rochester." The second sentence there isn't really valid, maybe you took a different route.

Thus !E(x,z), because E(y,x) and E(x,z) would imply E(y,z), which is false.

"Here's this app, here's what it does. How would you increase downloads?"

A quick brainstorm session shows you how they approach the situation, what tricks they have in their bag, and what methods they feel confident using (or if they're just BSing).

Interestingly enough, 50% of the time people answer "SEO," which is among the worst answers you could possibly give. The best answers often involve the person playing with the app and figuring out something you could actually build into the app itself.

These two functions are not separate.

In my own experience the marketer's primary job is to identify how and why your end-users might use your product, i.e. understand who these qualified leads are to begin with.

I'm clueless when it comes to marketing. Could you elaborate here with some examples? I think the majority of apps are in a place where nobody knows they even exist, so how could improving something in them improve downloads?

- Roll your own crypto. Claim unbreakable. Hold contest. Post on HN.

- Army of four-year olds.

- Invite NSA to design committee.

I like to see all kinds of answers, but particularly more theories are better, especially when justified at least loosely. Things like "change the light bulb", "flick the switch", and "check the circuit breakers" are evidence that they have the right mind for breaking a situation out into many different causes.

edit: I absolutely loathe 'out of the box' as a meme, but I love hearing responses like "is anything else in the room turned on?" as it shows a simpler, more direct way of assessment.

Given three tables:

    authors     books       sales
    ----------  ----------  ----------
    id          id          id
    name        author_id   book_id
                title       date
                            price

- price could be 0.0 for a book

- Total sales means the sum and not count

- Date format will be yyyymmdd (if not, assume that we converted in Oracle or Sybase)

    SELECT a.name, SUM(s.price) FROM authors a
    INNER JOIN books b ON (a.id=b.author_id)
    LEFT OUTER JOIN sales s ON (b.id = s.book_id)
    GROUP BY a.name
    HAVING (s.date >= '20131101' AND s.date <= '20131130')

Something like this could work (without going for an alternate approach such as Unions or sub-selects):

    SELECT a.name, ISNULL(SUM(s.price), 0.0) FROM authors a
    INNER JOIN books b ON (a.id=b.author_id)
    LEFT OUTER JOIN sales s ON (b.id = s.book_id)
    GROUP BY a.name, s.date
    HAVING (ISNULL(s.date, '20131101') >= '20131101' AND ISNULL(s.date, '20131101') <= '20131130')

If it were me, I'd prefer to see those that made no sales based on the question. I guess if I didn't want to see them, I would ask for "where sales are greater than $0.00".

    SELECT authors.name, SUM(sales.price) FROM authors
      INNER JOIN books ON authors.id = books.author_id
      INNER JOIN sales ON books.id = sales.book_id
      WHERE sales.date >= Nov 2013 AND sales.date < Dec 2013
      GROUP BY authors.name

I like this question because the base query, however you interpret the unclear parts, is easy, but it still allows candidates to impress me by asking about the "edge" cases. And even if they just makes assumptions, I can still ask them to do the other versions to see if they really know what they're talking about. I'm always amazed at how many people can't convert an inner join to a left join, or can't change a sum() to a count().

If you want to clean it up, drive the compressors/limiters less. ie. Turn the input trim down or turn compressor input gain down.

Another option is to open the compressors up. Take some (or all) of the compressors in the chain and halve their ratios.

A/B and compare.

(Depends on what the source of the track is.)

A lot of writers and would-be writers also have blogs; it only takes one to three paragraphs to figure out who can sling a coherent sentence and who can't.

Like FizzBuzz, being able to sling a coherent sentence doesn't mean that one can write a coherent 50-page document, but those who can't write a coherent sentence can't write a coherent 50-page document.

[1] Try http://blog.seliger.com if you're curious.

I'd have thought there are a lot of people who can write any quantity of text with impeccably placed commas (and semicolons, when the required tone permits them), but would freeze and stutter and gabble if asked for "a couple of major comma rules".

I'd put myself among their number, if only because it's not clear to me what sort of thing you mean by "comma rules". Descriptions of some situations where it is appropriate to use commas? "Commas are commonly used to separate items in a list when there are more than two such items" or "commas may be used, like this, to surround interpolations -- but for all but the shortest such interpolations you should consider using parentheses or dashes, or restructuring the sentence"? Descriptions of situations where it's inappropriate to use commas? "If you have two things that can function as separate sentences, don't separate them only with a comma; use a full stop or, in some contexts, a semicolon"? Or higher-level fuzzier principles? "Stops of all kind are placed to correspond roughly with pauses in speech and boundaries of grammatical units. The comma is the 'smallest' of stops, and is generally not used where the pause would be long or where the break in grammatical structure is great." Or what?

(I suspect a cultural difference at work here: I think formal analysis of grammar and punctuation may be a bigger deal in the US than it is in the UK.)

The short answer is "pretty well." Usually I ask specifically for major comma rules, which I'd tend to define as:

* Connecting independent clauses with a conjunction * As part of a list * To offset a word or phase at the start of a sentence. * Like parentheses (or, in the lingo, an appositive phrase).

If they say, "I have no idea," that's a very bad sign; if they ask questions like yours, that's a good sign.

A fun, short book called Write Right! by Jan Venolia is worth reading if you're interested.

But that is not the same thing as "knowing the rules". A writer may be able to write perfectly correctly without being able to enunciate any rules accurately at all.

Perhaps you play one or more sports. Could you write down accurate rules telling you how to hold and move a tennis racquet, or exactly how to flex the relevant joints when kicking a soccer ball? Of course writing is more deliberative than tennis or soccer, but a good writer isn't thinking about grammar and punctuation much more than a good sports player is thinking about joint angles and muscle groups.

Also, of course, there isn't universal agreement about what is and isn't correct, nor about what the best set of rules is for describing what's correct. For instance, if you compare the famous "Comprehensive Grammar of the English Language" by Quirk and Greenbaum, and the more recent "Cambridge Grammar of the English Language" by Huddleston and Pullum, you'll find that their analyses are sometimes very different. Totally different rules, even though they're describing substantially the same language.

This seems like a case where "why do we use it," an "how do we use it correctly" are obvious but the definition of what it actually is is a complexity we covered once in freshman statistics and never needed again.

You don't hire a telemarketer by asking them "what is a telephone" you hire them by making sure they know how to use one correctly.

You're assuming an underlying model for the data. You have a test statistic( that estimates a model parameter) and you have a hypothesis regarding a parameter. The p-value is the probability that you get a test statistic more extreme than the one observed assuming that your hypothesis is true.

Ex. You have a sample of 1000 men's heights. You compute the sample average height as 5'9 and a sample standard deviation of 3 inches.

(Unlikely) hypothesis: the average height is 4 feet. Your p-value is the probability of getting an sample average more extreme than 5'9 given that your 4 ft height hypothesis is true. Given that the sample standard deviation is 3 inches and 5'9 is 7 standard deviations from 4ft... the p-value is going to be small, so you'll reject that.

Note: I'm leaving out details and assumptions

I usually ask about HTTP and DNS (for web-focused) or Kerberos/AD logins (for user focused).

There are a lot of moving parts to either of these, so a question like: "You type a web address into a browser, it doesn't load" can turn into questions about the DNS resolver process, system and network config, split horizon, time setup, etc.

Basically, I want to know if they have a grasp of how things all go together, and how to test the individual parts that make up the whole.

     * At which layer things are in the OSI model.

     * How to reset AD user passwords.

     * What different kinds of servers are for.

     * Access port 25 in VLAN1 but not VLAN2 using port forwarding in the firewall

      * What ways of securing a DMZ are available in emergencies.

We don't use tcpdump all that often as we have more advanced tools, but if you can't understand a pretty raw representation of network traffic, you're probably not qualified to administer those advanced tools.

...without jQuery.

The DOM API isn't very large/complicated, and it shouldn't be hard to MOSTLY memorize it. It isn't a "gotcha" question though, a good interviewer is not gonna ding the heck out of you if your forget bits of it (most web devs do spend most of their time with jQuery, YUI, etc after all) - it's about whether you understand what's going on behind the scenes.

After all, I often have to look up a rarely used method. Seems unfair to judge harshly if they do so.

Fizzbuzz for websites would be to have someone code two paragraphs side by side with a header and footer in CSS.

I suppose there are people out there that are working as front-end developers for websites that only work in HTML and CSS, but I would think that's getting more rare as time goes on. Of course, that could just be bias based on my own career.

But, going with your suggestion as a thought exercise, I would go in a different direction. To make a pattern like fizzbuzz I suppose I would do something more like: build a page with a series of paragraphs so that these CSS properties apply to every third paragraph, these CSS properties apply to every fifth paragraph, and so on. Something possible with CSS but requires the ability to think things through.

Nobody is going to color code repeating paragraphs in CSS on every project. You wouldn't use that javascript on every project either. (Perhaps these days you would I guess, but I'd argue its overkill for basic websites, to be honest) I can guarantee you're farting around with the box model though, and odds are you could be using a framework to do it for you. Which is precisely why I'd want to test it.

For what I would consider a basic website I'm doing a decent amount of CSS and JS work. But I suppose that could depend upon your definition of a basic website.

EDIT: I should clarify... They weren't asking about the theory behind Ohm's law but rather to apply it to various circuits.

Edit: Last minute surge and we're on the front page! Amazing - thanks to those who voted - I'm waiting to see if we get any more answers ...

Would the equivalent not be making a basic circuit to do something specific and hence a specific example that has one or two potential obvious issues?

  A-->   +--[1 Ω]--+--[1 Ω]--+
         |         |         |
       [1 Ω]     [1 Ω]     [1 Ω]
         |         |         |
         +--[1 Ω]--+--[1 Ω]--+
         |         |         |
       [1 Ω]     [1 Ω]     [1 Ω]
         |         |         |
         +--[1 Ω]--+--[1 Ω]--+    <-- B

Examples of such questions:

Draw the graph of a function f, continuous on the reals, such that: f(x) > 0 always, f'(x) < 0 always, and f''(x) always has the same sign as x.

The line y=3x-2 is tangent to the graph of y=f(x) at x=4. What is f'(4)?

"How do you reflect a vector about a normal? Name some uses."

"What is the dot product? Name some uses."

These aren't just filters but an experienced real-time rendering or physics programmer is going to have quite a lot to say about the practical implementations of either in particular situations and what hardware features are available to help you with them...

if there is a good theoretical understanding then they can talk a lot about what the dot product is, its relationship to matrix multiplication and tensor inner products in general. they can explain multiple approaches to the problem of reflecting the vector and derive their solutions from first principles instead of just repeating remembered knowledge.

there are lots of little domain specific bits of knowledge as well e.g. the reflection question can lead to discussion of the Blinn half angle approximation - why it works and why its no longer a particularly valid optimisation on today's hardware - the dot product question can lead to discussion of how to efficiently handle solving a quadratic equation on the GPU

really i expect a decent (games/vfx) programmer to run out of time whilst elaborating on answers to either of these questions (although not to the detriment of the rest of the test of course...).

the best filter is a strong demo though imo. never met a bad programmer who has a decent demo... none of the average, lazy or bad programmers i've worked with have one that i couldn't have crapped out in the evening before an interview.

  A nation's newest war ship is slowly disappearing. The ship's hull
  is made of Aluminium while its cannon bores are made of Stainless Steel.
  What is happening, why, and how do you stop it?

In terms of reporting...there's no litmus test for how well you can report an event. The education beat, however, is pretty common for new reporters (it was my first), which is ironic considering how ridiculously complicated education is as a topic (same kind of financial/budgetary documents as any business, government bureaucracy, board politics, and of course, dealing with children)

Write your own Fourier Transform. [If your FizzBuzz questions involve actually writing/coding the FizzBuzz, I'd not request actually writing it...]

How would you weight a naive implementation of the DFT vs the FFT?

Luckily he didn't specify the dimensional requirements, so we can get away with f^[0] = f[0].

The first is the easiest, and the second one isn't bad. The 3rd and 4th trip up most people though.

I'd love something like [0]You can't javascript under pressure, but You can't Query under pressure for SQL. :-)

[0]http://games.usvsth3m.com/javascript-under-pressure/

(The "you won" screen is also godawful, not least because of the potential risk of triggering seizures in the epileptic, but also very much because it's incredibly ugly. I mean, I know that tasteless is the new tasteful, but really.)

We're hiring...

More seriously, shouldn't it be possible to post a version thoroughly enough sanitized to avoid giving the game away to your potential applicants, without losing the sense of the original? You don't identify your organization in your HN profile, so it doesn't seem terribly likely anyone who's looking for hints on your hiring process will find it. And, hey, it's entirely possible you'll get feedback which helps improve the question you're actually using in your interviews!

I'd use the Web SQL Database stuff that W3C was working on, except that they stopped doing that in 2010, which guarantees the corpse is dead and rotting; unfortunately, the only emulation libraries I've been able to find implement various key-value stores on top of WebSQL, which is the precise inverse of what I'd need.

I suppose it'd be theoretically feasible, albeit hideously ugly, to create and populate a fresh database and account per user on a MySQL engine; with careful grants and a bit of scripting to kill slow queries before they can multiply and throttle the server, that might be workable on the small to medium scale, although I don't doubt a "Show HN" post would kill it in short order.

Thinking about it, I suspect I've more or less recapitulated why there is currently no "You Can't SQL Under Pressure"; it's a more subtle problem than it seems at first blush. If you come up with any clever ideas on the subject, I'd love to hear about them!

(I catch anything sent to viewthesource.org, so I like to customize it when giving my email to people)

It should be noted that we're in Bentonville, AR. That could potentially be a limiting factor for some people.

That must be a weird change, yeah, but it sounds good on the whole. It's a shame the timing didn't work out on this; if I still lived in Memphis, I'd have jumped at the opportunity. (I didn't like living in Memphis very well -- Bentonville seems like it'd be much more congenial.)

I know a little bit about JB Hunt's IT. They use COBOL and Java. They might have some other stuff, but they seem big on those two from what I've heard.

But I can't think of a similarly low-level proof of Fermat's Little Theorem. Is there an obvious one I'm missing?

But the product is also a^(p-1).(p-1)! by commutativity. So a^(p-1)=1 (mod p).

There's a clever idea in there, to consider prod(ka) for fixed a and k=1..(p-1). Not finding the clever idea means you won't prove it. Finding the clever idea is tricky. Once you know the clever idea the proof is trivial.

If hiring someone, I would describe some practical scenarios problems involving the solution of finite-dimensional linear systems, and ask to see how they would suggest solving them in each circumstance (LU, QR, SVD, iterative methods, etc). More discussion oriented than in doing rote recital of algorithm structure, probably.

I would do something similar for functional characterization/pattern extraction via FFT/DCT/SVD/wavelets/ICA/etc.

Finally, I would construct some problems involving appropriate selection of statistical inference models and associated tests of hypothesis (from the usual the Fisher and Neyman-Pearson perspectives). The basics of Bayesian inference is good to know as well.

Is it the case that someone who can't answer these near automatically is, in effect, incompetent (in this field)?

I'm wondering if you've set the bar higher than FizzBuzz is in computing, or if this really is equivalent.

Thanks!

I feel like the mechanics of test selection biases against people who've specialized in Bayesian stuff—which might be very interesting! It's definitely a make-or-break kind of thing as to whether you can correctly formulate all the various moving parts and relate them correctly.

That said, I also wouldn't expect someone to write out implementations on a whiteboard under pressure (I'm not a Google recruiter). I'd be more interested in prodding their brain to gauge their general level of understanding, which is (I'm pretty sure) how hiring committees for mathematicians in academia operate. If they have a good foundation, I think it's less important that they've rote memorized implementation details.

Honestly, after a certain amount of time, I'd expect a new hire would be able to teach me what is state-of-the-art in the field based on new literature.

But the questions I'd have in mind would be couched like this:

Linear system:

    - Is it small, square, and numerically well-conditioned? Use LU - it's pretty fast to write and pretty fast to use in practice.

    - Is it small, but rectangular (ie. overdetermined), or not as well conditioned? QR is a good choice.

    - Is it small, but terribly conditioned, or do you want to do rank revealing, or low-rank approximation while you're at it? Will you be using this matrix to solve many problems (multiple right-hand sides)? SVD would fit the bill

   - Is it large, or sparse, or implicitly-defined (ie. you don't actually have access to the elements of the matrix defining the system - you just have a surrogate function that gives you vectors in its range, or something)? Use an iterative algorithm. Krylov subspace methods (MINRES, GMRES, conjugate gradient, etc) are your friends here.

    - If you wanted to determine the "strength" of a waveform (in a finite uniform sampling of data) that is re-occurring in a fairly regular way (like arterial pulse in an array of data taken from an oximeter), what type of transformation would you use, and how would you use the resulting information given in transform domain?

   - What if you wanted to determine the strength of a waveform that is short lived/impulse in nature, but re-occurs without any known periodicities (eg. eye blinks artifacts in a sample of EEG data)

   - How would your answers to the above questions change if there are n separate channels of data collected simultaneously (ie. sampled in different locations), which may be analyzed together?

    - What does statistical significance mean, in the context of decision making? Is it a property of the test you perform, or is it a property of your data? (sort of a trick question, this basically rehashes the Fisher vs. Neyman & Pearson debates of the 20th century stats community)

   - Some cod problems of when to use z, t, f tests. Basically, you use them when your situation matches the appropriate inference models (two normally-distributed sample comparison of means with identical variances? t test.)

   - How do you construct an optimal test from scratch, if one doesn't already exist for your particular situation? (basically, if minimize type II error with fixed type I makes you comfortable for your problem, can you do use the Neyman-Pearson lemma to do likelihood ratio construction correctly)

   - What does a p-value actually mean? What if you instead wanted to have actual probabilities for your hypotheses, or you had apriori information that you wanted to use? (Bayesian inference is the winner here)

   - Probably something from point estimation: least squares, minimax criterion, Bayesian MAP estimates, general model fitting, those sort of thing. Brings it all back around to numerical (where I'm most comfortable). Like how applying statistical ridge regression is just knowing how to code up Tikhonov regularization, when you get down to implementation.

    You are given a text in a file. Count all the words in the
    text and print out the words with their number of occurences
    in descending order.

Print number of words:

    wc -w <filename>

    cat <filename>  \
    | gawk '{for (i=1;i<=NF;i++) print $i}' \
    | sort          \
    | uniq -c       \
    | sort -rn      \
    | less

My initial question starts with: "build a function that takes a string and produces an integer". About 30% of candidates fail to get anywhere. 50% produce an incorrect implementation. 20% produce an implementation that is mostly correct. 9% produce an implementation that is mostly correct and well tested. 1% actually produce a complete and correct response. Which, as of right now, translates to exactly 1 candidate in 2 years. Who was rejected due to culture fit. A complete and correct answer is not required to pass the screen. ;-)

The reason this question is so effective is due to how the question is asked and the details of the solution. There is a lot more than just the initial problem statement. The full script assess: the candidates ability to determine requirements; ability to produce complete set of unit tests; ability to handle the boundary conditions.

There is a sharp division that occurs between QA engineers and non-QA engineers on the requirements gathering. All but 1 non-QA engineer I've interviewed assumed they had all the requirements before writing code. A clever solution is almost useless if it solves the wrong problem. Sometimes even worse than useless if the code adds a maintenance cost for no value.

Covering all the critical cases in testing is the next part that most candidates fail at. Even if the requirements they assumed are correct, none of the non-QA engineers have succeeded in writing a complete and good set of tests. Many add too many tests.

After those two the other parts are just seeing how close they can get to building the correct implementation. The candidates typically pass if they do well in all parts; perfection is not required. Still, I think it's interesting to note that almost nobody has ever written a 100% correct solution. Even if they are given all the requirements in detail.

This question does not asses algorithm design ability. At all really. Well, I suppose there was somebody who immediately proposed "binary search!" and really wanted to stick with that idea. No clue why...

    def string_to_int(str):
        
        return 1