DEV Community: Getting Apps Done

Join Some Tech Slacks

Joshua Graham — Sun, 06 Oct 2019 19:24:11 +0000

I posted a brand new podcast episode this week suggesting folks join more tech slacks. I’d love to get some suggestions to share.

I specifically suggested local tech slacks as a great way to get to know local developers and recruiters. But I also suggested there were others like remote worker slacks etc that can be great resources.

It's an amazing way to get to know local developers. These are folks who work for companies you might want to work for.. They can make introductions, suggest companies you should apply you and can even put you forward for positions. Getting to know them and, more importantly, letting them get to know you can be a huge boost to your career.

Equally, a lot of these Slack communities have recruiters keeping an eye on the goings on. They're looking for potential recruits, keeping an eye on (and sharing) local events and generally are really great connections to have.

Connection is a huge part of networking. I used to view networking and marketing fairly negatively, I saw the worst of it. But what I've since learned is that networking and marketing are both based around creating connections and relationships. These are mutually beneficial things that are good for everyone. Yes, some people abuse that, but you don't have to! You can create really awesome relationships with other developers and recruiters and that can be your ticket to the job you're looking for!

Another aspect that goes back to the first one. There are other developers in these communities. Not only can they point out companies to work for and make recommendations... But they're also experienced and experiencing similar things to you. They're looking for jobs. They're freelancers looking for jobs. They're developers who've created apps they're trying to market. Their experience is of value and can help you along your journey. Sharing their experience and yours is a great way to promote the community and yourself!

So, if you're a part of a tech Slack you think would be beneficial to others, I'd love to hear about it so I can share. If you're looking for specific recommendations, feel free to share those as well!

In the meantime, if you're interested in the podcast episode!

Go Join Some Tech Slacks!

Three quick tips for getting a job as a developer

Joshua Graham — Wed, 25 Sep 2019 13:15:51 +0000

Why three quick tips? Why not?! There are a lot of different tips and suggestions for getting a job as a developer, but these are three particularly great ways to stand out.

Why donuts? Because I like donuts. That's why! 🍩

1. Use everything you have to stand out.

I spent a lot of years doing the exact opposite. My resume was perfectly designed to be “normal” it had all the right content. It was formatted cleanly and minimally so as not to offend. I followed every rule of professionalism I could find.

But something magical happened when I decided I just didn’t care. (sorry.. this is as close as we're going to get to a Harry Potter reference this time around...) Someone once told me it’d better to have 90 people hate you and 10 love you than to have 100 simply not notice at all. I think that’s probably a bit extreme, but these days I’m all about showing personality and my unique traits. I’d someone doesn’t like it, maybe I didn’t want to work with them anyway! But, more importantly, it gives me a chance to be noticed!

2. Join your local tech Slacks

Get to know local developers and recruiters. Engage with them and let them get to know you! Again, you want to be noticed, don’t hide away and just watch.

(This isn’t just restricted to Slack. Local dev communities on Meetup, LinkedIn, Facebook, etc can all be just as good.)

If they’re running events volunteer to help out, even if it’s just cleanup after.

If newer developers are asking questions you can answer, answer them! If you’re embarrassed to answer in front of others, answer in private. Word will still get around that you’re helpful.

Have some opinions. If you don’t have any, spend some time researching a particular area of interest until you know enough to have one.

Which leads me to our last item....

3. Write more!

Writing articles (or making videos or podcasts) have three huge advantages.

In order to write something you need some knowledge. That likely means learning more than you know today. They say the best way to learn is to teach!

This also generates more content to gain more of that all important attention. Post your articles here on dev.to. Post them on LinkedIn. Share them in any of the dev communities you found.

Creating this sort of content also puts back into the community. The community supported you in your journey, by adding some back you’re doing your part to ensure there’s fresh content to support newer people.

That's three...

These three alone won't guarantee a job, but they can absolutely put you on the right track. Want some more tips? We talk about these subjects a lot on our podcast Getting Apps Done

Specifically it's worth checking out:

https://gettingappsdone.com/episodes/resumes-interviews-and-chainsaw-wielding-teenagers/

https://gettingappsdone.com/episodes/unicorns-in-business-suits/

Why Community Is So Important For Developers

Joshua Graham — Fri, 20 Sep 2019 15:18:14 +0000

Why Community Is So Important For Developers

Community has changed for developers

In 1995 I got my first computer and signed onto AOL (America Online) for the first time. It didn't take long before I found my way to the various chatrooms that were available on AOL and I immediately fell in love with the idea.

Around the same time, a friend introduced me to creating software. My teenaged and enthusiastic brain very quickly began drawing out UI and planning UX on paper in the evenings planning to build my own chat.

You see, I didn't just want to take something off the shelf and open a chatroom and give it a name. I wanted to BUILD my own chat.

It didn't take long before I discovered IRC and that was it. I was hooked on chats for a long time. It opened me up to an entirely new world that wasn't quite the same as the small town midwest US I grew up in.

IRC was also the default place I went to to find a developer community. We didn't have Twitter or LinkedIn. There was no Dev.to or other great hub for developers online. The term social networking didn't exist. What we did have was books, some web resources, manuals and readmes, forums and IRC.

Now, here's the rub. I found IRC to be a horrible place to learn how to develop software. The "community" was more of a clique. If you were in, you were in. But if you weren't, you were just an idiot. It was built around proving yourself and being better than others. That made it very difficult for it to be inclusive.

Some IRC channels and networks were better than others. Some forums were pretty good. Some folks were just generous and put their knowledge up freely on their websites. But it was hit or miss at best.

The state of community now

The state of the developer community was so bad, it entirely put me off for a long time. I was determined to be a developer, so I was. I learned from books and manuals and those kind people who laboured to share their knowledge on websites.

Somewhere along the journey, things began to change though. Blogging began to become more and more popular and I noticed more people were sharing their knowledge. There was a more open attitude toward people being new to things. It started to feel inclusive.

When I finally did begin to look at communities on the various social networks I was shocked to discover such huge and supportive groups of developers, entry level, senior and everything between conversing freely without fear of being laughed at, kicked or banned simply for not knowing how to do something they'd never done before!

This wasn't the developer mentality I'd given up on and left behind. This was something new and really incredible. The support I saw in groups like #100DaysOfCode on Twitter and here on Dev.to was simply awesome!

Development has changed

So, to the point of this article. Why is this such an important thing? Why is it even more important today than it was when I started developing software?

Development is hard. 😉

I could probably just end right there. I think most of us know that. Development is amazing and joyous and it's the way I've chosen to solve problems for over two decades. But it's also pretty damned difficult! It's hard to get into the developer mindset in the first place. Picking up that first language can be hell.

But it goes further than that. Development is getting harder. In some ways, things have improved so much. Better automatic memory management. Better cross platform and cross browser support. So many new tools out there to make things easier. But all those tools are also a way that things have gotten harder.

There are so many popular languages, frameworks, tools and libraries it's hard to know where to start! This is one of the most common stresses I see from new developers. "Which way is the right way?" "What should my development setup look like?" "Should I be using this tool or this one?" "What language should I learn?" There are just so many options and so many variants and methodologies that it's ridiculously difficult to know if you're going down the right path or a rabbit hole. The burden of choice! it's like being given a giant box of Bertie Bott's Every Flavour Beans with no one to tell you which ones are earwax! (I've been told every article must have a Harry Potter reference... I'm not sure if this is true or not, but I'm sticking with it. 🧙‍♂️)

