• Contractor Khan (unregistered)

    Min is the reason why you should keep files on people that applied, as you are allowed to, for 6 months, with NOTES on what they admitted lying about.

    VB isn't that hard I suppose, what's the worst that could happen.

    VB life support machines. Shudder.

  • CRNewsom (unregistered) in reply to Contractor Khan
    Contractor Khan:
    VB life support machines. *Shudder*.

    You haven't heard of them? The Kevorkian Institute uses them almost exclusively.

  • (cs) in reply to Contractor Khan
    Contractor Khan:
    Min is the reason why you should keep files on people that applied, as you are allowed to, for 6 months, with NOTES on what they admitted lying about.

    VB isn't that hard I suppose, what's the worst that could happen.

    VB life support machines. Shudder.

    Well, with VB6 at least you can't put life saving critical code in a finally block.

  • (cs) in reply to Contractor Khan
    Contractor Khan:
    VB life support machines. *Shudder*.

    Is that a) life support machines developed in VB, or b) Min, the "machine" used to keep a VB application alive?

  • techie (unregistered)

    Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?

  • unther (unregistered)

    A similar thing happened here. We had a doctor of mathematics and computer science applying here telling us all about his skills in ... well, almost everything. In short, he presented himself as a programming god humbling all of us little grunts.

    In reality, he had no qualifications. He wrote his thesis on formal languages, which is probably the most theoretical part of computer sciences. He had no experience in programming or in designing business applications. He failed in writing a one-line-.NET-program (create an account in a CRM-system with just a title) after ONE week. He couldn't even read an SDK. However, HE was VERY surprised when he found out that we "simple grunts" could read UML without being a doctor of computer science.

    When we found out that he worked as a medium and clairvoyant on some 0900-number-company (stumbled over it when we googled his name), his days were counted...maybe this guy and his story would qualify for an entry here...

    Anyway, this scheme seems to work more often than you think.

  • (cs) in reply to techie
    techie:
    Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?

    Does it matter? From my perspective, lying to a potential employer is a show-stopper, hands down.

  • JonC (unregistered)

    Surely TRWTF is giving someone who has 'Oracle T-SQL' and 'Microsoft Solaris' on their CV the benefit of the doubt.

    That would have been setting alarm bells ringing immediately for me.

  • mafro (unregistered) in reply to techie
    techie:
    Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?

    Blind assumption is safe in this case I believe.. Perhaps they were looking for someone with experience programming?

    That's what I tend to do...

    CAPTCHA: ingenium (!)

  • techie (unregistered) in reply to Markp
    Markp:
    Does it matter? From my perspective, lying to a potential employer is a show-stopper, hands down.

    Well, yes, since she was already an employee in the company apparently.

  • Dave (unregistered) in reply to Markp
    Markp:
    From my perspective, lying to a potential employer is a show-stopper, hands down.

    From my perspective, getting caught lying to a potential employer is a show-stopper, hands down.

  • (cs) in reply to techie
    techie:
    Markp:
    Does it matter? From my perspective, lying to a potential employer is a show-stopper, hands down.

    Well, yes, since she was already an employee in the company apparently.

    Read the article again. It seems to be saying she received the position in the other group after being denied by Alex's group.

  • Waffle (unregistered) in reply to Markp
    Markp:
    techie:
    Markp:
    Does it matter? From my perspective, lying to a potential employer is a show-stopper, hands down.

    Well, yes, since she was already an employee in the company apparently.

    Read the article again. It seems to be saying she received the position in the other group after being denied by Alex's group.

    Yeah, lying finally got her a job.

  • morry (unregistered)

    never put critical business transaction code in finally blocks.

    I put all my absolutely critical business transaction code on a piece of paper, photograph it on a wooden table, then post that picture next to my computer. that way when the power goes out, I can execute the code myself.

    where are you supposed to put the code? Magic fairy blocks?

  • (cs)

    package test;

    public class minBean {

    private String min = "Brillant";

    public String getMin() { return min; } }

  • KTC (unregistered) in reply to techie
    techie:
    Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?
    I think we can safely assume Min didn't know how to program in any language she said she can after Alex from her answers found out she "had never actually used Visual Basic. Or C++. Or, really, any other programming language". Or maybe the part where she freely answered affirmative to the question which stated she had never used any of "these skills and technologies".
  • (cs)

    I tend to use "finally" as an attempt to gracefully fail after all other avenues have proven fruitless; I always sort of thought that was the point of finally...To clean up after failed Catches. I tend not to use finally though, so I'm not the best person to opine.

    I guess, thinking about it, you could use it as a sort of general cleanup...Seems...I don't know...Odd.

  • SomeCoder (unregistered) in reply to morry
    morry:
    never put critical business transaction code in finally blocks.

    I put all my absolutely critical business transaction code on a piece of paper, photograph it on a wooden table, then post that picture next to my computer. that way when the power goes out, I can execute the code myself.

    where are you supposed to put the code? Magic fairy blocks?

    That's what I was wondering. If you want a guarantee that your code will be executed... well I guess there are no guarantees. Don't use computers to execute business critical code?

    I guess my point is, if the computer is suddenly shut off, it doesn't matter where your put your code*, finally or no. It's not going to be run if the machine is off.

    *Note: I know it matters where you put business critical in an app but my point is, Alex was being a tiny bit pedantic in my opinion.

  • (cs) in reply to JonC
    JonC:
    Surely TRWTF is giving someone who has 'Oracle T-SQL' and 'Microsoft Solaris' on their CV the benefit of the doubt.

    That would have been setting alarm bells ringing immediately for me.

    That reminds me of one question I got in my previous job:

    "Which version of Solaris do I need to run Linux?"

    The only blooper I might pass, however, might be something like "Microsoft Sybase" or "Sybase SQL Server", as they are practically the same thing. Except Sybase actually runs in non-MS platforms!

  • (cs) in reply to techie
    techie:
    Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?

    Well, like others said, catching her lying in the interview pretty much precludes anything else.

    But I'd guess coupling that with glaring errors like 'Microsoft Solaris' on her resume might be a worthy indicator of her programming ability

  • (cs)

    Shortly before I worked a my current company, we hired a network engineer named Bob. He had a bunch of certifications and came recommended, from where I'm not sure. During the interview, my boss described the work environment (NT4) and expectations. The boss wasn't going to insult his intelligence by asking silly technical questions.

    Bob is the reason now we ask a lot of technical questions and never rely on anything the candidate thinks about their own level of knowledge.

    Bob's first day or so, he was asked to install Windows NT on a server and configure IIS.

    Bob (aside to new co-worker) "Does he actually expect me to do that?"

    Bob was offered a new position as a jr level guy, at a much reduced pay rate. Luckily, he turned us down.

  • techie (unregistered) in reply to KTC
    KTC:
    techie:
    Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?
    I think we can safely assume Min didn't know how to program in any language she said she can after Alex from her answers found out she "had never actually used Visual Basic. Or C++. Or, really, any other programming language". Or maybe the part where she freely answered affirmative to the question which stated she had never used any of "these skills and technologies".

    I still don't think that's safe to assume. It could be that she's never used those skills and technologies in a professional capacity. Especially if there was a language barrier or anything. A WTF response to a valid programming question would have made this a great addition to the WTF files. Give me a smart person who understands logic, and I can teach them how to program. Give me a dumbass who has a CS degree, and they'll appear on this site eventually.

  • (cs) in reply to SomeCoder
    SomeCoder:
    morry:
    never put critical business transaction code in finally blocks.

    I put all my absolutely critical business transaction code on a piece of paper, photograph it on a wooden table, then post that picture next to my computer. that way when the power goes out, I can execute the code myself.

    where are you supposed to put the code? Magic fairy blocks?

    That's what I was wondering. If you want a guarantee that your code will be executed... well I guess there are no guarantees. Don't use computers to execute business critical code?

    I guess my point is, if the computer is suddenly shut off, it doesn't matter where your put your code*, finally or no. It's not going to be run if the machine is off.

    *Note: I know it matters where you put business critical in an app but my point is, Alex was being a tiny bit pedantic in my opinion.

    The secret is not to guarantee that your code will be completely executed, it is to guarantee that it will not be partially executed. Having a program fail completely is no problem at all...No harm, no foul, just run it again. Having it partially fail will screw up your whole week; that's why he mentioned database transactions.

    Using a Finally like they used it would be fine if all the Finally did was commit the transaction or something...Trusting it to break new ground is a recipe for the sort of subtle failure that makes you tear your hair out.

  • (cs) in reply to jefg

    package test;

    public class Min { private String min = "Brillant";

    public String getResume() { return "I know VB"; }

    public String getJob() { try { lieAboutVB(""); } catch (GotCaughtException e) { getJobSomewhereElse(); } finally { } return "finally, yay it worked!"; } }

  • (cs) in reply to techie
    techie:
    Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?

    I'm sure she had some basic programming knowledge, but we really needed someone who had experience with the "keywords" she listed. It was a big, boring company, so 30% of the job was navigating the bastardisation of the specific technology stack, 69.5% was communication/bureaucracy, .5% was actual programming.

  • Brandon (unregistered)

    if(computer.IsOver || computer.IsAboutToBeOver) { //execute critical business code }

    I win.

  • anon (unregistered) in reply to Satanicpuppy

    I almost never use finally, if you want to do stuff after a try-catch block then you don't really need the finally, these two blocks are almost always the same:

    try { result = a/b } catch (exception) { //handle divide by 0 } finally { return result }

    try { result = a/b } catch (exception) { //handle divide by 0 } return result

    also, any "mission critical" tasks would fare the same, and should have been recorded in a log system like a database uses instead of being 100% reliant on the code always executing

  • (cs) in reply to SomeCoder
    SomeCoder:
    morry:
    never put critical business transaction code in finally blocks.

    I put all my absolutely critical business transaction code on a piece of paper, photograph it on a wooden table, then post that picture next to my computer. that way when the power goes out, I can execute the code myself.

    where are you supposed to put the code? Magic fairy blocks?

    That's what I was wondering. If you want a guarantee that your code will be executed... well I guess there are no guarantees. Don't use computers to execute business critical code?

    I guess my point is, if the computer is suddenly shut off, it doesn't matter where your put your code*, finally or no. It's not going to be run if the machine is off.

    *Note: I know it matters where you put business critical in an app but my point is, Alex was being a tiny bit pedantic in my opinion.

    Same I thought. Finally blocks always execute, the only way they wouldn't execute would be in situations where no code will get executed, like kill -9'ing the process, or on power down. Anyway, any critical transactions should be inside a transaction block themselves, so these two cases would cause an auto-rollback anyway!

    Note: finally blocks will run even if the exception thrown is an unchecked one (i.e. RuntimeException).

  • techie (unregistered) in reply to Alex Papadimoulis
    Alex Papadimoulis:
    I'm sure she had some basic programming knowledge, but we really needed someone who had experience with the "keywords" she listed. It was a big, boring company, so 30% of the job was navigating the bastardisation of the specific technology stack, 69.5% was communication/bureaucracy, .5% was actual programming.

    Fair enough. I basically got the job because I was eminently trainable, and the job had the same breakdown :)

  • (cs)

    We have a couple places in our Java legacy code that use the following paradigm (simplified for readability, of course):

    public static int tester(String s) throws Exception
    {
      int retval = 0;
      try
        {
          retval = Integer.parseInt(s);
        }
      catch(Exception ex)
        {
          throw ex;
        }
      finally
        {
          return retval;
        }
    
    }
    

    The exception gets eaten and the method happily returns something, pretending there's no problem at all. Fixing it is on our list of things to do. Nothing's gone haywire ... yet.

  • anon (unregistered) in reply to danixdefcon5

    actually, you could return to jump over the finally, code still executes, just not the finally.

  • zoips (unregistered) in reply to anon
    anon:
    I almost never use finally, if you want to do stuff after a try-catch block then you don't really need the finally, these two blocks are almost always the same:

    try { result = a/b } catch (exception) { //handle divide by 0 } finally { return result }

    try { result = a/b } catch (exception) { //handle divide by 0 } return result

    also, any "mission critical" tasks would fare the same, and should have been recorded in a log system like a database uses instead of being 100% reliant on the code always executing

    finally is intended for (an attempt at) graceful cleanup when you plan to propagate the exception up the stack. At least that's always been my impression.

  • Anonymouse (unregistered) in reply to anon
    anon:
    I almost never use finally, if you want to do stuff after a try-catch block then you don't really need the finally, these two blocks are almost always the same:

    I believe the difference is, the finally block is in scope to access variables declared within the try block, while code added after, but not in a finally block, is out of scope.

    Of course that depends entirely on the language and it's scoping semantics so in some cases, there may be no difference. And also I suppose where the variables are declared.

  • anon (unregistered) in reply to zoips
    zoips:
    anon:
    I almost never use finally, if you want to do stuff after a try-catch block then you don't really need the finally, these two blocks are almost always the same:

    try { result = a/b } catch (exception) { //handle divide by 0 } finally { return result }

    try { result = a/b } catch (exception) { //handle divide by 0 } return result

    also, any "mission critical" tasks would fare the same, and should have been recorded in a log system like a database uses instead of being 100% reliant on the code always executing

    finally is intended for (an attempt at) graceful cleanup when you plan to propagate the exception up the stack. At least that's always been my impression.

    I'll agree with you there. but I don't like exceptions to go outside of the function it happened in, I tend to prefer using if statements to validate input and take care of any problems that arise. if I have to interface with something that throws exceptions (for example most pre-built DB handlers only use that) I use try-catch as a replacement for if. if this code doesn't work, handle all the errors and cleanup gracefully and return a standard response of what happened instead of complaining to the routine that requested the function to run.

  • The Land of Cleve (unregistered)

    Any idea where Min is today? She sounds ... familiar.

  • Brian (unregistered)

    Wow, alot of people don't understand try/catch/finally here. It makes no sense to put a return statement in your finally block. If you think it does then you miss the point of finally.

  • Andrew (unregistered) in reply to unther
    unther:
    A similar thing happened here. We had a doctor of mathematics and computer science applying here telling us all about his skills in ... well, almost everything. In short, he presented himself as a programming god humbling all of us little grunts.

    ...this scheme seems to work more often than you think.

    I don't think this person and Min are the same at all. This guy is far worse.

    He had a doctor of mathematics and computer science. She did not claim any advanced degree. Min's interviewer was likely more careful about skills. The other interviewer probably just assumed he knew how to program.

    Min admitted she knew no programming after she was caught. The good doctor told a lecture full of lies.

    Padding an entry-level resume is not as bad as using a Ph.D. to break into a field!

  • (cs) in reply to Contractor Khan

    I'd even suggest Min is the reason you stop looking at requirements (unless they are absolutely required) and start looking at abilities. Too many employers would take a fresh graduate that lists 15 languages you want them to know on their resume they "learned" in some school at god-knows-where over someone who has been in IT for a decade, but only has 10 of the 15 qualifications you want. And I'm just talking about offering them an interview. Once you offer the interview, it becomes obvious who is best for the job.

    Guess who is going to figure out how to get the job done faster and with fewer errors... And guess who is going to be far more useful to your company when hard times come.

  • Jabmist (unregistered)

    stack overflows will STILL call the finally

    package test; public class miscTest { public int loop(int x){ return (loop(x+1)); } public static void main(String[] args) { try{ int x=0;int y=5; miscTest test = new miscTest(); test.loop(1); double t = y/x;

    	}catch(Exception e){
    		System.out.println("catch start");
    		int x=0;int y=5;
    		double t = y/x;
    		System.out.println("catch end");
    	}finally{
    		System.out.println("finally");
    	}
    }
    

    }

    finally java.lang.StackOverflowError at test.miscTest.loop(miscTest.java:8) at test.miscTest.loop(miscTest.java:8) at test.miscTest.loop(miscTest.java:8)

  • Patrick (unregistered) in reply to JonC
    JonC:
    Surely TRWTF is giving someone who has 'Oracle T-SQL' and 'Microsoft Solaris' on their CV the benefit of the doubt.

    That would have been setting alarm bells ringing immediately for me.

    Those aren't even typos. They're blatant errors which are mix-mash of various technical terms. I could understand misspelling "DCOM" as "DCMO". And yes, your HR department needs to be told that not only did she lie on her resume, but she said she lied to the interviewer.

  • Steve (unregistered)

    I had one like "Min".

    I scratched the person, call him "Max" just for the sake of inventing a name, off the list after a brief phone interview on some fundamental technical grounds as well as a sneaking feeling that there was something wrong.

    A few months later, I was asked to take a look at some resumes for another position and there, again, was "Max". I mentioned my misgivings to the manager involved and dismissed the whole incident from my thoughts.

    A week or so later, there was "Max", settling into a workstation, having been hired over my misgivings. I told myself, "okay, I'll give 'Max' the benefit of the doubt and besides, 'Max' won't be working on my project, so it's someone else's problem."

    Except that about a month or so after that, for reasons which remain opaque to me, "Max" was assigned to my project as a Java programmer. "Max" claimed to be a database person and whined about having to program in Java, got into conflicts with one of the other programmers, and never actually completed anything useful -- I don't think I even got a Paula "brillant" from "Max".

    "Max" then wondered why his performance reviews were mediocre and complained of that his talents weren't being recognized.

    "Max" eventually got reassigned to another group which, to the best of my knowledge, has never produced anything beyond interiminable meetings and hangs on by attaching itself remora-like to other successful projects. Everyone seems happy.

  • (cs) in reply to Satanicpuppy
    morry:
    where are you supposed to put the code? Magic fairy blocks?

    This answers it pretty well...

    Satanicpuppy:
    The secret is not to guarantee that your code will be completely executed, it is to guarantee that it will not be partially executed. Having a program fail completely is no problem at all...No harm, no foul, just run it again. Having it partially fail will screw up your whole week; that's why he mentioned database transactions.

    Using a Finally like they used it would be fine if all the Finally did was commit the transaction or something...Trusting it to break new ground is a recipe for the sort of subtle failure that makes you tear your hair out.

    ... but to expand on that, from a code perspective, if you're lucky enough to have an underlying transactional system, it's like this:

    try { StartTransaction(); DoStuff(); } catch { RollbackTransaction(); } finally { CommitIfNotRolledBack(); }

    The underlying transaction system will auto-rollback if it never gets committed or rolledback. However, the real problem occurrs when someone doesn't have an underlying transactional system.

    try { ProcessAllRecords(); } catch //(or a conditional finally) { UndoAllProcessing();
    }

    If ProcessRecords() is not designed to be re-entrant, then you're pretty much screwed if an error occurs and UndoAllProcessing() never is run.

    To make matters worse, these problems compound themselves, so the second time you run the program, the un-catchable exception occurs again and further corrupts the underlying data.

    Finally should be used for things like memory cleanup so you don't end up with leaks, etc. If the program never hits that kind of finally block, it's OK, since the whole thing has crashed and burned already, and memory leaks are the least of your worries.

  • (cs)

    put life saving critical code in a finally block...

    Life saving? No. Clean up? Yes:

    class Doctor {
      public Doctor() {
         goToMedicalSchool();
         doInternship();
      }
    
      public void treatPatient(Patient patient) {
        try {
            diagnose(patient);
            treat(patient);
            patient.setStatus(Better);
        } catch (TreatmentFailed tf) (
            callPriest(patient);
            patient.setStatus(Deceased);
            // cheap joke re: patent.setStatus(FileNotFound);
        } finally {
          discharge(patient); // to family or mortician
        }
      }
    }
    
  • diaphanein (unregistered) in reply to SomeCoder
    SomeCoder:
    morry:
    never put critical business transaction code in finally blocks.

    I put all my absolutely critical business transaction code on a piece of paper, photograph it on a wooden table, then post that picture next to my computer. that way when the power goes out, I can execute the code myself.

    where are you supposed to put the code? Magic fairy blocks?

    That's what I was wondering. If you want a guarantee that your code will be executed... well I guess there are no guarantees. Don't use computers to execute business critical code?

    I guess my point is, if the computer is suddenly shut off, it doesn't matter where your put your code*, finally or no. It's not going to be run if the machine is off.

    *Note: I know it matters where you put business critical in an app but my point is, Alex was being a tiny bit pedantic in my opinion.

    The point was that the assertion that code in a finally block is always executed is wrong. Period.

    For instance, in C#, here's an example of a finally block that'll never execute, even without pulling the plug from your computer. The only output will be "Before fail fast":

    using System;
    using System.Collections.Generic;
    using System.Text;
    
    namespace FailFast
    {
    	class Program
    	{
    		static void Main(string[] args)
    		{
    			try
    			{
    				Console.WriteLine("Before fail fast");
    				Environment.FailFast(null);
    				Console.WriteLine("After fail fast");
    			}
    			finally
    			{
    				Console.WriteLine("in finally block");
    			}
    		}
    	}
    }
    
  • (cs)

    Reminds me of interviewing candidates with Active Directory experience. They would put 'AD' on their resume so we would ask them about it. They would typically say any of the following:

    "AD stands for Active Directory." "AD is what is used when you log in." "My consulting company told me to put that on there."

    When never found one that had actually had REAL experience with AD, so we hired a recent college grad and trained him. He was cheap and we could mold him into the developer we needed.

  • BentFranklin (unregistered)

    Someone please educate me a bit: How does a database survive a power cycle in the middle of writing a transaction?

    Captcha: appellatio (A program that sucks?)

  • Ken B (unregistered)
    Human Resources was a bit peeved that my group was so “picky” with our candidates ad rejected all of the qualified candidates (read: one) that they had sent over.
    You could have said "and I suppose you wanted me to hire *all* of the candidates you sent over?"
  • Andrew (unregistered)

    The arguments over try...catch...finally remind me of a story about the Java finalize() method. This mehod has far worse indeterminant behavoir than try...catch...finally.

    We had an otherwise brilliant programmer, with a C/Perl/CGI background but not Java. He even had a Master's degree in computer science.

    He was tasked with writing a JSP webapp for the company. The application usually ran fine, but occasionally it randomly executed some code.

    After much discovery, he found out that his AppClass.finalize() also overrode the Object.finalize() method. The garbage collector was running his method at random intervals.

  • Andrew (unregistered)

    The arguments over try...catch...finally remind me of a story about the Java finalize() method. This mehod has far worse indeterminant behavoir than try...catch...finally.

    We had an otherwise brilliant programmer, with a C/Perl/CGI background but not Java. He even had a Master's degree in computer science.

    He was tasked with writing a JSP webapp for the company. The application usually ran fine, but occasionally it randomly executed some code.

    After much discovery, he found out that his AppClass.finalize() also overrode the Object.finalize() method. The garbage collector was running his method at random intervals.

  • Dave (unregistered) in reply to shadowman
    shadowman:
    techie:
    Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?

    Well, like others said, catching her lying in the interview pretty much precludes anything else.

    But I'd guess coupling that with glaring errors like 'Microsoft Solaris' on her resume might be a worthy indicator of her programming ability

    I dunno could have just been a missed comma.

Leave a comment on “My Tales”

Log In or post as a guest

Replying to comment #209146:

« Return to Article