melreams.com

Nerrrrd

What should you ask in an interview: culture edition

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

Last time I talked about what technical questions you should ask in an interview, which is important but culture fit is at least as important. We’ve all heard of The No Asshole Rule, right? I firmly believe there is no such thing as an asshole so brilliant they’re worth working with, so for me culture fit trumps technical skill as long as all the candidates are halfway competent.

So what should you ask in interview to gauge culture fit?

First of all, the way many people talk about culture fit is completely and utterly wrong. Culture fit is not even slightly about figuring out if someone is cool enough to work with you. It is NOT about looking for a brogrammer who will play foosball and drink heavily with your team. It’s also not about finding someone who enjoys the same nerdy TV shows, books, games (video, card, or board), comics, etc as you do.

To quote Donna Choi’s Medium post about how they make hiring decisions at stackoverflow:

Be careful with “Cultural Fit”. This is often a catch-all for a vague sense of “would not fit in”, which can come to mean “is like me”. If you feel someone is a good or bad cultural fit, you must explain what you mean.
Valid “Cultural Fit” things: self-motivated, passionate, gets stuff done, cares about open source / giving back to the community, likes “default open”, hates office politics / meetings, pragmatic attitude towards tools / best practices, etc.
Invalid “Cultural Fit” things: obvious stuff like race, gender, sexual orientation, religion but also softer things like age, personality or hobbies (does not have to like Magic the Gathering to be a good dev). Assume that your bias is to hire people you “like” and be very careful of that.”

Another way to put it is how Johanna Rothman describes culture:

It’s about what you can and cannot say in the organization, how people treat each other, and what we reward.

Culture fit is about values, not about hobbies. A workplace run by grownups does not care even slightly about how “cool” you are or whether you’d be fun to hang out with. They care that you all have compatible views of the world. For example, some companies are very cautious and have very rigid procedures for deploying to production. Others do their best but ultimately feel that rolling back a bad release is not the end of the world. Commitment to work/life balance is another example of culture fit: is the company standard that nobody works overtime unless production is on fire, or are occasional spikes in hours to be expected? Priorities are also part of cultural fit: does the feature need to be perfect or just good enough? Are you planning to grow the company quickly and then sell it off, or are you planning to work here for the next ten years?

Rand Fishkin from Moz has a great definition of what culture fit actually is:

  1. Shared beliefs – the things that you collectively hold to be true about the world (e.g. good people tend to have traits like X, the right way to treat others is Y, what’s appropriate/inappropriate at work is Z).
  2. Shared priorities – what matters in terms of big, overarching things like work/life balance, short vs. long term commitment, how decision are made, etc.
  3. Stylistic cohesion – some people don’t work well together, others find themselves able and inspired to do more when surrounded by a certain type. Cohesion isn’t about finding lots of people who are the same, but about making sure there’s no one on the team that detracts from others and that many get more enjoyment and progress from the diverse perspectives their co-workers bring.

Now that we know what culture fit actually is, how do we figure out whether a candidate will fit?

First of all you need to know what your company’s culture actually is. Without some sort of solid definition, you’re stuck stumbling around asking largely random questions and hiring someone you “have a good feeling about,” which usually comes from them being like you. This is how you end up with a total lack of diversity and bad hires because you don’t actually know what you’re looking for.

Once you know what your culture actually is, it becomes a lot simpler to ask questions about it. If part of your culture is that everybody gets their say when a decision is made, ask your candidate how they think decisions should be made. If part of your culture is that when things go wrong you fix it first, try to keep it from happening again second, and look for someone to blame never, then ask your candidate how they think problems should be handled. If it’s important that your people get enough downtime, ask a team lead/manager candidate how they make sure their team gets enough downtime and how they handle it if upper management suddenly drops a new requirement on them. If you often have to meet rigid deadlines, ask how much flexibility they need.

Like I said in my post about technical interviewing, you are allowed to straight up ask about culture! Just make sure you’re actually asking about culture and not about whether you’d enjoy hanging out with the candidate.

For more example questions, I recommend looking at lists of questions for candidates to ask their interviewers. There’s some good stuff in this list and there are plenty more of them out there. Not all of those questions still make sense if you turn them around to ask a candidate, but you can steal a good chunk of them :)

Sadly, that’s the simple part of interviewing for culture fit. Another really important part is asshole detection, which can be a lot harder. Good culture fit questions will definitely detect at least some assholes, but people can be jerks in very subtle ways. I mean, nobody is going to tell their interviewer that they don’t listen to new ideas, but there is no shortage of people who will do things their way and only their way. People can also quietly wreck your company’s reputation by being enough of a jerk outside of work, in case you weren’t already paranoid about making a bad hire.

