3 ms·

> What other role requires you to complete an exam to be considered for a job (or even just an interview). Moreover a 4-8 hour exam with no syllabus. No 'past p

> What other role requires you to complete an exam to be considered for a job (or even just an interview). Moreover a 4-8 hour exam with no syllabus. No 'past papers' etc As far as I can tell, essentially all of them. Of course, many of them have no practical way to even attempt to assess competence, so they fall back on "situational" and "culture fit" bullshit. > I think this should stop. In it's place, developers can have a pet open-source project, which they submit with their application. Problem the 1st: how do you verify the example project is actually the candidate's own work? Problem the 2nd: building and maintaining a non-trivial open source project is a huge investment of time. There are many competent programmers who have a long list of things they must / would rather do when they get home from sitting at a computer programming all day. It's only more efficient if you send out 100s of applications, but as far as I can tell, competent programmers rarely spam 100s of applications. If you're just putting your toe in the water from time to time, taking a day off to do a traditional tech interview grill fest is a much more effective use of your time. Problem the 3rd: evaluating a large, unfamiliar codebase is actually really hard. All unfamiliar code looks shitty, because you don't have the full context to explain the choices made. Very few people have GitHub pages that actually look good. > I seriously wonder if we should all boycott dev tests. Good luck with that co-ordination problem. Tech interviews suck, for everyone involved. I still haven't heard a proposal for an alternative that isn't fatally flawed. (I consider "take home interviews" to be an incremental improvement on the basic whiteboard problem-solving test)

bbcbasic 11y ago
> Problem the 1st: how do you verify the example project is actually the candidate's own work? Get them to talk about it in the interview > Problem the 2nd: building and maintaining a non-trivial open source project is a huge investment of time... Not really - in one weekend you probably can create something interesting and good enough for showing off to an employer. Also it will probably draw you in and you spend more time (for the fun of it) making it better. But you don't have to. For those people who prefer FizzBuzz tests to implementing interesting stuff, I suggest companies provide the option to do a test for those who don't want to submit their project code. > Good luck with that co-ordination problem. A first stage could be that we say "no tests until at least an interview has occurred and the candidate has progressed to the next stage". That is in any candidates own interests regardless of other's actions - so wouldn't require coordination, just communication of the idea. It is in his own interests because the time spent on the speculative work could be better yielded doing something else, such as attending a meetup and generating more opportunities. Looking at it from a sales perspective of how to spend your time - lead qualification, lead generation etc. Why spend a lot of effort on an unqualified lead?
- matwood 11y ago
  Even trivial code is fine on Github. All I look for is that someone can actually write a bit of code, and a GH repo helps me quickly asses otherwise I have to do more digging. I've interviewed entirely too many people who are clueless and leave me wondering how they have ever had a job writing software. > For those people who prefer FizzBuzz tests to implementing interesting stuff, I suggest companies provide the option to do a test for those who don't want to submit their project code. In fact a great personal GH repo could be to implement FizzBuzz in a bunch of different languages. I think most companies would get an appreciate the joke.
jimbokun 11y ago
"Problem the 1st: how do you verify the example project is actually the candidate's own work?" Have them discuss the code in depth. Architectural and design decisions, coding conventions, alternate approaches they rejected, etc. Pretty hard to fake this if they didn't write the code. "Problem the 3rd: evaluating a large, unfamiliar codebase is actually really hard." Good chance to assess the candidate's ability to document. :) More seriously, though, this is again an opportunity for the candidate to walk you through the code.
- sheepmullet 11y ago
  Yes, but that switches the cost back onto the company instead of the employee.
  - bbcbasic 11y ago
    No it reduces the cost to the employee, with no additional cost to the company. At least in $ or time terms. Sure ... a senior developer interviewer may need to fire up a few extra neurons.
  - collyw 11y ago
    That's how it should be.

bbcbasic 11y ago

> Problem the 1st: how do you verify the example project is actually the candidate's own work? Get them to talk about it in the interview > Problem the 2nd: building and maintaining a non-trivial open source project is a huge investment of time... Not really - in one weekend you probably can create something interesting and good enough for showing off to an employer. Also it will probably draw you in and you spend more time (for the fun of it) making it better. But you don't have to. For those people who prefer FizzBuzz tests to implementing interesting stuff, I suggest companies provide the option to do a test for those who don't want to submit their project code. > Good luck with that co-ordination problem. A first stage could be that we say "no tests until at least an interview has occurred and the candidate has progressed to the next stage". That is in any candidates own interests regardless of other's actions - so wouldn't require coordination, just communication of the idea. It is in his own interests because the time spent on the speculative work could be better yielded doing something else, such as attending a meetup and generating more opportunities. Looking at it from a sales perspective of how to spend your time - lead qualification, lead generation etc. Why spend a lot of effort on an unqualified lead?

matwood 11y ago
Even trivial code is fine on Github. All I look for is that someone can actually write a bit of code, and a GH repo helps me quickly asses otherwise I have to do more digging. I've interviewed entirely too many people who are clueless and leave me wondering how they have ever had a job writing software. > For those people who prefer FizzBuzz tests to implementing interesting stuff, I suggest companies provide the option to do a test for those who don't want to submit their project code. In fact a great personal GH repo could be to implement FizzBuzz in a bunch of different languages. I think most companies would get an appreciate the joke.

jimbokun 11y ago

"Problem the 1st: how do you verify the example project is actually the candidate's own work?" Have them discuss the code in depth. Architectural and design decisions, coding conventions, alternate approaches they rejected, etc. Pretty hard to fake this if they didn't write the code. "Problem the 3rd: evaluating a large, unfamiliar codebase is actually really hard." Good chance to assess the candidate's ability to document. :) More seriously, though, this is again an opportunity for the candidate to walk you through the code.

sheepmullet 11y ago
Yes, but that switches the cost back onto the company instead of the employee.
- bbcbasic 11y ago
  No it reduces the cost to the employee, with no additional cost to the company. At least in $ or time terms. Sure ... a senior developer interviewer may need to fire up a few extra neurons.
- collyw 11y ago
  That's how it should be.