Community is the way

Communities help us connect with others who are in our situation, some who are just a bit ahead of us and some who are far ahead of us. They add a huge amount of context to everything we do. They provide us with a sounding board to make sure we're on the right track.

Doing this alone is absolutely possible. But humans learn better together. We're social creatures by our nature.

So, get out there and be a little more open. Share an article even if you don't think you've got much to say. If you can't manage a whole article, just a tweet is better than nothing.

Spend a little time encouraging others, sharing your failures, celebrating successes. Every one of those things can help others and the act of being more open will help you in ways you'd not imagine!

How has community supported you on your journey as a developer?

Tips for new developers looking for their first job!

Joshua Graham — Fri, 13 Sep 2019 12:03:32 +0000

Yesterday a new developer asked me for tips and suggestions for getting their first job. One of the suggestions I gave was to get involved in local tech Slacks. Getting to know other local developers, plus recruiters can make a big difference in finding companies that are open to taking on entry level devs, plus if you get to know them well enough they may well be willing to vouch for you, and not much beats that for getting your foot in the door!

What other tips and suggestions do YOU have? What's worked for you, or what are you trying in your search right now?

You've got an interview! Yay! Yikes!? 😬

Joshua Graham — Tue, 10 Sep 2019 13:45:25 +0000

One of the most anxiety inducing parts of getting a job in software development isn't learning how to code or getting your resume into shape, it's surviving interviewing. This is probably true of most fields, but software companies seem to go out of their way to find new and creative ways to pile on the stress!

From phone interviews to Skype video conferencing straight on through to in person interviews, they're all absolutely nerve wracking and can make even the most confident people a little jittery.

It's so easy, when you're nervous, to say the wrong thing, or to hesitate longer than you'd intended, to second guess everything you've said or how you sat or what you were wearing or whether your webcam is straight or not.. did they hear you humming Hedwig's Theme in the waiting room? 🦉 Did you really leave your laundry pile on that table back there... will they notice if you quickly move it? 👖👚👗👕🧺 🤯

I've been through quite a few interviews over the years and sat on both sides of the table. To this day, I get nervous, regardless of which side I'm sitting on. I'm absolutely not an expert on how to overcome all your fears and anxieties or how to nail every single interview, because every single interview will be completely different. Hopefully, though, I can share some tips and advice that will make it a little less terrifying and a little more successful.

Practice, practice, practice!

Above all else, practice makes something closer to perfect! Anything you can do to make the interviewing process feel a little more normal is going to make things go a lot smoother.

Do some mock interviews with a friend, current co-worker, find someone online who's willing to pick up the phone, your neighbour, the cashier at the shop down the road.... ANYONE willing to read some questions out to you, this is a huge step forward.

Practicing this, even with someone you know, will help you solidify what you want to say and how to say it. Note: I don't generally advise memorising and repeating anything verbatim, but having a good idea what you want to say and how you want to respond will make it easier to respond to similar questions in the interview.

If you can find a mentor, someone who's a year ahead of you, maybe even a couple mentors, someone a few years ahead, 10 years ahead... Get advice from them. Practice with them. They'll be able to learn more about you and help you identify things you might struggle with in an interview. (If you don't know anyone else, drop me a line! We can chat!)

Once you've done those things, start taking interviews, even if you're not all that interested in them. You might be surprised! Sometimes interviews taken on a whim turn out to be game changers. Nothing beats a real interview for practice. And if you're going to bomb on a real interview, it might as well be for a job you're not sure you want! 😁

You don't know what you don't know and that's ok!

Inevitably, unless you're applying for a role you're drastically overqualified for, you're probably going to run into a question you don't know the answer to.

I've seen a lot of advice on this one, suggestions like talking around the subject.... I tend to get right to the point. Just flat out tell them. "I don't know." That can be a perfectly valid answer on its own. If you feel they're looking for more, a good way to follow that up is "But, this is how I'd go about figuring it out..."

It's ok not to know everything. Tech is huge. It's great to know things, but it's a lot more important to know how to figure out the things you don't know.

There are also a lot of cases where you DO know the answer, but don't realise it. If you're unsure what they're asking for, you should absolutely ask them for clarification. "Could you please explain what you mean by binary search tree?" Sometimes just getting the definition is enough you can go work out a solution for it.

This is a really common issue in tech, as not all data structures, techniques, patterns, etc have the same names in every language, framework or methodology. We also have a habit of using acronyms for absolutely everything! Sometimes names can be different by industry or region as well. Asking for clarification is absolutely ok.

Teach others how to pass whiteboard tests

They say the best way to learn something is to teach something. There's a huge amount of truth to this. In order to be able to teach another person anything, you need to know more than you'd need to know just to do the thing in the first place.

There will be a lot of things you might know well enough to do them on a daily basis. You might have enough knowledge that you can figure something out with a quick Google and that's good enough when you're working. But in an interview situation you don't always have access to Google! (You should... because it's completely unrealistic to NOT have access to a computer and the internet while programming... but interviews are what they are!) You still need to be able to answer those questions and the best thing you can do is over-prepare.

By learning how to teach others to pass whiteboard tests, you put yourself in a better position to pass them. It's also a great way to pay back the community of developers who have supported you in your journey!

Remember, you're interviewing them too!

This is one that a lot of people miss and it's a shame. If a company hires someone who's not a good fit, they might miss out on some time/money, but most won't really struggle. If you take the wrong job, it can be extremely harmful to your financial and/or mental health.

You should absolutely be interviewing the company more than they're interviewing you. You should be looking for a situation that feels right to you. Where you'll be respected for who you are and what your current capabilities are, but also encouraged and enabled to grow and learn more.

