• Whocares? (unregistered)

    Bert wrote only purely functional code, that's obvious.

  • someone (unregistered) in reply to Whocares?

    Even if that's true (which I doubt), functional programming is still not well-suited to games. Or anything, for that matter. duck

  • bvs23bkv33 (unregistered)

    I told you, no loops - just PERFORM VARYING

  • Chris (unregistered)

    Maybe for performance purposes he automatically unrolls all of his loops? As in, to the point where he doesn't even realise he's doing it.

  • (nodebb)

    You may want to re-link the image to a stable revision number in case the author notices his mistake...

  • P (unregistered)

    This reminds me of this article:

    https://blog.codinghorror.com/why-cant-programmers-program/

    Yes, that was written a long time ago but just as relevant today.

  • Giulio (unregistered)

    I'd be honestly very interested in looking at 5 different 3D-related projects that don't use any loop, unless they're using LINQ and functional library algorithms, in which case.... meh...

  • Jim B (unregistered) in reply to bvs23bkv33

    Nice COBOL reference.

    And I'm an old COBOL programmer who moved to the 'dark' side of C#.

  • Jake (unregistered)

    Unrolling loop story: Working in VHDL, with a code generator built to churn out 18 examples of a fairly simple function with just a few variables changed, so I cheerfully wrote a loop. The compiler decided all that all the examples had to be conditional with each other, generating a vast amount of code that it then spent much more time cheerfully optimizing out again.

    With the lil' loop, compiling took about 45 minutes, and ground up at least 2GB of RAM. With the loop unrolled, just 18 consecutive statements with a few variables changed in each one, compiling took seconds and too little RAM to measure. The resulting object files were bit-for-bit identical.

    That code then had no loops in it (unless you count the inherent while(true) of an FPGA)

  • (nodebb)

    Snoofle is wrong about the best approach to interview questions. The way he advocates just measures salesmanship. Great if you're hiring a salesman. Meaningless if you're hiring a software programmer/developer/engineer. The kinds of interviews from worst to best are:

    D) Open-ended questions; C (Tie) Standardized test, such as Benchmark C (Tie)) Writing code with pencil and paper (measures penmanship) C+) Giving both of the C tests; B) Giving them a computer set up the way it will actually be set up at work, and giving them a task to perform. A) The same as above, but with internet access. They can search the net, but cannot post any questions.

    Addendum 2018-07-25 09:32: Combining the above methods gives the best results.

  • Donald Klopper (google)

    I see no comments yet on the spelling error (Cirlce) in the Positive feedback image.

    Lack of attention to detail would definitely be a red flag in an interview

  • Appalled (unregistered)

    (Sarcasm)Don't need no stinking loops nowadays. 20 years ago they invented drag and drop programming. Besides loops involve implicit or explicit GOTo's which are evil. If you don't stick with drag and drop you screw up all the newcoming programmers with all your ancient primitve coding techniques. (/Sarcasm)

  • snoofle (unregistered) in reply to tharpa

    The problem with coding tests is that in the time context of an interview, you really can't ask people to do anything of any real substance. I've taken several of those and the solution was always 20-40 LOC that I was able to whip off without any real thought. Allowing internet access to look-up a solution doesn't really tell you of the abilities of the candidate beyond that they know how to use search.

    Having them describe their approach to solving real world business problems (within proper context) as well as how they'd approach debugging/fixing things gives a pretty good indicator of their prior exposure and how they think. Asking them to describe how to solve a specific problem using a specific library will usually get you specific data structures/algorithms/etc that they'd use, which tells you if they've done it before and whether or not they took a reasonable approach.

    No approach yields perfect results all the time, but this hasn't failed me in 40 years.

    Just my $0.02

  • (nodebb)

    The reason that allowing internet access is part of the A+ question is that the ideal test mimics the real world as much as possible.

    You would have no way if knowing if it failed you 0 times, 1 time, or every single time in 40 years. Success means you hired the best person for the job. Failure means you passed up on someone better. Since managers are primarily a type of salesman, they will, of course, say that they have always succeeded.

  • tbo (unregistered) in reply to snoofle

    Having someone write 20-40 lines of code seems like it would weed out a lot of the people who can interview but couldn't actually do the job. This site is rife with examples.

  • tbo (unregistered) in reply to tbo

    And I just noticed whom I replied to, which means I read it wrong.

  • (nodebb)

    I seem vaguely to recall some Google Personnel Mgr (I refuse to use "HR" because I may or may not be 'human' but am damn well not a 'resource') saying that no matter what techniques they tried, their success rate didn't change. X% of hired candidates worked out , (100-X)% didn't, regardless of the interview type or evaluation.

  • Llarry (unregistered) in reply to tharpa

    That's not the only way to define "Failure". It is at least as likely to be "hired someone who turned out to not be able to do the job". I consider that to be a much more useful definition.

  • Zenith (unregistered) in reply to tbo

    Sometimes it also weeds out people who can do more than drag and drop. I took such an interview a few years ago. It's difficult knowing HTML/ASP but being handicapped by WebForms and WebForms copycat stupidity. You can fight some of those frameworks for days to save seconds of hand editing.

    Related to the article, I briefly worked with a framework-wrapping clown. Except he was the lead, not an interviewee. I really wonder how they get jobs. And keep them after years of delivering nothing but excuses. It's crazy.

    Interviewing in this area is pretty bad. Many of the questions are academic. What's inheritance or polymorphism? Something your team never ever uses after generating a Form or Page from the wizard. What are the pros and cons of object oriented versus procedural? A tendency to create thousands of one-time use objects because "static" and "shared" don't bring up any hits on Expert Sexchange. What are the stages of the SDLC? 10 minutes of requirements gathering, 18 months of no-oversight development in India, 3 rubber stamp tests, panic in production, and finger pointing. Why even answer?

  • Karl Bielefeldt (github)

    This particular case is why interviewers do FizzBuzz-type problems. It quickly weeds out the can't-even-write-a-loop programmers.

  • Developer Dude (google) in reply to tharpa

    Penmanship? Really? It's been decades since anybody need to read my handwriting. Let me guess, you also want the candidate to write in cursive?

    As for the computer with a dev env. - not everybody uses the same dev IDE; e.g., Eclipse v. IntelliJ v. NetBeans - so you may have handicapped the candidate right off the bat. If that is what you are going to do, let them bring a laptop and their own tools.

    Personally, I think I can tell a lot more about a dev by having them walk me thru code they have already written for another project than looking at what they can come up with off the top of their head (which often is not the best approach and not their best effort) - I want to see what they have come up with after several iterations/efforts/refactorings.

  • I Am A Robot (unregistered)

    If you've got someone to the interview stage and you're aware of open source projects they're involved with, then part of your research into them should be looking at the code in advance, rather than waiting till they show up.

  • Sole Purpose Of Visit (unregistered)

    So, the job's in c#, and the guy has a collection of C++ headers on display?

    I'd be inclined to ask further questions, like, why are you applying for a C# position? (Not necessarily an interview killer.)

    Deprecating one's experience with loops is hardly a bad thing. A same interviewer would ask "what do you use instead?"

    For C++, the DLR and lambdas would be a profitable way forward. For C#, Line would work -- and before anybody complains, it's a common technique in graphics programming these days. Just think "list comprehension," and there you go.

    Of course, it is quite possible that this guy is a lying doofus ... but apparently the interviewer couldn't be bothered to find out.

    Just how hard is it going to be to teach a new hire how to program loops, anyhow?

  • eric bloedow (unregistered)

    some of the comments reminded me of those old "interview 2.0" stories, where they would ask ABSURD RIDDLES that had absolutely NOTHING to to with the job! an extremely stupid management fad!

  • jesus (unregistered)

    yea, verily - this should be in tales from the interview

  • Navibulator (unregistered)

    I could see this being the case if you were using some library or framework like OpenCV to do the heavy lifting in your image processing. In fact, this goes along with the software engineering dictum of Don't Reinvent the Wheel.

  • Developer Dude (google)

    https://dzone.com/articles/programmers-and-puzzles

  • (nodebb) in reply to Developer Dude

    Like a thesis defence in viva voce - your interviewers have read your submission and now you're standing in front of them answering the questions they have about it.

  • JG (unregistered) in reply to Developer Dude

    How about getting them to do a code review?

  • anyone (unregistered)

    No raw loops - this is the correct way to do programming.

  • Zenith (unregistered) in reply to JG

    Hahahahahaha.! Are you trying to hire a style Nazi or a programmer?

  • siciac (unregistered) in reply to snoofle

    Having them describe their approach to solving real world business problems (within proper context) as well as how they'd approach debugging/fixing things gives a pretty good indicator of their prior exposure and how they think.

    You need that, I agree, but you will get candidates who are very knowledgeable about reciting what their team did to solve things, without really understanding basics like, well, loops and such.

  • siciac (unregistered) in reply to Developer Dude

    As for the computer with a dev env. - not everybody uses the same dev IDE; e.g., Eclipse v. IntelliJ v. NetBeans - so you may have handicapped the candidate right off the bat. If that is what you are going to do, let them bring a laptop and their own tools.

    The benefit of a coding tests is that they're reproducible. After two or three trials, you get a very good sense of how people think and what level they're operating at.

    We often forget the point of an interview: is this person likely to be successful in the role? Should we offer more cash to attract someone who is especially good?

    "Realistic" problems introduce a lot of complexity that doesn't get useful data. They're not "realistic" as they're still simplified and they can't possibly be representative of what you do. And they make it harder to compare across candidates and thus understand whether you're getting good information about the candidate.

  • Lerch98 (unregistered)

    I worked at a place years ago that had made many bad hires, as management could not evaluate the canidates skills. Policy changed, and they would have me in the interview loop. Instructions to determine if said candidate knew anything related to the job and if thier resume was truthful. I'm the bull####er's worst nightmare. There were many candidates that applied for C programming jobs. Many had a major in CS from a local university. 1/2 half of those candidates failed the first question; "Tell me about the fundamental data types in C language." I would hand them a marker and point to a white board. There were quite a few of them that looked at me. You would think that I asked them to explain quantum theory. If they could answer that question, then it would be to explain a union (or complex data type) and the third question would be to give an example of a loop. All the candidates that could answer the first questions could explain a loop. The other thing was bulll### on the resume. I would pick something off their resume and ask them to explain it. If they couldn't they would be dismissed. example One guy claimed to be a super expert with logic analyzers. I asked him to tell me about a L/A that he used and what he liked or didn't like; Answer "Humpf" my reply "Thanks for commin' in. I'll take you back to the HR office.

  • (nodebb) in reply to Sole Purpose Of Visit

    Just how hard is it going to be to teach a new hire how to program loops, anyhow?

    That'd be easy enough. But tell me, were you looking for a programmer, or for a prospective programmer whom you can afford to teach everything from scratch? Not to mention the risk he/she'll faint at the first request to code a destructor.

  • Lafcadio (unregistered)

    I have a set of four questions that I ask potential candidates in code interviews.

    1. Write a Java class. This class should contain a method that returns the smallest of three integers. Call this class from a standard main() method.
    2. Write a method that determines whether two strings contain exactly the same characters.
    3. Take data out of this map and put it into this one, with different keys. (It's a little more complicated than that, but yes, really; this is a common task in the product we work with.)
    4. Discussion of why trying to search for events in a database by timestamp might not be a good idea. (Again, relevant to the product.)

    I feel terribly guilty about asking senior-level candidates these questions. But I ask them anyway, and it can take 20 minutes or more to get through the first one. The number of people who get to question three by the time an hour is up is appallingly small. No, this is not all it takes to get a job at my company, but if I'm hiring a programmer...I want them to be able to program.

Leave a comment on “Finding Your Strong Suit”

Log In or post as a guest

Replying to comment #498022:

« Return to Article