Normally I don’t recommend trying to trick your candidate because I think it’s a dick move, but I’ve heard it can be really useful to take a candidate out to lunch or for an after work drink and see how they behave outside of work. You would think people would stay on their best behaviour when they haven’t even started the job yet, but something about being outside the office seems to help people forget they’re still being interviewed. To be fair, I wouldn’t want to work somewhere I couldn’t be myself, so as tricks go I don’t think that one is that bad.

Readers, do you have any tips on catching jerks who are smart enough not to be obvious about it?

What should you ask in an interview?

In a few of my how does it work? posts I’ve mentioned that asking about a particular data structure or algorithm is a boring interview question that doesn’t tell you much of anything about whether your candidate can code.

First of all, the reason I think asking someone to implement a data structure or an algorithm is boring is because all you learn by doing that is whether or not your candidate looked it up beforehand. Not even that, necessarily. Interviews are pretty stressful and plenty of people’s minds go blank when they’re stressed. I once choked on a question about the servlet lifecycle and it’s not like I don’t know how servlets work. If a question might tell you one thing and might tell you nothing, I don’t think it’s a good use of the limited amount of time you have in an interview.

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

I hate ridiculous brainteasers for the same reason – they’re just so binary.  Either your candidate gets the right answer or they don’t, which may or may not tell you anything because a stressful situation where you’re really scared of looking stupid is basically the worst possible environment to solve puzzles in.

Given all that, it seems fair to ask “Well what on earth should I ask in an interview?”

My take on it is that we’re overcomplicating the question. Which is kind of an occupational hazard, so don’t feel too bad about it :) Basically, if you want to know if someone can program, ask them about programming! Just straight up ask them how they would solve a problem.

One of my many pet peeves are wildly improbable scenarios questions like how many piano tuners are there in New York? Google, that’s how many. If you want to know how someone approaches a problem, just give them a programming problem. I really think it’s just weird to dance around the subject you really want to know about. You are allowed to straight up ask people about programming! It’s not as if programming problems are thin on the ground either (hey, what do you do all day again?), although it does take some work to find a problem that doesn’t require twenty minutes of backstory to explain why the problem is a problem. And if you’re asking improbable scenario questions because you want to see how a person thinks about a problem without them jumping directly into code, I think you’re depriving yourself of useful information. If somebody jumps directly into coding without thinking the problem through, I want to know that!

The kind of questions I think are interesting are realistic-ish (obviously you need something relatively simple if you want to ask more than two questions before you run out of time) scenarios like “given a system like x, how would you add feature y?” and “how does your solution change when you discover that the system is actually more like q than like x?” or “what would you do if production went down or was painfully slow?” or “given this description of a weird bug, what would you do to track it down and solve it?”

While every interviewing method has flaws, I like the idea of giving someone a take home project that either takes under two hours or that you pay them for, then talking about the choices they made in the interview. If you want to know if someone can code, just ask them to write some code! But for the love of god don’t ask them to do it on a whiteboard, that’s ridiculous. Coding on a whiteboard in no way resembles what a programmer does all day, even if your candidate is good at it it’s simply irrelevant to the job you’re trying to fill.

The downsides to take home projects are that they’re very biased in favour of people who have the free time outside of work to do them and that like everything else, it’s very very easy to do them badly. I’m willing to spend an hour or two on a take home project, but any more than that and I expect to get paid for my time.  That’s coming from someone who has no children, no pets, no elderly or sick relatives to look after, and practically no chores to do, too. For people who do have responsibilities, asking them to spend n hours of their scant free time on you is a big deal and you need to keep that in mind when you design your take home project.

Which is the other potential problem with take home projects: they need to actually take the amount of time you say they will. Yes, that means you need to have someone at the level you’re trying to hire for solve it first. I would say solve it yourself, but if you’ve been programming for ten years and you’re trying to fill a junior position, you need an actual junior to make sure what you’re asking for is reasonable.

That said, even the worst take home project is much more realistic than the ridiculous idea of asking people to take a short contract with you to see how they actually work with everyone in the office. There is basically zero chance anyone with any responsibilities is going to think “Sure, I’ll definitely quit my stable full-time permanent job to take a two week contract with some yahoo who might hire me if they decide they like me. What could go wrong?” That said, if you’re looking for people you can exploit, by all means keep hiring that way.

On a more cheerful note, a really good idea that came from a discussion on slack is having the candidate read some code and explain what it does. Most professional programming involves way more reading code and making sure you understand it, so much so that it seems like a really good idea to test people on that directly.

In general, ask stuff that directly relates to the job you’re asking someone to do. If you really do want them doing algorithm design then fine, ask them about algorithms. If you’re doing web apps, ask them about the frameworks you use or about general web concepts like concurrency, multi-threading, sessions, basic security, etc. If you do consulting, lean a little harder on scenarios where the candidate needs to ask questions to figure out what the client really needs, which is usually not what they asked for.

