Well that's very nice of you.
Here's my thoughts on tests - from an employers POV.
A test is a way of filtering large number of applicants down to a manageable number to interview. As such the questions try and focus on key areas the hiring manager requires. Some might be happy with a generic <insert language here> test, however we (and others) focus on certain aspects that we require *as a baseline*.
Test questions might be anything from fundamental principles (eg. logic), to API knowledge, to general knowledge.
But they do just provide a filter. Sometimes you get false positives (unsuitable applicant passes), sometimes you get false negatives (suitable applicant fails). Although this can seem (and indeed is) personal to the applicant, it is just a game of numbers to the hirer.
As an example I've got through 1,400 CVs in the past 12 months. If I'd have reviewed each CV properly it would have taken nearly 8 months work. To interview, would taken that up to 23.5 months.
The message I'm trying to get across is that you should not consider a fail at any particular test or interview for *any* company a personal thing.
The company will be looking for *suitable* employees - this doesnt just mean skills, it can mean personal attitude, team work, culture, language, etc etc. Some companies might even hire based on a willingness to work 12hr days 6 days a week (not me though!).
Just some thoughts from someone who's done a lot of interviewing and also been an interviewee a lot (I'm from a technical background - if you want to see my history then it's
here )
mbc
that only make sense if the test question is related to the position.
if you intend to broaden up those question, do that in verbal/face to face.
don't lum-sum anything to a test paper.
if you intend to use that at 1st filter, do it intelligently.
question about "king of programmer" in test paper, its a joke.