4 ms·

Thanks for the frank feedback. You raise a valid point: I should make more explicit what I am evaluating in the solution. I will update the relevant document s

Thanks for the frank feedback. You raise a valid point: I should make more explicit what I am evaluating in the solution. I will update the relevant document so that future applicants have a clearer idea of what they're being 'graded' on. Regarding the other points you raised, I disagree with many of them, but I think I'd chalk it up to 'reasonable people can disagree on these things'. If you would like me to respond to a specific item, let me know and I'll do my best. Best of luck, Diarmuid

wayn3 10y ago
Well, since you seem to know who I am, you probably know which challenge I was given. Do you really think its not an OO problem? Otherwise, you can probably have some of your other engineers review these tests if you are too busy to do it yourself. Not like this is rocket science. They can at least weed out clear failures like me :D
- basecase_com 10y ago
  > Well, since you seem to know who I am, you > probably know which challenge I was given. > Do you really think its not an OO problem? OO is indeed the most common strategy for solving the problem you received. However I'm sure you appreciate that you could use many different techniques. I think that after OO, ~functional solutions (ie: 90% pure functions, 10% non-pure) would be the next most popular. Such solutions can be quite elegant. > Otherwise, you can probably have some of > your other engineers review these tests if > you are too busy to do it yourself. Not > like this is rocket science. They can at > least weed out clear failures like me :D I know you're joking but I certainly realize that I reject many candidates who would actually have been great hires. It isn't possible for me to evaluate people 100% accurately, so I have to settle for conclusions drawn from an admittedly imperfect process. As for getting other engineers to help with the review process: I've been reluctant to do so in the past for a variety of reasons, but after 8 years (!) I'm actually considering it. Cheers, Diarmuid
- hvo 10y ago
  "If the hiring/interview process is needlessly complicated, run."

wayn3 10y ago

Well, since you seem to know who I am, you probably know which challenge I was given. Do you really think its not an OO problem? Otherwise, you can probably have some of your other engineers review these tests if you are too busy to do it yourself. Not like this is rocket science. They can at least weed out clear failures like me :D

basecase_com 10y ago
> Well, since you seem to know who I am, you > probably know which challenge I was given. > Do you really think its not an OO problem? OO is indeed the most common strategy for solving the problem you received. However I'm sure you appreciate that you could use many different techniques. I think that after OO, ~functional solutions (ie: 90% pure functions, 10% non-pure) would be the next most popular. Such solutions can be quite elegant. > Otherwise, you can probably have some of > your other engineers review these tests if > you are too busy to do it yourself. Not > like this is rocket science. They can at > least weed out clear failures like me :D I know you're joking but I certainly realize that I reject many candidates who would actually have been great hires. It isn't possible for me to evaluate people 100% accurately, so I have to settle for conclusions drawn from an admittedly imperfect process. As for getting other engineers to help with the review process: I've been reluctant to do so in the past for a variety of reasons, but after 8 years (!) I'm actually considering it. Cheers, Diarmuid
hvo 10y ago
"If the hiring/interview process is needlessly complicated, run."