What do you think, readers? Do you have any favourite interview questions?

First blogiversary!

I realized the other day my blog is just over a year old. My very first post was a Play framework tip that took two whole sentences to explain. Since then I’ve published 71 more posts, go me! Turns out one or two posts a week over a year really adds up.

What I’ve learned from my year of blogging is that building a habit is way more important to blogging regularly than motivation is. Some weeks I really do not want to write a post, but I do it anyway because breaking the habit bugs me more than sucking it up and writing the damned post :) Seriously, if I waited until inspiration struck to write a post there would be less than a dozen of them on this blog.

Not that you shouldn’t take advantage of motivation when you have it! The big thing that helped me finally start this blog after ages of thinking I should really start blogging was starting a new job and learning all sorts of cool stuff I wanted to a) share, and b) make sure I didn’t forget. Writing things down helps me remember them, and even if I forget stuff I’ve blogged about, I know where to look for it.

Another thing I’ve learned is that explaining something is a great way to learn it. I hope my series of posts about SOLID design principles were useful to other people, but I probably learned more writing them than any of my readers did. You may think you understand something after you’ve read a few posts about it, but there’s nothing like trying to write your own explanation of it to show you where the gaps are in your understanding.

Over the last year my most popular post was Showing up is my secret superpower. It’s really cool that people liked something I wrote enough to share it. Sometimes stuff you throw out there because you don’t know what to write about really clicks with people.

Stay tuned, I’m planning for many more blogiversarys!

Rubber duck debugging

Rubber duck debugging is one of those things that sounds completely ridiculous and is actually really helpful. To summarize the wikipedia page quickly, rubber duck debugging is when you figure out what’s wrong with your code by explaining it very carefully to an inanimate object.

You’re probably wondering why you would bother explaining your code to an object like a rubber duck or a teddy bear if you work as part of a team and you could just ask one of the other devs for help. Sometimes you should go directly to another developer. If there’s a serious bug in production that affects a lot of users, worrying about interrupting someone would be silly, it’s much more important to get production working again than to let Hypothetical Amy finish off her refactoring task before you bother her.

In other situations, it’s more important to give it a try yourself before interrupting anyone. The reason interruptions are such a big deal is that context switching is expensive and it’s even worse when switching to a programming task because of the number of details programmers have to “reload” into their working memory before they can get back into their work. Numbers on exactly how long it takes to get back up to speed after you’ve been interrupted vary, this Fast Company article says it takes a little over 23 minutes to get back on task but this New York Times article says it’s more like 25 minutes. If you ask someone to help you for just five minutes, it’s really not just five minutes, it’s also the time it takes for them to get back into what they were doing. That’s why programmers tend to get so cranky when you interrupt them :)

One way you can try to solve your own problem without interrupting anyone is rubber duck debugging. Having to explain all of the context around your problem, like what you’re trying to accomplish, what your code is supposed to do to get to that end result, what seems to be going wrong, where you think the problem is, what you’ve already tried, etc is one of the most useful parts of asking another person for help, and often the only part you need to solve your problem. Something about the process of explaining a problem to someone else helps you see parts that you missed before, whether it’s a log file you didn’t check or a logic error you didn’t catch. That explaining process doesn’t actually require a person to explain things to, it can work just as well if you explain it to the rubber duck, or the teddy bear, or a voice recording app on your phone or whatever works for you.

Personally, I like to write an email to the person I would ask for help if I really couldn’t figure it out myself. Putting a name at the top seems to help me get into the mindset of thinking about what that person would ask me about the problem and what they would likely suggest I try next. Most of the time I figure it out before I finish the email, but when I don’t, hey, I already have a nice tidy explanation of the problem that I can send to the person I would’ve asked for help anyway :)

If you’re stuck and don’t have anyone around to ask or just want to try everything you can before you ask for help, give rubber duck debugging a try. The worst case scenario is you end up with a good description of your problem that you could send to a friend of post in a forum.

Productivity is overrated

A little while ago I posted a productivity tip and immediately started worrying that I sounded like one of those awful productivity gurus who preach maximum productivity all day every day what do you mean leisure has value?

I want to be very clear here: my worth as a human being is not measured by how much stuff I get done and neither is yours. My sole interest in productivity is breaking the shame spiral.

The shame spiral I’m talking about is the horrible feedback loop where you procrastinate, feel ashamed of not getting enough done, procrastinate more because you associate the work with shame, feeling more ashamed because you’re still not getting anything done and on and on. I don’t want you to be the perfect [insert work here]-producing machine, I want you to be happy and to feel good about what you’ve done at the end of the day. In fact, I actively want you to not be a perfect work-producing machine because that’s no way to live. If you don’t enjoy your life and have time for friends and family (chosen or assigned) and hobbies it doesn’t matter how much you get done.

