bquinlan

I don't have time to do more detailed analysis but, from the article, "In 2052, ...Rose would be approaching her 60s." So lets assume that Rose would be exactly 60 in 2052. So she was born in 1992.

According to projections (http://www.census.gov/compendia/statab/2011/tables/11s0103.p...), a black woman who was 15 in 2007 would be expected to live to 63. So there is a significant risk that Rose would not live to the end of her payout period. But if the expected payout is >>18% of the present value of her payments (which it almost certainly is) then she got a bad deal.

Someone with time could use the annual mortality probabilities (http://www.ssa.gov/oact/STATS/table4c6.html) to calculate the expected payout. I'm bad at analysis so I'd probably use a Monte Carlo simulation.

On Windows, installing Python involves double clicking on the installer, pressing the "Next" button until it turns into "Finish" and then pressing that. No configuration should be required.

But point taken. It would be cool if Python were bundled with the Windows SDK.

Is installing Python 2.7 a huge barrier? I bet that you can download and install it in less than 60 seconds (https://www.python.org/download/releases/2.7.4/).

I'm the submitter and author of the interview solutions.

This project was meant as a learning project for me but I think that it might be useful to others who want to understand how Rust is different from other languages.

Are you talking about the lack of improvements in webapp2 or the lack of improvements in the App Engine Python SDK in general?

webapp2 was started outside of Google by Rodrigo Moraes, who has since moved on to other projects. Googlers have contributed to the webapp2 but have never taken the lead.

There are probably dozens of WSGI-compatible web frameworks that are under active development and you can choose any one that you like.

I actually agree with this remark: "In the talk.origins newsgroup someone made an offhand remark that they didn't see how anybody, no matter how klutzy their programming, could write an O(n^3) sort."

The examples were all constructed by smart people who are deliberately trying to invent slow algorithms. I don't think that a klutzy programmer would stumble upon any of them by chance.

The slowest sorting algorithm that I've seen in production was something like this:

  def sort(l):
      s = []
      while len(l) > 0:
          m = max(l)
          s.append(m)
          l.remove(m)
      s.reverse()
      return s

I looked like a hero when I reduced the main page load time for our biggest customer by 90% in one afternoon :-)

I while ago I wrote a simple Brainfuck interpreter, JIT and compiler (https://github.com/brianquinlan/brainfuck-jit).

The compiler implements the "Operation offsets" optimization as described in the article. It is actually pretty straightforward. This function converts a map of offset => delta to x86-64 instructions: https://github.com/brianquinlan/brainfuck-jit/blob/master/bf...

and the function following it generates that table.

A lot of the comments assume that there are only two choices: hire a local American worker or hire an immigrant. But, as the article shows, there is a third choice: hire outside of the US.

Giving this third choice, I don't think that restricting H1B visas in some fashion (either through cost or availability) will necessarily have the effect of increasing domestic wages. It may have the opposite effect and drive companies to open up shop outside of the US - Microsoft opened up a development shop in Canada for just this reason [1] and my understanding is that Microsoft would strongly prefer that all of its employees be in one location.

The biggest risk would be that American companies start choosing non-US locations as their engineering center-of-gravities because they want to avoid the coordination costs of distributed development without losing the ability to hire non-American workers [2].

[1] http://thetyee.ca/News/2007/11/07/MSWord/

[2] This already happens at a small scale already. I know of a SF-based startup that moved their engineering organization to Europe because they couldn't get visas for key team members.

I graduated in 1997 and, since then, have worked at:

- 2 big companies

- 2 small steady-state businesses (<100 people)

- 4 startups (one as a founder)

So far my best experience has been at Google, where I work now. Here are some of my reasons:

- I have a lot of opportunities to learn because there are so many people with diverse skills and expertise and Google has the resources and motivation to let people investigate novel technologies.

- I work with amazing technology. Google has the resources to devote many engineers to internal development tools and production technologies.

- I don't have to work with (many) crazy people. At startups and small businesses, I found that one crazy founder or manager (who is probably related to the CEO) can completely ruin the experience. Google has processes to avoid hiring such people or to deal with them post-hire.

- The work I do effects a lot of people. My Mom has commented on features that I've implemented. And, since we usually work in small teams, my impact isn't usually diluted by a lot of people.

- There is a lot of project diversity and ability to relocate (if you want). So far I've worked on Google's support systems (Dublin), search (Dublin), App Engine (Sydney) and Chromecast (Mountain View).

- I get paid well without a lot of risk. At Google my base salary is pretty high and I can treat my bonus and equity awards as extras that I don't need to count on. And the bank can count on Google too so I can get a reasonable mortgage.

Not everything is perfect, of course. Two months ago a bunch of work I did was thrown away because my manager's manager's manager's manager didn't like it (his reasoning was sound but...) [1]. And bigger companies are under increased scrutiny so you have to be more careful about privacy, regulatory compliance, etc. A lot of things that you would just do at a startup require consultation with lawyers at a big company.

And my other big company experience really really sucked. I won't go into the details here but I ended up quitting in about 3 months.

[1] http://www.reddit.com/r/Chromecast/comments/22n3uv/squirrels...

How are people at Google trying to screw up your life? Are you talking about the (seemingly bi-directional) hostility on Hacker News that seemed common a year ago or something more?

You mentioned that you sued and won some cases for tortious interference (https://news.ycombinator.com/item?id=7645843) - was that against Google employees? Can you share some details?

You should probably file your bugs here: http://bugs.python.org/ with the expectation that fixes will be backported.

I'd like to point out that the Python standard library offers an abstraction over threads and processes that simplifies the kind of concurrent work described in the article: https://docs.python.org/dev/library/concurrent.futures.html

You can write the threaded example as:

  import concurrent.futures
  import itertools
  import random

  def generate_random(count):
    return [random.random() for _ in range(count)]

  if __name__ == "__main__":
    with concurrent.futures.ThreadPoolExecutor(max_workers=2) as executor:
      executor.submit(generate_random, 10000000)
      executor.submit(generate_random, 10000000)
    # I guess we don't care about the results...

Changing this to use multiple processes instead of multiple threads is just a matter of s/ThreadPoolExecutor/ProcessPoolExecutor.

You can also write this more idiomatically (and collect the combined results) as:

  if __name__ == "__main__":
    with concurrent.futures.ThreadPoolExecutor(max_workers=2) as executor:
      out_list = list(
      	executor.map(lambda _: random.random(), range(20000000)))

In this example case, this will be quite a bit slower because the work item (in this case generating a single random number) is trivial compared to the overhead of maintaining a work queue of 200000000 items - but in a more typical case where the work takes more than a millisecond then it is better to let the executor manage the division of labour.

I actually don't mind the day-of-interviews thing because I find it fair and encourages hiring efficiency. For example, if I lose a day to do 6 interviews then the company loses 6 engineer-hours (+ time to write and assess feedback). That will discourage doing a large number of interviews with a low hire rate.

OTOH, I hate having interview "homework" because they take a lot of my time but cost the company almost nothing - they can easily have a hundred people doing the homework, get one engineer to spend a day evaluating them, and then only hire one person.