5 ms·

You are right that the biggest part of the job is easy - but testing the easy parts is useless - all programmers would pass it. A test must be hard in some way

• jzwinck 11y ago
  I assure you this is not always the case. I have worked directly with multiple people who could contrive the most exquisite solutions to really difficult problems but whose code was gibberish. Flagging such characteristics during recruitment would be valuable.
  • zby 11y ago
    Interesting - how would you flag it? In what way was their code gibberish? In my experience people who understand complex concepts can also understand how to write clear code. Maybe those that you are writing about were not motivated to do that - or maybe it never occurred to them that this was needed? Would you mind also explaining what you mean by this in "this is not always the case"? Because it does not seem to refer to my comment.
    • junto 11y ago
      I guess that concise implementations (e.g. in a one liner) are often a complete bitch to debug when someone else comes back to it to fix a problem years later. It is much more difficult to debug and fix existing code than develop it from scratch. Hence, if you found the problem hard to code in the first place, then when you come to debug it again later you've just screwed your future self.
      • zby 11y ago
        The problem with people writing too concise code is with their motivation not with their abilities - and so it is probably impossible to test (at least directly), because on the test they would have the motivation to do the right thing.
        • talles 11y ago
          I disagree. Knowing how much to abstract and writing clear code is indeed an ability.
        • st3v3r 11y ago
          No. If someone has to be "motivated" to write clear code, especially given that these tests are supposed to lead to jobs, then I would have to question their abilities. Writing clear code is an ability of itself.
          • zby 11y ago
            The point was about code 'too concise' - this is different from 'not clear'.
      • danielbarla 11y ago
        I've also seen (severe) examples of the converse - e.g. writing an 800 line monster which could better have been expressed as a regular expression (and a simple one, at that). This leads me to think that conciseness is not necessarily as simple as we tend to think. Sure, overly concise code with clever hacks are often a nightmare to debug, but that's mostly because they are the wrong abstraction and not capturing the problem well enough.
• logicality 11y ago
  if programmers are not actually solving similar problems as part of their jobs, sites like codility provide little value over standard IQ tests. all they do is waste the candidate's time and employer's money.
  • zby 11y ago
    In my opinion programming is about solving programming problems. There are other important parts - like understanding user needs etc - but solving problems is at the core of it. In practice usually these programming problems are easier - but to test how a programmer is proficient in solving them you need to use harder problems or maybe do some programming speed tests (many easy problems).
• deleted 11y ago
  [deleted]
• what2Do2016 11y ago
  you would be surprised how many "senior developers" I've worked with who can't write a decent CRUD app...
• richmarr 11y ago
  I think focusing on algorithms (if that's what you're suggesting) would be tunnel vision, and as a result the output of such a system will be much more weakly correlated with productivity than it should be. Beyond code literacy, the most valuable skills for a 99% of programming roles are empathy and diligence. Unless you're working on the kind of programming that's arguably pure mathematics, algorithms are just not important. There are plenty of ways to test diligence; empathy is a little harder to test directly but there are reasonable proxies. Disclaimer: I'm working on a product for applicant filtering (generic rather than coder-specific) https://www.beapplied.com/ https://www.beapplied.com/