Bonus Points For Project-Based Interviews

I'm in the middle of a job hunt right now, and so I'm thinking about a lot of issues as they relate to questions I'm asking during interviews. How do these companies determine 'culture fit'? How do I know whether or not their culture is inclusive? Will I be taken seriously, will I be listened to?

But the question that's obviously giving me the most headaches is whether or not I'll come off sounding knowledgeable during an interview. That's natural, right?

After 15 years in this field, I still suffer a little from impostor syndrome, and nowhere does that show itself more clearly than when I need to stifle it the most - during an interview.

Classic Q&A-style tech interviews are such a challenge for me. I am not great at regurgitating facts out of the standard library documentation. That's especially true when I'm being interviewed by a man (or group of men) - there's an unfortunate dynamic there that makes me question whether or not I belong.

But you know, that's not how I use Python every day anyway. You don't really want to gauge how well someone has memorized the standard library docs. In day-to-day programming work, it's not about what you've memorized - it's about knowing what to look up, knowing what questions to ask.

What you really want to know is how they approach problems, and how well they solve them. But asking someone to write a function or debug some code doesn't work as well either. I've had tasks like that as an interviewee. They might seem simple, the kinds of problem-solving exercises that might normally only take a few minutes, but when you're being watched, knowing you're being judged and scrutinized, those simple problems can become monumental.

And that's also not a reflection of how problems get solved in the real world. In a real development environment, there's collaboration, often there's more flexible time.

What I really prefer are project-based interviews - what are sometimes called take-home assignments - where I can develop some code beforehand and then explain my decisions to an interviewer. I've had a lot of success with this type of interview - from both sides of the process. It makes the interview feel less like a pressure cooker and more like an opportunity to show you what I can actually do.

How it works:

• Define a project goal, such as "build this type of game"
• Add some parameters - specific libraries to use, any specific functionality you want to see
• Don't mention tests, see if you get them

Then on the day of the interview, spend some time going over the code and examine the decision-making that went into it.

I understand the argument that this kind of exercise takes up too much free time for the interviewee. But as said interviewee, my position is this:

As programmers (particularly in open source), we're expected to write code in our spare time to contribute to open source libraries and projects, so that we can be judged on the quality/amount of that code. We're expected to write tech blogs and contribute in all kinds of other ways. All of that is unpaid work, usually done in our free time.

But somehow a few hours writing a take-home assignment is too much time to spend? For not-the-right-job, yes, I agree that it would be too much. But for the right job? I would feel just as excited about writing that code as I would about any other open source contribution.