What's important to you will depend on you. For some people it might be about flexible working hours, will you have a mentor to help you grow, do they offer remote working, what sort of clients do they work for (sometimes this can be a really big deal!), are there opportunities for supporting charity events, social activities, work-life balance, etc. Ask the interviewers directly, ask to talk to some people who would be your co-workers so you can ask them. It's well worth taking the time to do this, as these things make a huge difference in finding a great role over one that just pays the bills.

The person interviewing you might have no idea how to interview you

When it comes down to it, the people who will be interviewing you have other jobs. They may well have never interviewed someone before!

The first time I interviewed someone for a technical job I was 20, I had no clue what I was doing! 😬

This is something a person has been asked to do between their normal duties. There's a good chance they're hiring because of a high workload, so this person might well be stressed out and strapped for time.

That's a lot of factors that could lead to them doing a lot of things that really aren't going to help them gauge whether you're a good candidates and a lot more things that could make this a really uncomfortable experience for everyone involved.

This is a good opportunity to try to be accommodating and understanding of the situation they're in. Going in with some empathy and a good attitude can go a long way toward making everything go smoother.

Have a drink!

No, not an alcoholic drink! (Maybe after! 🍾) While I'm sure that could calm your nerves, that's probably not a good idea!

You're going to be talking a lot, which will dehydrate you and dry out your mouth quicker. It's a simple thing, but when they offer some water, take it! There's nothing worse than trying to answer questions when you're parched.

Also, did you know that when your mouth is dry, you make more clicking and popping noises while speaking? (Fun lesson learned from podcasting! 🎙) Having a glass of water at the ready can help with these. It's not the sort of thing people actively notice most of the time, but I try to avoid clicking and popping at the people who are interviewing me. It just doesn't seem like something I should do. 😁

Be you!

I say this all the time when talking about resumes/CVs. But this is entirely true in an interview as well. A big part of the interviewing process is deciding whether or not you'll be a good fit in the team. There are a lot of different ways this is done, some good, some bad. Most somewhere between. But you should always be you.

By pretending to be something else you're sabotaging this for everyone. If you're really not a good fit, or if they really don't like you for who you are, this isn't going to be a good experience for you.

Now, I know, when you've got bills to pay and just need a job, sometimes "good experience" takes a back seat. I totally get that. If that's the case, then your best bet is always going to be to get yourself into a position of financial safety first, THEN go find something that's a good match.

In general, though, if you can be yourself and find a team that appreciates that and gets value from your unique knowledge and personality, that's the best situation to be in.

It's tough, but it's worth it!

There's a lot going on with interviewing. There are a lot of different personalities involved. There are also a lot of pressures on both sides to get things right. All this leads to interviewing being one of the highest stress points of becoming a software developer.

In an ideal world, you'll run into an organisation and an interviewer (or interviewers) who work hard to make this process smoother and less stressful, but that might not be the case. They might not even be capable of doing that.

When it comes down to it, though, if you don't get this job, you'll learn a lot from the experience and take that with you to the next interview. There are so many jobs out there for software developers and so many ways for us to differentiate our skills.

Keep learning, keep trying! It won't take long before you're back here announcing your new role! In the meantime, if you've gotten this far, you're a real software developer already. Welcome aboard! ⛵️

If you'd like some more tips and information about building your resume and interviewing, we talk about these subjects a lot on our podcast Getting Apps Done

Specifically it's worth checking out:

https://gettingappsdone.com/episodes/resumes-interviews-and-chainsaw-wielding-teenagers/

Your First Day As a Developer

Joshua Graham — Fri, 06 Sep 2019 16:01:40 +0000

So, you've learned all the syntax and patterns, written a hundred and fifty-four apps demonstrating different abilities. You've graduated university or bootcamp and stocked your resume chock full of awesome. Your portfolio is looking sharp and really shows off all your skills and abilities. You've survived 38 phone calls, interviews and rejections with little to no feedback.

You've found that one employer who looks right. You were smooth and suave. You nailed that Fizzbuzz backward in ANSI C on the whiteboard while blindfolded and they've offered you a job!

At the end of it all, a large gruff man with a large grizzled beard has informed you: "yer a developer Harry!" (Ok... maybe not that one...)

Now what?

What should you expect on your first day as a developer? What shouldn't you expect? What's going to be expected of you? These are the sorts of questions that could keep a new developer up at night worried, battling with impostor syndrome, burying themselves into books about best practices and dealing with headless branches in Git. (Sounds like a horror story... 🎃)

I recently enjoyed a conversation with my podcast co-host, Kel Piffner about exactly this topic. We came up with quite a few things that really do cover a lot of what to expect as well as some things we've seen a lot of new developers come in expecting that were way off base.. Without further ado and wizard references... 🧙‍♂️🧙‍♀️

You aren't going to know what's going on

Even experienced developers will walk into a new role and be completely lost. Unless this is a completely green field project, there will be a history of code, architecture, infrastructure, constraints and processes in place. These will have grown organically and won't be exactly the same as any other environment you've ever worked in.

This is completely normal! It's a lot to digest and it takes some time to memorise them and know your way around all the different aspects that make up software development.

How are projects managed? Is there infrastructure in house or is it all in the cloud, what the hell is Server08? Oh, that's the UAT server. Wait... What's a UAT server? FYI: User Acceptance Testing (UAT) is like a proposed release in a special environment for end-users to give it a go and make sure it meets all their acceptance criteria... the things they wanted in the first place. There may well be special change control processes in place, the code will be arranged in a particular manner. The company might use micro services, serverless setups, massive crazy continuous integration processes, etc.

These are all things you'll need to learn and understand. Even if you know what everything is, you still need to figure out where things are and how they fit into the grand scheme. It's daunting, but... again... perfectly normal.

The tech stack

I've seen a lot of folks show up and be surprised and upset by the fact that they weren't able to use their preferred tech stack or tools. You don't get to pick the stack you're going to work with.

There will likely be a rich history of technical decisions and organic growth which has caused a particular tech stack to be in place. Or there may well have been a concerted effort to make the decision to use that stack. In either case, what you see is what you get and you're going to have to work with it for the foreseeable.

That doesn't mean everything is set in stone. There may well also be exceptions to this. In general, though, you'll be well served to accept this and start learning as much as you can about the stack you've got to work with.

Your new team!

Hopefully you'll be working with other teams. The company you work for may assign a mentor or buddy to you. They might even assign multiple! Or they might not assign anyone at all....

You are absolutely within you rights to ASK for one if they don't tell you who to ask questions and get advice from, but when it comes down to it every organisation has their own policies for how teams are structured and how on boarding new developers works.

If the company you're working for doesn't offer any of these things, talk to the other developers on your team and get to know them. That can be an excellent way to build a rapport with them as well as finding unofficial mentors!

