6 ms·

> but they want tests and for me to treat it like a real production work When hiring back-end devs, I explicitly make it clear I want at least some tests -- an

> but they want tests and for me to treat it like a real production work When hiring back-end devs, I explicitly make it clear I want at least some tests -- and the more the better. Of course I don't expect 100% test coverage but writing tests shows that 1) you understand best practices 2) you know how to write testable (readable, maintainable, clean and clear) code. If candidates chose just one module and tested that well it would be enough to get the point across. Seeing how people write their tests is also quite important for me -- if instead of using factories (or Faker or some other strong dummy data app) they instead decide to hardcode usernames and passwords, it's a huge red flag.

janephilipps 9y ago
Examples like this are why I think take-home challenges are a better way to assess a candidate's coding skills vs. their problem solving skills/how they think.
jhall1468 9y ago
> 1) you understand best practices Tests prove no such thing. Best practices aren't about output, they are about inputs. Tests determine if the expected output is the real output. > 2) you know how to write testable (readable, maintainable, clean and clear) code. Again, no they don't. I can test unreadable, unmaintainable dirty and unclear code. > if instead of using factories (or Faker or some other strong dummy data app) they instead decide to hardcode usernames and passwords, it's a huge red flag. No it doesn't. It shows that it's an arbitrary take home assignment that already took a week and they don't want to use yet another library to generate data for it. Honestly, you put so much emphasis on testing which is odd, because it's the easiest, most mundane thing to write. It provides nothing but "busy" work and fails to test the most important aspect of any candidate: can they problem solve.
- stevenjohns 9y ago
  > Tests prove no such thing. Best practices aren't about output, they are about inputs. Tests determine if the expected output is the real output Testing in and of itself is best practices. Having familiarity with and a strong understanding of how and what to test is extremely important for any modern development cycle. > Again, no they don't. I can test unreadable, unmaintainable dirty and unclear code. Except it's significantly more difficult. > No it doesn't. It shows that it's an arbitrary take home assignment that already took a week and they don't want to use yet another library to generate data for it If you don't have a strong dummy data suite to test against, then you're not testing properly. This actually justifies exactly what I'm talking about. > Honestly, you put so much emphasis on testing which is odd, because it's the easiest, most mundane thing to write. It provides nothing but "busy" work and fails to test the most important aspect of any candidate: can they problem solve. If it's mundane and easy then it should just be done. What I've found is that most can't. If the candidate pool was small, then I'd take less of an issue to it. But if 50 people come in and they can all problem solve, then I'm going to become more interested in who can solve problems elegantly.
  - sitkack 9y ago
    Directed at you and the parent. A better way to structure this is ask for at least one integration test, then tell the candidate that testing strategy and methodology will be discussed in the review. I had a coding test, not take home, where I was able to code on my own on a simple problem for about 45 minutes for each session then have a code review. We did this three times over three hours on increasingly harder problems. This exact same format could be done remotely.
nmjohn 9y ago
> they instead decide to hardcode usernames and passwords, it's a huge red flag. Why? That seems like an oddly specific thing to be a _huge_ red flag. Are you expecting random data to actually surface bugs - ie: making your tests non-deterministic? Or is there some other benefit you are looking for to make it such an important criteria?
- Clubber 9y ago
  Especially for something as throw away as a take home coding challenge.
  - stevenjohns 9y ago
    It may be a throwaway for the candidate, for the employer it's $XXX,000 a year and potentially ending the search for better, more suited candidates. If taking an extra an hour of time to sell your work is "throwaway" then that person is either shotgun applying to jobs (and not being hired for a reason) or they're not taking their application seriously.
    - pkaye 9y ago
      Then maybe communicate that salary amount to the candidate before so they can also decide if it is worth their time or not.
    - Clubber 9y ago
      That's fine, just understand that is a technique for finding "growing" developers, and still not a great one for that. If that's what you are looking for, that's fine. If you want tops, this isn't the way to go. Unless you've already hired someone that knows a top, you probably won't get them anyway. Think about it this way. It takes about 2 hours to learn how to write unit tests for someone who has never done it. Why make something as trivial so important in your interview process? I understand unit tests are important, but they aren't difficult.
      - ThrowawayR2 9y ago

