We do from time to time, but you do need some leadership positions where there's no time to train up. We've also got a problem with the way we budget...managers are given open headcount rather than open budget for headcount. So if you've got an open headcount, where is your incentive to hire a cheaper option?

No, we're not a startup. We're an established company with over 500 employees (70 technical, split somewhat evenly between the US and China) and close to $100m/yr run rate. We were acquired last year for $423.5m by a well-known and well-respected company with a ~$19b market cap (those numbers alone would be enough for someone Google-proficient to figure out who we are). We don't offer stock options anymore, but we do offer RSUs (whether the stock is up or down, it's still worth something). Out of everything you said, the 5-year contract is probably the only deal-breaker.

We're only looking for people who want the startup feel and agility (small teams, lots of freedom, minimal management), not the startup risk, compensation or work-life balance (the office is almost always empty by 6pm.)

I'm curious what you think a fair wage for a developer would be. I currently have 4 open positions that I'm having a bitch of a time filling. 2 are mid to senior Java openings and the other two are client-side UI positions. We're in downtown San Francisco very close to BART and close enough to CalTrain that our policy of a company-provided MiFi and 90 min of flex time (i.e. you work 45 min of your day on the train in both directions to offset the ~1 hr commute from the south bay) makes commuting from almost anywhere in the east bay or south bay a reasonable option.

I believe the package we're offering is very competitive and yet we only see a steady stream of untalented and mediocre developers. So what should we be offering? How should we be sourcing? We have a culture where people really enjoy working here, so if you're correct, there's obviously something systemically wrong with our recruiting process that we're not finding talented, let alone competent engineers.

The Star Trek reboot suffers from the same phenomenon that most of the recent reboots have. The first movie ends up being good because they get to explore the formative events that turn the characters from something normal into something resembling the iconic characters we know. It's also able to exploit the information we know about where the characters end up for jokes and introductions. But the first movie has to develop those characters nearly completely or they won't be formed enough for the first movie to complete its story arc, so the second film is left with an almost fully-formed character who doesn't have much room for growth.

Sometimes the movie will try to invent character growth that never existed in the original and sometimes Hollywood just amps up the special effects, but it almost always produces a movie that's much less interesting than the first. The only example I can think of off the top of my head where the second movie was great was the Dark Knight series. But that was due, for the most part, to an amazing performance by the villain. But, other than that anomaly, most follow-ups to hero films (I'm including Star Trek in the hero category since it's very similar once you consider the entire crew as the hero) just don't have any direction they can head that will be as interesting as the first movie.

Ashland, Oregon did this many years ago. From what I've heard from people that live there, it's worked out well.

If you change one, you can only keep one of the others fixed. This is an immutable law of any sort of work.

Where I work, we have an agile process, but we're rigid about one thing...sprint plans don't change. Once a sprint plan is finalized and developers have accepted it, managers have two options...blow up the sprint and create a new plan (with a new deadline) or wait until the next sprint. The former option is supposed to be an extreme case and all checkins for the sprint, whether complete or not, are reverted to the previous sprint state. This allows management the flexibility to not wait in emergencies (i.e. we signed a multi-million-dollar partnership with XYZ but their shrink-wrapped software releases two weeks from now and we need our integration by next week) and yet provides enough of a penalty that they don't do it very often.

My company just underwent some major changes. We had open positions before, but we recently had a number of people hit their 1-year cliffs and leave, so we now have a lot of open positions and I'm one of the people that's been designated as a hiring manager. I can tell you that we have zero intention of hiring H1-Bs. If someone already has the paperwork from a previous job, we'll consider them, but we need people now and aren't willing to sponsor.

And yet HR still insists on writing the overly-narrow job descriptions that everyone I know loves to hate. I've tried, on multiple occasions now, to get the descriptions changed to more of a "We use x, y and z and are looking for someone smart that either knows them or can learn them fairly quickly," but every time we test it out, they find ways to sabotage it (I was told, verbatim, "Github is too expensive for an experimental job posting, so we only posted it to Dice").

People on /. bitch all the time about how few jobs there are and how large companies are using H1-Bs to drive down wages. But I also get upwards of ~10 touches from recruiters (the few that mention salary usually say around $200k) on LinkedIn and we've had multiple openings go unfilled for the past 4-6 months because we simply can't find qualified candidates.

This exposure to the HR recruiting process has left me convinced that the majority of the problem isn't H1-Bs or disingenuous companies but, instead, HR that's out of touch with the way that talent looks for jobs these days. Because it's clear that there are people who want jobs and don't have them and jobs that want talent and can't find it.

Shameless plug: If you're in San Francisco and looking for a job, see here: (and don't worry if you don't meet the exact skill set requested)
UI Engineer
Java Engineer

There are a couple of advantages.

For one, the ability to run the same code on the server and client can be very useful. A number of years ago, I remember a presentation on GWT (framework for writing client-side code in Java) where the presenters mentioned that their app would benchmark the client and, when the client's DOM manipulation wasn't fast enough, would use an AJAX request to do the manipulation on the server and pass it back as HTML which was put into the document using innerHTML. In both cases, the exact same source code was executed, but they had the flexibility to run it in both contexts.