At the very least, in most organisations you'll be paired up with someone early on to walk through the project(s) and give you a bit of a tour. It's important to pay attention to this, but most folks won't expect you to memorise absolutely everything you learn on the first day (or days)!

Getting help

One of the most important things you'll learn in the first days of your new job is how and where to get help when you need it.

Communicating well with the team is going to make everything go smoother for everyone! That means asking questions when appropriate. If you're stuck on something, you've given it a good go for 30-60 minutes and you're not getting anywhere? Ask someone. Think you know what someone asked for, but you're not sure? Ask them to clarify. It's much better to ask a few more questions now than to go spend two days building the wrong thing!

Back to tech stacks and tooling, if you don't understand why something is in use, it's perfectly ok to ask respectfully about it. "Previously I've used X, it worked really well. I noticed we use Y here, could you explain it a little to me?" goes over a lot better than "I always use X, it's so much better than Y. Y sucks."

I don't know how many times, early in my career, I declared that X was vastly superior to Y, only to have someone more senior explain Y to me and realise I was completely wrong! Don't be me! 😬

Some things expected of you

Above all else, in a new position, you're expected to be willing to learn. As a bunch, I think developers tend to be pretty open to this, so I don't think I need to discuss it too much, but it is probably the single most important thing.

Some things that might be less obvious:

Estimation: You should be able to estimate how long tasks will take you. The better you are at estimating, the easier it makes things on everyone else. They'll be able to plan around you easier and will begin to trust you much faster than if you don't have this skill.

Setting expectations: This is a huge part of communication. Being able to set expectations appropriately makes all the difference in anything. If someone asks for something, make it clear what's involved, how long it will take and what the risks are.

Infrastructure: Having some knowledge of infrastructure is extremely beneficial in all IT. It's not traditionally the role of developers to understand a company's infrastructure, but knowing this helps you develop software better and gives you a greater understanding of what's going on with the software in general. 🖥

Process: Following the existing processes and understanding them is hugely important. This is part of how a team works together. If you're not following the process that can make things much harder on everyone else. So learn them and use them!

You're an important part of the team

Don't go into this thinking there will be senior developers who are shining examples of wonder and splendour. (I am, of course.... 😁) There will be other developers with other experience. They might be more experienced at some things and less at others. But their value doesn't negate yours!

You provide value to the team, and by learning you add more value to the team. It's in everyone's best interest to support that. So always keep in mind that you asking questions and learning is a contribution, not a bother or a nuisance!

There's a good chance you won't be writing code!

In most organisations you're not going to be writing much code at first. It's possible you'll get to work on some low priority items, but there's a very good chance you'll actually be tasked with a non-development job at first. Don't take it personally.

A lot of organisations will start new developers off vetting tickets. I'm a huge fan of this. This is one of the best ways to become a better developer. It's a very different point of view that is extremely important.

You immediately get to talk to the end-users, understand their frustrations as well as their mindset. You start to build mental images of their user personas which will help you make decisions that will improve the product in the long term.

It's also a really great way to get to know the product. By the time you're done verifying issues do exist or figuring out why you'll know the product inside and out. You'll start to understand it's strengths and weaknesses as well as its overall structure.

Take advantage of this opportunity, don't be offended by it! This is a good way to ease you into a new role while allowing you to provide value early on. Providing useful debugging information and possible solutions as well as keeping the queues clear will make you the senior developer's best friend very quickly!

It won't take long at all before they're happily pairing with you or allowing you to write your own bug fixes and feature additions.

It’s going to be different than you expected

I think the big thing to keep in mind is just that it’s going to be different than you have in your head. You’re going to be different as well. You’ll discover some things you thought were strengths really aren’t and you’ll discover new strengths you never knew you had.

It will be weird and wonderful and terrible all together. But this is the start of a journey that has so many possible routes and options!

I’d like to leave you with one parting note before I finish rambling. Many of the developers I see taking entry level positions now are better developers than I was while getting paid to do it professionally! 🤯 Give yourself more credit than you believe you’re due, because you’re probably going to be your harshest critic!

If you’re interested in listening to Kel and I chat about this on our developer podcast check out the latest episode at: https://gettingappsdone.com/episodes/your-first-day/

Go Break Some Resumé Rules! (or not!)

Joshua Graham — Thu, 29 Aug 2019 19:16:02 +0000

A lot of the rules you'll have learned about resumé building aren't all they're cracked up to be!

I remember in school we had a course on writing resumés (known as CVs on this side of the pond!). We were given examples of how to format it, a set of rules to follow and told to go make some.

I'm glad they set aside some time to talk about this, but most of what we were told turned out to be crap. 💩

I'd like to start off by saying, all rules about making resumés are not rules at all. They could be suggestions or guidelines, but there are absolutely no rules.

Your resumé doesn't have to be plain and boring so as not to offend other people. If you like pink, use some pink. If you like pink fluffy unicorns 🦄, then you go on and chuck in some unicorns.

I love helping folks with their resumés and this one comes up a lot when I'm reviewing them. Every single resumé I look at is pretty much identical. If I've got a stack of 20 of them to review to give feedback, or a stack of 100 to look for candidates to interview... it's just a stack of nigh on identical boring resumés with very little to separate them.

So the first piece of feedback feels a bit like marketing 101. It's better to have 90 people absolutely hate your resumé and chuck it in the bin and 10 people absolutely love it, than to have 100 people not notice it at all.

