• (cs) in reply to MurdocJ
    Anonymous:
    Anonymous:
    Damn straight.  How did he pass the tech interviews?

    We keep them simple:  in depth discussions of linked lists, hashtables, or whatever.  It's a rare candidate that can nail these topics... the poseurs wash out by the second question, the good guys start sweating at around the fifth or so.  The guys we want to hire start saying "that's really interesting" at around question seven.





    Funny... when I interview for a job, it runs more along the lines of "tell me why I should work for you" and "prove to me that your organization isn't dysfunctional".  So around the 2nd question I see my interviewers starting to sweat.


    Funny, when I interviewed for my current job, many interviewers basically said 'we know the organization is disfunctional.  We want you to fix the technical side.  Here's our plan on the organizational side.  Are we missing anything?'  Quite refreshing, and of course I took the job.

    (was the original anon, now logged in)
  • woohoo (unregistered) in reply to ammoQ
    ammoQ:
    blasterz:

    Brought up the same idea with management at my company. They shied away from the idea, saying that for legal reasons the'd have to go back and test all existing employees with the same criteria.


    Well, recently I've been tasked with selecting new programmers. First, I designed a test (in my case, it's just a short piece of code with a lot of syntax errors; candidates must find them). Then I had the existing staff do this test to see how much I should expect (it's rather hard to find all syntax errors in such a case). Since none of them scored extremely bad (everyone scored at least 60%), I decided to put the limit at 50%. So, even if those legal reasons existed in our country (I doubt it), I could say with confidence that all current staff members would have passed it.
    I know this does not really make sure that someone is a good programmer, but it's good enough to keep away the Paulas and Marks.

    Sorry, not good... that's exactly the same problem which is plagueing things like Java certification exams: It does not at all prove comprehension of important basic (and even less advanced) language concepts, OO-paradigms etc. For finding syntax errors we do have compilers and IDEs with syntax highlighting plus auto-compilation... Someone who found enough of the errors can still very well be a lousy programmer/developer, and someone with sound understanding who would complement your company might be just not talented in reading texts letter-wise... ;-)

  • woohoo (unregistered) in reply to powerlord
    powerlord:
    Anonymous:
    > one can still be an "expert" and not know a great deal about "protected".

    exactly.

    in the absence of inheritance, private and protected are essentially equivalent - and in my experience, even simple inheritance is uncommon. so i'm happy when i see protected or private at all. it tells me the programmer was at least trying to show the rest of us which member vars are open for external manipulation and which are for internal state, instead of making us guess...

    Get/Set functions? icing on the cake.

    not using a member variable in a derived class with the same name as one in the base class ?  priceless.

    In Java, protected variables are also visible to other classes in the same package.

    To reiterate, here are Java's four variable scopes: private int someCount;

    • Visible to objects of the current class.

    int someCount;

    • AKA package-private. Visible to objects of the current class and objects of any class in the same package as the current class.

    protected int someCount;

    • Visible to objects of the current class, objects of derived classes, and objects of any class in the same package as the current class.

    public int someCount;

    • Visible to everyone.

    Right on. Allow me to make this even clearer ;-)

                            public protected  (package)  private            
    
    same class                Y         Y         Y         Y
    
    
    other or subclass         Y         Y        [Y]        N
    in same package
    
    subclass                  Y         Y        [N]        N
    in different package
    
    other class               Y         N         N         N
    in different package
    
    -------------------------
    Y = Yes, is visible
    N = No, is not visible
    
    Notice the beautiful triangular matrix structure :-)
    The two occurences in [  ] are the most interesting: 
    Anything "package"-visible is "quasi-public" inside
    and "quasi-private" outside the same package (a bit like "friend" in C++).
    This is the reason why "package"-visibility is the default in Java.
    It is still a good idea to make access as restricted as possible - this means, use "private" inside yout own
    packages where applicable, it saves you from your own stupidity :-)
    
  • (cs) in reply to woohoo
    Anonymous:
    ammoQ:

    Well, recently I've been tasked with selecting new programmers. First, I designed a test (in my case, it's just a short piece of code with a lot of syntax errors; candidates must find them).

    Sorry, not good... that's exactly the same problem which is plagueing things like Java certification exams: It does not at all prove comprehension of important basic (and even less advanced) language concepts, OO-paradigms etc. For finding syntax errors we do have compilers and IDEs with syntax highlighting plus auto-compilation... Someone who found enough of the errors can still very well be a lousy programmer/developer,


    Candidates who pass this test are not automatically hired. The same program, with all the syntax errors corrected, also contains a logical bug and some awkward constructs. Candidates who pass the first part have to discuss these topics with me - why is it bad, what are the consequences etc.

    And someone with sound understanding who would complement your company might be just not talented in reading texts letter-wise... ;-)

    The first part (syntax error finding) has two rounds: First, Candidates mark all the errors they find by themself. After that, I mark the lines (or small ranges of lines) where they have missed errors, and they have a chance to look again. People who are reasonably familar with the language find most of the bugs in round two. If someone is completely unable to spot the bugs, he/she is not a good choice for us, since we need people who can also maintain our old programs as part of their job.

  • Grovesy (unregistered) in reply to woohoo
    Anonymous:
    powerlord:
    Anonymous:
    > one can still be an "expert" and not know a great deal about "protected".

    exactly.

    in the absence of inheritance, private and protected are essentially equivalent - and in my experience, even simple inheritance is uncommon. so i'm happy when i see protected or private at all. it tells me the programmer was at least trying to show the rest of us which member vars are open for external manipulation and which are for internal state, instead of making us guess...

    Get/Set functions? icing on the cake.

    not using a member variable in a derived class with the same name as one in the base class ?  priceless.
    In Java, protected variables are also visible to other classes in the same package. To reiterate, here are Java's four variable scopes: private int someCount; - Visible to objects of the current class. int someCount; - AKA package-private. Visible to objects of the current class and objects of any class in the same package as the current class. protected int someCount; - Visible to objects of the current class, objects of derived classes, and objects of any class in the same package as the current class. public int someCount; - Visible to everyone.
    Right on. Allow me to make this even clearer ;-)
                            public protected  (package)  private            
    

    same class Y Y Y Y

    other or subclass Y Y [Y] N in same package

    subclass Y Y [N] N in different package

    other class Y N N N in different package


    Y = Yes, is visible N = No, is not visible

    Notice the beautiful triangular matrix structure :-) The two occurences in [ ] are the most interesting: Anything "package"-visible is "quasi-public" inside and "quasi-private" outside the same package (a bit like "friend" in C++). This is the reason why "package"-visibility is the default in Java. It is still a good idea to make access as restricted as possible - this means, use "private" inside yout own packages where applicable, it saves you from your own stupidity :-)

    <FONT face=Arial size=2>Wow, didn't realise that protected in Java meant that the member was also 'friendly', I'm more used to C++ and C#.</FONT>

    <FONT face=Arial size=2>Currently in C# protected is only visible to derrvied classes, internal is visible only within the same package.</FONT>

    You can declare something has <FONT face="Courier New" color=#000080 size=2>protected internal, <FONT face=Arial color=#000000>and get a member which is both visible to derrived classes and to classes in the same package,</FONT></FONT>

  • (cs) in reply to John Hensley
    John Hensley:
    masklinn:
    danio:
    ammoQ:

    public abstract void setCount(Integer int); ... int is of course a reserved word, cannot be used as a parameter name


    WTF kind of language has both an int and an Integer?

    Haskell has both. Issue is that Java has them for crappy reasons ("native types" vs objects)

    Given that the overhead of a Java object includes

    • allocation time
    • heap block overhead
    • more work for the garbage collector
    • a class pointer
    • a mutex
    • a condition variable
    I don't really see what's so crappy about not using them for routine calculations. Java was made to be useful, not to be pure at any cost. Unlike Haskell, which maintains theoretical purity at the expense of being a dog for practical applications.

    Except that Java's behaviour makes integers (among others) a pain to work with:

    • to prevent the allocation of some Integer objects (that can be long-lived, you don't need to allocate 25 times the Integer of value "1", one is enough, so the overhead of Integer objects is at best minimal) the force(d, pre 1.5) you to manually box your ints to Integers whenever you wanted to do anything even remotely "complex" such as putting them in ... say ... an arraylist
    • And no one ever said that you had to create objects, merely that their interface had to be that of an object, just use litteral ints and translate method calls on them to static method calls on the Integer class if you wish or something
    • Plus Java's Integer objects are a pain to manipulate & work with, and they're not interface-compatible with the "native" ints
    • At the end of the day, I never saw anything pointing out that C#'s ints were much less efficient than Java's, and yet they're (used as) full fledged objects, or they were last time I checked.

    About Haskell... bah I guess you'll just have to tell the Pugs team that Haskell is slow and they should switch to Java right?

    While Haskell is noticeably slower than C/C++ (and D, too), it's not much slower than Java (using the Hotspot JIT VM), and it usually hogs much less memory... Not to mention it's often much less verbose.

  • (cs) in reply to masklinn
    masklinn:
    • At the end of the day, I never saw anything pointing out that C#'s ints were much less efficient than Java's, and yet they're (used as) full fledged objects, or they were last time I checked.


    Aren't C#'s ints primitive types (aka "simple types") just like Java's ints, but C# hides that by autoboxing?
  • (cs) in reply to ammoQ
    ammoQ:
    masklinn:
    • At the end of the day, I never saw anything pointing out that C#'s ints were much less efficient than Java's, and yet they're (used as) full fledged objects, or they were last time I checked.



    Aren't C#'s ints primitive types (aka "simple types") just like Java's ints, but C# hides that by autoboxing?

    Correct, C# primitives (well, value types) are placed on the stack, while reference types (objects) are placed on the managed Headp. The only time problems occur is when treating value types as reference types, such as when adding value types to the standard Lists and Hashtables which take in an object as a value to add.

    .net 2.0 has that problems solved for the most with generics.

  • (cs) in reply to ammoQ
    ammoQ:
    masklinn:
    • At the end of the day, I never saw anything pointing out that C#'s ints were much less efficient than Java's, and yet they're (used as) full fledged objects, or they were last time I checked.


    Aren't C#'s ints primitive types (aka "simple types") just like Java's ints, but C# hides that by autoboxing?

    Yes, that's why I said (used as), they're primitive types but the way they're used is no different than that of a full fledged object: the abstraction over primitive type doesn't leak much.

    Java, on the other hand, has no abstraction at all over primitive types (well it now has some with autoboxing in 1.5, but ints still don't "look" like objects by a far margin), therefore the fact that primitive types are not objects at all leaks into the language.

    Grovesy:
    ammoQ:
    masklinn:
    • At the end of the day, I never saw anything pointing out that C#'s ints were much less efficient than Java's, and yet they're (used as) full fledged objects, or they were last time I checked.



    Aren't C#'s ints primitive types (aka "simple types") just like Java's ints, but C# hides that by autoboxing?

    Correct, C# primitives (well, value types) are placed on the stack, while reference types (objects) are placed on the managed Headp. The only time problems occur is when treating value types as reference types, such as when adding value types to the standard Lists and Hashtables which take in an object as a value to add.

    .net 2.0 has that problems solved for the most with generics.

    Didn't know there were problems with Lists and Hashtables (I didn't do much C#), thanks for the info. I thought C# autoboxed with these as well.

    How do generics solve the issue though? Primitive types are still primitive types aren't they?

    Anonymous:
    Now we're in trouble, deriving from both these classes (though logical at first glance) is gonna end you in a world of hurt...

    Isn't the issue mostly with the Method Resolution Order? I know that's one of the only problems that were raised with MI in Python. Spawned quite a lot of discussions though.

  • (cs)

    Anonymous:

    "protected" is the worse, because it's ONLY useful when you do implementation inheritance, which is more often than not Dangerous and Wrong. (Yes, there are cases when it isn't -- but those are not the majority)


    I think this point is maybe only valid in whatever line of work it is that you do, I'm a games programmer and we use implementation inheritance (and therefore the the "protected" keyword) extensively. For example, a typical shooting game engine's structure will have something like:

    // Base class for everything that gets made by the core engine's class factory
    class Object
    {}

    /*
     Base class for all objects that are (or can be) located in the game world, this class typically has a position and orientation
    */
    class Entity : public Object
    {}

    /*
    Base class for something fired from a weapon, has collision detection code and methods for applying damage to players/monsters etc...
    */
    class Projectile : public Entity
    {}

    // Makes explosions, apply damage to monsters/players over an area
    class ExplodingProjectile : public Projectile
    {}

    /*
    The actual class we make when we fire a rocket launcher, has all code for things that are entirely specific to this weapon
    */
    class Rocket : public ExplodingProjectile
    {}

    In this way we can maximise sharing of functionality and minimise rewriting things repeatedly. Sure, it's not perfect, there's always the dreaded Diamond Inheritance problem, but to call it Dangerous and Wrong seems pretty OTT. There's an antipattern called the "Golden Hammer". Sounds to me like you're doing the opposite, dismissing a technique because of it's bad points without really considering situations where it is in fact quite suitable, sort of like a "Pariah Monkeywrench" or something...

    In case you were wondering, the diamon inheritence problem goes like this, imagine we made:

    /*
    Has functionality for rendering laser effects
    */
    class LaserProjectile : public Projectile
    {}

    And then did:

    class ExplodingLaserProjectile : public LaserProjectile, public ExplodingProjectile
    {}


    Now we're in trouble, deriving from both these classes (though logical at first glance) is gonna end you in a world of hurt...

    Agreed, you have to know when to inherit or to aggregate; either can lead to all types of hurt if used incorrectly. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    I used to be a 'HPC' as a backend / middle tier in various industries from a major search engine, insurance, banking, CRM, estate agency to content management systems (where I stayed put). In all of those industries I have found Inheritance has had its place. For example within pension products: Product->Concrete Product, Scheme->Concrete Scheme, with The Scheme aggregating a product. <o:p></o:p>

    For technologies such as asp.net, it can often be useful to create an abstract class which inherit from System.Web.Page, and have all your pages inherit from instead of System.Web.Page.<o:p></o:p>

    Personally, I prefer the idea of specialization, which can be found in relational theory.<o:p></o:p>

    <o:p> </o:p>

     

  • (cs) in reply to masklinn

    Sorry for being so brief, it's a huge subject which various books dedicate several chapters to so, very basically. Excuse the inaccuracies<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    The problem with the old way in .net 1.1, was when adding / reading a value type from a collection, various boxing and unboxing operations had to go on. In effect because Hashtables and lists took in 'Objects' as parameters, value types had to be wrapped up in objects, and so ended up on the Managed Heap, instead of the nice quick stack.  <o:p></o:p>

    Instead with .net 2.0 couple with C# 2.0 we can do this following<o:p></o:p>

    List<int> myList = new List<int>();<o:p></o:p>

    List.Add(1); <o:p></o:p>

    List.Add(2);<o:p></o:p>

    Various clever ticks go on once compiled which prevents the whole boxing / unboxing thing going on at the IL level (similar to Java Byte Code)<o:p></o:p>

     

  • SixtiesLibber (unregistered) in reply to geezer coder

    Anonymous:
    If you were old enough to have been shaving for more than three years, you might realize that the more things change, the more they stay the same.  There are always the mouth breathers who shouldn't be trusted to tie their own shoes, and the folks who read manuals in the evenings for fun and will amaze you with the breadth of their understanding if you shut up long enough to listen. 

    Thank you!!! from a 66-year old ex-Fortran programmer who taught myself Java a few years ago.  You young people are spoiled not having to deal with pointers!

  • Tox (unregistered)

    really, the WTF lies in the bloated Java itself. It's great for creating more job positions and lowering the overall salary standard.

    Let's see what we need to do, in Java, to create the following web form that posts someone's name and phone number to another page:

    <form method="POST" action="somepage.jsp">
    Names: <input name="names" type="text"><br>
    Phone: <input name="phone" type="text"><br>
    <input type="submit" value="Submit">
    </form>
    <!--disclaimer: this doesn't validate; it doesn't look good; i don't care -->

    Java Programmer #1, write a tag output class, so that no raw HTML is exposed:
    class HTMLTagManager{
      public void setTagName(string tagname);
      public void addProperty(fieldname,fieldvalue);
      public void outputStream();
    }
    //usecase:
    HTMLTagManager tm=new HTMLTagManager();
    tm.setTagName("form"); tm.addProperty("method","POST"); tm.addProperty("action","somepage.jsp"); tm.outputStream();

    Java Programmer #2, create a form generator:
    class EnterpriseFormManager{
    public addFormObjects(FormObject fo);
    public outputStream();
    }
    //usecase:
    EnterpriseFormManager efm = new EnterpriseFormManager();
    FormPhone = new (FormPhone)FormObjectFactory.createPhoneObject();
    efm.addFormObjects(FormPhone);
    //...
    efm.outputStream();

    Java Programmer #3, complete the FormObjectFactory

    Java Programmer #4, create a "UserFriendly GUI" by allowing the end users to draw flow charts and generating forms on the fly

    and the generated code will probably look like:
    <script src="form_manager_clientside.js"></script>
    <form name="Expresso_Form_2012C_" method="POST" action="somepage.jsp">
    <!--Brillant Name Object Starts Here -->
    <input name="names" type="text">
    <!--Brillant Name Object Ends Here -->
    <!--Brillant Phone Object Starts Here -->
    <input name="phone" type="text">
    <!--Brillant Phone Object Ends Here -->
    <input type="submit" value="Submit" onclick="submitform('Expresso_FORM_2012C_');">
    </form>

    Now Java Programmer #5 has a job to create the form manager JavaScript:
    function submitform_ie(formname){
    document.all[formname].submit();
    }
    function submitform(formname){
    if (isIE) submitform_ie(formname); else alert("sorry you have to use the best browser ever!");
    }

    Well, I've tried my best to disgust everyone here by trying to incorporate most of the WTF we've seen in the past two weeks. Still it's not nearly as close as some of the enterprisy Java solutions. Sad.

     

  • (cs) in reply to Tox
    Anonymous:

    really, the WTF lies in the bloated Java itself. It's great for creating more job positions and lowering the overall salary standard.



    IMO this bloat is more a result of the "best" practices than the language itself. Java programs can be small and efficient, but nobody does that.
  • (cs) in reply to Grovesy
    Grovesy:

    Sorry for being so brief, it's a huge subject which various books dedicate several chapters to so, very basically. Excuse the inaccuracies<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    The problem with the old way in .net 1.1, was when adding / reading a value type from a collection, various boxing and unboxing operations had to go on. In effect because Hashtables and lists took in 'Objects' as parameters, value types had to be wrapped up in objects, and so ended up on the Managed Heap, instead of the nice quick stack.  <o:p></o:p>

    Instead with .net 2.0 couple with C# 2.0 we can do this following<o:p></o:p>

    List<int> myList = new List<int>();<o:p></o:p>

    List.Add(1); <o:p></o:p>

    List.Add(2);<o:p></o:p>

    Various clever ticks go on once compiled which prevents the whole boxing / unboxing thing going on at the IL level (similar to Java Byte Code)<o:p></o:p>

     

    Ok, so it was more of a speed optimization (keeping integers on the stack at all times instead of switching them to the heap) than a huge leaking abstraction right?

    Or did I miss something else?

    ammoQ:
    Anonymous:

    really, the WTF lies in the bloated Java itself. It's great for creating more job positions and lowering the overall salary standard.



    IMO this bloat is more a result of the "best" practices than the language itself. Java programs can be small and efficient, but nobody does that.

    Efficient that highly probable, but small? What's the basis of comparison? ASM?

  • (cs) in reply to masklinn
    masklinn:
    ammoQ:


    IMO this bloat is more a result of the "best" practices than the language itself. Java programs can be small and efficient, but nobody does that.

    Efficient that highly probable, but small? What's the basis of comparison? ASM?


    Small compared to the bloated "best practices" java programs, while still doing something usefull.
    Note: When writing "small", I was merely talking about LOC(*), not the size of the executable class (20 K) + the necessary runtime environment (130M).


    (*) I know LOC is not a perfect measurement for source file size. IMO it would be much better to count tokens instead. I wonder why this is not standard... or is it?
  • (cs) in reply to masklinn

    masklinn:
    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    Ok, so it was more of a speed optimization (keeping integers on the stack at all times instead of switching them to the heap) than a huge leaking abstraction right?<o:p></o:p>

    Or did I miss something else?<o:p></o:p>

    <o:p></o:p>

    In effect, yes. As well as adding some handy type safety. Previously with an out of the box ArrayList I could have done the following<o:p></o:p>

    ArrayList list = new ArrayList();<o:p></o:p>

    list.Add(1);<o:p></o:p>

    list.Add("hello");<o:p></o:p>

    list.Add(new Customer("ACME"));<o:p></o:p>

    To get around this, we would have to derive a new class from Array List and override the Add / Get Methods to take in a particular type.<o:p></o:p>

    Now, <o:p></o:p>

    List<SomeObject> myObject new List<SomeObject>();<o:p></o:p>

    will only accept objects of type SomeObject (or derrived from SomeObject). <o:p></o:p>

    ammoQ:

    IMO this bloat is more a result of the "best" practices than the language itself. Java programs can be small and efficient, but nobody does that.
    <o:p></o:p>

    I Agree, and the same could be said of any language C++, .net, Ruby and Java. We could create a webform or windows form app which taps straight into the database and populates straight from data sets, which for small applications would be a sensible soloution. <o:p></o:p>

    On the other hand, when creating an 'enterprisey' application (our 'enterprisey application' has close to 5,000 servers, and delivers 30,000,000,000 page impressions a month), in such cases to have a load of webforms that simply tack straight into the underlying databases (and other data sources) just isn't sensible and would be a complete cluster **** in terms of maintenance. Sure it could be more efficient and we could probably halve the number of servers, but we would end up spending most of our time chasing bug fixes instead of developing new features. Developer = 50k (GBP), server = 1k<o:p></o:p>

     

  • (cs) in reply to GalacticCmdr

    Of all the WTFs to choose for a Java hate-in, this is one of the silliest.

  • (cs) in reply to Grovesy
    Grovesy:

    ammoQ:

    IMO this bloat is more a result of the "best" practices than the language itself. Java programs can be small and efficient, but nobody does that.
    <o:p></o:p>

    I Agree, and the same could be said of any language C++, .net, Ruby and Java. We could create a webform or windows form app which taps straight into the database and populates straight from data sets, which for small applications would be a sensible soloution. <o:p></o:p>

    On the other hand, when creating an 'enterprisey' application (our 'enterprisey application' has close to 5,000 servers, and delivers 30,000,000,000 page impressions a month), in such cases to have a load of webforms that simply tack straight into the underlying databases (and other data sources) just isn't sensible and would be a complete cluster **** in terms of maintenance. Sure it could be more efficient and we could probably halve the number of servers, but we would end up spending most of our time chasing bug fixes instead of developing new features. Developer = 50k (GBP), server = 1k<o:p></o:p>



    I have no experience with such large deployments but I think you know what you are doing.
    Anyway, I would not advocate JSP pages going directly to the database even for small installations, because of the maintenance problems.
    But there is still a large gap between "something that is small, but maintainable and does the job" and "what some people do to make even small installations enterprisey".
  • (cs) in reply to ammoQ
    ammoQ:
    Stupidumb:
    I was just wondering why it is not proper to open a curly brace on a new line? Is it considered standard by most people to put it at the end of the function declaration on the same line?

    Modern compilers create 15% faster code if the curly brace is on the end of the function declaration line.


    Experience proves the contrary. By opening a curly brace on a new line, you will compile 15% more lines of Java per second. No kidding.
  • (cs) in reply to trollable
    trollable:
    ammoQ:
    Stupidumb:
    I was just wondering why it is not proper to open a curly brace on a new line? Is it considered standard by most people to put it at the end of the function declaration on the same line?

    Modern compilers create 15% faster code if the curly brace is on the end of the function declaration line.


    Experience proves the contrary. By opening a curly brace on a new line, you will compile 15% more lines of Java per second. No kidding.


    Tried that. But apparently it doesn't work. Maybe it's because the program consists of a single class with a single method that contains 60000 lines spagetti code within a single large loop, without any curly braces except for the class, the method and the loop.



    ;-)
  • Joel (unregistered) in reply to po_pimp
    The real WTF is that they did not follow up the technical interviews with requests for code samples. BS-ing a technical interview is easy, but when put to the real test of coding, this guy would most likely have been exposed.
    Why wait until after the interview to ask about coding? If there is one question that a technical interview loop for a software developer should cover it's "Can they write code?" Simple questions -- reverse a string, count the number of unique chars in a string, find the intersection of two lists of ints in less than O(N^2) - can reveal enormous amounts of information about whether the person in front of you is BSing or not. Don't give them an exercise to do at home. Ask them right there, on the spot, to write the code on a whiteboard or a sheet of paper. If they can't write code then, don't expect them to be able to after they've been hired.
  • Hugh (unregistered) in reply to derby

    I prefer "pedantic" to "wacky"! Channellock is a manufacturer not a type of tool (I believe Channellock call them tongue and groove pliers).

  • David Walker (unregistered) in reply to Hugh
    Anonymous:

    I prefer "pedantic" to "wacky"! Channellock is a manufacturer not a type of tool (I believe Channellock call them tongue and groove pliers).

    Yes, but everyone I know calls them Channellocks.  Just like (almost) everyone calls facial tissues Kleenex and petroleum jelly is called Vaseline...

  • (cs) in reply to David Walker
    Anonymous:
    Anonymous:

    I prefer "pedantic" to "wacky"! Channellock is a manufacturer not a type of tool (I believe Channellock call them tongue and groove pliers).

    Yes, but everyone I know calls them Channellocks.  Just like (almost) everyone calls facial tissues Kleenex and petroleum jelly is called Vaseline...

     

    True, but does that make them right :-) ? Just because everyone is being wrong, dosen't default them to being correct.    

  • nokidsretireyoung (unregistered) in reply to Gamer
    Anonymous:

    ammoQ:
    People who are unwilling to take a risk probably do not have kids anyway.

    Actually, having kids just requires the applicants to pass a usually quite short practical exam.



    Nah, you've got that wrong.  It actually merely requires the applicants to fail Contraception 101.

    "I'm spayed, and I'm proud"
  • Me (unregistered) in reply to ammoQ

    Try

    public abstract class FooBar {
            public abstract void foo();
            public final void bar() { }
    }

  • expresso machine (unregistered) in reply to graywh
    graywh:
    Does anyone find it amusing that the framework is called Expresso (a Portugese newspaper, among other things), but the coffee is espresso. 


    no.
  • Chris (unregistered) in reply to Sam
    Anonymous:
    This is an example of why "tech" interviews are almost completley worthless. I keep pushing to give people non-trivial but still small problems to solve and see what they come up with.


    For my current job, I had to go in for a day's trial as part of the interview process. That way, you can talk yourself up as much as you like, but you'll get nowhere if your code is WTF-worthy. The same system allows someone like me, without qualifications nor experience, to show that I know what I'm doing..
  • (cs) in reply to Chris
    Chris:

    For my current job, I had to go in for a day's trial as part of the interview process. That way, you can talk yourself up as much as you like, but you'll get nowhere if your code is WTF-worthy. The same system allows someone like me, without qualifications nor experience, to show that I know what I'm doing..


    I don't like this approach too much, for several reasons:
    - it takes a lot of effort
    - results are subjective (how many comments are enough?)
    - people who have used a different language the last year or so might have difficulties to switch to the required language fast enough; they need some time to acclimatize and might fail the test, despite their skills and experience
    - Sloppy programmers might force themself to write neat code on that day, but fall back to bad habits as soon as they are hired

    But for newbies who have no track record to check, such a test might be your best shot.
  • Bill (unregistered) in reply to dave

        Funny, I didn't think the guy with a WRENCH was a programmer. I just thought he was a clueless guy who didn't know what a wrench was for.  Agesit? Nope.

  • Revoemag (unregistered) in reply to Bill

    Anonymous:
        Funny, I didn't think the guy with a WRENCH was a programmer. I just thought he was a clueless guy who didn't know what a wrench was for.  Agesit? Nope.

    I thought the "Old Guy" was Shawn and the "tool" was Mark. The "Old Guy" is looking at the "tool" saying, "What the ... ?!"

  • Matt The Aussie (unregistered) in reply to Will

    Hey I want to know if the people who Hired him got the axe as well?

  • Matt The Aussie (unregistered) in reply to SixtiesLibber

    My first job out of Uni, I was Junior by 21 years to the next persion in my team.
    With Me the team count was 11.

    We were all Unix C and I attribute my java prowess to those guys.

    You keep trucking on Old timer!!

  • Anony Moose (unregistered)

    Say you're trying to hire a Java developer, because your team of 5 coders has spent 8 months working on a system written in Java, and rewriting the entire thing in C++ would be stupid.

    The guy who comes in for the job claims to be a C++ expert with a passing fmiliarity of Java, and claims that he could learn Java quickly enough to be useful.

    So you ask what 'protected' means in C++.

    An acceptable answer is a listing of the consequences of using 'protected' and possibly a list of reasons why they're too risky for general usage.

    An unacceptable answer is "I don't know, I was always told not to use it" because that shows that he's merely doing what he was told without actually understanding the reasoning behind his actions. It's not a good sign.

    Even worse is an incorrect understanding, because it means that the guy is not an "expert" as claimed, and thus you have no basis to assume that he has the necessary skills, regardless of language that you're interested in.

    You can't get away with calling yourself an expert without being able to demonstrate fundamental knowledge of core parts of the language you claim to know, or without being able to show that you can understand the justification and reasoning for particular decisions you've made.

    If you work with idiots who say "don't do X, it's bad" then you either find out for yourself why they say that, or you will be screwing yourself out of the opportunity to be taken seriously as an expert if they were wrong. On the other hand, if they had a point then you'll have the opportunity to distinguish yourself from the people who never bothered to find out the reasons behind the belief. Either way, understanding beats blindly accepting other people's opinion as law.

    I don't care about reputation - rumor is no substitute for actually being able to demonstrate skills that you explicitly claimed to posess. You might be able to "pick up" C++ in a day, but if that's true and you claim to be a C++ expert then pick it up the day before the interview, and don't come to the interview promising to get around to picking it up later.

  • (cs) in reply to Sam
    Anonymous:
    This is an example of why "tech" interviews are almost completley worthless. I keep pushing to give people non-trivial but still small problems to solve and see what they come up with.
    This becomes difficult when one's home office prohibits written problems because your office doesn't have a PhD to properly evaluate the results.  (I wish I was kidding.)
  • Erik (unregistered)

    This, like many of the stories on WTF, reflect poorly on the hiring manager.  The hiring manager should know how to ask open-ended questions during the interview.  Let the candidate decide how to interpret the question, what aspects of it are important enough to be addressed and which are not relevant.  The hiring manager should be able to pick apart the candidate's answer when it sounds overly bookish or vague.

     Many of these horror stories on WTF are the result of very poor judgement of the hiring manager.  Seriously, how could this candidate make it through the interview process?  The candidate has a vested interest in "bigging himself up."  The hiring manager has a vested interest in sizing the candidate up.  This catastrophe is the result of a manager asking a new employee to do something the employee was not capable of doing.  That is the manager's fault, not the employee's.

    I enjoy these stories.  But I am not always sympathetic to the protagonist.  Often they bring on troubles through their own poor judgement.

  • BrandonPhone (unregistered)
    Comment held for moderation.

Leave a comment on “The Abstract Candidate”

Log In or post as a guest

Replying to comment #:

« Return to Article