janephilipps 9y ago

Examples like this are why I think take-home challenges are a better way to assess a candidate's coding skills vs. their problem solving skills/how they think.

jhall1468 9y ago

> 1) you understand best practices Tests prove no such thing. Best practices aren't about output, they are about inputs. Tests determine if the expected output is the real output. > 2) you know how to write testable (readable, maintainable, clean and clear) code. Again, no they don't. I can test unreadable, unmaintainable dirty and unclear code. > if instead of using factories (or Faker or some other strong dummy data app) they instead decide to hardcode usernames and passwords, it's a huge red flag. No it doesn't. It shows that it's an arbitrary take home assignment that already took a week and they don't want to use yet another library to generate data for it. Honestly, you put so much emphasis on testing which is odd, because it's the easiest, most mundane thing to write. It provides nothing but "busy" work and fails to test the most important aspect of any candidate: can they problem solve.

stevenjohns 9y ago
> Tests prove no such thing. Best practices aren't about output, they are about inputs. Tests determine if the expected output is the real output Testing in and of itself is best practices. Having familiarity with and a strong understanding of how and what to test is extremely important for any modern development cycle. > Again, no they don't. I can test unreadable, unmaintainable dirty and unclear code. Except it's significantly more difficult. > No it doesn't. It shows that it's an arbitrary take home assignment that already took a week and they don't want to use yet another library to generate data for it If you don't have a strong dummy data suite to test against, then you're not testing properly. This actually justifies exactly what I'm talking about. > Honestly, you put so much emphasis on testing which is odd, because it's the easiest, most mundane thing to write. It provides nothing but "busy" work and fails to test the most important aspect of any candidate: can they problem solve. If it's mundane and easy then it should just be done. What I've found is that most can't. If the candidate pool was small, then I'd take less of an issue to it. But if 50 people come in and they can all problem solve, then I'm going to become more interested in who can solve problems elegantly.
- sitkack 9y ago
  Directed at you and the parent. A better way to structure this is ask for at least one integration test, then tell the candidate that testing strategy and methodology will be discussed in the review. I had a coding test, not take home, where I was able to code on my own on a simple problem for about 45 minutes for each session then have a code review. We did this three times over three hours on increasingly harder problems. This exact same format could be done remotely.

nmjohn 9y ago

> they instead decide to hardcode usernames and passwords, it's a huge red flag. Why? That seems like an oddly specific thing to be a _huge_ red flag. Are you expecting random data to actually surface bugs - ie: making your tests non-deterministic? Or is there some other benefit you are looking for to make it such an important criteria?

Clubber 9y ago
Especially for something as throw away as a take home coding challenge.
- stevenjohns 9y ago
  It may be a throwaway for the candidate, for the employer it's $XXX,000 a year and potentially ending the search for better, more suited candidates. If taking an extra an hour of time to sell your work is "throwaway" then that person is either shotgun applying to jobs (and not being hired for a reason) or they're not taking their application seriously.
  - pkaye 9y ago
    Then maybe communicate that salary amount to the candidate before so they can also decide if it is worth their time or not.
  - Clubber 9y ago
    That's fine, just understand that is a technique for finding "growing" developers, and still not a great one for that. If that's what you are looking for, that's fine. If you want tops, this isn't the way to go. Unless you've already hired someone that knows a top, you probably won't get them anyway. Think about it this way. It takes about 2 hours to learn how to write unit tests for someone who has never done it. Why make something as trivial so important in your interview process? I understand unit tests are important, but they aren't difficult.
    - ThrowawayR2 9y ago