Also, using the same languages allows you to minimize the frameworks and technologies you use, making it easier for developers to know them in depth and making it easier, in general, to find developers. You also get a lot more organizational flexibility when developers can be assigned to either front-end or back-end tasks or even hybrid tasks that would otherwise require two different developers with separate skill sets to complete.

Node has been very successful thus far by making use of one important observation...the majority of applications spend most of their time waiting for things (mostly IO) to complete rather than actually doing something. This allows it to use a language that is still, by comparison, dog slow and still be faster than implementations in other languages when implementing most problems. The thing about functional languages like JavaScript is that they're ideally suited to the asynchronous style of programming where every call takes a callback and completes immediately. But functional languages don't seem to get used server-side. There is some Erlang (WebMachine and Riak are awesome at what they do), but most server-side languages are OO and make it very difficult to do this sort of asynchronous programming in a way that feels natural to the developer.

The problem with Node taking over the server side is, as mentioned, JavaScript is still dog slow. There will be times when your bottlenecks are computational and not IO. The Node answer to this is to drop to C/C++, but how many JavaScript developers can do this? Still, no matter what you think of JavaScript as a language, Node.JS is asking some very interesting questions about the nature of server-side programming and which optimizations are most important. Dismissing it because of the toy language it uses is a mistake.

Most of hiring is PR. The best candidates aren't the ones who respond to job postings or who's résumés you find during searches. Finding the best talent requires tapping professional networks and creating the impression, both internally and externally, that the company is a great place to work. For tech jobs, that includes demonstrating that the company is committed to tackling interesting problems and that employees have the chance to be creative and take risks. Google, more than anyone else in the market, has been able to build this perception. And announcements like this only perpetuate this...this is less about them changing their approach to hiring and more about them treating hiring as a big data problem with an interesting answer.

Google's hiring process has, for a long time now, not been about finding the best candidates to work at Google. It's primary value has been the impression that it leaves on candidates that they don't hire. A Google interview is an experience unto itself and helps perpetuate Google's reputation in the industry. This, combined with their army of recruiters, leads to a very high quality of candidate applying with Google and means that their interview process can have a lot of false negatives and still be ridiculously effective.

My company is currently trying to hire a ton of people and I've been trying to impress upon our recruiters how wrong-headed their approach as been thus far (they only post ads and search for résumés). Hiring the best today requires a holistic approach that draws quality people to your company instead of requiring individual touches to bring them in.

Shameless plug: If you're in San Francisco, know either Java or JavaScript and are even thinking of looking for a job, please submit your résumé here or here. We work with a lot of cutting edge technologies, have a small company feel with large parent company that gives great benefits while staying very hands off and our customers love our product (all we have to do is execute technically and we'll grow from $100m/yr run rate to over $1b).

If the government had rules relating to how people's retirements could be invested in hard drives, then I think such rules would be warranted. Among other things, it's the rules for 401(k)s, IRAs and other such accounts that create a need for regulation in the financial markets.

Also, hard drive manufacturers didn't come crying to the government for hundreds of billions of dollars claiming that their mistakes would otherwise crater the economy. When hard drive companies manage to cause an event with a title (and consequences) as compelling as "The Great Depression", it will also be time to regulate the hell out of them.

You know it, you love it. Just continue using Github (just on your own servers)

I would have a lot more sympathy for companies like HBO if they made these services available to everyone. But, instead, you need to spend hundreds, if not thousands, of dollars per year on separate TV service from one of a few blessed providers. If HBO had a ~$10/mo plan that gave access to HBO:Go only, I'd be right there with you condemning people for sharing accounts. But as long as they're using the new online services to prop up the entrenched satellite/cable services and make the service unavailable to many people at any price, they deserve all the abuse they get.

The government finally decided to care and used the one achilles heel of BitCoin...conversion to and from dollars. If BitCoin had some innate value, it wouldn't be a problem, but since it's primary use is as an exchange currency for dodging taxes and selling goods on the black market, this change is going to seriously impact the value of the currency.The government can't control BitCoin, but it can control US financial institutions and other companies that need to interact with those financial institutions.

We'll now see how well the BitCoin market can operate as a completely stand-alone entity.

As poorly written as GP's post was, it zeroed in on the most interesting thing that, at least for me, was said in the interview. When someone is as accomplished in so many areas as Mr Dyson is, it stands to reason that he'd have at least some insight into the educational process. And in both his response on his own education and in the one where he talked about his daughter's education, he indicated that he thought the success of both educational processes was due to a "benign neglect" which allowed the child to actively pursue education rather than having it imposed upon them.

I'm betting that this is true for a certain type of child...one who is curious and driven to learn and that many students don't fit into that category. But thinking back on my own education, I wonder how much more successful I would have been if I'd played a bigger role in shaping my curriculum rather than having it dictated by the schools I attended.

I'm only starting to let the idea marinate a bit, but I feel like there's got to be some way to incorporate this cooperative learning phenomenon where teachers get out of the way of students and simply make themselves available as resources rather than lecturing, dictating and otherwise trying to push information into the heads of students. If feels like a pull methodology would allow students to better learn at their own pace.

The tragedy is that Bush was able to derail his run for the presidency in 2000. He should have been president then, not in 2008. Our country would be in a much better state now if that had happened.