Move to your new university and use the summer to do (at least one) research rotation.
Here's why: you said "for the next 5 years." I'm not sure where you got that time period from, but if you're doing your PhD in the US, you're going to find that it's a completely open ended process. This is *really* important to internalize, because every other form of education that you've had experience with has a fixed term: you do what they tell you to for the prescribed time period and at the end they hand you the diploma. You can't run down the clock on a PhD. You don't graduate until you can convince your advisor that you've done enough to merit the degree. And it's generally against your advisor's personal interests to let you graduate.
So, if you want to complete your degree in a reasonable period of time (e.g. 5 years), you have two tasks: 1) Find a lab with a research advisor who you like and trust, because you're putting your life in his or her hands. If you wouldn't give him/her copies of your keys and your ATM PIN, you shouldn't be in that lab. 2) Get established in that lab so you can start organizing and taking charge of your own project and working toward first-author publications.
The first step towards this is doing lab rotations. Summer is often a good time to do these, because your first year is likely to be filled up with classes which will make it difficult to spend enough time in a lab to really get a feel for it. Just make sure that the PI in whichever lab you're rotating in is going to be around (sometimes they are gone for months at a time in the summer) because the most important thing you need to get out of the rotation is deciding whether you trust the PI.
I suspect there will be several threads of people recommending various voyages of self-discovery or self-education. If you had something that you really *wanted* to do, I wouldn't try to talk you out of it, but from the way you've phrased your question it doesn't really sound like there is, and there's no point finding a new hobby this summer that you won't have time to continue once you start your program.
As a current resident, I feel obligated to point out that there have actually been some real improvements in the past 10 years on resident work hours. The most important ones being: * No more than 80 hours worked in a week (Many surgery residencies previously averaged up to 100.) * No more than 30 hours in a row (Previously 36 was the standard; 48 was not unheard of.) * 4 days completely off out of every 4 weeks. There are some loopholes (e.g. you can stretch the 80 hours to 88 if the time is categorized creatively) and abuses (some programs encourage their residents to under-report time), but I think it's generally a big step in the right direction for patient safety and resident quality of life. Something to think about: These rules only apply to residents, who are always supervised to at least some extent. They don't apply to attendings (fully boarded doctors). So you won't be treated by a resident who hasn't slept in 72 hours, but if you're in a non-teaching hospital it's still possible that the non-resident doctor treating you there hasn't slept in 72 hours.
Leon, a family friend, died on December 8th and his funeral is being held today. He loved lengthy discussion and bullshit sessions revolving around science and technology and I'm sure is loving it that slashdot is part of his send-off.
I have (as far as I know) never been maliciously plagiarized, but I have been surprised at how many times I've been plagiarized by papers that cite my own. Clearly, they're not trying to hide anything, or they wouldn't have bothered to cite the paper that they're copying from, but there seem to be many authors who don't see anything wrong with lifting a paragraph and just changing a couple words. Certainly the few I've contacted about doing this have seemed very surprised that I should think there's anything wrong with it. Obviously this kind of thing isn't as serious as what's being alleged in TFA, since none of them were claiming credit for my ideas or work, but I think it is a point along the continuum of laziness and dishonesty of grabbing something that's someone else's rather than doing it yourself.
I had a similar problem in college, when as a freshman I felt very lucky to get john@[mycollege].edu as my address. Apparently lots of people think they have "John" as an alias in their address book that will get automatically expanded, and many of them are incorrect in this assumption. A few thousand misaddressed emails later, I didn't feel quite so lucky.
The worst of it was a mailing list that randomly chose my address as the example address for their explanation of how to compose a subscribe message, just as the Net was being flooded with AOLers. You can imagine how many times (per day!) I was subscribed to the list.
The smartest thing we can hope to do probably is map out the DNA for every endangered species, in the hope that one day we will be advanced enough to synthesize this DNA again "de novo" in a lab and bring the species "back" if we ever need it.
This probably wouldn't be enough. Although in a sense an organism's DNA has all the information needed to construct the organism, the DNA sequence is just a string of data. Construction of the organism requires (very, very complex) interaction between this data string and a "reader" (the cell). While the fundamental code of the DNA (translation to proteins) is fairly consistent across most organisms, the regulatory mechanisms (among other things) which are essential for life vary pretty widely. If you had cells from a closely related organism, you might be able to make it work, but then if you had a closely related organism, it probably wouldn't be so important in the first place.
An (admittedly poor) analogy: If you had a single jpeg file and no knowledge of the jpeg format, how easy would it be to recreate the original image?
Anyway, my point is that it's important to keep in mind that there may be as much information content in the "reader" as in the the "data", even when the data has enough information for the "reader" to construct duplicate "readers".
Ignorance of the law is no excuse. But ignorance of information about another party in a civil matter is a (partial) excuse.
And the situation that we have with software now is that there are so many patents out there that it essentially impossible to write any meaningful program without potentially infringing on at least a few of them.
So you either decide to play it safe, avoid any possible infrigement and never write any code, or you accept that you're probably going to infringe on something and you avoid exposing yourself to three times the liability (not to mention the hassle and expense of reading patents) by remaining ignorant of what has been patented.
Patent enforcement is the job of the patent holder. You do not need to do "due diligence" unless you are basing your design on someone else's patented product. Or you are attempting to publish your own patent.
That makes sense, doesn't it? Looking up and citing other work in the field is certainly the way that academic publishing works. Unfortunately the unintended consequences of patent law make it such that it doesn't work out that way.
When I was (forced by my boss to be) applying for a software patent, my boss told me to look around for other things that might be similar to what we'd done. And as soon as the patent lawyers heard that he told me that, they went through the roof, and immediately told me to stop. Here's why:
Patent law says that you're legally required to reference any potentially overlapping work that you know about in your application. If someone can show that there was something that you knew about and didn't cite in your application, it's grounds for revoking the patent. It's very hard to write laws that talk about what someone ought to know or be aware of, though, so you only have to include things that you are actually aware of. But the more citations you include in your application, the greater the chance that the examiner will reject the application because of one of those related patents you cited. (You can see where this is going...) So, from a legal standpoint, the best situation is one where you honestly have no knowledge of any other work in the field, so you can submit an application with no citations. So you never do any kind of "due diligence" searching when you submit a patent, because all it can do is decrease the chances that it will get granted.
So you really probably shouldn't ever read patents (see my other post in this article about why it's a bad idea for programmers to look for infringing patents). Which is kind of strange and sad considering that one of the main points of the patent office was supposed to be to provide a legally protected way to publicize information about technology to encourage further growth and development.
IANAL, either. Just a disappointed observer, discouraged at how terribly out of control our patent office and patent law has become.
Some IANAL-ing, but from apparently reputable sources:
Looking through patents to see if you might be infringing is generally a really, really bad idea. If you infringe a patent you may be liable for damages, but if the patent holder can show that you knowingly infringed the patent, you're on the hook for treble (lawyer speak for triple) damages. A friend of mine who's a developer at a big software company got in trouble for looking up a patent for just this reason.
Maybe if there were a reasonably small number of patents of limited scope it would make sense to look through them and try to steer clear of infringment, but given the number and scope of patents that have been granted, it's almost impossible to avoid infringing on something. Therefore, the accepted strategy (even for big companies that could afford to have a team looking at patents) seems to be to avoid looking at patents so as to avoid taking on further liability.
If it's any consolation, a lone developer's pockets are shallow enough that it's probably pretty unlikely that anyone's going to bother with a patent lawsuit. Probably a good idea to incorporate, though, so in the rare event of a lawsuit the worst that happens is the company goes bankrupt; otherwise your personal assets are at risk.
I saw a demo of a molecular visualization program running on one of these at the American Chemical Society convention a couple months ago.
In general, I'd say the quality is quite good. The image I saw had about 6 or 8 inches of apparent "depth" between what appeared to be closest to me and what was furthest away. It was reasonably clear, although not quite as clear as the flat image. You seem to lose some resolution (horizontal resolution, at least) when it goes into 3D mode.
Of course, one of the big deals about it is that it doesn't require glasses, so nothing to lose, no flickering, etc. This does mean that there is a fairly small "sweet spot" that your head has to be in in order to see the 3D display. If you're positioned outside of this the display looks like a mess. I don't think more than one person can really see the image at a time when it's in 3D mode (there's a big button above the keyboard for switching between 2D/3D).
I'm not sure what the API is like for getting a program working with the 3D functions. It was being demoed by a software company, and the guy there gave me the impression that some amount of modification to their app had been necessary (ie that most 3D apps wouldn't work correctly without being adapted) but that it hadn't been too difficult. 'Course you've generally got to take tech info from salesfolk with a grain of salt.
I think her hashing scheme needs a little work. Looking through the comments, lots of people identify blots as [noun] [present participle] (e.g. "batman flying"). All present participles end in -ing, so I think you would find a high incidence of 'g' in even positions of passwords generated with this scheme.
I have some friends that work on creating large (long) carbon nanotubes. As of about 2 years ago, they were unable to make tubes longer than about 1 cm. Things may have improved somewhat in the last couple years, but basically we're about 8 orders of magnitude short of the length needed for a space elevator.
Yeah, you're right, you were supposed to glue the nose cone of the Mosquito on. No hole in the tube, though, and no special motor: the ejection charge was supposed to blast the remains of the motor out of the rocket so the rocket would tumble down (the real trick was finding the damn thing).
Motors without ejection charges are mostly meant for use as the non-final stages of multi-stage rockets, IIRC.
Presumably one of the reasons you'd be building this library and gaining this knowledge is to get a job. One book that I think is especially helpful for that is
Programming Interviews Exposed. Most of the book is made up of step by step examples of how to solve the kinds of problems that are presented in interviews. This is something you might not get from the other books that have been mentioned, because interview problems tend to be significantly different from those that you would encounter in classes or real programming.
Of course, I may be a little biased, since I'm one of the authors, but some other
people seem to have found it pretty useful, too, so hopefully you'll consider it worth a look.
Wait, we've got a transit/rail company that intentionally naming something Octopus? That would never fly in California.
(For those who never had the pleasure of taking California state history, there was a period in the late 19th century when the railroad monopoly controlled much of the state. Frank Norris wrote a scathing
novel about the railroads' misdeeds titled... The Octopus.)
Despite the comic possibilities of the bathrobe with giant felt hands, my favorite episode has gotta be "Warrior of the Lost Worlds"
Lotsa good stuff, including an annoying talking motorcycle that repeats everything twice (think robotic, repetitive Jar Jar) with a video display screen that serves to display the MS Windows Starfield screen saver for the entire duration of the movie, and one of the best "bad guys" of all time: MegaWeapon. MegaWeapon is a black dumptruck covered in cardboard cones like so much spiky acne.
I'm probably going to get an offtopic for this, but...
Is it just CS and programming that you're finding yourself disillusioned with, or is it kind of everything in life right now? I ask this because it sounds to me like you may be depressed, and attributing the symptoms of that depression to loss of interest in what is currently one of the biggest parts of your life (getting through your CS degree).
If you feel like everything else in your life is just great, then feel free to ignore this post.
On the other hand, if you've been feeling a general sense of purposelessness, lack of motivation about other areas of life, experiencing sleep disturbance (either trouble sleeping or sleeping all the time), or been down about life in general, you might want to consider getting some professional counseling. If you are depressed, it's likely that when you get some help for the depression, you will rediscover your passion for technology.
BTW, IANAP (I am not a Psychiatrist/Psychologist) so standard disclaimers apply.
One argument is that it can help people to test their systems for vulnerabilities, bit I think that exploit code is not strictly necessary for this. People who really need it to test systems are in a position where they should have the capability or the resources to generate a "test script" for themselves, once given an accurate description of the vulnerability.
It's been demonstrated by NIMDA, Code Red, etc. that many sysadmins lack the time/ability/inclination to even patch their systems; now you're expecting them to not only patch them but implement exploit scripts to test the patches? Unlikely..
So perhaps the argument is that most people don't actually need to test the exploit; they can just deploy the patches and move on. That hasn't been my experience. I saw at least one report on Slashdot of a website taken down by NIMDA because patches had been applied, but in the wrong order.
On a more personal note, the IE *.eml vulnerability patch (also exploited by NIMDA) didn't take on my Win98 laptop, despite repeated installation attempts. There were no error messages in applying the patch, it just didn't close the vulnerability. There's no way I would have known this without having a test script that demonstrated the hole. And while I probably have the capability to implement a test script given a complete description, I certainly don't have the time (med school. it's a good way to soak up time.)
As one of the authors of Programming Interviews Exposed, there are a few things I thought I might respond to in the review and some of the early posts.
Dissection of point 1
I agree with Gavin's assessment of what knowledge is important. What we really meant is you need to know every quirky feature (even obscure ones) of the core language. For instance, you should be familiar with bitwise operators, even if you rarely use them in your programs. If you say you know C, you should know what a union is. It's certainly not necessary to be familiar with every library and technology that's ever been tacked onto the language.
Weaknesses
Component programming and I18N are both important topics. I do feel that in most cases, they fall into the "they won't ask you unless it's on your resume" category, but perhaps we'll be able to include some material on them in the next edition;-)
Posts expressing discontent with the whole idea of being quizzed
I have to admit, I was more than a little put off the first time I was quizzed in an interview. However, I've come to understand that some amount of this is a necessary evil. Unfortunately, there are a large number of applicants who claim they can program, but, to be blunt, can't. I'm talking about people who claim to be "Senior Java Developers" and don't know how to declare a variable. Some of these folks can actually talk a reasonably good game, so it's very hard to screen them out without asking applicants some sort of programming questions.
A couple of people have mentioned that factual recall Trivial Pursuits-type questions doesn't really prove anything. I definitely agree with this, and I think most companies do, too: most of the questions I've faced have required intelligent application of a little knowledge everyone should have, rather than encyclopedic recall. I wouldn't want to work for a company that emphasized the latter kind of question.
All that said, I do think that there is too much emphasis on time-pressured puzzle-solving in most interviews. As I mentioned, some of this is useful to screen out fakers, but the real measure of a programmer is what he/she can do in a few weeks or months, not in 25 minutes. I think interviewers ought to spend more time asking about the applicant's experience and past projects. Nevertheless, right now most interviewers do focus on puzzle questions; we thought it would be most helpful to write a book to prepare people for interviews as they are rather than interviews as we wish they were.
Finally, a big thanks to Gavin Bong for taking the time to read and review our book.
Slashdot Mirror
Move to your new university and use the summer to do (at least one) research rotation.
Here's why: you said "for the next 5 years." I'm not sure where you got that time period from, but if you're doing your PhD in the US, you're going to find that it's a completely open ended process. This is *really* important to internalize, because every other form of education that you've had experience with has a fixed term: you do what they tell you to for the prescribed time period and at the end they hand you the diploma. You can't run down the clock on a PhD. You don't graduate until you can convince your advisor that you've done enough to merit the degree. And it's generally against your advisor's personal interests to let you graduate.
So, if you want to complete your degree in a reasonable period of time (e.g. 5 years), you have two tasks: 1) Find a lab with a research advisor who you like and trust, because you're putting your life in his or her hands. If you wouldn't give him/her copies of your keys and your ATM PIN, you shouldn't be in that lab. 2) Get established in that lab so you can start organizing and taking charge of your own project and working toward first-author publications.
The first step towards this is doing lab rotations. Summer is often a good time to do these, because your first year is likely to be filled up with classes which will make it difficult to spend enough time in a lab to really get a feel for it. Just make sure that the PI in whichever lab you're rotating in is going to be around (sometimes they are gone for months at a time in the summer) because the most important thing you need to get out of the rotation is deciding whether you trust the PI.
I suspect there will be several threads of people recommending various voyages of self-discovery or self-education. If you had something that you really *wanted* to do, I wouldn't try to talk you out of it, but from the way you've phrased your question it doesn't really sound like there is, and there's no point finding a new hobby this summer that you won't have time to continue once you start your program.
Best of luck with your program.
...next album: Throwing Fiber?
As a current resident, I feel obligated to point out that there have actually been some real improvements in the past 10 years on resident work hours. The most important ones being:
* No more than 80 hours worked in a week (Many surgery residencies previously averaged up to 100.)
* No more than 30 hours in a row (Previously 36 was the standard; 48 was not unheard of.)
* 4 days completely off out of every 4 weeks.
There are some loopholes (e.g. you can stretch the 80 hours to 88 if the time is categorized creatively) and abuses (some programs encourage their residents to under-report time), but I think it's generally a big step in the right direction for patient safety and resident quality of life.
Something to think about: These rules only apply to residents, who are always supervised to at least some extent. They don't apply to attendings (fully boarded doctors). So you won't be treated by a resident who hasn't slept in 72 hours, but if you're in a non-teaching hospital it's still possible that the non-resident doctor treating you there hasn't slept in 72 hours.
Leon, a family friend, died on December 8th and his funeral is being held today. He loved lengthy discussion and bullshit sessions revolving around science and technology and I'm sure is loving it that slashdot is part of his send-off.
I have (as far as I know) never been maliciously plagiarized, but I have been surprised at how many times I've been plagiarized by papers that cite my own. Clearly, they're not trying to hide anything, or they wouldn't have bothered to cite the paper that they're copying from, but there seem to be many authors who don't see anything wrong with lifting a paragraph and just changing a couple words. Certainly the few I've contacted about doing this have seemed very surprised that I should think there's anything wrong with it. Obviously this kind of thing isn't as serious as what's being alleged in TFA, since none of them were claiming credit for my ideas or work, but I think it is a point along the continuum of laziness and dishonesty of grabbing something that's someone else's rather than doing it yourself.
I had a similar problem in college, when as a freshman I felt very lucky to get john@[mycollege].edu as my address. Apparently lots of people think they have "John" as an alias in their address book that will get automatically expanded, and many of them are incorrect in this assumption. A few thousand misaddressed emails later, I didn't feel quite so lucky.
The worst of it was a mailing list that randomly chose my address as the example address for their explanation of how to compose a subscribe message, just as the Net was being flooded with AOLers. You can imagine how many times (per day!) I was subscribed to the list.
The smartest thing we can hope to do probably is map out the DNA for every endangered species, in the hope that one day we will be advanced enough to synthesize this DNA again "de novo" in a lab and bring the species "back" if we ever need it.
This probably wouldn't be enough. Although in a sense an organism's DNA has all the information needed to construct the organism, the DNA sequence is just a string of data. Construction of the organism requires (very, very complex) interaction between this data string and a "reader" (the cell). While the fundamental code of the DNA (translation to proteins) is fairly consistent across most organisms, the regulatory mechanisms (among other things) which are essential for life vary pretty widely. If you had cells from a closely related organism, you might be able to make it work, but then if you had a closely related organism, it probably wouldn't be so important in the first place.
An (admittedly poor) analogy: If you had a single jpeg file and no knowledge of the jpeg format, how easy would it be to recreate the original image?
Anyway, my point is that it's important to keep in mind that there may be as much information content in the "reader" as in the the "data", even when the data has enough information for the "reader" to construct duplicate "readers".
Or the sig of a CS prof at my undergrad school:
Today is the car of the cdr of your life.
Ignorance of the law is no excuse. But ignorance of information about another party in a civil matter is a (partial) excuse.
And the situation that we have with software now is that there are so many patents out there that it essentially impossible to write any meaningful program without potentially infringing on at least a few of them.
So you either decide to play it safe, avoid any possible infrigement and never write any code, or you accept that you're probably going to infringe on something and you avoid exposing yourself to three times the liability (not to mention the hassle and expense of reading patents) by remaining ignorant of what has been patented.
Patent enforcement is the job of the patent holder. You do not need to do "due diligence" unless you are basing your design on someone else's patented product. Or you are attempting to publish your own patent.
That makes sense, doesn't it? Looking up and citing other work in the field is certainly the way that academic publishing works. Unfortunately the unintended consequences of patent law make it such that it doesn't work out that way.
When I was (forced by my boss to be) applying for a software patent, my boss told me to look around for other things that might be similar to what we'd done. And as soon as the patent lawyers heard that he told me that, they went through the roof, and immediately told me to stop. Here's why:
Patent law says that you're legally required to reference any potentially overlapping work that you know about in your application. If someone can show that there was something that you knew about and didn't cite in your application, it's grounds for revoking the patent. It's very hard to write laws that talk about what someone ought to know or be aware of, though, so you only have to include things that you are actually aware of. But the more citations you include in your application, the greater the chance that the examiner will reject the application because of one of those related patents you cited. (You can see where this is going...) So, from a legal standpoint, the best situation is one where you honestly have no knowledge of any other work in the field, so you can submit an application with no citations. So you never do any kind of "due diligence" searching when you submit a patent, because all it can do is decrease the chances that it will get granted.
So you really probably shouldn't ever read patents (see my other post in this article about why it's a bad idea for programmers to look for infringing patents). Which is kind of strange and sad considering that one of the main points of the patent office was supposed to be to provide a legally protected way to publicize information about technology to encourage further growth and development.
IANAL, either. Just a disappointed observer, discouraged at how terribly out of control our patent office and patent law has become.
Some IANAL-ing, but from apparently reputable sources:
Looking through patents to see if you might be infringing is generally a really, really bad idea. If you infringe a patent you may be liable for damages, but if the patent holder can show that you knowingly infringed the patent, you're on the hook for treble (lawyer speak for triple) damages. A friend of mine who's a developer at a big software company got in trouble for looking up a patent for just this reason.
Maybe if there were a reasonably small number of patents of limited scope it would make sense to look through them and try to steer clear of infringment, but given the number and scope of patents that have been granted, it's almost impossible to avoid infringing on something. Therefore, the accepted strategy (even for big companies that could afford to have a team looking at patents) seems to be to avoid looking at patents so as to avoid taking on further liability.
If it's any consolation, a lone developer's pockets are shallow enough that it's probably pretty unlikely that anyone's going to bother with a patent lawsuit. Probably a good idea to incorporate, though, so in the rare event of a lawsuit the worst that happens is the company goes bankrupt; otherwise your personal assets are at risk.
I saw a demo of a molecular visualization program running on one of these at the American Chemical Society convention a couple months ago.
In general, I'd say the quality is quite good. The image I saw had about 6 or 8 inches of apparent "depth" between what appeared to be closest to me and what was furthest away. It was reasonably clear, although not quite as clear as the flat image. You seem to lose some resolution (horizontal resolution, at least) when it goes into 3D mode.
Of course, one of the big deals about it is that it doesn't require glasses, so nothing to lose, no flickering, etc. This does mean that there is a fairly small "sweet spot" that your head has to be in in order to see the 3D display. If you're positioned outside of this the display looks like a mess. I don't think more than one person can really see the image at a time when it's in 3D mode (there's a big button above the keyboard for switching between 2D/3D).
I'm not sure what the API is like for getting a program working with the 3D functions. It was being demoed by a software company, and the guy there gave me the impression that some amount of modification to their app had been necessary (ie that most 3D apps wouldn't work correctly without being adapted) but that it hadn't been too difficult. 'Course you've generally got to take tech info from salesfolk with a grain of salt.
I think her hashing scheme needs a little work. Looking through the comments, lots of people identify blots as [noun] [present participle] (e.g. "batman flying"). All present participles end in -ing, so I think you would find a high incidence of 'g' in even positions of passwords generated with this scheme.
I have some friends that work on creating large (long) carbon nanotubes. As of about 2 years ago, they were unable to make tubes longer than about 1 cm. Things may have improved somewhat in the last couple years, but basically we're about 8 orders of magnitude short of the length needed for a space elevator.
Yeah, you're right, you were supposed to glue the nose cone of the Mosquito on. No hole in the tube, though, and no special motor: the ejection charge was supposed to blast the remains of the motor out of the rocket so the rocket would tumble down (the real trick was finding the damn thing).
Motors without ejection charges are mostly meant for use as the non-final stages of multi-stage rockets, IIRC.
Presumably one of the reasons you'd be building this library and gaining this knowledge is to get a job. One book that I think is especially helpful for that is Programming Interviews Exposed . Most of the book is made up of step by step examples of how to solve the kinds of problems that are presented in interviews. This is something you might not get from the other books that have been mentioned, because interview problems tend to be significantly different from those that you would encounter in classes or real programming.
Of course, I may be a little biased, since I'm one of the authors, but some other people seem to have found it pretty useful, too, so hopefully you'll consider it worth a look.
---
Can you get modded down "Self Promotion"?
Wait, we've got a transit/rail company that intentionally naming something Octopus? That would never fly in California.
(For those who never had the pleasure of taking California state history, there was a period in the late 19th century when the railroad monopoly controlled much of the state. Frank Norris wrote a scathing novel about the railroads' misdeeds titled... The Octopus.)
So who wants to be the first to submit this one to engrish.com?
Despite the comic possibilities of the bathrobe with giant felt hands, my favorite episode has gotta be "Warrior of the Lost Worlds"
Lotsa good stuff, including an annoying talking motorcycle that repeats everything twice (think robotic, repetitive Jar Jar) with a video display screen that serves to display the MS Windows Starfield screen saver for the entire duration of the movie, and one of the best "bad guys" of all time: MegaWeapon. MegaWeapon is a black dumptruck covered in cardboard cones like so much spiky acne.
The only thing missing was the sampo..
I'm probably going to get an offtopic for this, but...
Is it just CS and programming that you're finding yourself disillusioned with, or is it kind of everything in life right now? I ask this because it sounds to me like you may be depressed, and attributing the symptoms of that depression to loss of interest in what is currently one of the biggest parts of your life (getting through your CS degree).
If you feel like everything else in your life is just great, then feel free to ignore this post.
On the other hand, if you've been feeling a general sense of purposelessness, lack of motivation about other areas of life, experiencing sleep disturbance (either trouble sleeping or sleeping all the time), or been down about life in general, you might want to consider getting some professional counseling. If you are depressed, it's likely that when you get some help for the depression, you will rediscover your passion for technology.
BTW, IANAP (I am not a Psychiatrist/Psychologist) so standard disclaimers apply.
One argument is that it can help people to test their systems for vulnerabilities, bit I think that exploit code is not strictly necessary for this. People who really need it to test systems are in a position where they should have the capability or the resources to generate a "test script" for themselves, once given an accurate description of the vulnerability.
It's been demonstrated by NIMDA, Code Red, etc. that many sysadmins lack the time/ability/inclination to even patch their systems; now you're expecting them to not only patch them but implement exploit scripts to test the patches? Unlikely..
So perhaps the argument is that most people don't actually need to test the exploit; they can just deploy the patches and move on. That hasn't been my experience. I saw at least one report on Slashdot of a website taken down by NIMDA because patches had been applied, but in the wrong order.
On a more personal note, the IE *.eml vulnerability patch (also exploited by NIMDA) didn't take on my Win98 laptop, despite repeated installation attempts. There were no error messages in applying the patch, it just didn't close the vulnerability. There's no way I would have known this without having a test script that demonstrated the hole. And while I probably have the capability to implement a test script given a complete description, I certainly don't have the time (med school. it's a good way to soak up time.)
As one of the authors of Programming Interviews Exposed, there are a few things I thought I might respond to in the review and some of the early posts.
Dissection of point 1
I agree with Gavin's assessment of what knowledge is important. What we really meant is you need to know every quirky feature (even obscure ones) of the core language. For instance, you should be familiar with bitwise operators, even if you rarely use them in your programs. If you say you know C, you should know what a union is. It's certainly not necessary to be familiar with every library and technology that's ever been tacked onto the language.
Weaknesses
Component programming and I18N are both important topics. I do feel that in most cases, they fall into the "they won't ask you unless it's on your resume" category, but perhaps we'll be able to include some material on them in the next edition ;-)
Posts expressing discontent with the whole idea of being quizzed
I have to admit, I was more than a little put off the first time I was quizzed in an interview. However, I've come to understand that some amount of this is a necessary evil. Unfortunately, there are a large number of applicants who claim they can program, but, to be blunt, can't. I'm talking about people who claim to be "Senior Java Developers" and don't know how to declare a variable. Some of these folks can actually talk a reasonably good game, so it's very hard to screen them out without asking applicants some sort of programming questions.
A couple of people have mentioned that factual recall Trivial Pursuits-type questions doesn't really prove anything. I definitely agree with this, and I think most companies do, too: most of the questions I've faced have required intelligent application of a little knowledge everyone should have, rather than encyclopedic recall. I wouldn't want to work for a company that emphasized the latter kind of question.
All that said, I do think that there is too much emphasis on time-pressured puzzle-solving in most interviews. As I mentioned, some of this is useful to screen out fakers, but the real measure of a programmer is what he/she can do in a few weeks or months, not in 25 minutes. I think interviewers ought to spend more time asking about the applicant's experience and past projects. Nevertheless, right now most interviewers do focus on puzzle questions; we thought it would be most helpful to write a book to prepare people for interviews as they are rather than interviews as we wish they were.
Finally, a big thanks to Gavin Bong for taking the time to read and review our book.
John Mongan