I have been applying to a lot of jobs lately and I've done quite a few "prove you know what's up" tests and projects. I think it might be a good exercise to go over them in my head and talk about how everyone could win from these tests.

Note: this write up is meant for remote development work!

When are employment tests good?

I think tests for entry level/junior positions are necessary to prove:

• Understanding of fundamentals (list, tuple, etc.)
• Experience with testing (nose, pywebtest, selenium)
• Experience with an ORM/SQL
• They are a self-starter and motivated

When are employment tests not as helpful?

If the position you are trying to fill is for an expert or senior level position that applicant should already have ample code samples and open source contributions to go through. I don't think it's necessary to check for fundamentals in this situation. It'd be more important to me that the person is a good fit personality wise for the team.

For a senior position it might be more valuable to give them a problem and ask how they would organize a team to solve it? Not sure, I'm still a Junior!

Photo by JISC

What are useful takeaways?

A good employment test should give the interviewee an opportunity to showcase their skillset.

For example, if testing someone for a Django/Python environment:

• They understand the WSGI-way of building web apps, django views vs class based views, mixins, etc.
• They should be able to write unit tests and functional tests with selenium
• They should be able to do queries with the ORM and build models
• Given very specific instructions, they should be able to finish the test in a reasonable amount of time.
• Give opportunities to showcase something interesting

A good experience I had

In one test I made up a set of models and as a bonus the employers asked me to write up a strategy to test the models.

Not only does this give me an opportunity to strut-my-stuff, but it makes the problem just a little more interesting. I started to open up my brain and think of ways to test the code which made me think more clearly about the overall architecture—and it was fun!

A bad experience I had

If your interviewee is completely baffled by the test because it's so specific and they could solve the problem using their own tools: that is a bad experience for everyone. Valuable time is soaked up during the test Googling how to use library X and framework Y.

Instead, the applicant should be encouraged to use whatever strategy they see fit to solve the problem and then they should be tasked with explaining why they chose that route. Often times when you meet someonew new, they have a few tricks up their sleeve you may have never seen before!

Another bad experience I had

The test was super vague, as if the person who wrote the test didn't care much about the end result. It bothered me that there was a one paragraph explanation and so much openness. No real time limit, no concrete goals. Also, when I asked for more details it took almost a week to get a response. The lack of response made me lose interest in that position.

Photo by Matthew Roth

What are less useful takeaways?

• They know how to do some obscure binary arithmetic.
• Large chunks of the test not entirely related with the position's description, like applying for a Python position but being tested on ASP.
• Solving a problem within very particular restrictions.

When testing an employee for remote work

Do

• Be super organized and descriptive.
• Leave the interviewee alone, only a few questions should be asked. If you are too available it might get the interviewee out of the creative headspace and into the follow-the-leader headspace.
• Test internally first, if no one else can pass your test then it may be too obscure.
• Take as many parts of setup out of the equation as you can: git vs mercurial, database fixtures. Allow the interviewee some latitude to solve problems.

Don't

• Change/improve instructions during testing, it breaks focus and uses up valuable nervous energy.
• Put off answering interviewee questions.
• Put short time limits, give them a way to prove speed but at the same time architect something nice.

I thought I'd take a moment to talk about what I do and where I do it, here it goes!

Why web development?

I've always loved solving problems. In high school one of my hobbies, if you can believe it, was helping out the teachers by making tools for grading, quizzes and studying.

In college my tastes drifted away from Computer Science. I switched to Education and my plan in life was to become a teacher. Everything changed when my mother was in a terrible motorcycle accident. She came out of a coma with a 1% chance to survive, but she suffered massive brain damage.

I dropped out of school and moved home to help, but I needed some way to make a living with a flexible schedule so I could stay with my mum. I picked back up web development and here I am today about three years later.

Why North Idaho?

Killarney Lake

It's beautiful here! I want to raise my family in this great community with safe schools and lots of outdoor activities to do. Recently I have gotten into Kayak Fishing and North Idaho is the place to do it.

Also there is so much around here for great little one day vacations like the Davenport in Spokane with dinner at Sushi.com. Or, if you're into French food, one of my other favorite restaurants is in Post Falls: Fleur de Sel—forgive them for their website!

#represent

That's how I ended up in web development and why I love CDA!