.ltag__user__id__214934 .follow-action-button { background-color: #161616 !important; color: #66e2d5 !important; border-color: #161616 !important; }

Kel

Developer: software | processes | people. Likes cookies 🍪. they/them

KellenPiffner https://kellen.piffner.com

In fact, this can be an awesome thing. Kel, my co-host on the podcast, loves to refer to this as filtering. You can filter as much or as little as you feel comfortable doing, but filtering allows you (and prospective employers) to try to find good matches. When there are no filters, no controversial items in there, nothing that really stands out... then neither side is getting any benefit.

When it comes down to it, your resumé is your elevator pitch. It should lead the person reading it to want to know more about you. Once you've got them hooked, then make it easy for them to find out more. Draw them in and keep them interested!

How to make your resumé stand out

Ok. So it's good to stand out from the pile, but how the hell do you do that?

You be you. What's unique to you? Use your unique experiences to promote you! When someone is looking for candidates, they will have some interest in tech stacks and history, but they're also looking for another human being that's going to contribute to the team.

My sister has one of the best relatively unique pieces of background information. I haven't quite convinced her to use it yet, but it's awesome! She spent some time working with AmeriCorps. Beyond purely being an awesome way to contribute to society and, in her case, doing good work to maintain natural areas, she gained some amazing skills that apply to so many other roles.

She spent part of her time leading a team of young people, most between 18 and 25 doing trail maintenance. We're talking about a bunch of teenagers running around with chainsaws... and no one got hurt. Seriously... Who wouldn't take one look at that and think, "now that's some amazing team leadership!"? Even if I'm looking for software developers those skills are invaluable.

You're looking to stand out, and the things that are unique to you, are what really make that happen. That includes your experiences and your personality, which is another area that's often neglected, or done because someone was following a rule.

Some folks say you shouldn't put anything personal on your CV. Some say you absolutely must. A bit contradictory there... My view is, once again, you be you. Demonstrate your personality by deciding for your own damn self! If you want to slather your CV with unicorns and rainbows, go for it! If you want to show off your design chops and create a modern and amazing experience? Rock on! If you prefer logic and order, show off with a nicely organised minimal setup. No matter what choice, some people will love it, some will hate it. But that will always beat everyone ignoring it.

Information architecture.

Now, I said if you're logical and like order you should make it nicely organised, but this goes for everyone. Information architecture is key. You're building a user experience.

One thing I see a ton of is just following the tried and true format. Name and contact details at the top, followed by a summary, followed by work history, followed by education.

That can be ok, but put a little bit of thought into it. If your education or personal projects are more relevant to the job, then put them above your work history. Put some order to the information to help people find out why you're a good fit.

In addition to organising the information, you need to really think about what you WANT to say.

Don't just flood your resumé with as much information as you can. It can be very tempting to just type out absolutely everything you can think of so you don't miss any opportunities. But what will end up happening is you'll create pure information overload. No one will be able to find the important things! This is definitely a quality over quantity situation!

Do think about some of the types of content you need. One that often gets overlooked is what I like to call "keyword fodder". Most of us will be submitting resumés to job sites where agencies and "head hunters" will be doing keyword searches. It's good to have simple sections that tick the boxes for those.

Along with that, make sure you add context. If you claim to be an expert in Java, make sure you share why. Which roles did you use Java for? How did you use it? How long have you been using Java? I like to stick in a section of my favourite languages and put years next to them.

Note: I'm not a big fan of using stars or any other form. If you tell me you've been developing Python for 3 years, that's something specific. If you tell me you're a 4 star Python developer I'm left wondering... what do you class as a 4 star Python developer?

Bonus: Don't forget the cover letter!

I've actually had people tell me they thought cover letters weren't a thing anymore. This couldn't be further from the truth! Cover letters are the perfect opportunity to be specific. Who are you and why are you, specifically, awesome for this job, specifically?!

Once again, there are no rules. This is a letter from you to the person who's going to read your resumé! Share with them what you think is important!

Bonus Bonus: Github and portfolio

I can't tell you how many times I read a resumé and somewhere in there find a link to their GitHub account. This sounds great in theory. What usually happens is this: I arrive at their GitHub. They have 158 repositories for every single little piece of project work they did in bootcamp or university and I have no clue what I'm supposed to be looking at!

You can star some repos, create really great readme's to explain why this repository is important. What am I looking for? Did you come up with a novel solution to a specific situation? Did you learn something really important while working on it? Did you create an awesome looking interface? Toss in some screenshots! Maybe even a GIF showing off some functionality! Make it easier for me to know why I'm looking at this.

I also strongly believe in building a portfolio site, particularly for frontend devs, but this can be great for everyone. Concentrate the information you want to share! Build some case studies to show off your process. How do you tackle a project? Guide someone through your experience and skills. Show off with a video walk through or twelve of things you've worked on.

So go be you, stand out, do your thing, break some rules

When it comes down to it, a lot of this is about letting you shine through in your resumé and remembering that the rules really aren't rules, even all the things I said in this! If you feel most comfortable following the rules, that's absolutely ok too! But if you do want to break a few, go for it! 😁

Want to know more? We've got a couple podcast episodes that have even more ideas about resumés and interviewing!

Also, if you want some feedback on your resumé, feel free to drop me a note! I'd be happy to check it out and get you some honest feedback.

We're All a Bunch of Impostors!

Joshua Graham — Tue, 20 Aug 2019 15:52:51 +0000

Impostor Syndrome isn't just for new devs

When I talk to newer developers, there's clearly a struggle with impostor syndrome and the frustration of simply not having all the answers. I've had people ask me questions like, "am I smart enough for this?" and so many comments like, "I'm an aspiring developer." from people who are building more complex software than anything I built professionally for a number of years.

I wish I could say that goes away just by gaining in experience, but I can't tell you that without being a lying liar! 🤣 I've been developing software for nearly 25 years and have worked for a lot of companies on a lot of projects and still suffer just as much as ever.

My faith in my ability to build apps has increased drastically, but I still feel like I did early in my career: I'm always looking at other people who know things I don't.

We focus too much on what we don't know

Tech is huge. There's so much out there to see, learn and understand. It's very easy to find things we don't know. It's the same for everyone in this field. When we see someone else who DOES know those things, it's easy to feel like they're ahead of us; they're the guru and we're just faking it.

Sometimes it's hard to put this in perspective and focus on what I DO know instead of all the things I don't. (Let me tell you... that's a big list... 😛) It's hard to stop looking at what everyone else knows, has achieved or is doing and, instead, focus on me. What do I know? What have I achieved? What am I doing that's awesome?

No one is doing us any favours!

When I was in school, I remember teachers and advisors telling me all these things I needed to know. Particularly as I had an interest in computers, they were insistent I had to go to university. I had to study calculus, because I'd use that all the time!

It got to the point I really started to debate whether I wanted to be a programmer at all. I'd been working on personal projects for a couple years. I'd even made some money building websites for people. But everyone kept saying I needed to be awesome at math and know all kinds of things I really had no desire to learn.

It was daunting. It was discouraging. In fact, it was enough I put programming aside for a while and did IT support instead. (Which is something I'm very grateful for, but that's another story entirely!)

As it turns out, I didn't need to know most of those things. I'm not working on advanced algorithms. I don't use trigonometry or calculus on a daily basis (or ever, really..) I use some geometry and some algebra... and that's about it. There are certainly some specialised branches of software development where more advanced math would be useful, but you don't HAVE to learn any of this stuff if it isn't your thing! You can still be an awesome developer with the skills and knowledge sets that ARE your thing.

You don't have to get it all right today

I recently posted about failure, I've been talking a lot about this concept lately, as it's not something many people want to talk too much about. We're told in school that we have to do well. We have to get good grades and if we don't, it's too late. We're built up to believe there's some cut off point where we've just failed.

But failing and learning from our mistakes is part of growing. Just because you don't know something today doesn't mean you won't know it tomorrow or in a year. You don't have to know everything. What you do need is to know how to learn it when you need to.

There's a huge amount of anxiety and stress around this in bootcamps and universities. Worry about not knowing every type of sort or recursion pattern. Fear about not knowing every command Git has or being able to recite off the top of the head exactly how to do a binary tree search.

I get it! Whiteboard tests are real. They're also really crappy. (Again, a message for another time, but I really do hate whiteboard tests!) But most of these things you'll naturally learn on the job. You'll get used to them. In fact, I'd fail most whiteboard tests purely because I learned these by necessity and don't know the names of half of them! But you can and will learn these things well enough to pass the test and get a good job if you stick with it.

Learn to embrace you

When I talk to new developers and look at their Github repositories, a lot of them look the same. I'm really not interested in whether they can recite anything off the top of their head, or immediately know the answer to any arbitrary question or if they've got a repository for every single dev skill in the book they were learning from... I'm looking for people who have their own unique skills and interests.

Instead of worrying about everything we "should" know, I think it's better to embrace who we are. Enjoy what you enjoy, learn what you want to learn and spend more time discovering what makes you happy. Have more fun doing personal projects that are zany and eccentric or if you love beautiful code, do that and highlight it. Build amazing solutions to mundane things or simple solutions to extremely complex things. Figure out what your thing is and focus on that.

One side of impostor syndrome is that we're constantly comparing ourselves to other people... who aren't us. In fact, most of the time we probably wouldn't want to be the person we're comparing ourselves to.

I, personally, find myself comparing me to people who are really great at refactoring or design or new developers who are still so excited about everything javascript. I envy them a bit before I remind myself I wouldn't want to be any one of them. I'd go crazy. That's not me.

If you're new to development

If you're reading this and you're a beginner to development, I'd like to offer a few tips that might help you put some things in perspective.

New developers are awesome. You're so enthusiastic. You haven't been siloed into a particular way of thinking and you bring a huge amount to the table simply by being new!

Ignore what everyone has told you about being a developer. (except me... clearly 😉) Your journey is your own. There are so many ways you can fit in and be an amazing developer that no one else's experiences or knowledge will exactly mirror yours.

Don't stress about job specs. I know, they have a huge shopping list of "requirements" on there, but most of those are simply not requirements. Apply for the job anyway if you think it's a good fit. Write a great covering letter explaining why you think you'd be perfect for the job with or without those required skills! Cover letters are so underrated!

Learn as much as you can about the things that interest you. That's how you'll specialise. That's how you'll find what you're great at. Don't worry about what anyone else is doing. Experiment, if you decide you don't like something you learned, try something new! Embrace those differences! They'll make you stand out.

Finally... give yourself the credit you deserve. You're a software developer. If you've only written the TODO app example or a small shell script, you qualify!

One last note: Kel and I talked recently on the podcast about building your CV/resumé and standing out. We talked about some of the topics in this article from a slightly different perspective. Be sure to check that out too! We may or may not also talk about unicorns in this episode... 🦄 So if that's your thing... we've got you covered!

Failing Doesn't Make You a Failure

Joshua Graham — Mon, 19 Aug 2019 13:29:32 +0000

Failure Is Normal

I screw things up all the time

I got my first computer in 1995 I was introduced to Visual Basic by a friend and pretty much immediately decided programming was what I wanted to do. I've been doing it ever since. A little bit on and off, but mostly, yeah, pretty much since then.

So it's been almost 25 years now. I currently work as a consultant. I run a lot of development teams for a lot of different companies. We have a variety of clients, everything from well established finance and engineering companies to small startups.

I think there a lot of misconceptions about what a developer should be and what we are and how we judge each other and ourselves... probably more ourselves than anybody else... that I think are really wrong and they're hurtful to us and they don't make us better developers at all.

Throughout my career I have built a lot of software. I have created my fair share (maybe a few more... 😬) of null references, caused quite a few infinite loops, caused machines to blue screen, to crash. I've taken out entire server rooms in the past....

I don't tell you these things because I want you to think I'm a bad developer. I want you to know this about me because that's all normal. Ok... to be fair, not everyone will take out an entire server room... But it's normal to make mistakes, to get things wrong, even to just downright screw up.

While I've made mistakes, I've also learned a lot from them and built a lot of software that has been used by thousands of people and stood the test of time.

I feel that's something that we miss a lot. We get this idea that failing is bad. It's very easy to relate failing to being a failure. And we forget that failure is normal; failure is a part of growth.

But it's normal to fail

So I think to start with, it's really important to just know that it is okay to fail. You can still be a rock star developer, you can be a huge asset to a company, create a huge amount of value and be open to the fact that you're going to fail.

I think we all need to kind of keep that in mind because we don't know all the answers. In fact, when I'm hiring a new developer, the first thing I try to find is not that they know all the answers. I typically try NOT to ask them many questions that they have to give me a direct answer to.

I ask them to work with me and to learn with me about something that they don't necessarily know. Because I think it's much more important that you can find the answers; that you're willing to learn and look and seek because, let's face it, even if you do know every single answer today you won't in a year. That's the way tech is.

Failure is a part of growth

I think we can do that by allowing for failure and failing quickly. We should push the boundaries a little bit and increment ourselves just a little bit at a time and push ourselves forward through that process.

There's this concept of progressive overload that's very popular with weightlifting, but I think it works in everything in life, particularly in development.

I remember when I was younger, I played a lot of video games. (My parents swore up and down I should work more on getting jobs and less on playing video games! Sorry mom and dad! 😁) In video games, the best way to level up was to go fight the bad guys who were beyond your current skill level, because you got a lot more experience for them. That was the quickest way to level up.

It's the same with development. If you push a little bit beyond your comfort zone, get outside of that and open yourself to... maybe bombing on this one, but learning from it. Then, when you do screw up, admitting: "Okay, I really screwed this up. What can I do better next time?" Then picking up and moving on from that. Get feedback from others, learn and improve yourself. That's the way to push yourself forward and get closer to being a really great developer.

Safety is a key

The problem is, it's very easy to say failure is ok and normal, but it's very hard to admit to failure because, in general, most of us have a reason to want to avoid that.

I'm scared because, let's face it, I've got kids, I've got to feed them, I've got a mortgage to pay. So when someone who's in some way controlling the money I have to pay for those things is asking me questions, I don't want to admit, "I don't know that" or "I've bombed that" or "I've screwed that up" because I can't do that safely.

Unfortunately, most places are not, as a default, safe places to admit failure. There's a chain of fear. When you tell your boss you did something wrong, they have to tell their boss something went wrong on their watch. When you're in an interview and you don't know the answer to something, even if the person believes you are able to do the job, they're afraid if they bring you on and things go wrong, they'll be held responsible.

In most situations, one of the best things we can do for ourselves is put ourselves in a position of safety. I'm going to admit, right now, this is something easy to say, but harder to do.

Money

One of the single greatest things you can do to put yourself in a position of safety is to put yourself in a good position of financial safety. Pay off any debts you can. Build up a little bit of money, even if it's just to cover your next month.

It's incredible the amount of freedom you get to say, "actually, you know what? If I screw this up, it's probably going to be okay." It's just amazing. It doesn't take a lot to get yourself in a position where you feel a little bit more okay about take a little bit of a risk here and there. As we said, you've got to push yourself a little bit outside of those comfort zones and take a few risks here and there. And the more comfortable you are with that, the more you're able to do that.

Have a backup (and/or back out) plan

Another really great lesson I learned early in my career is: have a backup plan. It's a numbers game. Eventually you're going to fail. It doesn't matter how careful you are it doesn't matter how many scenarios you plan for. Eventually you're going to miss something. Knowing what you plan to do when that happens can make all the difference in the world.

Early on, I had a manager who was absolutely awesome. He allowed me to go push my boundaries. And when I did screw things up he would show up right there and say, "okay, so this happened. What are you going to go do to fix it?" He would then proceed to protect me from everyone else while I did what I needed to do to sort the problem out and learn from it.

And at the time I didn't recognize how important that was, but that was one of the steps in my career that allowed me to understand, okay, so first off, failure is normal and second, I'm going to learn something from this. I'm going to figure out how to fix this. And it didn't take long before I was coming back to him the moment something went wrong, saying, "hey, I screwed up. This is what I'm going to go do. Is that okay?" And he'd say, "yeah, yeah, go for it. Get it done.".

I think having that lesson, learning how to create a backup plan to then not hide from it... not to brush it under the carpet or blame somebody else, but to actually just say, "yeah, I did this..." helped me change how I approach problems.

Transparency changes the picture

I think it's a very good way to begin to be a bit more transparent, to begin to be a little bit more open because most of us are hiding a lot of stuff. Just the act of not hiding it, simply by saying, "you know what? I screwed this up." It makes it okay for somebody else to say, you know, I screwed something up too. The next time, something comes up and they screw something up. They're much more likely to say, "yes, actually I did this. How do we get out of this? What do we do now? What's the next step?"

This is huge for leadership and for teams. There's no magic to it. There's no action plan. Honesty and transparency and respect go hand in hand and tend to spread on their own.

For developers, if your leadership isn't doing this, support each other. Be honest and share with each other. This is what I think of when I think about rockstar developers. This is what I want to be and strive for every day: Not knowing all the answers, but learning new ones all the time, being more open, being more transparent and pushing myself and others forward.

If you want to know a little more about safety and transparency, Kel and I have a couple podcast episodes about these topics:

Put On Your Hardhats!

Failure Is Good!

Also, this is based on a talk I gave at LeicesterJS. You can listen to that talk on the podcast as well!

Compromise and Test

Kel — Mon, 12 Nov 2018 17:41:03 +0000

Photo by rawpixel on Unsplash

In my previous post I talked about what to do when presented with a question of priorities. I argue that the answer is to do "both". But what about when those two priorities are mutually exclusive? "Do we make the button green or orange?" You can't really do both in this case, right?

When two people disagree on a choice like this, it often means there's a fundamental difference in understanding of the topic itself. Maybe they 'weigh' the priorities differently. In the example of "green" vs. "orange", maybe they're really arguing "positive" vs. "bright".

The first step in any disagreement is to get people talking it through. With luck, they can work it out just by sharing their own understandings of the subject. But fairly often the opinions will be strongly held, and difficult to change. So then what?

The answer is exactly the same as the question priorities: Do them both.

In this case, it's not a question of difficulty, but of cost. Doing them both costs twice as much, but often will lead to a better overall solution. This is the same idea behind A/B testing where you put both options out there and let the data decide.

Even for simpler things, where 'common sense' dictates one is probably better than the other, data (or customer feedback) can often reveal completely different understandings.

And beyond ending up with a better solution, this is another way to get arguing team members to compromise and work together, which is almost always more valuable than getting a button color just right.

The Choice of Priorities

Kel — Mon, 22 Oct 2018 21:17:40 +0000

Photo by Brendan Church on Unsplash

Recently my daily feed was filled with a discussion about "What's more important? Writing maintainable software, or shipping software?"

There was a lot of back and forth about code quality, technical debt, not being able to sell something that isn't complete, and all the other points you would expect in this type of argument.

In the end, I'm pretty sure "shippability" was "winning", but I want to make a different point: The fact that you're having an argument about it, that many people have strong opinions on both sides, means that both are important.

Do them both.

Yes, that's more difficult. But that's how you get better, and it's why people pay more for experienced developers.

(If you're new, though, definitely just get something done and make it better over time. "Don't let perfect get in the way of good enough.")

Your interview questions are awful (but we can fix them)

Kel — Wed, 17 Oct 2018 17:17:16 +0000

Photo by Brendan Church on Unsplash

The first time I was involved in a technical interview I was asked to present and grade a coding question: "What does this script do?" The candidate was then handed a print out of a (relatively) simple VBScript that changed the computer name of a Windows PC.

Only one candidate answered correctly. Every other candidate failed the question with an "I don't know."

On first glance, this seems a reasonable question. Part of the job they were interviewing for often required working with scripts to deploy computers and software. I told them that we weren't looking for a specific answer, just a general idea of "What does this do?" The candidate failing to even make a guess seems like an interview fail. They couldn't think on their feet. They couldn't think creatively.

But was it really a failure of the interviewee?

As a test, we handed out that same question to a few of non-technical folks in the office. All of them answered correctly within a minute of skimming it by looking at method and variable names and guessing.

It's been a long time and many interviews since those first ones and I now look at their failure to respond as a failure on my part as the interviewer. If a non-technical person could answer the question correctly, most of these candidates should have gotten it right, too. So why didn't they? Why did they only answer with a "I don't know?"

Fear

Photo by Ben White on Unsplash

Job interviews are scary. Unless they don't need the job, there's real risk involved in failing an interview. Paying bills, making rent, supporting a family, growing their career in a direction that really excites them. The more they want or need the job, the more that fear is present with them in an interview.

An important part of an interviewer's job is to help them relax. You're not going to learn the full range of their skills if they're too nervous to answer your questions. The easiest way to help a candidate relax is to help remove their fear of failing. You can do this surprisingly simply: Ask them more questions that they're going to fail.

It seems backwards, right? But the goal here isn't to catch them in a trap, but to show them that answering a question incorrectly is safe to do. Dig into their wrong answers, see how they got there. Ask similar questions to see if they know related information. If they look nervous, tell them it's ok to not know the answer.

Some people think interviews should test for "handling stressful situations". Unless your business is in high stress situations (think: disaster relief operations), then this is bullshit. It's your job as an employer to provide a safe place to get work done.

Part of what you have to do to measure a candidates full skill is prove to them that you're not going to judge them arbitrarily. Prove to them that one wrong answer will not keep them from getting a chance at a job.

So what should I have done differently? I was on the right track, reassuring them that guesses were fine, but I didn't go far enough in helping them relax or preparing them to answer. And part of that was due to the specificity of the question itself.

Digging into a skill

When you have a question with a specific answer you create a very obvious point where the candidate can fail. They know getting the job relies strongly on the correct answer, and that fear of failure will be eating up most of their thoughts.

To help mitigate this, you ask lots of questions. Think about it like this: Would you prefer one chance, 0% or 100%, on passing a test, or 10 chances, where it's possible to get a 70% passing grade?

In the example of the computer rename script, the skill I was looking for was "The ability to work with scripts". Preferably creating and editing, but just being able to read them to see if it "did what you want" would have been fine.

A better question: "Have you ever used a script to automate a task before?"

"But wait!" you say. "That answer isn't measurable! How do I know if they got it right?!" Answer: You ask more questions.

For example: If the candidate said yes, ask them about the time they used it. Ask them about what it did, how many computers it ran on. Ask them where they found the script, and how they knew what it did.

Even if they said no, they still haven't necessarily failed. Ask them if they think they could "figure it out." (I've yet to interview a technical job candidate who wasn't confident they could figure something out that they didn't know given time and google). Now do the handout. The handout in our interview was an actual script we used daily. It was an accurate representation of the job. Tell them that. It gives them incentive to really try figuring it out since it's the job they want to do. For an even more accurate job representation, hand them a laptop with Google ready. Letting someone know that you won't arbitrarily limit their tools to get a job done does wonders for relaxing them.

By the power of your beard and Google, figure out the answer. Photo by rawpixel on Unsplash

Measuring a skill

After reading the above, you're probably thinking "But that question sounds too easy with all that help". You're right! And isn't that great? Think about how many candidates could show that they could really do the job. We just went from one, to (likely) all of them.

On top of that, if you went down the first question path, you know how deep their scripting skills go. You can measure it relative to your own skill. Are they better at scripting than you? Worse? Maybe they've written lots of scripts, but in different areas than yours. Write that down. Those are all important impressions to use when comparing candidates against each other.

Before you begin an interview, you should have a list of specific skills you're looking for and a list of open ended questions that can help candidates tell you about times they've used those skills.

Once you have that list, talk to them until you can answer these questions:

Do they know more than you?
Do they know less? How long would it take you to train them to a level of competence needed to do the job?
Do they have other, similar skills to make up for not knowing this specific skill? How deep does that skill go?
How excited are they about the skill. Is it an interest? Something they hate but do anyway?

A helpful "trick" for getting to the depth of a candidates skill is to tell them exactly what you're looking for! They'll be eager to show you that they can do it, or to show you skills similar to what you're looking for.

Keep in mind the real question you're trying to answer: Do they have the skill and desire necessary to do the job? If you can't confidently say 'yes' or 'no', keep digging, keep asking questions. I really can't stress this enough. This is important. You're in a position of authority - in a position to approve or deny them livelihood. If you reject someone for a position, you should be prepared to explain the reasons why for your choice.

Note: I've found it common that interviewers don't feel confident enough in their own abilities to judge someone else. Two things to keep in mind:

You're measuring their skill relative to yours. You don't need to know everything about a subject to do that.

Someone, likely your manager, thought you were qualified because you had the skills they're looking for. You can do this.

If you really aren't qualified, though, make sure someone else in the room is. (For example: back when I gave that first interview, you wouldn't have wanted me to grade someone's diplomatic skills.)

Comparing candidates

Once you have the relative skill of candidates, it's pretty straightforward to compare them. Once again, though, you should be able to confidently describe why one candidate is better than another. Use specific terms. In a perfect world, you would be able to coach a failed candidate explaining the things they should work on.

Also, you should have multiple people performing these skill measurements, and the people doing those measurements should have the skill level you're looking for. (There's no real point in having your worst communicator interviewing someone about their email skills.)

One other thing to keep in mind: Sometimes a candidate comes along with a great set of skills that doesn't neatly fit into any one role. If you can make it work in your organization, these people make great employees. The diversity of those skills can lead to innovative solutions to difficult problems. When you can: fit roles to people, not people to roles.

Iterating your process

A lot of my opinions on interviews formed after my boss handed me a stack of developer resumes and told me I had 30 minutes to screen each of them for the necessary tech skills. Three or four interviews a day, generally given back to back, for a couple weeks.

During that time, I iterated. I wrote down which questions worked well to draw out a candidates skills and which ones didn't. Most of the time I could confidently tell within those 30 minutes whether they had what we wanted or not. And, if I wasn't confident, I passed them on anyway. I didn't want my gut 'feeling' to be the deciding factor on someone's employment.

But I was mostly surprised at how effective this method was. At the end of every interview, I could accurately communicate their skills relative to mine to my manager so he knew which ones to interview next, and I could repeat the results of the process with the next candidate.

Iteration is always important. Something I've learned relatively recently is to keep metrics at each 'stage' of an interview process. Every stage acts like a 'filter'. They're an arbitrary line in the sand that candidates have to make it across. "The top 10 candidates". It's important to know where people fall out and if great candidates are falling through. If you see a problem, fix it and try again.

Some additional reading on the subject: We’re Bad at Interviewing Developers (and How to Fix It). (I swear I didn't intentionally pick the same title. Great minds think alike?)

Conclusion - Interviews vs. Tests

Photo by rawpixel on Unsplash

Finally, I'm not Google or Facebook. When you start hiring on that scale, you need more specific metrics to be able to assure relative consistency of skills. Those types of questions have become the 'standardized testing' of jobs.

If you're not hiring on that scale, then you likely just want more developers like the ones you have. Let them interview and make good decisions from that.

And if you do need metrics, test, but don't grade based on the results of those tests. Try to avoid letting your measuring instrument influence the results of what you're trying to measure.