Funniest IT Related Boasts You've Heard? 490
Karma asks: "The other day I saw a Slashdot comment which read, '[Projects] don't start getting interesting until you are dealing with Staff Years to develop them. Anything under that and you can actually keep the full design in your head'. An immodest boast, but not too funny. This made me wonder, in the macho worlds of IT and developers, what are the funniest and silliest boasts or bragging claims you've made, or heard? Tell us how they came back to haunt the overconfident."
"Expert Programmer" (Score:3, Insightful)
1 out of 15 pass. It's pathetic.
Can you pass this test? Post a link to your resume, we are hiring in the East Bay, California. C#.
Re:"Expert Programmer" (Score:5, Insightful)
Yes. But:
> C#.
You can't pay me enough.
Re:Boast? (Score:5, Insightful)
Besides, it's clear you don't have a three digit UID. Bagdad Bob says so.
--
Evan
Re:"Expert Programmer" (Score:2, Insightful)
Re:"Expert Programmer" (Score:5, Insightful)
For many of the people I know, going to college for CS is about 2 things:
1) Learning basic programmatic workflow and practices
2) Being able to show the piece of paper
Unfortunately for alot of people hiring, #2 is most important. For employers who I have -respected- #1 is the most important and they can recognize that with #1 and a creative thinking brain that any coder can quickly pick up new languages and technologies.
And people who excel at creative programmatic thinking often are the types that remember concepts, not trivia (the idea of testing intelligence and not memory). Expecting a person to remember, in a high stress situation, the terminology you learned in school tests the trivia.
Forgetting terminology (versus forgetting -theory-) doesn't mean that they cheated in school, it only means they remembered stuff differently. How many of us remember more than one or two geometry theorems even a few months after passing our last geometry test?
It is sad, but there are a number of elitists out there who use tests like the one you are so proud of. Do you give any type of explanation if the interview-ee says "what do you mean by that?" or do you assume that they have failed at that point? If you assume failure at that point you are the problem, not them.
If on the other hand you give a brief example and wait to see if they catch on, then you should be able to see who is truly good by how quickly they can code and/or how efficient that code is.
A person doesn't need to know the terminology -before- they join a group to be useful to that group. They need to be able to quickly put your group's terminology into a working context and start expanding on it. Otherwise all you are doing is a form of secret handshake.
This is one of the reasons that the original IQ tests were considered to be biased. They measured vocabulary knowledge as a prerequisite to concepts. Newer tests try to be language independent, recognizing that cognitive ability is more important.
Or in shorter terms, I agree with the grandparent of this post, you made the kind of boast that the submitter was talking about.
Re:"Expert Programmer" (Score:2, Insightful)
{
item->next = head;
*head = item;
}
Or something like that. Adding the the head of a list is always quicker than iterating to the end
Re:"Expert Programmer" (Score:2, Insightful)
I've done it before of course, and it would take me 10 minutes to come up to speed on the data structure then slightly longer to bodge it together in language of your choice.
However being a net admin I rarely have to cobble together any more important than some single run through perl scripts and occasionally debug someone elses code, I rarely have to code anything substantial from scratch. So I'm a bit out of practice!
I think whats more important here is the fact you're 15 and have taught yourself linked lists. You may not be the worlds best programmer right now (although that will certainly come with time and experience by the sounds of it) but you have the right initiative to pick something up by yourself and learn it. I don't know how long it took you to figure it out, but I get the impression probably not long. I'd far rather work with or for someone who was quick at picking up technologies and displayed some kind of iniative than someone who was rigidly stuck in one line of thinking.
Stick at it, you're on the right track and in a few years time with some job experience under your belt you'll pick up a load of stuff...even if you don't realise it!
Kev
Re:When I was in college.... (Score:1, Insightful)
Re:It'll be done on time! (Score:3, Insightful)
Re:My favorite Resume blunder... (Score:5, Insightful)
Since then I've realized that at some companies, resumes really ARE expected to be fiction, and they select the fiction they enjoy the most.
You should get (Score: 6, Insightful) for that comment as today, November 2, 2004, millions of American voters go to the polls and select a candidate for the topmost job in the land based on exactly that same criterion.
Re:Heard this one the other day... (Score:3, Insightful)
Re:Why are you using a linked list? (Score:3, Insightful)
Why would anyone ever use a linked list?
You want a specific example? Okay, the kernel process queues. These are linked lists that store information about which process is waiting on what: there's a queue for processes that are waiting for a CPU to become free, a queue for processes that are waiting for activity on a filehandle (for example, all the preforked web servers waiting on the accepting filehandle), etc.
They cause memory fragmentation
You can use a free list of processes, or have the processes in an array and just link them onto the queues as needed without pulling them from the array.
screw up your cache
I have no idea how you come to that conclusion
add two pointers of overhead per item (quite possibly in a different memory location from the data)
The link field is in the process data structure, so it's one pointer per item, and always in the same location as the data.
are slow to access thanks to all that dereferencing
Ah, that's a big deal there. For example, the run queue is a sorted list. You almost always pull elements off from the head. Moreover, you put elements on in the middle, sorting on their PRI.
If the run queue were implemented as an array, you'd have to move stuff on every insert. If you're smart, you're putting the soonest-run process at the end, so you don't have to move everything when you delete. But now you're also having to track the length so you can find the last one, instead of just having a pointer straight to the element you're about to access (ie, the head).
Also, you can move processes between queues quickly. When a SYN comes into your HTTP socket, you can move one of the preforked processes from the accept queue to the run queue by changing a few pointers, instead of having to do laborious copies of array chunks.
In general, arrays are good for indexed access, and changes at the end. But they suck at changes in the middle. They also don't let you walk a list as it's changing, at least, not as easily as a linked list does. Also, linked lists let you very easily move items between multiple lists. There's lots of reasons to go one way or another. You implied that you've read Knuth; I find it surprising that you didn't pick up that there are different structures for different needs.
This is just one example; there's many others. Don't make sweeping assumptions about what the right data structure is in all cases. If the interviewer tells you to write a linked list, then write a linked list; don't argue that no-one would ever use a linked list.
Re:COOL! (Score:4, Insightful)
meep! meep!
Re:COOL! (Score:5, Insightful)
-davidu