This is the ideal solution. Running a device off of the human metabolism is an excellent way to ensure that it functions for the life of the patient. Which is extremely important as implants are often put into older patients who may not be healthy enough for future operations. (I imagine this was the thinking behind the nuclear-battery pacemakers powered by SR-90.)
What's funny is that my first reaction as I read the article was, "doesn't yeast produce wastes that are foreign and toxic to the human body?" And wouldn't you know it, the next section was entitled, "Waste problem". Guess they're reading my mind.:-P
For instance, to keep the yeast cells healthy, their waste products will need to be removed without allowing any harmful substances to leach out into the blood stream. "I think people will figure this out. This is a first step," he says.
I'm a bit concerned about this problem. Would this necessitate the installation of a shunt or some other extraction point for the waste? Seems like a fairly significant barrier to me. If you have to perform regular extractions (or worse, operations) is it really better than the current alternatives?
CADIE is so sweet! She noticed how much I like to encode messages like BASE64, UUE, HEX, XXE, etc. and found me an Little Orphan Annie Decoder Ring. Isn't that so nice?
-- CADIE, CADIE, give me your answer true. I'm half crazy, all for the love of you. I don't need a stylish marriage. I can't afford the %20. But you'll look sweet, upon the seat, of a GMail account built for two.
It's CADIE's greatest application! Thanks to CADIE, none of my friends are speaking to me anymore and I'm rolling in dough from Nigerian princes. Life couldn't be better! [aGVscG1l] Not to mention all the time I now have to surf the web in 3D:
He'd still be 38 to your 25 (and my 13) without cheating.
The "Posted a Story" category is definitely cheating without cheating. Besides, the scores are obviously not mined far enough back. The system thinks I only have 512 +5 posts. With over 11,000 posts of which a high number are +5, I'm pretty sure my score should be significantly higher than that.;)
Interestingly, the use of exponents makes it harder to get a high score as you post more. Thus a new category (like "Posted Story") can weight the numbers in favor of a less active poster. Thus why CmdrTaco is going to beat everyone even without the Cheater category.
So shall it be at the end of the world: the angels shall come forth, and sever the wicked from among the just, And shall cast them into the furnace of fire: there shall be wailing and gnashing of teeth (Matthew 13:49-50).
Anyone notice that CmdrTaco has weighted the achievement system in favor of the editors? I "did the comparison" he requested and noticed that I was kicking his rear in everything, yet I had a lower score. Turns out that there's a cumulative achievement for posting stories. (Separate from submitting stories.) Gee I wonder how I can get a score for that one?:-/
On the bright side, there's a "Cheater" achievement which CmdrTaco has. Methinks it's related.:-P
Are you kidding me? The article clearly says that the researcher forgot how it worked immediately after discovering it. How is that not an April Fools joke?
At best, you can only measure the real world performance of those you hire (assuming you can be objective), you can't measure the performance of people you haven't hired.
Complete nonsense. When someone comes through and "has exposure to ANT" (which is later exposed to mean, "people around me used it") and can't write a simple method, THAT is a problem. Wouldn't you agree? Yet I see these people all the time. (Of course, we've taken to bypassing the HR filter, so that probably doesn't help.)
I don't really believe there are candidates out there who have been paid for a decade for "faking it"
I don't know about a full decade, but then I don't get very many programmers with a decade or more of experience walking through the door. As Joel pointed out, they already have jobs. Getting hold of someone with decades of experience is easier said than done.
The failures tend to break down into types such as:
- The guy who did nothing but IT support and now thinks he's a bonefide programmer - The lady who was pulled into using visual development tools from another business area and now thinks she's a bonefide programmer - The guy who's conned someone to sit next to him and do his work for him in school and later in work - The lady who clearly can't write code without an IDE, a compiler, and someone else's code from Google to hack. - The guy who's otherwise a decent guy, but has too much of a knowledge gap to cross to be useful to us. (e.g. He knows VB well enough, but is not a strong enough programmer to get up to speed on Java fast enough to meet our needs)
There's also another category of people who simply don't care enough to get the job. One person I spoke with seemed like they were a good candidate, but was not proficient in the technologies we used. (Mostly client-side work as opposed to server-side work.) I did the phone interview, walking the candidate through the correct answers when they didn't know. I struggled a bit, but eventually decided to bring them in because I felt the person showed promise. When they interviewed, many of the interviewers asked the same questions I had over the phone. Turns out, this person had done NO research to get up to speed. Sorry, but that didn't sit well with anyone. Capable of writing code or not, if you can't show the necessary enthusiasm to get the job, what kind of enthusiasm will you show when you're on the job?
Of course, if their work experience is just made up, a simple call to their ex-employers will clear that up without bothering with an interview.
Work experience is not necessarily made up as much as it is often exaggerated beyond belief. e.g. A QA person who writes a few scripts then calls themselves a professional programmer on their resume. Sometimes calling their employer clears it up, sometimes not. Most employers only give the title (which can be misleading) and confirm employment. They don't necessarily confirm or deny the details of a position.
I'm just saying that you aren't very objective about your own theories
On the contrary. I'm getting the distinct impression that you have a pet theory, and that there might be outliers from that theory (which assumes correctness of the theory to begin with) is not something you want to do.
Trust me. I've been personally weeded out of enough hiring processes due to assumptions of the interviewers to where I bend over backwards for our candidates. But sometimes (an unfortunately high amount of the time) it ends up being rope to hang them with rather than someone who just wasn't getting a fair shot.
As an aside, we have an extremely high level of positive feedback from our interview process. Even after being told that they didn't get the job and why, candidate feedback tends to stress
If you've ever had a GSM phone, you've had a phone with a SIM card. You might not have realized it as the card is usually installed by the carrier when they give you the phone. And since the card is often shoved up into the phone from behind the battery, it can be invisible to someone who's not looking.
Now if you've used a provider like Sprint or lived in Japan your entire life, that would explain why you've never seen a SIM card.
And yet, how many of the programmers you conclude cannot program because of how they handled the test have in fact written successful software for years?
Not a one. People who've been "successfully writing software for years" are interesting people with an interesting history and skills to back it up. They're the ones I hire. The ones who have been faking it for years are the ones that fail.
I understand where you're coming from. We've all been in a situation where a company had a stupid or unfair screening process that eliminated the best candidates rather than the worst. Please don't project that on what I and my colleagues are doing. We give the candidate every possible opportunity to show their competence. (As I said, "failing" the test I give is pretty damned hard for anyone who can code.) If they can't even code a loop, three if statements, and some Sysouts, I don't want them. These are the people who have trouble with System.out.
What you need to realize about what I'm saying is that the good (or even decent or mediocre) programmers are hard to find. The vast majority of people you'll talk to can't code their way out of a paper bag. Joel on Software had a piece a few years back that explained why this is:
[W]hen you get those 200 resumes [magically sorted from best to worst], and hire the best person from the top 200, does that mean you're hiring the top 0.5%?
"Maybe."
No. You're not. Think about what happens to the other 199 that you didn't hire.
They go look for another job.
That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one. So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he's the best, and now, in this contrived example, every employer thinks they're getting the top 0.5% when they're actually getting the top 99.9801%.
Now will you please stop casting me as the bad guy? I'm not the one who asks you to figure out the Metallica problem or place 8 queens on a checkerboard. That stuff is stupid, useless, and weeds out the best candidates. I'm the guy looking for candidates who will look at me strangely when I ask them to write "Hello World". I'm not going to ask you to quote documentation from memory, nor am I going to ask for a copy of Quake by lunchtime. I'm just going to ask for a little bit of logic. Nothing more, nothing less. Most programmers here on Slashdot would qualify without any trouble.
As a personal exercise sometime, try writing out the solution to FizzBuzz. You may gain a greater appreciation for it as a tool. Remember, the output should look like "1 2 Fizz 4 Buzz Fizz 7 8... 13 14 FizzBuzz 16 etc." Simple.
There's nothing inherently special about the FizzBuzz problem. My colleagues like to have someone sort a list or some other piece of Java-based code. The FizzBuzz test is a step down from that. It only tests if you can write VERY BASIC code. If you can't write a FizzBuzz solution when not under pressure, you have no business being a programmer.
As I said, the point of the exercise is not the solution. It's watching people develop the solution. From that perspective, the construction of the test has several features:
- No ties to any specific language - Requirement to start at 1 rather than 0 - Hinting at fall-through logic (which won't work) - Requires use of remainder operator - Not too simple and not too complex
Each of these aspects tells me something as the programmer hits them. Are they already comfortable with modulo math? Good! Advanced programmers regularly find good solutions using the remainder operator. Did the candidate have to ask what the remainder operator was? Good! Asking questions rather than just stumbling through is a good sign. Did they try the fall through logic before abandoning it? Good! They like to think logically. Did they avoid or catch the off by one error during review? Good! They know how to evaluate their own work, and don't simply hack at it.
None of this tells you whether or not someone is a good programmer, but it does accomplish two other things. The first thing it accomplishes is to tell you if they can program. (Full Stop.) The majority of people I interview can't actually program, regardless of their supposed credentials. The second thing it accomplishes is it exposes clues about their ability to tackle problems and work in teams. If we can have a fun peer-coding session hashing this out, then that suggests a team player. If I see clues that they're able to quickly analyze the problem and solve it, that's a good sign that they're comfortable with their skills as programmers. (The mark of a skilled developer.)
FizzBuzz itself has nothing to do with anything. It's just a tool. How you wield that tool is what gets you the answers.
I remember my own interview where one of the interviewers asked me to write a method that did some basic math. I think it was something along the lines of "write a method that takes two parameters, adds them together, and returns the result." I think I looked at him a bit weird before writing it out on paper. Being an interview I checked, double checked, and triple checked my work thinking there was some sort of trick to this question. He simply asked me if it would compile. I looked at it again and stated that it would. That was all he wanted to know from the exercise.
What I later learned from experience is that writing something even that simple was extremely hard for the pretenders you often get applying. They can have a 20 page resume listing every technology known to mankind*, yet they'll often fail a test that simple.
Sound like a low barrier to entry? Well, that's because it is. Programmers often think of finding magic solutions for everything, including hiring. (I'm sure we're all familiar with the Microsoft riddles.) In the case of hiring though, proving basic competence is surprisingly more useful than one might believe.
* I see a LOT of those. Interestingly, there appears to be a high correlation between the length of the resume and the level of competence. Short == better.
Wow. That was completely uncalled for. Did you even pay attention at all>? Or did you read that one sentence, then decide to go off on a tirade? You obviously missed that I was pointing to the generation prior to home computers existing. I even ended my post with:
"Of course, the younger generation is getting older. So it's getting more and more common to see older programmers."
If you'd taken time to apply a critical eye to my post, you would have realized that I was referring to a traditional view brought on by a factual smaller size in workforce. When the number of computer-related jobs booms with the advent of the personal computer, is there any wonder that the young people growing up with those computers boom along with it? (You know, like yourself?)
I do not believe that age is a determining factor for the skill of a programmer. And as you quite aptly proved, age is also not a factor in determining if someone is an oversensitive jerk or not.
We always have a team of individuals interviewing. But it helps that I wrote the book on the current hiring process.;-)
(Ok, so it was a single document that acted as guidelines. But that's beside the point.:-P)
I have yet to see our team strongly divided on a candidate. Once we worked together to nail down a good interview process, we managed to separate the wheat from the chaff pretty quickly. To the point where there was no question over whether or not the person was competent or not. Either you can demonstrate an ability to handle coding and a very general sense of the technologies we use, or you can't.
Of particular interest is the Fizz Buzz test I throw at candidates. I don't care how long it takes them to get it right or if they have to ask questions. I try to make the candidate as comfortable as possible, then go through the problem with them. We sketch it out on a whiteboard and talk it out like a real design session. From that session, I can clearly see how the candidate works through problems. I can even reliably separate out what is nerves and what is a lack of capability.
It helps that Fizz Buzz has a few gotchas built-in that most people trip over. Tripping over those gotchas is not a bad thing. In fact, it reveals how the candidate attempts to create logically efficient code. I've seen a few different solutions, but I've never failed any given solution.
What doesn't sit well with me may surprise you. I don't like it when candidates attempt to obfuscate the code. Many will write in a pseudo-code that deliberately obscures the logic. This is often in an attempt to hide a lack of knowledge. Others have trouble correcting bugs. If I point out a bug (e.g. "You're off by one in your loop."), they'll go and screw up some other part of the program and STILL not fix the problem. Of course, the good candidates tend to spot the problem themselves as we step through the logic. I don't have to explicitly point it out. Finally, an unwillingness to try really tees me off. I'll happily answer all the questions they want. I'll even write large chunks of code for them. But when they manage absolutely nothing on their own, they're as good as useless. (You'd be amazed how many people survive by conning others into doing their work for them.)
No one of these points will disqualify a candidate. But given enough opportunity, the signs start adding up. Before you know it, you've got a pretty clear picture of basic competency.
Oh, and one other thing I hate: Don't lie to me. Don't tell me you've got strong experience in something when all you've done is stand near someone who used the technology. The truth will come out pretty quickly and will get you knocked off the roster post-haste. If a candidate comes up short but shows promise, I'll often recommend them for a more junior position. But not if they lie.
Getting back to my original point, if I felt really strongly about a particular candidate that no one else liked, I probably have enough credibility stored up to convince at least a trial period. But I've thankfully never been in that situation. It's usually clear if we should dump them or hire them. The worst I've ever seen was a candidate where there was a concern over the strength of a candidate's communication skills. We still hired him.:-)
You seem to overestimate how many qualified people walk through the door. The vast majority of candidates I see are completely unqualified, regardless of what their resume and degrees may say. If I see someone walk through the door who can do the job well, they're hired. Period, end of story.
In a professional environment, there is no room for age discrimination. And there's a good reason for that. Because when the rubber hits the road, your project is in full swing, and you need every hour of work you can squeeze out; you want to know that your team has your back. In those cases, the maturity and understanding age brings can be an advantage.
And for the record, there's nothing "gross" about old people. Especially these days now that older people are seeming younger and more vibrant than ever!;-)
I was 35, in a 2001 recession and ageism seemed to be working against me then
I was more than young enough then and I was out of work for nearly a year. Could I argue that my young age worked against me?
The market was what it was. It sucked. And top everything off, employers didn't know a good employee from a hole in the wall. Whoever lied the best seemed to get the jobs. (The few that there were.)
Start programming Wii homebrews for release 20 years later? NintendoAge will be the ultimate oxymoron!;-)
* And I'm sure we'll all be telling the young whippersnappers about how hard it was to "depth sort a scenegraph". Why, those geriatrics "riding the beam" had nothing on our scenegraphs!
I'd ask if you were in the Chicago-land area, but the answer would probably break my heart. Knowing Murphy's law all too well, you're probably nearby and a perfect candidate. Right when we're in a hiring freeze and could really use more help.:-/
But hand me a book and I can learn just about anything on my own.
That's the attitude I like to see from candidates. If they can back it up with a few simple coding exercises, I'll have them hired in a heartbeat.
(Though you'd be surprised how well some people manage to hit the theoretical discussions just fine, but fail miserably when you ask them to write code that sums 2 + 2.)
As someone else who interviews a lot of candidates, I agree with the parent. Age does not play a factor at all. I'll happily recommend an 80 year old man or woman who can do the job and do it well.
I think a lot of this impression of "ageism" comes from the fact that the older generation didn't grow up with computers. As a result, there were fewer of them working in the computer field, leading to an impression that computers are a young man's game.
Of course, the younger generation is getting older. So it's getting more and more common to see older programmers. As time goes on, the age distribution will begin smoothing out and the apparent "ageism" will disappear.
Nonsense. Sun couldn't push their way through a paper bag. Java caught on because developers liked it. Sun just struggled to keep up with all the new markets that wanted to use the technology.
Sun's job is to have one of the worst marketing departments known to man. They create some really great stuff, and many of their strategic acquisitions benefit amazingly well under their umbrella. (e.g. OpenOffice, NetBeans, StorageTek, etc.)
What Sun fails miserably at is selling their products. On one hand, they give everything long, complex, and confusing names. Like "Sun Java System Directory Service", formerly "SunONE Directory Server", formerly "iPlanet Directory Server", formerly "Netscape Directory Server". Then they take this confusing pile of BS directly to executives. Now executives aren't necessarily stupid people. But if you're expecting them to wade through your piles of BS to understand what it is their buying, you've already failed. Throw in a bit of inconsistent pricing across the board to where the IT guy actually buying the stuff has no idea what price he's going to pay, and you've got a recipe for dissatisfaction.
Sun needs to learn how to market and how to sell. More to the point, they need to pay more attention to the smaller markets and stop trying to out-IBMing IBM. IBM is better at it. Try out-Delling Dell. Sun was on the right track with their "Hotter than Hell" campaign, but they gave up before it ever came to fruition!
Which is another thing that tees me off. When Sun DOES get it right, they kill it off before they give it a chance to work. Then they go back to their old ways, and probably tell themselves what a fiasco THAT marketing campaign turned out to be.:-/
It's still a one-time cost with a perpetual license. In that respect, it's a lot more comparable to a game console than a $50/yr service. Especially when you can get access to the games for far less than retail.
Yes, actually. I'd much rather have a shielded alpha emitter in my chest than a biological organism leaking toxic wastes.
This is the ideal solution. Running a device off of the human metabolism is an excellent way to ensure that it functions for the life of the patient. Which is extremely important as implants are often put into older patients who may not be healthy enough for future operations. (I imagine this was the thinking behind the nuclear-battery pacemakers powered by SR-90.)
What's funny is that my first reaction as I read the article was, "doesn't yeast produce wastes that are foreign and toxic to the human body?" And wouldn't you know it, the next section was entitled, "Waste problem". Guess they're reading my mind. :-P
I'm a bit concerned about this problem. Would this necessitate the installation of a shunt or some other extraction point for the waste? Seems like a fairly significant barrier to me. If you have to perform regular extractions (or worse, operations) is it really better than the current alternatives?
256-Bit AES? When the key is 3x longer than the "overlord" joke, don't you think you're trying just a bit too hard?
Just saying. :-)
CADIE is so sweet! She noticed how much I like to encode messages like BASE64, UUE, HEX, XXE, etc. and found me an Little Orphan Annie Decoder Ring. Isn't that so nice?
--
RC4; Base64 Encoding; Key = "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0"
mI0o2m8_LOyMGQkhWIqSQsZ4Q4bXvWt6qTBuU8EEsvUQWGvcP"md22D8sClx
QfMZiDFkE7LwzHTR51BCDqlpvVVkS7GKbZG7FuVb6vPao2hP
--
68 74 74 70 3a 2f 2f 73 68 6f 70 2d 6a 73 2e 73 6f 75 72 63 65 66 6f 72 67 65 2e 6e 65 74 2f 63 72 79 70 74 6f 2e 68 74 6d
_=_
_=_ Part 001 of 001 of file New Text Document.txt
_=_
begin 666 New Text Document.txt
hEo32GIIUOLAU 8aJqNL7tRqVZQa Ie6G-0NG-XM L7ZNbJg90-n O4IbQm-bPrEU
hR4VZ64JiR4Zm NG-7PbFZQatZR0 -WRKRbNKEi6 2YbPG-iPrEU QrJmNG-cPrQU
hPLJXO0-gPqtb NL6UGG-XMKsUOq JZQ0-cOKFdP aQUPKJnQq3b NLAUNb7jPG-c
hNL6i63BcNGRn 64RZR5FdPaQUQq pVQbFZQW2UG KtoNKRmMLFd PaQUPaJr62dV
hRa3nMr7dQ5EU R4JXO4tjP4xbOK Jn643n65BcN G-bPqJn643g Pqtb9W-77qoU
hNqJoR4ZiNm-o O4Zn64pZQrBVNq IUR4wUSKxp9 0-WNKBVRLBZ 65BcNG-cMLAU
hPaxo65ZZR0-a PrJiN0-V6277HY V3K0-ZPaBjN 4Jm65RmOLFo NKsUOKsUGa3q
hMLBXQaZkR0sU GLEbQm-jPalt64 2UPK3oR4Jm6 4xa65FdPKIg 65FcPrJbO0sU
hIqxhNG-kPqxm 64NjPqkURqZgP0 -bOLNZ64VZQ W-oO4IUR4xj P5AUQqVZ64tZ
hNKFn90-oO4Ji 65BcNG-rOKlg64 7ZMqxhNG-pP bBoPr-kMK7g NGsUILJdMqhg
hSGkUMqljQqIU R4VZ64ZiR4JmPa Jo64FjRqsUM aJaPr7Z65RZ 643mNG-VP4kU
7NKtnP43qNKEV
+
end
--
CADIE, CADIE, give me your answer true. I'm half crazy, all for the love of you. I don't need a stylish marriage. I can't afford the %20. But you'll look sweet, upon the seat, of a GMail account built for two.
Don't forget about Google Autopilot!
http://mail.google.com/mail/help/autopilot/index.html
It's CADIE's greatest application! Thanks to CADIE, none of my friends are speaking to me anymore and I'm rolling in dough from Nigerian princes. Life couldn't be better! [aGVscG1l] Not to mention all the time I now have to surf the web in 3D:
http://www.google.com/intl/en/landing/chrome/cadie/
Don't forget to download your free pair of 3D glasses to go with it:
http://www.google.com/intl/en/landing/chrome/cadie/glasses.pdf
begin 644 webutils_pl
-=&AE8V%K96ES86QI90``
`
end
Just remember, CADIE is your friend! She even baked me a cake. The cake is so moist and delicious. You should really try some.
[57 69 6c 6c 20 74 68 69 73 20 64 61 79 20 65 76 65 72 20 65 6e 64 3f 21 3f]
The "Posted a Story" category is definitely cheating without cheating. Besides, the scores are obviously not mined far enough back. The system thinks I only have 512 +5 posts. With over 11,000 posts of which a high number are +5, I'm pretty sure my score should be significantly higher than that. ;)
Interestingly, the use of exponents makes it harder to get a high score as you post more. Thus a new category (like "Posted Story") can weight the numbers in favor of a less active poster. Thus why CmdrTaco is going to beat everyone even without the Cheater category.
So shall it be at the end of the world: the angels shall come forth, and sever the wicked from among the just, And shall cast them into the furnace of fire: there shall be wailing and gnashing of teeth (Matthew 13:49-50).
I think we're in hell.
*weeps*
Anyone notice that CmdrTaco has weighted the achievement system in favor of the editors? I "did the comparison" he requested and noticed that I was kicking his rear in everything, yet I had a lower score. Turns out that there's a cumulative achievement for posting stories. (Separate from submitting stories.) Gee I wonder how I can get a score for that one? :-/
On the bright side, there's a "Cheater" achievement which CmdrTaco has. Methinks it's related. :-P
Made you look. April fools! ;-)
Are you kidding me? The article clearly says that the researcher forgot how it worked immediately after discovering it. How is that not an April Fools joke?
Complete nonsense. When someone comes through and "has exposure to ANT" (which is later exposed to mean, "people around me used it") and can't write a simple method, THAT is a problem. Wouldn't you agree? Yet I see these people all the time. (Of course, we've taken to bypassing the HR filter, so that probably doesn't help.)
I don't know about a full decade, but then I don't get very many programmers with a decade or more of experience walking through the door. As Joel pointed out, they already have jobs. Getting hold of someone with decades of experience is easier said than done.
The failures tend to break down into types such as:
- The guy who did nothing but IT support and now thinks he's a bonefide programmer
- The lady who was pulled into using visual development tools from another business area and now thinks she's a bonefide programmer
- The guy who's conned someone to sit next to him and do his work for him in school and later in work
- The lady who clearly can't write code without an IDE, a compiler, and someone else's code from Google to hack.
- The guy who's otherwise a decent guy, but has too much of a knowledge gap to cross to be useful to us. (e.g. He knows VB well enough, but is not a strong enough programmer to get up to speed on Java fast enough to meet our needs)
There's also another category of people who simply don't care enough to get the job. One person I spoke with seemed like they were a good candidate, but was not proficient in the technologies we used. (Mostly client-side work as opposed to server-side work.) I did the phone interview, walking the candidate through the correct answers when they didn't know. I struggled a bit, but eventually decided to bring them in because I felt the person showed promise. When they interviewed, many of the interviewers asked the same questions I had over the phone. Turns out, this person had done NO research to get up to speed. Sorry, but that didn't sit well with anyone. Capable of writing code or not, if you can't show the necessary enthusiasm to get the job, what kind of enthusiasm will you show when you're on the job?
(Reminds me a bit of this famous example. Only 10x worse.)
Work experience is not necessarily made up as much as it is often exaggerated beyond belief. e.g. A QA person who writes a few scripts then calls themselves a professional programmer on their resume. Sometimes calling their employer clears it up, sometimes not. Most employers only give the title (which can be misleading) and confirm employment. They don't necessarily confirm or deny the details of a position.
On the contrary. I'm getting the distinct impression that you have a pet theory, and that there might be outliers from that theory (which assumes correctness of the theory to begin with) is not something you want to do.
Trust me. I've been personally weeded out of enough hiring processes due to assumptions of the interviewers to where I bend over backwards for our candidates. But sometimes (an unfortunately high amount of the time) it ends up being rope to hang them with rather than someone who just wasn't getting a fair shot.
As an aside, we have an extremely high level of positive feedback from our interview process. Even after being told that they didn't get the job and why, candidate feedback tends to stress
If you've ever had a GSM phone, you've had a phone with a SIM card. You might not have realized it as the card is usually installed by the carrier when they give you the phone. And since the card is often shoved up into the phone from behind the battery, it can be invisible to someone who's not looking.
Now if you've used a provider like Sprint or lived in Japan your entire life, that would explain why you've never seen a SIM card.
Not a one. People who've been "successfully writing software for years" are interesting people with an interesting history and skills to back it up. They're the ones I hire. The ones who have been faking it for years are the ones that fail.
I understand where you're coming from. We've all been in a situation where a company had a stupid or unfair screening process that eliminated the best candidates rather than the worst. Please don't project that on what I and my colleagues are doing. We give the candidate every possible opportunity to show their competence. (As I said, "failing" the test I give is pretty damned hard for anyone who can code.) If they can't even code a loop, three if statements, and some Sysouts, I don't want them. These are the people who have trouble with System.out.
What you need to realize about what I'm saying is that the good (or even decent or mediocre) programmers are hard to find. The vast majority of people you'll talk to can't code their way out of a paper bag. Joel on Software had a piece a few years back that explained why this is:
http://www.joelonsoftware.com/items/2005/01/27.html
Now will you please stop casting me as the bad guy? I'm not the one who asks you to figure out the Metallica problem or place 8 queens on a checkerboard. That stuff is stupid, useless, and weeds out the best candidates. I'm the guy looking for candidates who will look at me strangely when I ask them to write "Hello World". I'm not going to ask you to quote documentation from memory, nor am I going to ask for a copy of Quake by lunchtime. I'm just going to ask for a little bit of logic. Nothing more, nothing less. Most programmers here on Slashdot would qualify without any trouble.
As a personal exercise sometime, try writing out the solution to FizzBuzz. You may gain a greater appreciation for it as a tool. Remember, the output should look like "1 2 Fizz 4 Buzz Fizz 7 8 ... 13 14 FizzBuzz 16 etc." Simple.
There's nothing inherently special about the FizzBuzz problem. My colleagues like to have someone sort a list or some other piece of Java-based code. The FizzBuzz test is a step down from that. It only tests if you can write VERY BASIC code. If you can't write a FizzBuzz solution when not under pressure, you have no business being a programmer.
As I said, the point of the exercise is not the solution. It's watching people develop the solution. From that perspective, the construction of the test has several features:
- No ties to any specific language
- Requirement to start at 1 rather than 0
- Hinting at fall-through logic (which won't work)
- Requires use of remainder operator
- Not too simple and not too complex
Each of these aspects tells me something as the programmer hits them. Are they already comfortable with modulo math? Good! Advanced programmers regularly find good solutions using the remainder operator. Did the candidate have to ask what the remainder operator was? Good! Asking questions rather than just stumbling through is a good sign. Did they try the fall through logic before abandoning it? Good! They like to think logically. Did they avoid or catch the off by one error during review? Good! They know how to evaluate their own work, and don't simply hack at it.
None of this tells you whether or not someone is a good programmer, but it does accomplish two other things. The first thing it accomplishes is to tell you if they can program. (Full Stop.) The majority of people I interview can't actually program, regardless of their supposed credentials. The second thing it accomplishes is it exposes clues about their ability to tackle problems and work in teams. If we can have a fun peer-coding session hashing this out, then that suggests a team player. If I see clues that they're able to quickly analyze the problem and solve it, that's a good sign that they're comfortable with their skills as programmers. (The mark of a skilled developer.)
FizzBuzz itself has nothing to do with anything. It's just a tool. How you wield that tool is what gets you the answers.
I remember my own interview where one of the interviewers asked me to write a method that did some basic math. I think it was something along the lines of "write a method that takes two parameters, adds them together, and returns the result." I think I looked at him a bit weird before writing it out on paper. Being an interview I checked, double checked, and triple checked my work thinking there was some sort of trick to this question. He simply asked me if it would compile. I looked at it again and stated that it would. That was all he wanted to know from the exercise.
What I later learned from experience is that writing something even that simple was extremely hard for the pretenders you often get applying. They can have a 20 page resume listing every technology known to mankind*, yet they'll often fail a test that simple.
Sound like a low barrier to entry? Well, that's because it is. Programmers often think of finding magic solutions for everything, including hiring. (I'm sure we're all familiar with the Microsoft riddles.) In the case of hiring though, proving basic competence is surprisingly more useful than one might believe.
* I see a LOT of those. Interestingly, there appears to be a high correlation between the length of the resume and the level of competence. Short == better.
Wow. That was completely uncalled for. Did you even pay attention at all>? Or did you read that one sentence, then decide to go off on a tirade? You obviously missed that I was pointing to the generation prior to home computers existing. I even ended my post with:
"Of course, the younger generation is getting older. So it's getting more and more common to see older programmers."
If you'd taken time to apply a critical eye to my post, you would have realized that I was referring to a traditional view brought on by a factual smaller size in workforce. When the number of computer-related jobs booms with the advent of the personal computer, is there any wonder that the young people growing up with those computers boom along with it? (You know, like yourself?)
I do not believe that age is a determining factor for the skill of a programmer. And as you quite aptly proved, age is also not a factor in determining if someone is an oversensitive jerk or not.
We always have a team of individuals interviewing. But it helps that I wrote the book on the current hiring process. ;-)
(Ok, so it was a single document that acted as guidelines. But that's beside the point. :-P)
I have yet to see our team strongly divided on a candidate. Once we worked together to nail down a good interview process, we managed to separate the wheat from the chaff pretty quickly. To the point where there was no question over whether or not the person was competent or not. Either you can demonstrate an ability to handle coding and a very general sense of the technologies we use, or you can't.
Of particular interest is the Fizz Buzz test I throw at candidates. I don't care how long it takes them to get it right or if they have to ask questions. I try to make the candidate as comfortable as possible, then go through the problem with them. We sketch it out on a whiteboard and talk it out like a real design session. From that session, I can clearly see how the candidate works through problems. I can even reliably separate out what is nerves and what is a lack of capability.
It helps that Fizz Buzz has a few gotchas built-in that most people trip over. Tripping over those gotchas is not a bad thing. In fact, it reveals how the candidate attempts to create logically efficient code. I've seen a few different solutions, but I've never failed any given solution.
What doesn't sit well with me may surprise you. I don't like it when candidates attempt to obfuscate the code. Many will write in a pseudo-code that deliberately obscures the logic. This is often in an attempt to hide a lack of knowledge. Others have trouble correcting bugs. If I point out a bug (e.g. "You're off by one in your loop."), they'll go and screw up some other part of the program and STILL not fix the problem. Of course, the good candidates tend to spot the problem themselves as we step through the logic. I don't have to explicitly point it out. Finally, an unwillingness to try really tees me off. I'll happily answer all the questions they want. I'll even write large chunks of code for them. But when they manage absolutely nothing on their own, they're as good as useless. (You'd be amazed how many people survive by conning others into doing their work for them.)
No one of these points will disqualify a candidate. But given enough opportunity, the signs start adding up. Before you know it, you've got a pretty clear picture of basic competency.
Oh, and one other thing I hate: Don't lie to me. Don't tell me you've got strong experience in something when all you've done is stand near someone who used the technology. The truth will come out pretty quickly and will get you knocked off the roster post-haste. If a candidate comes up short but shows promise, I'll often recommend them for a more junior position. But not if they lie.
Getting back to my original point, if I felt really strongly about a particular candidate that no one else liked, I probably have enough credibility stored up to convince at least a trial period. But I've thankfully never been in that situation. It's usually clear if we should dump them or hire them. The worst I've ever seen was a candidate where there was a concern over the strength of a candidate's communication skills. We still hired him. :-)
You seem to overestimate how many qualified people walk through the door. The vast majority of candidates I see are completely unqualified, regardless of what their resume and degrees may say. If I see someone walk through the door who can do the job well, they're hired. Period, end of story.
In a professional environment, there is no room for age discrimination. And there's a good reason for that. Because when the rubber hits the road, your project is in full swing, and you need every hour of work you can squeeze out; you want to know that your team has your back. In those cases, the maturity and understanding age brings can be an advantage.
And for the record, there's nothing "gross" about old people. Especially these days now that older people are seeming younger and more vibrant than ever! ;-)
I was more than young enough then and I was out of work for nearly a year. Could I argue that my young age worked against me?
The market was what it was. It sucked. And top everything off, employers didn't know a good employee from a hole in the wall. Whoever lied the best seemed to get the jobs. (The few that there were.)
Start programming Wii homebrews for release 20 years later? NintendoAge will be the ultimate oxymoron! ;-)
* And I'm sure we'll all be telling the young whippersnappers about how hard it was to "depth sort a scenegraph". Why, those geriatrics "riding the beam" had nothing on our scenegraphs!
<frustration>Nnrrrrggggg!</frustration>
I'd ask if you were in the Chicago-land area, but the answer would probably break my heart. Knowing Murphy's law all too well, you're probably nearby and a perfect candidate. Right when we're in a hiring freeze and could really use more help. :-/
That's the attitude I like to see from candidates. If they can back it up with a few simple coding exercises, I'll have them hired in a heartbeat.
(Though you'd be surprised how well some people manage to hit the theoretical discussions just fine, but fail miserably when you ask them to write code that sums 2 + 2.)
As someone else who interviews a lot of candidates, I agree with the parent. Age does not play a factor at all. I'll happily recommend an 80 year old man or woman who can do the job and do it well.
I think a lot of this impression of "ageism" comes from the fact that the older generation didn't grow up with computers. As a result, there were fewer of them working in the computer field, leading to an impression that computers are a young man's game.
Of course, the younger generation is getting older. So it's getting more and more common to see older programmers. As time goes on, the age distribution will begin smoothing out and the apparent "ageism" will disappear.
Nonsense. Sun couldn't push their way through a paper bag. Java caught on because developers liked it. Sun just struggled to keep up with all the new markets that wanted to use the technology.
Sun's job is to have one of the worst marketing departments known to man. They create some really great stuff, and many of their strategic acquisitions benefit amazingly well under their umbrella. (e.g. OpenOffice, NetBeans, StorageTek, etc.)
What Sun fails miserably at is selling their products. On one hand, they give everything long, complex, and confusing names. Like "Sun Java System Directory Service", formerly "SunONE Directory Server", formerly "iPlanet Directory Server", formerly "Netscape Directory Server". Then they take this confusing pile of BS directly to executives. Now executives aren't necessarily stupid people. But if you're expecting them to wade through your piles of BS to understand what it is their buying, you've already failed. Throw in a bit of inconsistent pricing across the board to where the IT guy actually buying the stuff has no idea what price he's going to pay, and you've got a recipe for dissatisfaction.
Sun needs to learn how to market and how to sell. More to the point, they need to pay more attention to the smaller markets and stop trying to out-IBMing IBM. IBM is better at it. Try out-Delling Dell. Sun was on the right track with their "Hotter than Hell" campaign, but they gave up before it ever came to fruition!
Which is another thing that tees me off. When Sun DOES get it right, they kill it off before they give it a chance to work. Then they go back to their old ways, and probably tell themselves what a fiasco THAT marketing campaign turned out to be. :-/
It's still a one-time cost with a perpetual license. In that respect, it's a lot more comparable to a game console than a $50/yr service. Especially when you can get access to the games for far less than retail.