This does nothing to prove that software patents are good in any way.
Good, since that's not what I was trying to prove.
I never claimed they were good or bad.
My actual claim is that they're neutral and that only uses of them are either good or bad.
A hammer is neutral. If I use it to build a house, it's good; if I used to hit somebody in the head, it's bad. The hammer, however, is not inherently bad.
Only the bad cases ever make the news. There are thousands of software patents owned by hundreds of companies that use them judiciously. A handful of bad examples reported on/. doesn't mean they're all bad.
They're only opening [their software patents] up for open-source projects, meaning IBM projects can use them and open-source projects can use them, but IBM's closed-source competitors can't.
Hopefully, this will finally prove to the "all software patents are evil" crowd that software patents are not inherently evil: it's just how they're sometimes unfortunately used.
The phone syncs with a computer and the iTunes Music Store like an iPod does...
An iPod does not sync with the iTunes Music Store. It syncs with the iTunes music player.
The significance is that the iPod (and presumeably the new phone) can play any MP3 file regardless of how you obtained it and not just music purchased from the iTunes Music Store.
I haven't heard any stories as to how he is as a manager after returning to Apple, but before he was kicked out, he was a horrible manager who belittled and intimidated employees. Read any number of books on Apple's or Jobs' history for details.
So it's rock solid for somewhere between 24/7/121 and 24/7/182 then?
I don't know whether it's the service that hiccups or the modem. If I assume the latter, then the service itself is rock solid 24/7/365 and it's the modem that's flaky.
If you pay a little more, you can get a static-IP package. I've had it for years and it's rock solid 24/7/365. (About once every 4-6 months, I have to reboot the DSL modem, however.)
Re:Discarding too many people
on
Defining Google
·
· Score: 1
No, I really meant "how well it works." (If I didn't mean that, I wouldn't have written it.) For example, you have no way of knowing if and how often software on Google's server farms crash requiring a reboot because of their extreme redundancy.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
It'd still get rid of people who might be technical, quick thinking, but not good conversationalists.
It has nothing to do with good conversation. It has to do with a bright candidate who wants to jump in and point out there's a better way to do it or desribe how s/he had solved a similar problem in the past. Engineers love to show off.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
Your technique may be great for marketing type of folks, but not necessarily for IT.
As I pointed out more than once, this technique was used by Bell Labs. If they aren't high-tech, I don't know who is.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
I'm sorry that your job, livelihood, and future hang in the balance on one interview.
I never said it did.
Maybe you should just stick with your original plan to become a farmer.
Maybe you should learn how to read and attribute quotes correctly: I never said I had such a plan.
I don't understand what it is about that format that draws additional users, but it drives me fsckin nuts.
The advantages of XML are that (1) it's plain text and therefore easy to read, and (2) it's easy to parse because all XML is the same, hence you need only one parser. Even if you don't have a schema, you can simply look at the data and pretty much figure it out. Try that with some weird binary format.
But I do agree that there's too much hype around XML.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
... that assumes the interviewer is competent in both technical and conversational aspects. Too often it seems to be one or the other. A good conversationalist might invite many chances for questions that can't be answered properly or might confuse the interviewee with misleading details.
Clearly if you're a top research-type company that hires smart people, you'll also be smart enough to carefully choose who you have do interviews.
It's a tad too multifaceted for me to believe it always works though.
I never claimed it always works. My claim is that it probably discards far fewer qualified people. Having the technique used by Bell Labs is a pretty good endorsement that it's effective. In its heyday, the brain-power of Bell Labs could have dwarfed Google.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
What's high pressure about an interview?
(I can't believe you're actually asking that question.) Answer: having your job, livelihood, and future ride on the outcome is pretty high-pressure for most people.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
... I've been taught it's polite not to interrupt.
(It seems I need to spell out the details of the technique in exhaustive detail.) Clearly, if you're the interviewer, you intentionally have pauses as if you're trying to think also. This allows gaps where the candidate can interject.
So with the programmer's case here, using real-time problem solving as a way to find better programmers should work, I think.
Except that a programmer's daily job is not to solve a series of small, interview-type questions in real-time. Programmers usually work on week- or month-long projects. Additionally, they're not faced with the added pressure of having their job ride on what they say in the next 3 minutes.
Aside from that though, from a practical point of view, what other choice is there? If the interviewers do not make the interviewee solve problems for them right then and there, they have no way of knowing what the programmer's potential really is.
There are several ways. Just because you can't think of one in real-time doesn't mean they don't exist.
When you have to screen so many applicants, why wouldn't you use real-time tests as a way to do so?
Because you're quite possibly discarding the person who will think up the Next Big Thing that will make you millions. Google's workforce is homogeneous: everybody has the same abilities and thinks the same way. To cover the broad spectrum of good ideas requires a diversity of people who think in different ways.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
That's all well and good, but I'm guessing Google has no use for an employee who gets his insight during idle moments.
Companies couldn't care less where, when, or how you get good ideas if it makes them money. Some of the best ideas in history were invented this way.
If a person's brain freezes during an interview, how exactly can this person be relied upon?
I don't see the relationship between freezing up during a high-pressure interview and reliability. Nonsequitur.
To put it another way, how do you propose Google determine your expertise?
There are plenty of ways to guage a person's abilities. (I already posted one such way in another follow-up.) Just because you can't think of one doesn't mean they don't exist.
(I suppose if I were interviewing you, you wouldn't be getting the job since you can't seem to think of any other ways.)
Re:Discarding too many people
on
Defining Google
·
· Score: 5, Interesting
I do a lot of interviews where I work and many times I may ask a difficult problem that I want to see solved in real-time, but I don't expect them to actually solve it.
And this can leave a candidate frazzled for the remainder of the interview. A techinique that works better, IMHO, is that used by Bell Labs (at least at the time I was there). The technique is that you talk about a current or recent problem and walk through the solution trying to engage the candidate. You observe the candidate. If s/he just sits there and listens: rejection. If s/he asks interesting questions and offers up solutions before you do, you're got yourself a winner.
By interviewing this way, you're not directly asking the candidate to solve a hard problem on the spot and, consequently, you're not making the candidate into a frazzled, nervous wreck.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
In fact, just because you -think- you would have been happy there as a fulltime employee doesn't mean you can prove you would have been, therefore, your example doesn't really disprove anything.
I worked there for 18 months full-time. My office was there and everything. The only difference was that my salary was being paid from my "home" department's budget. So, yes, I did de-facto work there.
Re:Discarding too many people
on
Defining Google
·
· Score: 1
... there is also little correlation between being a good programmer and being a talented and useful employee of a large innovative company.
If you're a good programmer, then you must be talented in programming by definition. A company whose business relies on software requires good programmers (or at least those who are "good enough"). So it's not clear how you come to your conclusion.
Being a good programmer also doesn't correlate with being able to work well in a team, being able to speak English well (i.e., native language), being able to manage money, being able to decorate, or being able to do an infinite number of other things. Pointing out what being a good programmer doesn't correlate with (a) isn't very useful and (b) does nothing to refute my point.
Incidentally, the ability to solve puzzles in real-time during an interview also doesn't correlate with being a useful employee of a large, innovative company.
Slashdot Mirror
Oh, wait...
Only the bad cases ever make the news. There are thousands of software patents owned by hundreds of companies that use them judiciously. A handful of bad examples reported on /. doesn't mean they're all bad.
Yes, I'm fully aware that some cameras and digital phones have OLED displays. I clearly said, "... use OLED displays in their laptops."
*drool*
I haven't heard any stories as to how he is as a manager after returning to Apple, but before he was kicked out, he was a horrible manager who belittled and intimidated employees. Read any number of books on Apple's or Jobs' history for details.
No, I really meant "how well it works." (If I didn't mean that, I wouldn't have written it.) For example, you have no way of knowing if and how often software on Google's server farms crash requiring a reboot because of their extreme redundancy.
But I do agree that there's too much hype around XML.
(I suppose if I were interviewing you, you wouldn't be getting the job since you can't seem to think of any other ways.)
By interviewing this way, you're not directly asking the candidate to solve a hard problem on the spot and, consequently, you're not making the candidate into a frazzled, nervous wreck.
Being a good programmer also doesn't correlate with being able to work well in a team, being able to speak English well (i.e., native language), being able to manage money, being able to decorate, or being able to do an infinite number of other things. Pointing out what being a good programmer doesn't correlate with (a) isn't very useful and (b) does nothing to refute my point.
Incidentally, the ability to solve puzzles in real-time during an interview also doesn't correlate with being a useful employee of a large, innovative company.