You know how it is, you can work with technology X for 3 solid years, know the API inside out, etc. But then you work on another project using other technology and 3-6 months later you could damn well still work in X but would have to have a short period to get back up to speed.
For an interesting position I found, the client wants to give a technical test to remote applicants... 30min to actually write code in X. Now I know full well I can do the work but 30min is a hard call if you are rusty... you could spend all the time trying to remember how the config files work or looking up the name of the class you want to use!
I think both of us agree with Joel Spolsky's view "pick the best developer, not the one who can recite the API by memory" but I'm not sure how to play it. Since it's remote/freelance work I guess I could make some short-term concession on rate to get my foot in the door since the project and normal rate are pretty attractive - this is not uncommon in the freelancing, non-agent-based world although I'm sure it sounds odd.
Any advice?
For an interesting position I found, the client wants to give a technical test to remote applicants... 30min to actually write code in X. Now I know full well I can do the work but 30min is a hard call if you are rusty... you could spend all the time trying to remember how the config files work or looking up the name of the class you want to use!
I think both of us agree with Joel Spolsky's view "pick the best developer, not the one who can recite the API by memory" but I'm not sure how to play it. Since it's remote/freelance work I guess I could make some short-term concession on rate to get my foot in the door since the project and normal rate are pretty attractive - this is not uncommon in the freelancing, non-agent-based world although I'm sure it sounds odd.
Any advice?
Comment