You will never ever hear productivity tips from me about shit like how much work you can get done if you start waking up at 5 am or how you should listen to professional development audiobooks on your commute. You are allowed to listen to music and relax on your way to work. You do not have to cram something useful into every minute of every day.

A question I hardly ever see anyone ask in articles or blog posts about productivity is why you want to be more productive. Everyone just assumes that getting more done must automatically be a good thing. Getting stuff done is a great feeling if it’s something important to you and you’re not pushing yourself into burnout, but you know what else is great? Downtime. Playing a boardgame with your friends or trying out a new restaurant or going for a walk or reading a novel.

Personally, I do feel unfulfilled if I do nothing but play computer games when I come home from work for too many days in a row. I like the sense of accomplishment that comes from making progress on personal projects. But just like computer games can’t be my whole life, neither can work. That’s just not healthy and that lack of perspective leads to shitty work anyway.

Before you look at a productivity tip, ask yourself why you want to get more done. If you have a project that you want to finish, great! But if you feel guilty if you’re not doing something useful every minute of every day or you don’t want your parents to be disappointed in you or you feel like you’ll be left behind if you don’t spend every minute working, you officially have my permission to say “Fuck it, I’m going to go play videogames.” Don’t be productive for the sake of being productive, do stuff that’s either personally meaningful to you or fun.

 

Showing up is my secret superpower

Or, networking for misanthropic nerds.

I’m shy, awkward around people I don’t know well, and honestly kind of a dork. So how is that I got three of the four jobs I’ve had since college by knowing people? I show up. That’s seriously it. Physically show up to events, make a minimal effort to be friendly, and you will get to know people who will either introduce you to someone who will offer you a job or offer you a job directly.

So let’s get into details. When I say “events” what am I actually talking about? User groups, code camps, meetups, developer get-togethers, conferences, etc. Victoria is not a large city and we still have a wealth of meetups, your city almost certainly has some too. Google is your friend here, as is twitter and other social media. I found out about whiskydev because a friend tweeted about it. At whiskydev I met a friend who introduced me to my new boss, and now I work at an awesome startup.

If you’re particularly shy, I recommend user groups or meetups where someone gives a talk. How do you know the group is having someone give a talk? They’ll usually announce the speaker and topic ahead of time because they’re excited about having an actual speaker (depending on the group’s topic, it can be a huge pain to find someone to speak so organizers are usually pretty stoked about finding someone) and so that people who either don’t care about or love that topic can make plans accordingly. Talks are easier for shy people because a) you can spend most of your time at the meeting quietly taking notes, and b) afterwards you can ask people how they liked the talk instead of agonizing over how to start a conversation. Not that I’ve ever done that.

Another tip for shy people or for people who are really serious about networking is to volunteer. I volunteer with a number of organizations and I speak from experience when I say there is no such thing as too many volunteers. Come early and help set up, stay late and help clean up, or ask the organizers if they need volunteers for anything. The answer will almost certainly be yes, and now you’ll have a defined job to do which makes it way easier to talk to people.

It’s great if you can be friendly and talk to people, but the first step is just physically showing up. Start there and you’ll be fine.

But to be fair, I have to mention that it is possible for showing up to backfire horribly. If you show up and act like an asshole, word will spread. Victoria in particular is a very small town when it comes to tech. The person you’re a jerk to today could easily be friends with the team lead who’ll be interviewing you tomorrow. On the upside, you kind of have to work at it to be enough of a jerk that someone would tell a friend not to hire you. People are generally pretty forgiving and we all know what it’s like to put our foot in our mouths. Just don’t be a dick and you’ll be fine. That doesn’t mean you can’t have opinions, just that you should phrase them as opinions. For example “I hate working with javascript” is just an opinion, but “javascript sucks and only shitty programmers use it” is going to make you look like a jerk.

And one more tip, particularly for students: class counts as networking. Your professors have probably had students before you, and certainly know people in the industry. Those former students may be the ones interviewing you or asking your professor about you. People your former classmates work with might also ask them what you were like as a classmate. Think about what you want them to say before you show up late and blow off assignments. This applies to your current job as well – just like you aren’t going to stay in one place for your entire career, neither are your coworkers. If you interview somewhere a former coworker now works, what are they going to say about you if the interviewer asks them?

To summarize, my tips for networking are:

  1. Show up
    1. Try to be friendly
  2. Don’t be a dick
  3. For extra credit, volunteer

That’s all you need to do to make contacts who might one day help you find a job. “Networking” can sound like something only slimy salesdroids do, but it’s really just showing up and trying to be friendly.