Skip to main content
added 159 characters in body
Source Link
AnoE
  • 9.1k
  • 18
  • 37

This answer makes no statement on whether these kinds of tests are a good thing or not (or whether I condone them), but focuses on the specific question.

How can I decide if I should take on technical tests that I consider absurd (e.g. an unreasonably large task with a short time limit) in the future?

Like you would do in the real world:

  • Communicate how long the task would take reasonably.
  • Lay out your plan of what to do in the given time (i.e., do less, or do it worse, or both).
  • Do as much as you can, to the least level of quality which you can stomach. Focus on getting a working solution before a complete solution.
  • Document clearly where you cut corners, what the implications are, and the resulting TODOs.

All of this would help me greatly, as an employer or client, to judge whether I want to to work with you.

Depending on the management structure of the employer/client, the guy employing you (i.e., your direct boss/customer) could very well be in a position where he cannot influence what kind of work you get. Matrix management does exist... in this case I would prefer to have someone who can handle such situations with grace over a hero who delivers the greatest code of all time, but is not able to communicate about time/quality limits.

The exact measure of whether to go for more quality, or for more content, depends. For example, in your case, you will probably be mostly interested in them seeing that you can provide quality work. So you might cut a few features (by using some placeholder etc.), but keep your code quality high. Similarly, if the work were, say, security related, you would do the same. But if it's a completely uncritical proof of concept of something, then one might veer more in the other direction. Document all of this (succinctly), and you're well on your way.

PS: I like to avoid "mad or bad" judgements. I.e., you should not care about whether the client is just crazy, or out to get you (i.e., have you perform work for free), solely judging by the size of the task. The real quantity that matters to you is your time, and that was fixed. As long as you're fine with investing the two hours into a potential new client, it should not matter whether the task is easily done, or a high pressure job, or just two hours of small talk at their office.

How can I decide if I should take on technical tests that I consider absurd (e.g. an unreasonably large task with a short time limit) in the future?

Like you would do in the real world:

  • Communicate how long the task would take reasonably.
  • Lay out your plan of what to do in the given time (i.e., do less, or do it worse, or both).
  • Do as much as you can, to the least level of quality which you can stomach. Focus on getting a working solution before a complete solution.
  • Document clearly where you cut corners, what the implications are, and the resulting TODOs.

All of this would help me greatly, as an employer or client, to judge whether I want to to work with you.

Depending on the management structure of the employer/client, the guy employing you (i.e., your direct boss/customer) could very well be in a position where he cannot influence what kind of work you get. Matrix management does exist... in this case I would prefer to have someone who can handle such situations with grace over a hero who delivers the greatest code of all time, but is not able to communicate about time/quality limits.

The exact measure of whether to go for more quality, or for more content, depends. For example, in your case, you will probably be mostly interested in them seeing that you can provide quality work. So you might cut a few features (by using some placeholder etc.), but keep your code quality high. Similarly, if the work were, say, security related, you would do the same. But if it's a completely uncritical proof of concept of something, then one might veer more in the other direction. Document all of this (succinctly), and you're well on your way.

PS: I like to avoid "mad or bad" judgements. I.e., you should not care about whether the client is just crazy, or out to get you (i.e., have you perform work for free), solely judging by the size of the task. The real quantity that matters to you is your time, and that was fixed. As long as you're fine with investing the two hours into a potential new client, it should not matter whether the task is easily done, or a high pressure job, or just two hours of small talk at their office.

This answer makes no statement on whether these kinds of tests are a good thing or not (or whether I condone them), but focuses on the specific question.

How can I decide if I should take on technical tests that I consider absurd (e.g. an unreasonably large task with a short time limit) in the future?

Like you would do in the real world:

  • Communicate how long the task would take reasonably.
  • Lay out your plan of what to do in the given time (i.e., do less, or do it worse, or both).
  • Do as much as you can, to the least level of quality which you can stomach. Focus on getting a working solution before a complete solution.
  • Document clearly where you cut corners, what the implications are, and the resulting TODOs.

All of this would help me greatly, as an employer or client, to judge whether I want to to work with you.

Depending on the management structure of the employer/client, the guy employing you (i.e., your direct boss/customer) could very well be in a position where he cannot influence what kind of work you get. Matrix management does exist... in this case I would prefer to have someone who can handle such situations with grace over a hero who delivers the greatest code of all time, but is not able to communicate about time/quality limits.

The exact measure of whether to go for more quality, or for more content, depends. For example, in your case, you will probably be mostly interested in them seeing that you can provide quality work. So you might cut a few features (by using some placeholder etc.), but keep your code quality high. Similarly, if the work were, say, security related, you would do the same. But if it's a completely uncritical proof of concept of something, then one might veer more in the other direction. Document all of this (succinctly), and you're well on your way.

PS: I like to avoid "mad or bad" judgements. I.e., you should not care about whether the client is just crazy, or out to get you (i.e., have you perform work for free), solely judging by the size of the task. The real quantity that matters to you is your time, and that was fixed. As long as you're fine with investing the two hours into a potential new client, it should not matter whether the task is easily done, or a high pressure job, or just two hours of small talk at their office.

Source Link
AnoE
  • 9.1k
  • 18
  • 37

How can I decide if I should take on technical tests that I consider absurd (e.g. an unreasonably large task with a short time limit) in the future?

Like you would do in the real world:

  • Communicate how long the task would take reasonably.
  • Lay out your plan of what to do in the given time (i.e., do less, or do it worse, or both).
  • Do as much as you can, to the least level of quality which you can stomach. Focus on getting a working solution before a complete solution.
  • Document clearly where you cut corners, what the implications are, and the resulting TODOs.

All of this would help me greatly, as an employer or client, to judge whether I want to to work with you.

Depending on the management structure of the employer/client, the guy employing you (i.e., your direct boss/customer) could very well be in a position where he cannot influence what kind of work you get. Matrix management does exist... in this case I would prefer to have someone who can handle such situations with grace over a hero who delivers the greatest code of all time, but is not able to communicate about time/quality limits.

The exact measure of whether to go for more quality, or for more content, depends. For example, in your case, you will probably be mostly interested in them seeing that you can provide quality work. So you might cut a few features (by using some placeholder etc.), but keep your code quality high. Similarly, if the work were, say, security related, you would do the same. But if it's a completely uncritical proof of concept of something, then one might veer more in the other direction. Document all of this (succinctly), and you're well on your way.

PS: I like to avoid "mad or bad" judgements. I.e., you should not care about whether the client is just crazy, or out to get you (i.e., have you perform work for free), solely judging by the size of the task. The real quantity that matters to you is your time, and that was fixed. As long as you're fine with investing the two hours into a potential new client, it should not matter whether the task is easily done, or a high pressure job, or just two hours of small talk at their office.