I agree completely. I'm hopeful that we'll elect a Democrat sometime soon. We haven't had one since Carter.

Huawei has already been caught putting government backdoors into their networking equipment. It's not Lenovo's reputation that's being impugned, it's the Chinese Government's. It's no different than concerns over using US cloud services given what's been revealed about the NSA's FISA requests to Apple, Google, Microsoft and others.

It's entirely reasonable to assume that any cloud service with a US presence could potentially cooperate with the NSA even if they have no current history of doing so. Likewise, it's entirely reasonable to assume that any Chinese company may be forced to cooperate with the Chinese government. Hell, it's entirely reasonable to assume that any product produced in China may have backdoors. I hope, for the sake of the security of these countries, that they're also including products designed in countries without a record of these practices but produced in China in their black-listed equipment.

This is a lesson that I wish more language designers would grok. At this point, with everything that has been written in C, the first feature you implement beyond the basics of your language should be easy bi-directional C interoperability. And if you can use C calling conventions, that's even better. It's super frustrating to watch a promising language like Go waste years creating their own API when they could have gotten near instant adoptability if they'd just allowed us to use their language with our existing C/C++ code.

C is like email. Anything that seeks to replace it can't operate under the assumption that people will use the new solution instead of it. It has to be designed from the beginning to work with it and enable a gradual migration away from it.

Those numbers are entirely reasonable and, assuming those are base numbers before a 10-15% bonus and RSU grants, we can and do pay developers that much. If that assumption is wrong, we pay a bit more. Our benefits are also well above average. If you're looking to move, we should talk.

Feel free to contact me at: tblair [at] demandforce.com

Yes, we can afford a few extra grand to help move and we'll pay to fly candidates in for their interviews. We do ask out-of-area candidates to go through an extra phone screen just to give both sides a greater confidence that it's worth the time, expense and hassle that go along with a long-distance interview.

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.