Google’s really not leaving any stone unturned at IO today — it’s now also announced a brand new Android Open Accessory standard, which promises to effectively be its own version of “Made for iPod.” That means that any accessory designed using the API (which could even be something like an exercise bike) will be compatible with any Android phone or tablet — running at least Android 2.3.4 or 3.1, that is. What’s more, Google is also making a reference hardware design dubbed an “ADK” available to developers and, get this, it’s based on Arduino. Right now, it only includes USB, but Bluetooth support is planned for the future — developers can hit up the link below for the complete details on how to get started with it.
Google has announced a new Android@Home initiative at Google I/O today. The system consists of open source libraries that will enable developers to build apps that can discover, connect and communicate with devices and appliances in the home.
This framework makes Google’s own home automation service that developers can build using the new Android Open Accessory API’s. The API’s will allow Android devices to access and control items in the home like lights and speakers.
It also announced a partnership with LG to produce the first lightbulbs controllable using the Android accessory API’s. You’ll be able to turn lights on and off using an Android tablet or phone.
Google stated its commitment to being able to control your environment from Android devices with the phrase ‘we want every device in your home.’
It also talked about a new device called Project Tungsten, that is basically a home controller that runs Android. This will act as an access point for your devices to use to control items around your house.
The demonstration of the way that Tungsten allows your Android devices to play back music and recognize things like CD’s wirelessly were pretty amazing. In the image above a CD was waved near the Tungsten-enabled device and the music began playing from a music library.
With Android@Home, Google is clearly taking aim at Apple’s AirPlay. Not only does the initiative focus on wireless music playback but they take the whole concept one degree further in allowing control and automation of the home with the set of new API’s. It will be interesting to see how Apple responds at WWDC and if they have plans to take AirPlay beyond the music streaming arena and into the realm of home control.
With this announcement, Google clearly positions itself to have the most connected set of devices for users interested in interacting with their home environment.
The Google Android@Home API’s will become available to developers some time in the next few months.
Google’s mantra of launching products early and often didn’t exactly work with Google TV. It hit the ground with a gimped feature set and limited hardware options. The analogy of Android simply hasn’t held true as hardware makers and retail vendors alike simply haven’t picked up the devices. Today, at Google I/O, new hardware partners were announced as well as an updated OS. Google TV might finally be off the starting line.
According to CNET, Google will unveil its cloud music service, Music Beta, at the I/O Developer Conference. The free service will be invitation-only (and US-only) at launch, and it will allow users to upload up to 20,000 songs onto Google’s servers and stream that music to many web-connected devices.
If all that sounds good to you, here’s the monkey wrench: the service won’t work on iOS devices, because Google has (perhaps deliberately) hobbled it by requiring support for Flash Player. While this means the service will work on PCs, Macs and some Android devices, any iPhone, iPod touch or iPad owners will be forced to use alternative services, like Amazon’s Cloud Player or Apple’s presumably forthcoming “iCloud” service.
Like Amazon, Google hasn’t secured licensing deals with the major music labels before launching its music streaming service. Unlike Amazon, Google doesn’t have its own music store to assist in monetizing that service, and by choosing to utilize Flash in its implementation, Google’s also shut out over 100 million potential mobile users from Music Beta. Google, of course, has a “convenient” answer for any iOS users wanting to use Music Beta — buy an Android device — but those of us who are unwilling to do so will either flock to Amazon’s service or hope that Apple comes out with something superior.
We’ve all lived the nightmare. A new developer shows up at work, and you try to be welcoming, but he1 can’t seem to get up to speed; the questions he asks reveal basic ignorance; and his work, when it finally emerges, is so kludgey that it ultimately must be rewritten from scratch by more competent people. And yet his interviewers—and/or the HR department, if your company has been infested by that bureaucratic parasite—swear that they only hire above-average/A-level/top-1% people.
It’s a big problem, especially now. There’s a boom on. I get harassing emails from recruiters every day. Everyone’s desperate to hire developers…but developers are not fungible. A great coder can easily be 50 times more productive than a mediocre one, while bad ones ultimately have negative productivity. Hiring one is a terrible mistake for any organization; for a startup, it can be a catastrophic company-killer. So how can it happen so often?
Like many of the hangovers that haunt modern software engineering, this is ultimately mostly Microsoft’s fault.2 Back when they were the evil empire where everyone secretly wanted to work, they were famous for their “brain-teaser” interview questions – Why are manhole covers round? – and, of course, they asked new university graduates about computer science theory; “Write me a binary search.”
Everyone wanted to be like Microsoft, even Google, until everyone wanted to be like Google (until recently); and so that interview meme persisted. Check out these two recent posts on the subject of interviewing, courtsey of Hacker News: one from a would-be employee, one from a Google interviewer. A couple of illuminating quotes from the latter: “I’m not even necessarily saying that this is a good metric” and “If it’s any consolation, at least we don’t ask gotcha riddle questions anymore. Those were especially offensive.”
It’s nice to see that Google have almost sort of realized that their recruiting algorithm is problematic. Too bad they haven’t fixed it. See also Jean Hsu’s “How Effective Are Technical Interviews?” The fundamental problem is that the skills required to pass today’s industry-standard software interview are not the skills required to be a good software developer. Oh, there’s some correlation, but it’s like the Oakland Raiders always drafting the fastest runners available, only to discover to their endless dismay that the NFL is not a foot race.
Actually it’s worse than that. At least wide receivers have to run, whereas I can guarantee you, without fear of contradiction, that no software engineer will ever have to write a binary search after they are hired. It’s like choosing a contractor because they know how to forge and cast steel using coal, iron, an oven and a bellows, when they actually need to know a) the address of the nearest Home Depot b) what to do with the steel once they buy it.
Joel Spolsky once correctly explained that you’re generally looking for two things in an employee: Smart and Gets Things Done. (Academia is teeming with people who are the former but not the latter.) First, though, you have to establish something else: Not Completely Inept. You’d be amazed how many totally incompetent people show up for technical interviews. Google’s binary search is presumably intended as their “FizzBuzz” – a low bar you have to hurdle just to get in the door. But a FizzBuzz should take all of five minutes, before the real interview begins.
So what should a real interview consist of? Let me offer a humble proposal: don’t interview anyone who hasn’t accomplished anything. Ever. Certificates and degrees are not accomplishments; I mean real-world projects with real-world users. There is no excuse for software developers who don’t have a site, app, or service they can point to and say, “I did this, all by myself!” in a world where Google App Engine and Amazon Web Services have free service tiers, and it costs all of $25 to register as an Android developer and publish an app on the Android Market.
The old system was based on limited information—all you knew about someone was their resume. But if you only interview people with accomplishments, then you have a much broader base to work from. Get the FizzBuzz out of the way, and then have the interviewee show and tell their code, and explain their design decisions and what they would do differently now. Have them implement a feature or two while you watch, so you can see how they actually work, and how they think while working. That’s what you want from a technical interview, not a measure of its subject’s grasp of some antiquated algorithm or data structure. The world has moved on.
1Yes, I am being deliberately sexist here, because in my experience those women who write code are consistently good at it.
2I don’t mind that Bill Gates is a megazillionaire; he’s done a lot of really interesting and innovative stuff. I do mind that a lot of unworthy people rode his coattails to minizillionaire status, eg the inventor of Hungarian notation, probably the dumbest widely-promulgated idea in the history of the field.
Google’s mantra of launching products early and often didn’t exactly work with 
We’ve all lived the nightmare. A new developer shows up at work, and you try to be welcoming, but he1 can’t seem to get up to speed; the questions he asks reveal basic ignorance; and his work, when it finally emerges, is so kludgey that it ultimately must be rewritten from scratch by more competent people. And yet his interviewers—and/or the HR department, if your company has been infested by that bureaucratic parasite—swear that they only hire above-average/A-level/top-1% people.
