Re:Most Resume Advice is Totally Subjective?
on
Resume Tips For Jobs
·
· Score: 1
You have a BS degree. That ought to be in the first third of your resume. As somebody who has to sift through resumes from time to time, I can tell you that my immediate feeling was that you were covering up not having a degree by listing all sorts of stuff, and I almost didn't read all the way down. I also would be highly skeptical of anybody who claimed as many programming/apps skills as you do -- unless you are totally hardcore, you are not current in more than a few of these skills, and maybe never were expert in most of them. Not picking on you especially, but in my experience I find that people who list tons of app and programming languages have either taken a college taster course in them (useless to me) or have had so many jobs each of which was different (jack of all trades master of none). My suggestion would be to make it clear which ones you are expert in (i.e. if you are a c++ coder, I expect to stick you in front of a PC and have you emitting quality code in the first week); and maybe list all the others as "have also used dBase II, Algol, Fortran 77, Windows 3.11, and 6502 assembly language". If you are a mega-geek and actually remember all the commands of SAS and Prolog, then I'd suggest you come up with a way to make me believe it. On the plus side, I think your resume is FAR more readable than 90% of the crapola which crosses my desk.
Umm, did you tell the CEO that worms almost always forge the from: header? Wait, never mind. He probably thinks that email is actually secure. The difference between intelligence and stupidity is that there is a limit to intelligence.
Since this comission theft is apparently legal, I'm going to modify our GL system here at the office to re-code all our product sales as being sold by me, so I get all the commissions. Why should those pesky sales people get any of the money, anyway? If they want money, they should become c++ programmers instead of salesmen.
re:"That'd be hard. A sector of a flash chip will wear out and turn into a "bad sector" after about 100,000 writes. The flash controller will have to have some sort of logic to treat repeated writes specially. Apparently, most modern CompactFlash cartridges' integrated controllers can do this; can anybody explain how such logic works? "
Flash-based RAM drives use a process called "wear levelling". There are lots of patented algorithms for this, but basically it boils down to keeping a write counter for each sector, and as it starts getting high, you swap this sector's storage location with a lightly-used sector. Over time, the thing will wear out if you do an average of a million writes to all sectors, which in practice never happens. You can run these things for a year on IOMeter and never wear them out.
This sort of thing is more useful in the UK, as there are numerous historical preservation zones where you can't even have a visible satellite dish. In the middle of a town, it's much easier to get permission if the mast is invisible. That, and the local schools won't start bitching about the unreasonably high rate of student's brain tumors if the masts are invisible.
I work on the design of hardware RAID controllers and the original post is missing a key piece of information -- are the two drives really bad, or were they just marked as bad by the RAID driver? I ask because often (particularly with parallel SCSI drives) you have a bad connection or a bad drive which causes one drive to hang, which makes the RAID set go degraded, but since the bus is still corrupted the next drive it tries to talk to will also appear be bad so the array is marked offline. This happens at least ten times as often as genuine double drive failures. How the RAID software reacts to double drive failures depends upon the author. You should have some kind of log or console printout -- the timestamp of the errors is the tell-tale clue, if the failures happened within a minute or so then you can be pretty sure that only the first failure is real.
First thing's first -- put in a set of scratch drives and see if the bus and HBA is working ok. Test it thoroughly! Then, using a read-only tool like IOMeter, check each of your original data drives individually to see if it can read reliably across the platters (If using NT for this test, do NOT let DiskAdmin write signatures on the drives!!). Hopefully one of the drives will be bad -- if so, set it aside. Perhaps you are certain you know which was the first drive to fail -- remove that one if you know it. Reboot, and see if the array metadata is recognized. If not, concentrate your efforts on fixing the second drive to fail. If there is a gap in time between the first and second drive failures then the data on the first drive to fail is no longer of any use to you as it is out of sync with the other drives. If you have more details please post them here and I will try to give you more detailed advice. One other soapbox comment -- people who sell RAID technology should always provide some kind of metadata debugger because, as they say, sh!t happens.
In 1997 the Mars Pathfinder probe had a problem with VxWorks and priority inversion. Perhaps the F22 is having something similar -- whenever you have a RTOS, the designer must try to anticipate when it's safe to block real time interrups and when it isn't. I don't know anything about the F22, but it's easy to imagine that it has hundreds of input sources with all sorts of latency requirements. AFAIK, it all comes down to some humans trying to balance these conflicting needs. Clearly they don't always get it right.
Yup, and there's nothing really stopping me from cloning a plate from somebody I don't like and driving 150 MPH through the speed cameras -- works best if they have a similar type of car, but who wants to guess at what stage any such error checking takes place? No doubt you have to go into court to prove your innocence. Somebody earlier talked about "civil disobedience" -- the whole traffic camera idea comes tumbling down once enough people start cloning the plates of innocent people (or, if you prefer, number plates seen in the car park of the camera manufacturer). (As a side note for American readers, in the UK you have to get your number plates printed at your local auto parts store and they don't care if you really own the number. Thus forgery is trivial.)
Maxtor's drive can burst 150 MB/s because the Marvell chip has an ATA/150 mode on the parallel side, and Maxtor has wound up their ATA clock accordingly.
Excitedly I just tried Cloudmark on Outlook 2000. Just as soon as I click on an imcoming email, somehow the mail is deleted and it doesn't even go to the deleted folder. I just lost some incoming mail! Anyone else find this bug?
If you plan to use a consumer-grade digital camera and calibrate it with known test patterns, you will have to be a little careful:
(1) Many cameras output in jpeg or other compressed formats. All lossy compression algorithms have artifacts, which are complex and counter-intuitive. All pixels interact with their neighbors to some extent. For example, two green dots far apart might come through correctly, but if they are too close together the color might change.
(2) The better cameras have electronic pixel shifting to give a higher apparent resolution. I'm sure this is a non-linear process which has been deliberately tweaked to appeal to the eye.
(3) The lenses will have non-linear aberrations which might need measurement.
IBM normally makes very very good drives with high reliability. We use many hundreds of them a month. However, two weeks ago we got a shipment of four cases of 75gig drives, with 20 drives per case. They were brand new, from a first-tier disty in factory packaging, sealed, with no visible shipping damage. We handled them with full ESD and shock/vibe protection, as always. Most of the drives in three of the cases failed with clicking and grinding as soon as power was applied. I did the engineering evaluation myself and triple-checked the test rigs, which were perfect. It's weird I'll grant you that. We shipped the working drives after a couple of days of testing, and thus far there are no reported field failures. IBM has been great and instantly swapped out the bad drives, no questions asked. The failures and their frequency was not subtle -- they clearly had some kind of manufacturing screw-up.
Well, we need to get rid of our stockpile of VX nerve agent, so why not unload it over any area we suspect might be a Bin Laden stronghold? It's technically a WMD, but recall that poison gas was used against the Kurds and nobody gave much of a damn. There was hardly an uproar about it, and the Kurds were more or less innocent. We have thousands of tons of VX, which ought to be able to render a few thousand square miles uninhabitable. The cool thing is that we could deny involvement, and blame Iran or Israel (everybody would know we did it, of course). I'm not suggesting we use VX against Kabul or other obvious civilian population centers -- for them, we use the B-2's to deploy GPS guided bombs to strike all known Taliban offices and bases, plus the known homes of their leaders. This would only be fractionally useful, but would give them something to think about. If we find complicity in other countries, like the Deputy Director of Syrian Intelligence, we smart bomb his home and kill his family and then claim we had nothing to do with it. If you are going to "send a message" to terrorists, you might as well send it in the only language they truly understand.
Slashdot Mirror
You have a BS degree. That ought to be in the first third of your resume. As somebody who has to sift through resumes from time to time, I can tell you that my immediate feeling was that you were covering up not having a degree by listing all sorts of stuff, and I almost didn't read all the way down. I also would be highly skeptical of anybody who claimed as many programming/apps skills as you do -- unless you are totally hardcore, you are not current in more than a few of these skills, and maybe never were expert in most of them. Not picking on you especially, but in my experience I find that people who list tons of app and programming languages have either taken a college taster course in them (useless to me) or have had so many jobs each of which was different (jack of all trades master of none). My suggestion would be to make it clear which ones you are expert in (i.e. if you are a c++ coder, I expect to stick you in front of a PC and have you emitting quality code in the first week); and maybe list all the others as "have also used dBase II, Algol, Fortran 77, Windows 3.11, and 6502 assembly language". If you are a mega-geek and actually remember all the commands of SAS and Prolog, then I'd suggest you come up with a way to make me believe it. On the plus side, I think your resume is FAR more readable than 90% of the crapola which crosses my desk.
Umm, did you tell the CEO that worms almost always forge the from: header? Wait, never mind. He probably thinks that email is actually secure. The difference between intelligence and stupidity is that there is a limit to intelligence.
Since this comission theft is apparently legal, I'm going to modify our GL system here at the office to re-code all our product sales as being sold by me, so I get all the commissions. Why should those pesky sales people get any of the money, anyway? If they want money, they should become c++ programmers instead of salesmen.
re:"That'd be hard. A sector of a flash chip will wear out and turn into a "bad sector" after about 100,000 writes. The flash controller will have to have some sort of logic to treat repeated writes specially. Apparently, most modern CompactFlash cartridges' integrated controllers can do this; can anybody explain how such logic works? " Flash-based RAM drives use a process called "wear levelling". There are lots of patented algorithms for this, but basically it boils down to keeping a write counter for each sector, and as it starts getting high, you swap this sector's storage location with a lightly-used sector. Over time, the thing will wear out if you do an average of a million writes to all sectors, which in practice never happens. You can run these things for a year on IOMeter and never wear them out.
This sort of thing is more useful in the UK, as there are numerous historical preservation zones where you can't even have a visible satellite dish. In the middle of a town, it's much easier to get permission if the mast is invisible. That, and the local schools won't start bitching about the unreasonably high rate of student's brain tumors if the masts are invisible.
I work on the design of hardware RAID controllers and the original post is missing a key piece of information -- are the two drives really bad, or were they just marked as bad by the RAID driver? I ask because often (particularly with parallel SCSI drives) you have a bad connection or a bad drive which causes one drive to hang, which makes the RAID set go degraded, but since the bus is still corrupted the next drive it tries to talk to will also appear be bad so the array is marked offline. This happens at least ten times as often as genuine double drive failures. How the RAID software reacts to double drive failures depends upon the author. You should have some kind of log or console printout -- the timestamp of the errors is the tell-tale clue, if the failures happened within a minute or so then you can be pretty sure that only the first failure is real.
First thing's first -- put in a set of scratch drives and see if the bus and HBA is working ok. Test it thoroughly! Then, using a read-only tool like IOMeter, check each of your original data drives individually to see if it can read reliably across the platters (If using NT for this test, do NOT let DiskAdmin write signatures on the drives!!). Hopefully one of the drives will be bad -- if so, set it aside. Perhaps you are certain you know which was the first drive to fail -- remove that one if you know it. Reboot, and see if the array metadata is recognized. If not, concentrate your efforts on fixing the second drive to fail. If there is a gap in time between the first and second drive failures then the data on the first drive to fail is no longer of any use to you as it is out of sync with the other drives.
If you have more details please post them here and I will try to give you more detailed advice.
One other soapbox comment -- people who sell RAID technology should always provide some kind of metadata debugger because, as they say, sh!t happens.
In 1997 the Mars Pathfinder probe had a problem with VxWorks and priority inversion. Perhaps the F22 is having something similar -- whenever you have a RTOS, the designer must try to anticipate when it's safe to block real time interrups and when it isn't. I don't know anything about the F22, but it's easy to imagine that it has hundreds of input sources with all sorts of latency requirements. AFAIK, it all comes down to some humans trying to balance these conflicting needs. Clearly they don't always get it right.
Yup, and there's nothing really stopping me from cloning a plate from somebody I don't like and driving 150 MPH through the speed cameras -- works best if they have a similar type of car, but who wants to guess at what stage any such error checking takes place? No doubt you have to go into court to prove your innocence. Somebody earlier talked about "civil disobedience" -- the whole traffic camera idea comes tumbling down once enough people start cloning the plates of innocent people (or, if you prefer, number plates seen in the car park of the camera manufacturer). (As a side note for American readers, in the UK you have to get your number plates printed at your local auto parts store and they don't care if you really own the number. Thus forgery is trivial.)
Maxtor's drive can burst 150 MB/s because the Marvell chip has an ATA/150 mode on the parallel side, and Maxtor has wound up their ATA clock accordingly.
Excitedly I just tried Cloudmark on Outlook 2000. Just as soon as I click on an imcoming email, somehow the mail is deleted and it doesn't even go to the deleted folder. I just lost some incoming mail! Anyone else find this bug?
SATA is stictly point-to-point. You can't daisy chain multiple drives.
If you plan to use a consumer-grade digital camera and calibrate it with known test patterns, you will have to be a little careful: (1) Many cameras output in jpeg or other compressed formats. All lossy compression algorithms have artifacts, which are complex and counter-intuitive. All pixels interact with their neighbors to some extent. For example, two green dots far apart might come through correctly, but if they are too close together the color might change. (2) The better cameras have electronic pixel shifting to give a higher apparent resolution. I'm sure this is a non-linear process which has been deliberately tweaked to appeal to the eye. (3) The lenses will have non-linear aberrations which might need measurement.
IBM normally makes very very good drives with high reliability. We use many hundreds of them a month. However, two weeks ago we got a shipment of four cases of 75gig drives, with 20 drives per case. They were brand new, from a first-tier disty in factory packaging, sealed, with no visible shipping damage. We handled them with full ESD and shock/vibe protection, as always. Most of the drives in three of the cases failed with clicking and grinding as soon as power was applied. I did the engineering evaluation myself and triple-checked the test rigs, which were perfect. It's weird I'll grant you that. We shipped the working drives after a couple of days of testing, and thus far there are no reported field failures. IBM has been great and instantly swapped out the bad drives, no questions asked. The failures and their frequency was not subtle -- they clearly had some kind of manufacturing screw-up.
Well, we need to get rid of our stockpile of VX nerve agent, so why not unload it over any area we suspect might be a Bin Laden stronghold? It's technically a WMD, but recall that poison gas was used against the Kurds and nobody gave much of a damn. There was hardly an uproar about it, and the Kurds were more or less innocent. We have thousands of tons of VX, which ought to be able to render a few thousand square miles uninhabitable. The cool thing is that we could deny involvement, and blame Iran or Israel (everybody would know we did it, of course). I'm not suggesting we use VX against Kabul or other obvious civilian population centers -- for them, we use the B-2's to deploy GPS guided bombs to strike all known Taliban offices and bases, plus the known homes of their leaders. This would only be fractionally useful, but would give them something to think about. If we find complicity in other countries, like the Deputy Director of Syrian Intelligence, we smart bomb his home and kill his family and then claim we had nothing to do with it. If you are going to "send a message" to terrorists, you might as well send it in the only language they truly understand.