Testing a new Apprentice Developer

Question

We are a website development company who is trialing an apprentice for 2 days. The aim is to see how much knowledge he really has and how much he is dedicated. We wish to perhaps test him in practical ways and not sit him behind a desk and throw him exam papers.

How could we test the apprentice who has little knowledge on PHP and sql (what we use)? The apprentice is 17 years old and has little to no experience. What activities would be good to give him that are not harsh but give us feedback to see if he/she is good for the role?

Answer 1

The apprentice is 17 years old and has little to no experience.

But, you say:

The aim is to see how much knowledge he really has

So, what is it? Are you going to test his mental capacity? Problem solving skills? Organizational socialization skills (how well he adapts)? Whether or not he knows the different between a UNION or a FULL OUTER JOIN?

I would give the apprentice a small, very simple project, and use one of your senior developers as a "mentor" for this individual. Let the apprentice know that they have someone to fall back on and it also gives them a chance to interact with others within the company. You can also use feedback from your senior developer so you don't have to micro manage this person.

Give them the freedom to think and the support network of a mentor to ask the questions to.

A simple project could be:

1. Create a webpage with minor styling and a login form (username and password)
2. Allow users to save that information to the database (basic php/sql test)
3. Don't allow Nulls (submitting a blank textbox) and use parameterized queries.
4. After someone has successfuly saved data to the database, reroute them to another webpage with the words "Thanks for registering." (or something trivial)

Answer 2

Put together some basic "queries" that could be used.

See how he arrives at his answers if you want someone who is going to be asking questions then rate him on that. if you want someone who can work by themselves see if they can find the answer on the web (assuming you give him a moderate amount of access) then also rate him on that, if he does both once or twice do that, then ask him "now how can you make that query better/simpler etc" and keep doing that, let him grow naturally, but also judge how happy he looks doing it.

Answer 3

I like Jimmy's answer, but feel like it could be extended upon further. Not knowing how much experience the person has, turn the "simple project" into something that can show basic and extended ability (as well as demonstrate how eager they are to learn technologies when they're not familiar).

What I mean by that is (again, borrowing @Jimmy's example) you may ask for one thing, but provide a "bonus" version of it shortly thereafter. For instance:

• Creating functional pages is one thing, while asking for a uniform/polished styling is extra credit.
• Being able to create login form, but adding validation to the form may be the extra credit.
• Mandating a specific user/password is used for authentication, while having them establish a database and a register form (using a database) would be the extra credit.

So on and so forth. This allows you to gain insight into a few metrics:

• Basic demonstration of ability
  Were they able to tackle some of the bonus tasks, and, if so, how many/which were they comfortable implementing?
• Task prioritization
  Were all required tasks done and were working on bonuses, or were they doing each one serially and didn't get some of the final tasks done.
• What questions were asked (if any)
  Did your mentor developer get approached on some of the topics they were unfamiliar with.
• Enthusiasm/self learning
  Did s/he do the bare minimum or try to do more (did they do the CSS themselves or use a Twitter Bootstrap)? You may learn what they are really efficient at just by the process they used.

I might even place an item at the bottom (separated from the list, but in the closest following paragraph) about optionally using source control. Something that describes you'd like them (if comfortable) to use the source control and check-in between tasks. From there, if/how it was used gives you a little more insight:

• Not Used
  • Mentor not approached
    Probably didn't even read the paragraph (keep this in mind for task that require micro and macro understandings).
  • Mentor approached
    Read paragraph, but not sure what it is.
• Used
  • One big check-in
    Last minute thing, they work-top to bottom without deviation.
  • Individual check-ins per item
    Read the entire requirement first (bonus: you have insight into how they work.)