The issue isn't that I got wrapped up in it, the issue is that screwing up something that you know is straight-forward towards the beginning of an interview will throw you off, because it's only an hour and you don't have opportunity to recover.
Was this a phone screen? Normal Google interviews are 5 hours; four one-hour technical interviews and a one-hour lunch.
All I can say is that I think you had a worse-than-average interviewer if you felt like nothing was done to help you feel less nervous. Sorry.
Also, as I said, most Google employees I talked to either joined right out of university, or required multiple tries at the interview process.
That's not my perception. Most of the 30+ people on my team were professional hires, most with 10-20 years of experience. Only one of them had more than one interview. I only had one.
I've worked with people that were absolutely brilliant programmers but were terrible to work with - horrible with communication, had to hand-hold to get them from one task to the next, and would never adhere to company best practices, among other things. These quizzes and problems don't do anything to ferret this kind of stuff out so how is your "big" company less prone to false negatives?
Clearly presenting the solution to a problem does a lot to demonstrate communication skills, so I think that does come out. And Google interviewers typically leave the problems underspecified, to see how the candidates will work out or ask about the pieces they need to clarify, which partly addresses your second point. As for adherence to best practices... no, the interview can't get at that, and I don't see how any interview really could.
If I sit down with a peer (the kind of person I'm looking for in most cases) it's easy to establish rapport. Can I talk about C++ standards, new language features, pros and cons and trade-offs? Can I bring up a tricky design problem and hash it over with them? And so on.
This is the approach I used for years... and I thought it worked pretty well, too. But I made a couple of bad hires using it (not at Google) because I ran into some guys who could talk the talk, but couldn't really do the job. The approach also presumes a level of experience that may not be present. You said you're looking for a peer in most cases, but what if you are evaluating a new grad? What if the new grad has never used C++?
My eyes were opened years ago when I started augmenting the sort of interview you describe with some simple coding problems -- just easy stuff like "write a function to insert an element into a sorted singly-linked list". What I found was that lots of people who'd been around the industry for a few years could talk about stuff quite well... but struggled to write code that worked, or generated the most inelegant, confusing muck imaginable.
IMO, the approach you're talking about is much easier to game and much more limited in applicability than the "solve a problem for me" approach used by Google and other big tech companies. It does have the advantage that it's less prone to false negatives (rejecting good people), but for most companies I think it's more important to avoid the false positives (accepting bad people).
The proof is in the pudding, and from what I see Google's approach works well at ensuring that only good people are hired. The people I worked with at IBM were highly competent, by and large, and the same is true of most of the smaller companies I worked for (with a notable exception). But at every other place I've been I ran into the occasional plodder, or just outright incompetent. So far, in my 8 months with Google, and in interactions with dozens of people in all sorts of job roles, I've yet to find a single person who isn't bright and competent. I'm sure Google rejects plenty of good people, too, but it appears to make very few bad hires.
That is why you talk to the candidate about his past accomplishments
Except that doesn't work. It's way too easy for candidates to slant or exaggerate their accomplishments, take credit for the work of others, etc. Sometimes you can figure that out by digging and finding holes in their knowledge of the accomplishments they're claiming -- but that can give you false negatives because people forget.
It also doesn't help much when evaluating people who are fresh out of school -- and Google hires a lot of those.
you get references
References don't work either. Many corporations have a no-references policy to protect themselves against lawsuits by former employees. For example, before coming to Google I spent 14 years at IBM. If Google had relied on references, the majority of my career would have given them nothing more than "Yes, Mr. Willden was employed by IBM from 1997 to 2011". Period. Any of my managers or peers who gave a more in-depth reference could have faced punitive action.
Actually, though, Google does check references. And I gave them the names of several of my former IBM colleagues who kindly violated company policy and provided detailed information.
But good references are no guarantee... lousy candidates can often find a few friends who will give glowing reviews. It's also far from unheard-of for a manager with a problem employee to willingly give an outstanding positive review to a potential employer. And bad references, or confirmation-of-employment references don't tell you much either. There's just too much potential for extraneous bias.
you can even talk about solving a hypotetical or real problem to see him in action.
Yes, this is the right approach, and it's the one Google interviewers are supposed to use.
But brain teasers are just that. They are aimed at that one "Gotcha" moment you either get or you dont.
Agreed, those are really bad interview questions. In the Google interviewing guidelines, and in the internal repository of interview questions, those sorts of questions are specifically disallowed. A question that depends on some flash of insight that may or may not come is useless, because even the smartest candidate may not get the flash, or may not get it right now.
Good interview problems have depth and breadth, with lots of opportunities for modifying them in small ways that change the character of the problem and appropriate solutions, and with lots of potential approaches for optimization. For example, I like to have them solve the same problem with limited resources, maybe a single embedded CPU with kilobytes of RAM, and with huge resources, maybe a 40,000-CPU compute cluster with terabytes of RAM, and then discuss the reasons for the differences in approach.
As an example, I had an interview with Google a few months ago. One of the questions was to write a UTF-verifier. The interviewer gave a quick description of what valid UTF looks like, and I had to write a function that verified if a given byte array was valid UTF. I hadn't done that kind of low-level bit-fiddling in a few years, and so getting the low-level stuff right (how do you check if the first bit is 1 again?) slowed me down significantly and really threw me off the larger view of the problem.
Part of the solution to this problem -- and it is a problem -- is the fact that you're not evaluated based on a single interview. The hope is that if you flub one interview, for whatever reason, there are three others.
But the real solution is to not try to remember stuff. The interviewer really isn't trying to evaluate your knowledge so much as your problem-solving ability, which includes how you react to needing information that you don't have. If you're getting hung up on some trivial side-issue, just tell the interviewer what you don't remember and ask if he'd like you to focus on solving that problem or if he'd rather give you a hint. Perhaps you could have just written the prototype for a function is_msb_one() and written the rest, then come back to that.
The truth is that this is one aspect of the interview process that I think really does apply very directly to the actual job. See, engineers at Google don't have a lot of supervision. It's really easy for someone, especially someone new, to end up wasting huge amounts of time trying to figure out something that they should either look up or ask someone about. So it's really important to find people who won't let themselves get wrapped around the axle. I'd say it's likely that in your case your interviewer dinged you for getting thrown off the larger view of the problem, rather than because you didn't remember some bit-twiddling tricks.
I've interviewed lots of people using puzzles of this sort, and I find they work really really well for picking out the better programmers. You need to understand how to do it correctly, though. You're not looking for whether they "get the right answer". You're looking to see how they approach the problem and what sorts of solutions they try (even if they end up not working).
Mod parent up.
I work for Google, and interview engineering candidates at Google (which doesn't make me special -- all Google engineers are expected to participate in interviewing), and the above describes what these puzzle questions are really intended to do.
Evaluating candidates is a really, really hard thing to do. Honestly, it's darned near impossible to do accurately unless you can bring someone in for a few weeks, put them to work on real problems and see how they really perform. Even then you're just scratching the surface. Trying to get a realistic read on someone's capabilities in just a single day? Yeah, right. But hiring decisions must be made, and Google gets hundreds of thousands of applicants per year.
So, the question becomes not how to truly, accurately evaluate each candidate, but how to fill the positions and ensure that no egregiously bad hires are made. It's sad to reject someone who is really good... but it causes tremendous grief to hire someone who just can't do the job, because firing people is really painful for everyone involved, and quite expensive to the employer.
With that in mind, here are my perspectives on the article's points, based not only on what Google does, but also on the dozens (hundreds?) of job interviews I did at previous employers.
1. Recognize that tests are artificial scenarios
This is inarguably true. The interview is a completely artificial environment which bears no relationship to the actual job. But there's no way to avoid that, so the question become what is the best way to extract as much useful information about a candidate's abilities and characteristics as possible in the brief time allowed. And the time has to be very brief, because getting any kind of an accurate reading depends on getting multiple points of view, and fitting four or five interviews into a day without killing the candidate means that each interviewer really only has about 45-50 minutes.
The article comments that the problems are hypothetical, without context, etc., but that's because there's no way to present real-world problems in the timeframe given. And, actually, underspecifying problems is deliberate, because it's a good way to see how the candidate reacts to inadequate requirements specifications, which is perhaps the one part of the interview which accurately models the real world at every place I've worked in 20+ years.
So, the goal is to construct an artificial environment which tests the things that can be realistically tested. Google is perhaps a little different than most companies in that Google doesn't really care what the candidate knows. The infrastructure is so different from everywhere else that it's really not important; there will be so much to learn anyway. Well, basic CS knowledge is crucial, but specific tools and techniques? Nah. What really matters is how quickly the candidate can understand problems, how effectively they can reason their way through the solution space, how well they can communicate their solutions -- verbally and in code -- and how well they can analyze their solutions and explore alternatives. It's all about problem solving and the only way to understand someone's problem solving abilities is to watch them solve a problem they haven't seen before.
The "they haven't seen before" is crucial... and it's also pretty easy to verify. Here's a word of advice: If you go into an interview and are presented with a problem you already know the solution to, tell the interviewer up front that you've seen it before. Odds are the interviewer will figure that
Fourth, in the old days, such awkward/geeky people didn't get much chance to reproduce.
I don't think this is true. I think in the old days such people were much more likely to reproduce with a partner who is more "normal", though, because it was harder to find a mate with similar characteristics. Instead, they just found someone who was less desirable in other ways. For example, uglier.
Does this happen on the phone or is it service based like Siri? I know Google has that massive voice recognition trainer they call Google Voice collecting billions of Bayesian decisions every day.
It's service-based. I've tried to use it a few times when I was in the sticks and didn't have reliable data service, and it just errors out every time when trying to translate the voice.
We didn't have them when I was a kid, either, but that is a sad and unfortunate thing.
In decades and centuries past, many disorders were not understood, not diagnosed and just attributed to stupidity, or rebelliousness, or negative character traits. Those people just failed or succeeded as best they could on their own -- mostly they failed. In the case of allergies many of them just died.
These disorders are fundamentally no different from, say, presbyopia. They have a mixture of congenital and environmental causes, and they are debilitating to those who have them. Centuries ago, people who were near-sighted just had to suffer with their "weak eyes". Medical science now has multiple options to correct that defect, via prosthetics or surgical alterations. The same applies to these "newer" disorders, except that we're only beginning to understand them and how to treat them.
I have ADD, as do my three boys (one is also hyperactive; ADHD). Actually, they all have more severe forms of it than I do. I recognize in them the same difficulties I had in school when I was a kid... with the difference that they take medications which reduce the impact of their ADD making it far easier for them to excel in school. Those who think such kids are "drugged dull" don't know anything about it; most ADD medications are stimulants. In fact, I've realized that I self-medicate for my ADD, too, except that I do it with caffeine rather than Concerta.
An even better personal example is my daughter, who suffers from a mental illness that has only been recognized in the last couple of decades (and we now know is very poorly named): Borderline Personality Disorder. In the past, people would just have said she's a bitch (actually, lots of people say that today), but we now understand that it is actually a severe emotional disregulation disorder. On the surface it looks like extreme, random bitchiness, but when you understand the nature of the disorder you begin to see the patterns and to understand the reasons and the triggers -- and to have some compassion for the fact that as much as it sucks to be around her, it really, really sucks to be her. In fact, more than 25% of people diagnosed with BPD do not survive to age 30, mostly because they kill themselves (she's been hospitalized multiple times for attempts).
What makes this even more interesting is that as I look back in my family history it becomes clear that there have been others who suffered from BPD. They all led utterly miserable lives, and about half of them suicided. But no one understood what it was; they just thought it was a character defect.
Today, we are beginning to understand it, and beginning to realize that it's not particularly rare. Many of the extreme assholes you run into really are just sick... and there are some treatments that can help.
From a pure Darwinian perspective, you can argue that all of this medical intervention is a bad thing; that these people should just fail, or die. I disagree. Just as I appreciate the fact that I can wear glasses to address my presbyopia, and use caffeine to help me concentrate, I appreciate that we are learning to remove handicaps from many capable and brilliant people.
An experience that has cemented my perspective on this is getting to know many of the other girls in my daughter's treatment center. The treatment center handles teens with both behavioral health and substance abuse problems -- and actually it turns out that substance abuse is most often an attempt to self-medicate for an underlying mental or emotional health disorder. This was a 24-hour residential treatment facility, so all of the kids there were pretty hard cases; they ended up there after repeated behaviors that were deadly dangerous to themselves and/or others, or after major run-ins with the law or (usually) both. They were also mostly kids with pretty good parents.
What I was surprised to find after getting to know a lot of them was that they were also, almost wi
The Android (and earlier iPhone) voice 'commands'? Garbage. Siri is fantastic to use. Wanna reply to a text message or email while driving?
I do that with my Nexus S all the time. Texts are read aloud to me, I reply verbally. I've carried on long conversations that way, with near perfect fidelity. I'm going to be very interested to see how Siri can be better.
I've been saying this for a long time; the purpose of patents is to encourage disclosure so that others will be able to find and use your ideas
The US Constitution spells out the purpose of patents: (paraphrasing) To encourage innovation and invention by providing a limited monopoly.
If you're looking for an institution that was specifically designed for disseminating and discussing ideas, then I would suggest you look at the academic community.
The US patent system was not created for the purpose of disclosure. It was created to encourage invention, as mandated by the US Constitution. Disclosure is just a necessary implementation detail, because the public needs to know specifically what they are forbidden to infringe upon.
Nonsense.
The Constitution doesn't define patent law. It just lays out the authority of Congress to grant short-term rights in order to encourage innovation. This is the origin of the authority to create patents and copyrights, but it doesn't define their purpose.
To understand patents, you need to review the various incarnations of the law, the history of the debates and discussions that defined its structure and purpose and -- most importantly -- the relevant jurisprudence, where the courts have clearly laid out the purpose. My characterization was correct.
Even before requiring that the source code be published, it'd be a good first step to require that it be written. Lots of the submarine patents are never even implemented. But, yeah, requiring publication of source would be good.
I would actually like to see publishing the source to be a requirement for obtaining copyright on software as well. The vast majority of commercial software benefits from copyright protection but will never, ever truly be released to the public domain (which is the fundamental purpose of copyright, to increase the flow of creative works into the public domain) because by the time the copyright expires an insanely long time from now the source code will be long lost. Of course, even if it were published, odds are very, very high that by the time it falls into the public domain no one will care any more, but still, the idea of copyright is that copyrighted material is supposed to become public domain eventually.
Oh, never mind. I didn't read to the bottom of the question. Passpack isn't a good solution (or at least not a complete one) because the OP doesn't want his siblings having access to his accounts until he's dead.
With a free account it only allows you to share with one other person, which isn't ideal for your use case -- though I suppose you could always just share the passpack login credentials.
Passpack is very convenient because it's browser-based, but security is supposed to be pretty good because it's all encrypted on the client before being sent to the server, so passpack never has enough information to be able to recover your passwords. I haven't verified the code, but the architecture looks very well thought-out from a security perspective. Sharing is done by first generating public/private keypairs for both participants and then encrypting the shared keys with the recipient's public key (well, that's the gist; the details are more complex). That stuff is all mostly transparent to users, though (mostly because there is some setup that has to be done).
I have been using it to manage all of the keys I use for various web accounts, and for sharing the passwords with my wife. It allows me to use long, complex, unique passwords for all of my web accounts, and to do so fairly conveniently. My wife doesn't like it; she'd rather just have a single password we both know and use on all of the important sites, but she also recognizes why that's a bad idea, so she uses passpack -- and grumbles about it.
Mine grows constantly, due to the continual influx of new photos and video. And whenever I upgrade my cameras the size per image or per minute of video increases.
When I looked at the data that I REALLY needed to keep, I came to "not very much". Nothing that I could not host (encrypted) at my provider. I am talking less then 20MB in data.
Don't have kids?
For those of us that do, we typically end up with a lot of photos and video that we would really, really hate to lose.
My solution for this is high-volume off-site backup using Tahoe LAFS. I have about 200 GB backed up now, and will have 400 GB within a couple of months.
20 disks seems like overkill for your storage needs. Seems like the more disks you use the greater the risk of failure of one or more of them. Also, your electricity bill must be through the roof. I have 4 3TB drives with a 3Ware controller in RAID5 array which gives me the same storage capacity with 1/5th the drives.
You should seriously consider adding another drive and migrating to RAID6, because RAID5 has a fatal flaw that may cost you all of your data (or at least force you to restore from backup, but, seriously, keeping 9 TB backed up isn't easy).
The problem with RAID5 is that if you lose one of your drives it leaves your array in a very risky state. This seems obvious, since it's clear that the failure of any drive at that point will lose all of your data, but it's actually at least an order of magnitude worse than it appears. Why? Because the failure of a second drive at that point is actually quite likely. When you install a replacement drive, the array has to resync to incorporate the new drive and get back to a health state. Do do this, the resync operation has to read every single block of every remaining drive. This means that if there are any other latent failures, unrecoverable blocks that just haven't been noticed yet, the resync will find them and the resulting failure will lose all of your data.
In fact, even a transient failure can lose all of your data. I was actually able to recover mine once, due to the fact that I was using software RAID rather than hardware. Linux mdraid allowed me to "forcibly" restart my degraded array (carefully specifying the order of my disks exactly as they had been; which information I had thanks to the e-mails md had sent me), at which point I ran out and bought enough big disks that I could back the entire set up. The backup succeeded.
After a similar experience which was even more harrowing because the failure wasn't transient, I abandoned RAID5 for data I care about and switched to RAID6.
My current approach is:
Unimportant data goes on RAID0.
Replaceable data goes on RAID5 (this is mostly movies ripped from DVD, in my case -- I have the DVDs and could re-rip if needed).
Important data goes on RAID6, with a hot spare. Since my RAID6 array has six disks (including the spare), this is as inefficient as RAID10 would be, but with better survivability (and worse performance, but that doesn't matter to me).
Irreplaceable, critically important data goes on RAID6 and gets backed up to a Tahoe-LAFS distributed grid, which will ensure that it will survive even in the event my house burns down. My portion of the LAFS grid resides on RAID5 at present, though I'd also be okay with keeping it on RAID0.
In addition, I also run regular surface scans on all of my drives. In theory this should make RAID5 acceptable since it should identify any waiting problems before the array is degraded. In practice, I still don't trust RAID5.
The other problem is that patents really fail at their primary purpose: encouraging disclosure. No one looks for algorithms by doing a patent search.
Mod parent up.
I've been saying this for a long time; the purpose of patents is to encourage disclosure so that others will be able to find and use your ideas (after paying a license fee -- that's the motivation to disclose). So the clearest test of whether or not the system is working is the degree to which working professionals utilize the patent database as a resource for solving their problems, and by that standard it's hard to imagine how the system could be a greater failure. Not only do software developers not mine the patent database for ideas, they are told by their attorneys to avoid looking at patents. Why? Simple: Because everyone recognizes that there is nothing of value to be found, and looking only creates risk because if you find out something you're doing is patented then you have to stop, or risk treble damages for willful infringement.
The bar for patents is so low, and the number of non-obvious patents so few, that there's no value in searching for patents. This makes it abundantly clear that the patent system has become a mechanism for locking up ideas, not for disseminating them, which means it has utterly failed its fundamental goal.
Patent reform is badly, badly needed, because right now the system we have is actually worse than nothing. I think a good patent system would be of value, but what we have now actively discourages innovation and squelches progress, at least in the software realm.
The only thing left to argue about is how much do we contribute... 80%? 50%?
That's not the only thing. Another thing we need to decide is how much it matters.
The planet has been both considerably hotter and considerably cooler than is now, several times each, so it's clear that it's a chaotically stable system. Otherwise it would have run away in one direction or the other. Indeed, some of the thermo-regulation mechanisms are quite obvious, such as increased temperatures causing increased evaporation, leading to more cloud cover, increasing the albedo of the planet and decreasing thermal input from the sun. I think it's very likely that nothing we can do will cause more warming than can be offset by reducing the thermal input by one or two percent, so long-term I don't think we need to worry about the planet becoming unlivably hot. Based on the what we know about the planet's history since life became widespread, severe cold periods are more likely to be inimical to human comfort than the hottest ones.
But, since we don't want to have to spend too much effort moving cities further inland due to rising seas, or otherwise adapting to the climate changes (especially rapid changes), we need to get an understanding of just how hot it's going to get, and just how fast it's going to get there. We should also consider impacts on wildlife, too, since (IMO) healthy nature is of benefit to humans. Understanding what the likely impacts of CC will be will allow us to make rational decisions about how we should respond. That's going to require a lot more climate science, though.
No, he doesn't. It's winding down exactly on the schedule set out by the DoD at the end of Bush's term -- though it wouldn't be ending even that soon except that the Iraqis won't let us stay any longer.
Are you kidding? This is *perfect*. Complain three times in meetings with as many witnesses as possible that "this exposes us to risk of downtime and high support costs", and be sure to end with "...this is your call, but its against my professional advice". Have that minuted.
That's a great approach if you are interested in competing with your boss, and taking his job. But you'd better be sure you can do it before you get that aggressive, because if he's politically savvy -- and it's not likely he got to be CIO if he's not -- he'll recognize that you're setting yourself against him. Depending on his character and his level of confidence, he may do nothing, he may just put a mental black mark against you to be remembered during next year's performance reviews, or he may set out to force you out.
Saying it once in front of witnesses, before he's already made the decision clear, is fine. That's not making a play, that's just doing your job and pointing out options and issues. But three times? In front of lots of people? And especially if you ask to have it written into the minutes... that's going on the offensive and he's very unlikely to miss it, or to take kindly to it.
Am I missing something here that says we have to compare all these people on the merits of their accomplishments?
No, you're not missing it, because it's not there. The summary and article say nothing of the sort.
What they do point out is that if we hadn't been somewhat sensitized to it because of annoyance at the media reaction to Jobs' death, we likely wouldn't have paid nearly as much attention as we have to Ritchie's passing. This isn't a question of comparing Jobs and Ritchie, it's just pointing out that we often don't recognize the accomplishments of the people who really changed the world, but did it quietly.
Slashdot Mirror
The issue isn't that I got wrapped up in it, the issue is that screwing up something that you know is straight-forward towards the beginning of an interview will throw you off, because it's only an hour and you don't have opportunity to recover.
Was this a phone screen? Normal Google interviews are 5 hours; four one-hour technical interviews and a one-hour lunch.
All I can say is that I think you had a worse-than-average interviewer if you felt like nothing was done to help you feel less nervous. Sorry.
Also, as I said, most Google employees I talked to either joined right out of university, or required multiple tries at the interview process.
That's not my perception. Most of the 30+ people on my team were professional hires, most with 10-20 years of experience. Only one of them had more than one interview. I only had one.
I've worked with people that were absolutely brilliant programmers but were terrible to work with - horrible with communication, had to hand-hold to get them from one task to the next, and would never adhere to company best practices, among other things. These quizzes and problems don't do anything to ferret this kind of stuff out so how is your "big" company less prone to false negatives?
Clearly presenting the solution to a problem does a lot to demonstrate communication skills, so I think that does come out. And Google interviewers typically leave the problems underspecified, to see how the candidates will work out or ask about the pieces they need to clarify, which partly addresses your second point. As for adherence to best practices... no, the interview can't get at that, and I don't see how any interview really could.
If you put quotes around the word you'll get the same effect.
If I sit down with a peer (the kind of person I'm looking for in most cases) it's easy to establish rapport. Can I talk about C++ standards, new language features, pros and cons and trade-offs? Can I bring up a tricky design problem and hash it over with them? And so on.
This is the approach I used for years... and I thought it worked pretty well, too. But I made a couple of bad hires using it (not at Google) because I ran into some guys who could talk the talk, but couldn't really do the job. The approach also presumes a level of experience that may not be present. You said you're looking for a peer in most cases, but what if you are evaluating a new grad? What if the new grad has never used C++?
My eyes were opened years ago when I started augmenting the sort of interview you describe with some simple coding problems -- just easy stuff like "write a function to insert an element into a sorted singly-linked list". What I found was that lots of people who'd been around the industry for a few years could talk about stuff quite well... but struggled to write code that worked, or generated the most inelegant, confusing muck imaginable.
IMO, the approach you're talking about is much easier to game and much more limited in applicability than the "solve a problem for me" approach used by Google and other big tech companies. It does have the advantage that it's less prone to false negatives (rejecting good people), but for most companies I think it's more important to avoid the false positives (accepting bad people).
The proof is in the pudding, and from what I see Google's approach works well at ensuring that only good people are hired. The people I worked with at IBM were highly competent, by and large, and the same is true of most of the smaller companies I worked for (with a notable exception). But at every other place I've been I ran into the occasional plodder, or just outright incompetent. So far, in my 8 months with Google, and in interactions with dozens of people in all sorts of job roles, I've yet to find a single person who isn't bright and competent. I'm sure Google rejects plenty of good people, too, but it appears to make very few bad hires.
That is why you talk to the candidate about his past accomplishments
Except that doesn't work. It's way too easy for candidates to slant or exaggerate their accomplishments, take credit for the work of others, etc. Sometimes you can figure that out by digging and finding holes in their knowledge of the accomplishments they're claiming -- but that can give you false negatives because people forget.
It also doesn't help much when evaluating people who are fresh out of school -- and Google hires a lot of those.
you get references
References don't work either. Many corporations have a no-references policy to protect themselves against lawsuits by former employees. For example, before coming to Google I spent 14 years at IBM. If Google had relied on references, the majority of my career would have given them nothing more than "Yes, Mr. Willden was employed by IBM from 1997 to 2011". Period. Any of my managers or peers who gave a more in-depth reference could have faced punitive action.
Actually, though, Google does check references. And I gave them the names of several of my former IBM colleagues who kindly violated company policy and provided detailed information.
But good references are no guarantee... lousy candidates can often find a few friends who will give glowing reviews. It's also far from unheard-of for a manager with a problem employee to willingly give an outstanding positive review to a potential employer. And bad references, or confirmation-of-employment references don't tell you much either. There's just too much potential for extraneous bias.
you can even talk about solving a hypotetical or real problem to see him in action.
Yes, this is the right approach, and it's the one Google interviewers are supposed to use.
But brain teasers are just that. They are aimed at that one "Gotcha" moment you either get or you dont.
Agreed, those are really bad interview questions. In the Google interviewing guidelines, and in the internal repository of interview questions, those sorts of questions are specifically disallowed. A question that depends on some flash of insight that may or may not come is useless, because even the smartest candidate may not get the flash, or may not get it right now.
Good interview problems have depth and breadth, with lots of opportunities for modifying them in small ways that change the character of the problem and appropriate solutions, and with lots of potential approaches for optimization. For example, I like to have them solve the same problem with limited resources, maybe a single embedded CPU with kilobytes of RAM, and with huge resources, maybe a 40,000-CPU compute cluster with terabytes of RAM, and then discuss the reasons for the differences in approach.
As an example, I had an interview with Google a few months ago. One of the questions was to write a UTF-verifier. The interviewer gave a quick description of what valid UTF looks like, and I had to write a function that verified if a given byte array was valid UTF. I hadn't done that kind of low-level bit-fiddling in a few years, and so getting the low-level stuff right (how do you check if the first bit is 1 again?) slowed me down significantly and really threw me off the larger view of the problem.
Part of the solution to this problem -- and it is a problem -- is the fact that you're not evaluated based on a single interview. The hope is that if you flub one interview, for whatever reason, there are three others.
But the real solution is to not try to remember stuff. The interviewer really isn't trying to evaluate your knowledge so much as your problem-solving ability, which includes how you react to needing information that you don't have. If you're getting hung up on some trivial side-issue, just tell the interviewer what you don't remember and ask if he'd like you to focus on solving that problem or if he'd rather give you a hint. Perhaps you could have just written the prototype for a function is_msb_one() and written the rest, then come back to that.
The truth is that this is one aspect of the interview process that I think really does apply very directly to the actual job. See, engineers at Google don't have a lot of supervision. It's really easy for someone, especially someone new, to end up wasting huge amounts of time trying to figure out something that they should either look up or ask someone about. So it's really important to find people who won't let themselves get wrapped around the axle. I'd say it's likely that in your case your interviewer dinged you for getting thrown off the larger view of the problem, rather than because you didn't remember some bit-twiddling tricks.
I've interviewed lots of people using puzzles of this sort, and I find they work really really well for picking out the better programmers. You need to understand how to do it correctly, though. You're not looking for whether they "get the right answer". You're looking to see how they approach the problem and what sorts of solutions they try (even if they end up not working).
Mod parent up.
I work for Google, and interview engineering candidates at Google (which doesn't make me special -- all Google engineers are expected to participate in interviewing), and the above describes what these puzzle questions are really intended to do.
Evaluating candidates is a really, really hard thing to do. Honestly, it's darned near impossible to do accurately unless you can bring someone in for a few weeks, put them to work on real problems and see how they really perform. Even then you're just scratching the surface. Trying to get a realistic read on someone's capabilities in just a single day? Yeah, right. But hiring decisions must be made, and Google gets hundreds of thousands of applicants per year.
So, the question becomes not how to truly, accurately evaluate each candidate, but how to fill the positions and ensure that no egregiously bad hires are made. It's sad to reject someone who is really good... but it causes tremendous grief to hire someone who just can't do the job, because firing people is really painful for everyone involved, and quite expensive to the employer.
With that in mind, here are my perspectives on the article's points, based not only on what Google does, but also on the dozens (hundreds?) of job interviews I did at previous employers.
1. Recognize that tests are artificial scenarios
This is inarguably true. The interview is a completely artificial environment which bears no relationship to the actual job. But there's no way to avoid that, so the question become what is the best way to extract as much useful information about a candidate's abilities and characteristics as possible in the brief time allowed. And the time has to be very brief, because getting any kind of an accurate reading depends on getting multiple points of view, and fitting four or five interviews into a day without killing the candidate means that each interviewer really only has about 45-50 minutes.
The article comments that the problems are hypothetical, without context, etc., but that's because there's no way to present real-world problems in the timeframe given. And, actually, underspecifying problems is deliberate, because it's a good way to see how the candidate reacts to inadequate requirements specifications, which is perhaps the one part of the interview which accurately models the real world at every place I've worked in 20+ years.
So, the goal is to construct an artificial environment which tests the things that can be realistically tested. Google is perhaps a little different than most companies in that Google doesn't really care what the candidate knows. The infrastructure is so different from everywhere else that it's really not important; there will be so much to learn anyway. Well, basic CS knowledge is crucial, but specific tools and techniques? Nah. What really matters is how quickly the candidate can understand problems, how effectively they can reason their way through the solution space, how well they can communicate their solutions -- verbally and in code -- and how well they can analyze their solutions and explore alternatives. It's all about problem solving and the only way to understand someone's problem solving abilities is to watch them solve a problem they haven't seen before.
The "they haven't seen before" is crucial... and it's also pretty easy to verify. Here's a word of advice: If you go into an interview and are presented with a problem you already know the solution to, tell the interviewer up front that you've seen it before. Odds are the interviewer will figure that
Fourth, in the old days, such awkward/geeky people didn't get much chance to reproduce.
I don't think this is true. I think in the old days such people were much more likely to reproduce with a partner who is more "normal", though, because it was harder to find a mate with similar characteristics. Instead, they just found someone who was less desirable in other ways. For example, uglier.
Does this happen on the phone or is it service based like Siri? I know Google has that massive voice recognition trainer they call Google Voice collecting billions of Bayesian decisions every day.
It's service-based. I've tried to use it a few times when I was in the sticks and didn't have reliable data service, and it just errors out every time when trying to translate the voice.
We didn't have them when I was a kid, either, but that is a sad and unfortunate thing.
In decades and centuries past, many disorders were not understood, not diagnosed and just attributed to stupidity, or rebelliousness, or negative character traits. Those people just failed or succeeded as best they could on their own -- mostly they failed. In the case of allergies many of them just died.
These disorders are fundamentally no different from, say, presbyopia. They have a mixture of congenital and environmental causes, and they are debilitating to those who have them. Centuries ago, people who were near-sighted just had to suffer with their "weak eyes". Medical science now has multiple options to correct that defect, via prosthetics or surgical alterations. The same applies to these "newer" disorders, except that we're only beginning to understand them and how to treat them.
I have ADD, as do my three boys (one is also hyperactive; ADHD). Actually, they all have more severe forms of it than I do. I recognize in them the same difficulties I had in school when I was a kid... with the difference that they take medications which reduce the impact of their ADD making it far easier for them to excel in school. Those who think such kids are "drugged dull" don't know anything about it; most ADD medications are stimulants. In fact, I've realized that I self-medicate for my ADD, too, except that I do it with caffeine rather than Concerta.
An even better personal example is my daughter, who suffers from a mental illness that has only been recognized in the last couple of decades (and we now know is very poorly named): Borderline Personality Disorder. In the past, people would just have said she's a bitch (actually, lots of people say that today), but we now understand that it is actually a severe emotional disregulation disorder. On the surface it looks like extreme, random bitchiness, but when you understand the nature of the disorder you begin to see the patterns and to understand the reasons and the triggers -- and to have some compassion for the fact that as much as it sucks to be around her, it really, really sucks to be her. In fact, more than 25% of people diagnosed with BPD do not survive to age 30, mostly because they kill themselves (she's been hospitalized multiple times for attempts).
What makes this even more interesting is that as I look back in my family history it becomes clear that there have been others who suffered from BPD. They all led utterly miserable lives, and about half of them suicided. But no one understood what it was; they just thought it was a character defect.
Today, we are beginning to understand it, and beginning to realize that it's not particularly rare. Many of the extreme assholes you run into really are just sick... and there are some treatments that can help.
From a pure Darwinian perspective, you can argue that all of this medical intervention is a bad thing; that these people should just fail, or die. I disagree. Just as I appreciate the fact that I can wear glasses to address my presbyopia, and use caffeine to help me concentrate, I appreciate that we are learning to remove handicaps from many capable and brilliant people.
An experience that has cemented my perspective on this is getting to know many of the other girls in my daughter's treatment center. The treatment center handles teens with both behavioral health and substance abuse problems -- and actually it turns out that substance abuse is most often an attempt to self-medicate for an underlying mental or emotional health disorder. This was a 24-hour residential treatment facility, so all of the kids there were pretty hard cases; they ended up there after repeated behaviors that were deadly dangerous to themselves and/or others, or after major run-ins with the law or (usually) both. They were also mostly kids with pretty good parents.
What I was surprised to find after getting to know a lot of them was that they were also, almost wi
They will break it, but don't worry they'll convince several other distros to follow their lead, since apparently they own Linux now.
I thought Ubuntu owned Linux now.
The Android (and earlier iPhone) voice 'commands'? Garbage. Siri is fantastic to use. Wanna reply to a text message or email while driving?
I do that with my Nexus S all the time. Texts are read aloud to me, I reply verbally. I've carried on long conversations that way, with near perfect fidelity. I'm going to be very interested to see how Siri can be better.
I've been saying this for a long time; the purpose of patents is to encourage disclosure so that others will be able to find and use your ideas
The US Constitution spells out the purpose of patents: (paraphrasing) To encourage innovation and invention by providing a limited monopoly.
If you're looking for an institution that was specifically designed for disseminating and discussing ideas, then I would suggest you look at the academic community.
The US patent system was not created for the purpose of disclosure. It was created to encourage invention, as mandated by the US Constitution. Disclosure is just a necessary implementation detail, because the public needs to know specifically what they are forbidden to infringe upon.
Nonsense.
The Constitution doesn't define patent law. It just lays out the authority of Congress to grant short-term rights in order to encourage innovation. This is the origin of the authority to create patents and copyrights, but it doesn't define their purpose.
To understand patents, you need to review the various incarnations of the law, the history of the debates and discussions that defined its structure and purpose and -- most importantly -- the relevant jurisprudence, where the courts have clearly laid out the purpose. My characterization was correct.
Even before requiring that the source code be published, it'd be a good first step to require that it be written. Lots of the submarine patents are never even implemented. But, yeah, requiring publication of source would be good.
I would actually like to see publishing the source to be a requirement for obtaining copyright on software as well. The vast majority of commercial software benefits from copyright protection but will never, ever truly be released to the public domain (which is the fundamental purpose of copyright, to increase the flow of creative works into the public domain) because by the time the copyright expires an insanely long time from now the source code will be long lost. Of course, even if it were published, odds are very, very high that by the time it falls into the public domain no one will care any more, but still, the idea of copyright is that copyrighted material is supposed to become public domain eventually.
Oh, never mind. I didn't read to the bottom of the question. Passpack isn't a good solution (or at least not a complete one) because the OP doesn't want his siblings having access to his accounts until he's dead.
With a free account it only allows you to share with one other person, which isn't ideal for your use case -- though I suppose you could always just share the passpack login credentials.
Passpack is very convenient because it's browser-based, but security is supposed to be pretty good because it's all encrypted on the client before being sent to the server, so passpack never has enough information to be able to recover your passwords. I haven't verified the code, but the architecture looks very well thought-out from a security perspective. Sharing is done by first generating public/private keypairs for both participants and then encrypting the shared keys with the recipient's public key (well, that's the gist; the details are more complex). That stuff is all mostly transparent to users, though (mostly because there is some setup that has to be done).
I have been using it to manage all of the keys I use for various web accounts, and for sharing the passwords with my wife. It allows me to use long, complex, unique passwords for all of my web accounts, and to do so fairly conveniently. My wife doesn't like it; she'd rather just have a single password we both know and use on all of the important sites, but she also recognizes why that's a bad idea, so she uses passpack -- and grumbles about it.
Mine grows constantly, due to the continual influx of new photos and video. And whenever I upgrade my cameras the size per image or per minute of video increases.
When I looked at the data that I REALLY needed to keep, I came to "not very much". Nothing that I could not host (encrypted) at my provider. I am talking less then 20MB in data.
Don't have kids?
For those of us that do, we typically end up with a lot of photos and video that we would really, really hate to lose.
My solution for this is high-volume off-site backup using Tahoe LAFS. I have about 200 GB backed up now, and will have 400 GB within a couple of months.
20 disks seems like overkill for your storage needs. Seems like the more disks you use the greater the risk of failure of one or more of them. Also, your electricity bill must be through the roof. I have 4 3TB drives with a 3Ware controller in RAID5 array which gives me the same storage capacity with 1/5th the drives.
You should seriously consider adding another drive and migrating to RAID6, because RAID5 has a fatal flaw that may cost you all of your data (or at least force you to restore from backup, but, seriously, keeping 9 TB backed up isn't easy).
The problem with RAID5 is that if you lose one of your drives it leaves your array in a very risky state. This seems obvious, since it's clear that the failure of any drive at that point will lose all of your data, but it's actually at least an order of magnitude worse than it appears. Why? Because the failure of a second drive at that point is actually quite likely. When you install a replacement drive, the array has to resync to incorporate the new drive and get back to a health state. Do do this, the resync operation has to read every single block of every remaining drive. This means that if there are any other latent failures, unrecoverable blocks that just haven't been noticed yet, the resync will find them and the resulting failure will lose all of your data.
In fact, even a transient failure can lose all of your data. I was actually able to recover mine once, due to the fact that I was using software RAID rather than hardware. Linux mdraid allowed me to "forcibly" restart my degraded array (carefully specifying the order of my disks exactly as they had been; which information I had thanks to the e-mails md had sent me), at which point I ran out and bought enough big disks that I could back the entire set up. The backup succeeded.
After a similar experience which was even more harrowing because the failure wasn't transient, I abandoned RAID5 for data I care about and switched to RAID6.
My current approach is:
In addition, I also run regular surface scans on all of my drives. In theory this should make RAID5 acceptable since it should identify any waiting problems before the array is degraded. In practice, I still don't trust RAID5.
But now it looks like I cannot afford them and will have to look into buying refurbished hdds.
Why ever not. Unless your income has dropped dramatically a 1TB or 2TB disk is no less affordable today than it was a year or two ago.
Unless your storage demands have grown apace of the normal increase in available capacities.
The other problem is that patents really fail at their primary purpose: encouraging disclosure. No one looks for algorithms by doing a patent search.
Mod parent up.
I've been saying this for a long time; the purpose of patents is to encourage disclosure so that others will be able to find and use your ideas (after paying a license fee -- that's the motivation to disclose). So the clearest test of whether or not the system is working is the degree to which working professionals utilize the patent database as a resource for solving their problems, and by that standard it's hard to imagine how the system could be a greater failure. Not only do software developers not mine the patent database for ideas, they are told by their attorneys to avoid looking at patents. Why? Simple: Because everyone recognizes that there is nothing of value to be found, and looking only creates risk because if you find out something you're doing is patented then you have to stop, or risk treble damages for willful infringement.
The bar for patents is so low, and the number of non-obvious patents so few, that there's no value in searching for patents. This makes it abundantly clear that the patent system has become a mechanism for locking up ideas, not for disseminating them, which means it has utterly failed its fundamental goal.
Patent reform is badly, badly needed, because right now the system we have is actually worse than nothing. I think a good patent system would be of value, but what we have now actively discourages innovation and squelches progress, at least in the software realm.
The only thing left to argue about is how much do we contribute... 80%? 50%?
That's not the only thing. Another thing we need to decide is how much it matters.
The planet has been both considerably hotter and considerably cooler than is now, several times each, so it's clear that it's a chaotically stable system. Otherwise it would have run away in one direction or the other. Indeed, some of the thermo-regulation mechanisms are quite obvious, such as increased temperatures causing increased evaporation, leading to more cloud cover, increasing the albedo of the planet and decreasing thermal input from the sun. I think it's very likely that nothing we can do will cause more warming than can be offset by reducing the thermal input by one or two percent, so long-term I don't think we need to worry about the planet becoming unlivably hot. Based on the what we know about the planet's history since life became widespread, severe cold periods are more likely to be inimical to human comfort than the hottest ones.
But, since we don't want to have to spend too much effort moving cities further inland due to rising seas, or otherwise adapting to the climate changes (especially rapid changes), we need to get an understanding of just how hot it's going to get, and just how fast it's going to get there. We should also consider impacts on wildlife, too, since (IMO) healthy nature is of benefit to humans. Understanding what the likely impacts of CC will be will allow us to make rational decisions about how we should respond. That's going to require a lot more climate science, though.
though he does get credit for winding down Iraq
No, he doesn't. It's winding down exactly on the schedule set out by the DoD at the end of Bush's term -- though it wouldn't be ending even that soon except that the Iraqis won't let us stay any longer.
Are you kidding? This is *perfect*. Complain three times in meetings with as many witnesses as possible that "this exposes us to risk of downtime and high support costs", and be sure to end with "...this is your call, but its against my professional advice". Have that minuted.
That's a great approach if you are interested in competing with your boss, and taking his job. But you'd better be sure you can do it before you get that aggressive, because if he's politically savvy -- and it's not likely he got to be CIO if he's not -- he'll recognize that you're setting yourself against him. Depending on his character and his level of confidence, he may do nothing, he may just put a mental black mark against you to be remembered during next year's performance reviews, or he may set out to force you out.
Saying it once in front of witnesses, before he's already made the decision clear, is fine. That's not making a play, that's just doing your job and pointing out options and issues. But three times? In front of lots of people? And especially if you ask to have it written into the minutes... that's going on the offensive and he's very unlikely to miss it, or to take kindly to it.
Am I missing something here that says we have to compare all these people on the merits of their accomplishments?
No, you're not missing it, because it's not there. The summary and article say nothing of the sort.
What they do point out is that if we hadn't been somewhat sensitized to it because of annoyance at the media reaction to Jobs' death, we likely wouldn't have paid nearly as much attention as we have to Ritchie's passing. This isn't a question of comparing Jobs and Ritchie, it's just pointing out that we often don't recognize the accomplishments of the people who really changed the world, but did it quietly.