• (cs)
    how would you build a priority queue?

    Using a heap stored in an array?

  • No (unregistered)

    It's relevant

  • koekum (unregistered)

    Oh, and you may as well stop reading...

    the rest of the comments are just filler

  • Rachelle (unregistered)

    This comment runs like a dog, but its ok for a firsat attempt.

  • SysKoll (unregistered)

    So what you are saying is that you don't reward honesty in résumés. You just want another carefully weasel-worded, buzzword-compliant, boring résumé.

    That'd be TRWTF.

  • MattWPBS (unregistered)

    I reckon what the résumé is saying is "If you ask someone you've pissed off to write your résumé or polish it up, check it before using it."

  • (cs) in reply to SysKoll
    SysKoll:
    So what you are saying is that you don't reward honesty in résumés. You just want another carefully weasel-worded, buzzword-compliant, boring résumé.

    That'd be TRWTF.

    Well if you read as far as something that says "I don't know how to use interfaces" and more or less says "and I can't be bothered to learn them" when you use them extensively then it's a pretty good reason to reject them.

    The fact that they admit to not understanding them isn't really the problem; the flat refusal to learn them is. It's a pretty core concept of abstracted development - I'd hate to work on even a moderately sized project with someone who didn't know how to use them.

  • Michael (unregistered)

    Ha ha ha ha! I took a combined 6 years of Italian through junior high and high school. All I retained was: mi piace le tue tette!

    Captcha: tristique. A mystifying trisquit?

  • Dei (unregistered)

    You must hire someone with a resume like that, they will be very entertainig in the office.

  • Chris (unregistered) in reply to SlyEcho
    SlyEcho:
    how would you build a priority queue?

    Using a heap stored in an array?

    Hold on a minute. Shouldn't we involve a table and pictures or something?

    We're also going to need XML, Webservices, PHP, a neural net, and some assembly sprinkled in (to make it very fast).

  • (cs) in reply to hikari
    hikari:
    SysKoll:
    So what you are saying is that you don't reward honesty in résumés. You just want another carefully weasel-worded, buzzword-compliant, boring résumé.

    That'd be TRWTF.

    Well if you read as far as something that says "I don't know how to use interfaces" and more or less says "and I can't be bothered to learn them" when you use them extensively then it's a pretty good reason to reject them.

    The fact that they admit to not understanding them isn't really the problem; the flat refusal to learn them is. It's a pretty core concept of abstracted development - I'd hate to work on even a moderately sized project with someone who didn't know how to use them.

    Speaking as someone who hasn't used interfaces hardly at all since college, I have to agree. If something is required at your job, you need to pick it up.

    The guy sounded like amateur hour anyway. Resume's need to be professional, and you don't need to include lines like "This is where I taught myself how to code." If you did teach yourself, keep it TO yourself. Self-taught coders have tons of bad habits.

  • Chris (unregistered) in reply to SysKoll
    SysKoll:
    So what you are saying is that you don't reward honesty in résumés. You just want another carefully weasel-worded, buzzword-compliant, boring résumé.

    That'd be TRWTF.

    Suppose the resume said "I hate other people. They are stupid and always wrong. When will everyone just recognize my genius and worship me as their god?"

    Would you hire TopCod3r because he was being honest? Or save yourself the hideously painful ulcer?

    I didn't realized honesty was the only qualification and competence was uninteresting.

  • (cs)

    I'm still scratching my head... what does XML have to do with a queue, especially a non-persistable queue? Why would nine out of ten candidates recommend something like that?

  • St Mary's Hospital for the Eternally Sleeping (unregistered)

    Uh, the Italian language technician, would you hire him or not?

    awful:

    1: inspiring awe 2: filled with awe: deeply respectful or reverential 3: extremely disagreeable or objectionable

  • Raven Darke (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    I'm still scratching my head... what does XML have to do with a queue, especially a non-persistable queue? Why would nine out of ten candidates recommend something like that?

    Because, to quote Abraham Maslow, "When the only tool you have is a hammer, every problem begins to resemble a nail."

  • christian (unregistered)

    Could bringing in people as "fillers" put the school in danger for a civil suit?

    They're intentionally misrepresenting the possibility of an employment opportunity, which wastes the candidate's time and money.

  • foobar (unregistered)

    Point of clarification: It's generally not universities, per se, that impose the three interview minimum rule but governments. Many state jobs have the same issue: they've already decided who they want to fill the position but by law they're required to post the job for a minimum period of time and interview a minimum number of people--including the person that they've already decided upon!

  • Procedural (unregistered) in reply to christian

    Agreed; the purpose of such a law must be to insure that the competent are hired, instead of just rewarding inertia.

    This is a triple failure: 1) the hiring institution ends up with the familiar rather than the best; 2) people's time and money is wasted on known false promises (which is tantamount to fraud); 3) the people in charge not only fail to do their job, but also teach themselves and each other that such failure is acceptable; those are the people who will get promoted the next time some poor guys are asked to pay with their time and money as unpaid extras to come to an interview they have no chance of getting.

  • Frost (unregistered) in reply to SlyEcho
    SlyEcho:
    how would you build a priority queue?

    Using a heap stored in an array?

    Silly "XML" and "JavaScript" comments aside, I'd dig out one of my old textbooks, or just google for pseudocode. TRWTF is expecting any other answer. A priority queue is easy to implement as a tree.

  • (cs)
    Paul H.:
    it didn't take long for the dev manager to admit he had given all of them the answer because he was tired of us rejecting candidates.
    Adam:
    I have been asked to scan through the résumés and select the ones that have the relevant experience. Why the agencies don't do this is beyond me.
    The agencies don't do it because they don't make money unless you hire someone, and they don't care who you hire as long as it's their candidate. So the more candidates they send, the greater the chance that you'll be fooled by interview-time bullshitting and hire some idiot.

    When we were interviewing for a developer position and had rejected the third candidate from one headhunter due to them not being able to satisfactorily answer our technical questions, he took me aside and said, "Look, why don't you give me a copy of your list of questions, and I'll weed these guys out for you."

    Things that will never happen: A. Headhunter gets a list of our questions.

  • James (unregistered) in reply to foobar
    foobar:
    Point of clarification: It's generally not universities, per se, that impose the three interview minimum rule but governments. Many state jobs have the same issue: they've already decided who they want to fill the position but by law they're required to post the job for a minimum period of time and interview a minimum number of people--including the person that they've already decided upon!

    I speak from experience -- in my gov't job, I applied for a bunch of positions only to find (long after the fact) that they'd been "filled" by the incumbent. Of course, they were filled weeks before I was even interviewed.

    The problem arises because there's no way to generate genuinely objective data about someone's qualifications. If the interviewer wants Joe to beat Sally, he's going to emphasize Joe's strong points and downplay Sally's, so even if there's an official audit, there's almost no chance of showing impropriety. It's sad, but I don't know how to fix it.

  • Buddy (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    I'm still scratching my head... what does XML have to do with a queue, especially a non-persistable queue? Why would nine out of ten candidates recommend something like that?

    It has nothing to do with queues, but if the applicant doesn't understand data structures or algorithms, and maybe has experience only in XML, or it was the most recent thing they were doing, then what the heck, throw XML out there.

    I don't even bother asking algorithm questions in interviews, kids these days just copy stuff off the web. If something comes up that they have zero experience in, I just spell it out in excruciating detail. By and large, they don't have debug skills either. Without a debugger, they're hopeless.

    I remember once was tracking down a problem in JavaScript which was supposed to be validating form input. The problem report consisted of "It's not working." which was pretty good considering it had no grammatical or spelling errors. The idiot was flustered, clicking the submit button over and over and nothing was happening. I'm not sure what he was expecting by clicking submit repeatedly, maybe it would somehow fix itself, but anyway.

    I sat next to him and helped him debug. I said put an alert just after the function line, that's to confirm the function is called. Got the alert popup. Then said, okay move it after the next line and run again, that's to confirm if it executes that line. Got the alert popup. Did this maybe 10 times, moving by blocks and by lines, and he still didn't get it. By then we found the offending line which had some trivial error, likely missing a closing bracket.

    Right up until the day we let him go, he still never figured out to debug.

  • (cs) in reply to JamesQMurphy
    JamesQMurphy:
    I'm still scratching my head... what does XML have to do with a queue, especially a non-persistable queue? Why would nine out of ten candidates recommend something like that?

    It's easy to do trees in XML. I get chills though when thinking about implementing a heap algorithm with XML DOM structures.

    (Might be worth doing for the Stupid Coding Tricks column along with the T-SQL Mandelbrot)

  • Jay (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    I'm still scratching my head... what does XML have to do with a queue, especially a non-persistable queue? Why would nine out of ten candidates recommend something like that?

    Because the first rule of good programming today seems to be, "Make the solution as complicated as possible." If you can build a very complicated solution and make it work, this proves that you are a programming genius. The fact that it will waste system resources, that no one will be able to maintain it because they can't figure it out, etc, these are the kind of carping criticisms made by lesser mortals who could not have assembled this complicated structure that you have built.

  • MisterCheese (unregistered)

    Don't some dogs run quite quickly?

  • (cs)

    How do you build a priority queue?

    If I'm hiring a Java programmer I expect the candidate to say "new java.util.PriorityQueue<E>();".

    Or at least that's what I expect a Java programmer to write in a real application. I don't want the programmer to go away for two weeks and come back with a handmade priority queue. (A good part of this website's content is stories about pages of handcrafted code that should be replaced with a one-line call to a built-in function.)

    I don't absolutely expect a candidate to know what a priority queue (or a soft reference or a curried function or a JavaScript closure) is. If he / she asks "What's a priority queue?" I'd say "You put things in in any order and they come out in order of priority." The next questions I would hope the candidate asks are "Is there something in a class library that does that?" and "Does it have to be thread-safe?"

  • Jay (unregistered) in reply to James
    James:
    foobar:
    Point of clarification: It's generally not universities, per se, that impose the three interview minimum rule but governments. Many state jobs have the same issue: they've already decided who they want to fill the position but by law they're required to post the job for a minimum period of time and interview a minimum number of people--including the person that they've already decided upon!

    I speak from experience -- in my gov't job, I applied for a bunch of positions only to find (long after the fact) that they'd been "filled" by the incumbent. Of course, they were filled weeks before I was even interviewed.

    The problem arises because there's no way to generate genuinely objective data about someone's qualifications. If the interviewer wants Joe to beat Sally, he's going to emphasize Joe's strong points and downplay Sally's, so even if there's an official audit, there's almost no chance of showing impropriety. It's sad, but I don't know how to fix it.

    I used to work for a company that had a programmer who was from China. Apparently there was some law that every couple of years we had to certify to the government that we had searched for an American citizen to do this job. She was a good employee, so we had absolutely no desire to replace her with someone new. Sure, a new person might turn out to be even better, but they could also turn out to be an incompetent jerk. Better to stick with the known quantity. So every time this requirement came around, we printed a want ad in a newspaper with a circulation of about 30 that was filled with every technical requirement we could think of, and prayed that no one remotely qualified would apply. One year we did have to actually interview a couple of people, wasting our time and theirs.

  • (cs) in reply to Jay
    Jay:
    JamesQMurphy:
    I'm still scratching my head... what does XML have to do with a queue, especially a non-persistable queue? Why would nine out of ten candidates recommend something like that?

    Because the first rule of good programming today seems to be, "Make the solution as complicated as possible." If you can build a very complicated solution and make it work, this proves that you are a programming genius. The fact that it will waste system resources, that no one will be able to maintain it because they can't figure it out, etc, these are the kind of carping criticisms made by lesser mortals who could not have assembled this complicated structure that you have built.

    And our programming languages promote this (ahem Java ahem).

  • joe (unregistered) in reply to Frost

    Not sure if I'm missing something, Frost, but you're aware that a heap is a special case of a tree, which happens to have the nice property of being easy to store in an array? (left-balanced, root at element 1, child of n at 2n and 2n+1, etc.)

    Of course, the class library does it better, but good to know your data structures. I don't mean this as an insult (there's enough of that on these boards), just trying to help out.

  • D. Travis North (unregistered) in reply to Michael
    Michael:
    Ha ha ha ha! I took a combined 6 years of Italian through junior high and high school. All I retained was: mi piace le tue tette!

    Heh...I always joke that I took "Three years of Spanish I"

  • Jay (unregistered)

    And in a similar vein, when I worked for the government, there used to be a rule that we could not buy anything without getting at least three competitive bids, and then we had to fill out forms showing how we compared these bids, and if we didn't pick the one with the lowest price, justify why another was clearly better.

    These rules applied to ALL purchases. So when we needed to buy, say, a box of pencils, we had to go through the whole bureaucratic procedure. We probably spent hundreds of dollars worth of employee's time to save ten cents on a $5 purchase. Finally the government realized how ridiculous this was and passed new rules, allowing us to make small purchases -- I think the rule was under $5000 total per year or some such for our department -- without the silliness.

    A few years later a newspaper printed an "expose" about how the government was signing millions of contracts without competitive bids, they built it up into a big scandal, and we had to go back to the time and money wasting process.

  • (cs) in reply to SysKoll
    SysKoll:
    So what you are saying is that you don't reward honesty in résumés. You just want another carefully weasel-worded, buzzword-compliant, boring résumé.

    That'd be TRWTF.

    No. What he's saying is that he wants someone who is actually qualified for the job that he's applying for, and isn't just a script kiddie wanna-be no talent idiot.

    Basically, it means don't bother to send in your resume. The fact that you're trying to submit the poser's shows that you're not qualified.

  • (cs) in reply to christian
    christian:
    Could bringing in people as "fillers" put the school in danger for a civil suit?

    They're intentionally misrepresenting the possibility of an employment opportunity, which wastes the candidate's time and money.

    Can you prove that? With evidence that's admissible in a court of law? (The fact that they "acted bored" isn't admissible evidence.)

  • Fuzzypig (unregistered)

    I marched into an interview and I was greeted by Fred, Harry and John. Now I was very nervous and never caught the job titles. I got about half way through the interview, for a DBA job, I suddenly got into my stride and said "Well the biggest problem I face is that most development managers are pretty dumb, they never think of operational timescales.". Suddenly John gets up and walks out, 2 mins later the interview is called to a halt, shake hands and ushered out.

    The agency calls me and says it all went well but they don't want a call back after you said something very offensive. I'm a very careful person and I couldn't think what it was. She then said, "Well apparently you said all developers were stupid, but you said it to the development manager, he wasn't very happy."

    Me and my mouth! Cringe

  • Dirk Diggler (unregistered) in reply to Jay
    Jay:
    James:
    foobar:
    Point of clarification: It's generally not universities, per se, that impose the three interview minimum rule but governments. Many state jobs have the same issue: they've already decided who they want to fill the position but by law they're required to post the job for a minimum period of time and interview a minimum number of people--including the person that they've already decided upon!

    I speak from experience -- in my gov't job, I applied for a bunch of positions only to find (long after the fact) that they'd been "filled" by the incumbent. Of course, they were filled weeks before I was even interviewed.

    The problem arises because there's no way to generate genuinely objective data about someone's qualifications. If the interviewer wants Joe to beat Sally, he's going to emphasize Joe's strong points and downplay Sally's, so even if there's an official audit, there's almost no chance of showing impropriety. It's sad, but I don't know how to fix it.

    I used to work for a company that had a programmer who was from China. Apparently there was some law that every couple of years we had to certify to the government that we had searched for an American citizen to do this job. She was a good employee, so we had absolutely no desire to replace her with someone new. Sure, a new person might turn out to be even better, but they could also turn out to be an incompetent jerk. Better to stick with the known quantity. So every time this requirement came around, we printed a want ad in a newspaper with a circulation of about 30 that was filled with every technical requirement we could think of, and prayed that no one remotely qualified would apply. One year we did have to actually interview a couple of people, wasting our time and theirs.

    It would be a shame if you had to hire an American citizen and pay a living wage.

  • (cs) in reply to Buddy
    Buddy:
    By and large, they don't have debug skills either. Without a debugger, they're hopeless.

    I remember once was tracking down a problem in JavaScript which was supposed to be validating form input. The problem report consisted of "It's not working." which was pretty good considering it had no grammatical or spelling errors. The idiot was flustered, clicking the submit button over and over and nothing was happening. I'm not sure what he was expecting by clicking submit repeatedly, maybe it would somehow fix itself, but anyway.

    I sat next to him and helped him debug. I said put an alert just after the function line, that's to confirm the function is called. Got the alert popup. Then said, okay move it after the next line and run again, that's to confirm if it executes that line. Got the alert popup. Did this maybe 10 times, moving by blocks and by lines, and he still didn't get it. By then we found the offending line which had some trivial error, likely missing a closing bracket.

    Right up until the day we let him go, he still never figured out to debug.

    So your "debug skills" essentially amount to a bunch of print statements? People are failing to sprinkle alert()s throughout their code and you're getting on their case for not knowing how to properly debug? Uh...

    Don't get me wrong, using print statements to "step" through code has uses, but if the code only has a simple typo, there are all manner of tools you can use as a first pass which can show you such errors in much less time that it takes to pop up an alert after each and every line of code. And then of course there are actual javascript debuggers that will let you set breakpoints, etc...

  • (cs) in reply to Buddy
    Buddy:
    I don't even bother asking algorithm questions in interviews, kids these days just copy stuff off the web. If something comes up that they have zero experience in, I just spell it out in excruciating detail. By and large, they don't have debug skills either. Without a debugger, they're hopeless.
    At 55 years old, I don't qualify as a kid. I started programming for fun in 1981 on a Color Computer, got a CS degree in 1993, and have been writing software for a living since 1995, so maybe I'm not too much of a kid in that respect, either.

    That said: I do quite a lot of "copying stuff off the web". Beyond the abstract stuff that applies no matter what language you use, little of what they taught in my college classes is applicable to my present day work.

    What's that you say? "Study to keep abreast of changes?" Oh, I do. I'm glancing up at the bookshelf over my desk as I write this, and here's what I see:

    Regular Expressions with .Net C# 3.0 in a Nutshell .Net 2.0 Generics Pro LINQ Language Integrated Query in C# 2008 ASP.Net AJAX in Action SQL Server 2005 Reporting Services Learning WCF

    Regular Expressions may have been around for a while; the rest are new. And while I don't devote every spare minute of my free time to studying, I have worked through all of those books and now use what I learned from them.

    Still, I reach for the internet more often than I reach for a reference book. Why? Because the information is there. My job is to create software by the best and most effective means possible, not to always draw on a store of memorized knowledge.

    For developers nowadays, knowing how to find information is about as important as knowing how to debug.

  • Jo Bob (unregistered) in reply to wee
    wee:
    Don't get me wrong, using print statements to "step" through code has uses, but if the code only has a simple typo, there are all manner of tools you can use as a first pass which can show you such errors in much less time that it takes to pop up an alert after each and every line of code. And then of course there are actual javascript debuggers that will let you set breakpoints, etc...

    How in the HELL is someone going to understand what an automated tool is doing, when they can't even learn to do the simple manual equivalent?

  • (cs) in reply to wee
    wee:
    So your "debug skills" essentially amount to a bunch of print statements? People are failing to sprinkle alert()s throughout their code and you're getting on their case for not knowing how to properly debug? Uh...

    I noticed this too, but you beat me to it.

    That said, sometimes that is the best (or only) way to debug. I'm working on a real-time system that runs under VxWorks, on three different processor cards, each running several dozen different processes, with all manner of TCP clients/servers, and messages all over the place. You can't possibly attach a debugger to this thing, and setting breakpoints or tracing through one process step-by-step would break the real-time nature of the system. Sometimes I do have to stoop to statements like

    cout << "Got here successfully, return value = " << value << endl;

    in order to trace what's going on. Not fun. Of course we use smaller scale unit tests wherever possible, but some things require the entire beast to be up and running.

  • danielc (unregistered)
    Each candidate gave a perfect, clear, correct answer... It didn't take long for the dev manager to admit he had given all of them the answer because he was tired of us rejecting candidates.

    I've heard of recruiters doing the same thing. They debrief the candidates after an interview and then prep future candidates with frequently asked questions. So, beware...

  • Andy (unregistered)

    Jim, Have you ever considered not intentionally subverting the system, and actually trying to determine the best candidate for the job?

    In the long term that might work better than interviewing three random suckers and then just hiring the boss's kid.

  • Franz Kafka (unregistered) in reply to Jay
    Jay:
    I used to work for a company that had a programmer who was from China. Apparently there was some law that every couple of years we had to certify to the government that we had searched for an American citizen to do this job. She was a good employee, so we had absolutely no desire to replace her with someone new. Sure, a new person might turn out to be even better, but they could also turn out to be an incompetent jerk. Better to stick with the known quantity. So every time this requirement came around, we printed a want ad in a newspaper with a circulation of about 30 that was filled with every technical requirement we could think of, and prayed that no one remotely qualified would apply. One year we did have to actually interview a couple of people, wasting our time and theirs.

    If your coworker is game, there's a straightforward way around this requirement - get her citizenship :P

  • Montoya (unregistered)

    TRWTF in story 1 is the system; someone thought that requiring 3 interviews would prevent favoritism and ensure fair employment practices. Obvious fail.

  • Buddy (unregistered) in reply to wee
    wee:

    So your "debug skills" essentially amount to a bunch of print statements? People are failing to sprinkle alert()s throughout their code and you're getting on their case for not knowing how to properly debug? Uh...

    Don't get me wrong, using print statements to "step" through code has uses, but if the code only has a simple typo, there are all manner of tools you can use as a first pass which can show you such errors in much less time that it takes to pop up an alert after each and every line of code. And then of course there are actual javascript debuggers that will let you set breakpoints, etc...

    I can guarantee, this was not a guy you'd want to show advanced tools to, dear God, no. Stick to alert for this guy.

  • (cs) in reply to Fuzzypig
    Fuzzypig:
    The agency calls me and says it all went well but they don't want a call back after you said something very offensive. I'm a very careful person and I couldn't think what it was. She then said, "Well apparently you said all developers were stupid, but you said it to the development manager, he wasn't very happy."

    Me and my mouth! Cringe

    Heh. I have a similar story, only (thankfully) a happier ending. I was asked how I liked round-trip engineering with a particular UML design tool. Turns out I had used the tool in university, and even TA'd a course using it not long before. Frankly, I wasn't too impressed with it.

    I told them I'd had experience with that particular tool and felt that was an awful lot of overhead and not particularly conducive to the real-world, where you are constantly tweaking your design to arrive at the final solution. A good tool for some things, I concluded, but shouldn't be relied on too much, especially for anything larger than a school assignment, and trying to stick to round-trip engineering got in the way too much when doing the actual software development. The interviewers exchanged glances and were quiet for a moment when I'd finished. Then they told me that the department was transitioning to using this particular tool for all of their software design and documentation.

    Oops?

    It was revealed to me much later, after I got the job, that my answer to that question was essentially what sealed the deal. I had realistic expectations, knew the tool but knew its limitations, when to use it and when not to. Other candidates apparently either adopted a "my way or the highway" approach (let me hack it all together, who needs tools?) or a too-theoretical expectation (use the tool for everything).

  • (cs) in reply to Raven Darke
    Raven Darke:
    JamesQMurphy:
    I'm still scratching my head... what does XML have to do with a queue, especially a non-persistable queue? Why would nine out of ten candidates recommend something like that?

    Because, to quote Abraham Maslow, "When the only tool you have is a hammer, every problem begins to resemble a nail."

    Only since they know XML (or claim to) they must have a few more tools in the tool chest (can't use xml whilst being completely ignorant to other techniques and tools).

    More like: They have a meagre selection of lowgrade tools (dollar store phillips screwdrivers that strip screws and the likes) but choose to always pull out their shiney hammer.

    That reminds me of a tv show called, "Canada's worst handyman." Funnyish show (counterpart to Canada's worst driver). In one episode the contestants were tasked with patching a small portion of drywall (a square less than a square foot). One contestant for some reason decided his cordless drill wasn't the appropriate tool, and a handheld screwdriver was too inefficient soooo (you probably guessed it already).. he used a hammer to nail in drywall screws (or rather attempt to hammer in). He was big into the brute force attempt at solving problems.

  • Addison (unregistered)

    Wow the American government sounds retarded. The worst we have it here in Canada is the fact that the government I work for is bilingual, so everyone who's hired full time (unless they just work off in a corner) has to know both English and French. Since almost no English person ever bothers to learn French (unless they want a government job :P) 60% of my co-workers are French even though the city I live in is only about 10% French.

    Oh and if they make a job posting and say "needs 3 years of experience in x" and someone has 2 and a half they are automatically turned down without anyone relevant ever looking at the resume.

  • Addison (unregistered) in reply to dubbreak
    dubbreak:
    That reminds me of a tv show called, "Canada's worst handyman." Funnyish show (counterpart to Canada's worst driver). In one episode the contestants were tasked with patching a small portion of drywall (a square less than a square foot). One contestant for some reason decided his cordless drill wasn't the appropriate tool, and a handheld screwdriver was too inefficient soooo (you probably guessed it already).. he used a hammer to nail in drywall screws (or rather attempt to hammer in). He was big into the brute force attempt at solving problems.

    I love that show!

  • (cs) in reply to dubbreak
    dubbreak:
    One contestant for some reason decided his cordless drill wasn't the appropriate tool, and a handheld screwdriver was too inefficient soooo (you probably guessed it already).. he used a hammer to nail in drywall screws (or rather attempt to hammer in). He was big into the brute force attempt at solving problems.
    I worked with a guy like that. When he routed the edge of a board, he would grasp the router, set it against the board, and then start furiously shoving it down arms' length of the board, then dragging it back for another shove, as if it were his forceful actions that were shaping the wood rather than the motor spinning the bit.

    Sadly, we were construction contractors at the time.

  • Jay Jay (unregistered) in reply to WhiskeyJack

    Unfortunately, I had something like this happen to me except that I already worked for the company. A member of upper management came to me and specifically asked me to evaluate a UML tool with respect to the code it generated. Seeing as how it just generated function stubs, I told him that, according to the requirements I had been given, it was a waste of time. Useful for spec'ing out a project, but absolute crap as far as generating code. I gave it a failing grade, once again based upon what had been requested of me.

    Turns out that he had preemptively purchased a corporate license and just needed a positive recommendation for his boss (a member of VERY high management) to sign off on it. My failing grade made it (and him) look bad.

    Just scant months later, the same guy was in charge of my division; I didn't see another raise in the year and a half I managed to survive the constant stream of crap directed my way before leaving for MUCH greener pastures.

Leave a comment on “The Mandatory Three, The Easy Road to Success, and Relevant Inexperience”

Log In or post as a guest

Replying to comment #:

« Return to Article