My friend Ron Coulson (who I’ve known practically forever) has challenged himself to write a poem a day this year. He is well underway. This is #63 of 366, because, you know, leap year.
I’ll be the first to admit I’m no poet, but the subject matter here is near and dear to me — learning! I also enjoy a good metaphor and the Viking theme here is vivid and wonderful. Overall, it struck me as fantastic and I thought I’d like to share it with you all. Ron generously agreed. I hope you enjoy it as much as I did!
Let us devour knowledge in a way
That would make vikings cringe
Let’s gorge ourselves until we
Vomit certainties no one can dispute
Let truths drip from our chins
As the spittle of enlightenment
Lands in our opponents eyes
Raise your mugs, my friends
Then chug down life’s lessons
Until we are drunken sages
Then do it all again
-Ron Coulson (2016)
If these words have inspired you to learn, check out the new page I’ve added to the blog where I’m attempting to keep track of some of the best coding katas. Try one out. Let me know if you have favorite katas you’d like to see there.
Remember that the type of person you want to hire is going to expect around 3-4 hours total in the hiring process. If they feel that you don’t perform due diligence with them, their concern will be that you are not doing it with anyone else and that the team will suffer. Of course if the candidate doesn’t seem like a good fit at any point, cut them loose immediately and politely.
If your candidate made it this far, it’s time for…
Phase 3: In-Person Interviewing
Let Your Experts Do The Talking
Next, have candidates interview on-site with your existing people for one to two hours (if you don’t want the whole team in there at once divide the time into 20-30 minute blocks). There are pros and cons to both approaches.
Be sure to communicate any overarching goals with your team. If this person is to fill a specific role, let them know so they can analyze the fit. If everyone you hire should be a continuous learner, make that clear. If you want someone who won’t be bored with tedious work, that should also be communicated. There are only two technical guidelines to stress.
Long coding assignments should not be performed on a whiteboard.
Long coding assignments should not be performed on a whiteboard.
There are plenty of decent alternatives to making a developer sweat about syntax and handwriting. Bring a laptop to the interview and pair program with them. Send them a coding assignment to complete on their own prior to the interview (time-boxed of course). This applies to anything longer than a fizz buzz-type problem.
Otherwise, let your experts ask whatever questions they believe are important. They are evil geniuses who want to unleash hell on your candidates, AND THEY SHOULD. These should be some of the people you trust the most to help achieve your goals as an organization, they know the right questions to ask!
Afterward, get a quick thumbs-up count from your team and if it went well…
Perform A Leadership Review
Do an in-person with anyone your team doesn’t dislike. Probably 30 minutes or less. See if your impressions from the online/phone screenings seem to hold up. If you are considering this person for a role that may increase in responsibility, make sure to ask the right questions (including if they are interested in that sort of thing).
At this point, assuming success, proceed to…
The Final Phase: In-Person Closing
Sell, Sell, Sell (Be Obvious And Honest)
Allow 30 minutes to answer their questions and really sell them on the opportunity.
What you have to offer is great, remember that! This is the company you chose to work for and continue to stick with. Even you you are having a bad day (we are all entitled occasionally) do not sell the opportunity short. Talk about the best parts of your job. Be enthusiastic. After all…
“Nothing great was ever achieved without enthusiasm.”
– Ralph Waldo Emerson
Be completely open and honest. Don’t conceal problems but don’t highlight them as anything other than what they truly are: opportunities to improve. Developers are optimists. We believe in change for the better and want to help it happen. Appeal to our desire to solve problems.
The candidate that makes it this far should have a very informal lunch with the team he will be working with so everyone can get a feel for interpersonal relations… it’s very difficult to get a feel for someone who is expecting trick technical/personal questions at any point and is on foreign territory. Lunch offsite is neutral territory and you can learn a lot about a person in that environment.
Lunch is a good habit to get into anyway. I like it.
It goes without saying that if you get to this point then you most likely have a keeper.
Make An Offer
Do this after lunch or do it the following day. You should know if this is the right person for the job or not. You have all the information. If the answer is no, tell your candidate as soon as you know.
Negotiation is to be expected. However, in today’s competitive market, get your best offer out on the table as soon as possible.
NEVER try to undercut a programmer/developer/engineer/etc. It will not end well for you. The candidate maybe offended and walk, or worse, join the company and go though all the training and ramping-up and leave for a better opportunity in 6 months.
There are many, many jobs and too many online resources available to compare salaries and other benefits. If you aren’t sure you are being realistic, check out your competition on Glassdoor or general rates on Salary.com. Take this data to the powers that be and make a change if needed.
If there are other great reasons to work for the company, things that give you a competitive edge, highlight them. If you have a great environment for learning (see my posts on the subject here, here, and here) tout it! If you’ve hired well-known or respected developers, point candidates to their online presence on Github, LinkedIn, and Stack Overflow for verification. If you have stock options, great healthcare, or free/discounted products, talk about them.
You get the idea.
Overall, this is pretty similar to the process one employer used when convincing me to move to halfway across the country (for minimal pay increase, no stock options, etc.) and I had plenty of other opportunities. The overall process is proven and is common with really good shops that care about hiring the right people. Remember to always end the process after any stage as quickly and succinctly as possible. Do not get a reputation for wasting people’s time.
This is the 3rd and final post in my series on continuous developer learning. I recommend you read 2014 Developer Learning Guide Part 1 and Part 2 if you haven’t already.
When I started writing about this subject, I thought I would cover all of the options in one post.
One of the wonderful things about learning, is that there is a lot to learn about it! I’m in the process of recording a new podcast with a friend of mine and one of our first episodes will iterate just exactly why we believe continuous learning is so important. Stay tuned!
Now, the finale…
In-Person (Larger Groups/Formal Training)
This is one that I need to get more involved in. I’ve heard great things about hackathons. I only attended my very first one a couple weeks ago and it was a good experience (all WiFi issues aside).
Additional personal experience is more related to startup work even less formal than these events. There have been a couple of times I’ve tried to put together a quick app or program in a short amount of time using the MVP or “Minimum Viable Product” approach from The Lean Startup. I found that I learned a remarkable amount in a short amount of time.
I learned even more when I did this together with some friends who ranged in skills from entrepreneur to systems admin to programmer to business development.
Code Camps/Large Conferences
I’ve considered writing an entire post about these. There is nothing like being surrounded by others who are looking to improve and be awesome at what we do.
This kind of event can run from half a day to a full week. They tend to be a little heavier on the pocketbook, but you can find lower cost options as well. If you live in an area with a very active tech community, you will probably have many great local options that at least save you on the travel costs.
Conferences really get the creative juices flowing and keep you fired up about your work. Most major tech companies have at least one developer conference per year (Google, Apple, Facebook, Microsoft).
Employers with a decent training budget send their developers to 1-2 larger conferences per year (almost never 3+).
I try to mix it up like so:
1-2 out of town conferences. I enjoy travel and this is a nice opportunity to get out of the state for a few nights.
2-3 local conferences. To help keep the budget down.
As many code camps as I can reasonably attend.
Why so many? There are a lot of topics I’m interested in and it just so happens that they are all related to my work. This year, I attended an AngularJS conference (ng-conf), an Agile conference (AgileRoots was amazing), Utah Code Camp, and DevFest Family. I’m still planning to attend a large UX conference and a more hard-core software engineering/architecture conference.
I’ve also found it extremely valuable to speak at some of these events. No one learns more than the person who stresses over getting in front of a bunch of smart people to tell them about something!
This type of training is great when you have a team that all needs to get on the same page. Schedule a trainer to come out to your company on your schedule. I will turn you loose on Google for this one… do a little research and you will find many companies offering this type of service.
My experience here is positive. On-site training sessions can be highly valuable just make sure you get a great trainer. Interview them first or suggest a trial session.
Costs, I’m not super sure on but what is published online is $1000-5000 per session. If you think you will have an ongoing need for this, negotiate a better rate.
Certifications are highly valuable for IT people although they are not be as well recognized in development circles. I have a former boss who refused to interview candidates with Microsoft’s developer certification on their resume…
Advanced degrees are valuable if you are specializing in certain areas of our field. Machine learning, concurrent programming, and human computer interaction are all excellent examples.
Both certifications and advanced degrees become considerably more valuable if your company is willing to pay for part or all of the tuition. Without that, I would probably avoid them because your return on investment may not be very good.
As you can see, the options for learning run the full gamut of price, time, and commitment. The great news is, even if your company has little or no budget for training, all you need is a couple committed developers to get started with the less expensive (free) types of training. Even better if your company agrees to a budget or commits to learning in other meaningful ways (time/food/support).
I recommend that you seek out employers who understand and value learning. I have and I couldn’t be more glad.
Remember to read 2014 Developer Learning Guide Part 1 and Part 2 if you haven’t already. Follow me on Twitter (@dubmun) for comments about development and other shenanigans.
In Part 1 of this sequence of blog posts, we covered online and print learning. Part 3 is now available as well. This time we will review some of the in-person options for learning and focus in on smaller groups. But first…
An Elaboration On “The Best”
I suggested in 2014 Developer Learning Guide: Part 1 that A-players, top developers, etc. only want to work for companies that have a great learning culture. This doesn’t necessarily mean that they already ARE working for these companies. The point is that, given the choice, the best developers know the value of learning and want to be part of groups where everyone is actively engaged in it. If you are already working for a company like this, I congratulate you on your outstanding choice!
The most common argument I’ve heard for choosing or sticking with a company with poor learning policies/funding: “If a company pays well enough, I can afford my own learning/training.”
This is true. The fallacy is that all of the developers will use their “extra money” for this purpose. We all have obligations and sometimes paying off that credit card or taking a family trip might take priority over paying for our own training. When the employer provides budget and opportunity specifically for training, the entire team is far more likely to take advantage of it. This leads to the entire team learning and growing together. You avoid the situation where stragglers are content to stagnate and contribute a steadily degrading quality of work (and contribute steadily degrading quality of feedback on teammates’ work).
TL;DR I stand by my original statement with a few caveats.
This is not to say that everyone should try to learn in the same ways. Some people don’t take much away from certain types of training and learning opportunities. There is absolutely nothing wrong with this, in fact, it is the purpose of these posts to provide a comprehensive list of the options that are out there! My hope is that you won’t focus on only one type of training. A rich selection of options awaits. I encourage you to try many and find out which work best for you.
In-Person (Smaller Groups)
Start or join a book club/group/discussion. If you don’t like the word “club” find something different. Oprah won’t mind… why do you even care what she thinks? Hopefully your company is willing to sponsor a book group with lunch provided and books paid. This is a minimal expense and provides a great return on investment. Reading books alone often isn’t enough. Having discussions with peers (who will definitely have takeaways you didn’t consider) is a great way to help maximize learning. In addition, adding coding exercises that pertain to the book topic occasionally really helps to cement the knowledge. More on that later…
One thing I’d like to call out here: if your group is larger than six people, consider breaking out into smaller groups for the majority of your discussion time. This is a neat trick I picked up from Mike Clement at Utah Software Craftsmanship meetups. Large groups tend to lend themselves a couple of antipatterns:
At best some participants may not participate because the more dominant voices in the room are taking up too much time.
At worst, you may have people napping in the back.
We implemented the breakout approach at my current company with great success. We get back together for an overall discussion for 10-15 minutes at the end of the hour and cover the points each group thought were most important.
Selecting the right kind of book is a very important concern here. Voting as a group is a nice way to get an idea of what people are interested in. Always be sure to select titles that will be good for discussion. Code cookbooks are an outstanding example of what not to read. I tend to prefer books grounded in theory, patterns, practices more than how-to books on specific technologies. If you aren’t sure where to start or don’t have money for books initially, there is a lot of great free material for discussions available online. Many blog post make for excellent discussions (hint, wink, nudge).
Presentations/User Groups/Meetups/Open Space
This section is a little more broad. Intentionally. There is an entire class of in-person interactions that can be extremely valuable learning tools. Many are existing groups and some you’ll have to go out of your way to create.
Presentations – The most formal entry of the section. Presentations are sometimes more valuable for the presenter than they are for the people watching. Nothing cements knowledge in your brain like stressing over sharing it with 5 to 500 other people all at once (for me anyway).
What you will take away from attending a presentation depends on your own personal learning style, the effectiveness of the presenter, and how much attention you actually pay to the presentation. I get nuggets from attending presentations but in general they have moderate value for me. So, “Present, present, present!” becomes my mantra.
“But where can I present?” you ask? The opportunities are out there. Present at work, user groups/meetups, coding dojos, code camps, large conferences, or just record yourself and post it online. Not sure how to get started? Go and watch someone present and ask them how they did it. This is also a topic I may write more on in the future.
User Groups/Meetups – Unfortunately I missed a great one of these (Utah Software Craftsmanship) last night because of pressing matters elsewhere. These groups are somewhat hit and miss, but if you find a few that are a good cultural fit and really match your interests they can be fantastic. User groups/meetups are a great place to learn, practice presentation skills, mingle with fellow techies, and often get free food.
If there isn’t a local user group that fits your interests, start your own. The most difficult part is securing a venue but local colleges and businesses are often willing to host your group. In addition, larger groups will attract sponsors who may provide swag for giveaways and/or food.
The best current place to look for a public group (or start one) is on Meetup.com.
Open Space Technology – I’ve only participated in one open space-style of meeting/collaboration unfortunately. It was at an Agile Roots conference back in 2009 and had a fairly profound impact on me. If you have the opportunity to attend an open space, I highly recommend it.
Coding exercises are a general term for writing code following a format lead by a presenter. There are many different subsets of exercises including design, gamified, and code katas. All of these have value, but I’m going to focus on the latter.
If you aren’t familiar with the term code kata, here is what Wikipedia says: “A code kata is an exercise in programming which helps a programmer hone their skills through practice and repetition.” http://en.wikipedia.org/wiki/Kata_(programming). I like to compare it to a martial arts kata where we work to develop the equivalent of “muscle memory” for certain coding techniques. Coding dojos are specialized meetups of people who perform code katas as a group. Participating in a coding dojo is something I look forward to every week. I always learn something new and almost always have the opportunity to help others do the same.
I have a future blog post queued up about my experience with starting a coding dojo at HealthEquity over the past year.
It turns out I have too much to say for a 2 part post. In the third and final part of this post I will cover more in-person options for learning. It focuses on larger groups and formal training. Find it here: Part 3.
Also, be sure to check out Part 1 if you missed it.
I’d love to see your thoughts and comments below or to @dubmun on Twitter.
I had the opportunity to present a couple of sessions at the inaugural Dev Fest Fam conference today.
I’ll predict your next question: “Is this what has been keeping you from posting the sequel to 2014 Developer Learning Guide Part 1?” The honest answer is no. I’ve been busy, it’s true, but I want the next installment of this post to be very good so I’ve been particular about publishing it until it is 100% ready.
This conference is a fantastic idea! It was put on by a couple of local Google User Groups and hosted at Utah Valley University. For a first time conference, it was great and I have the feeling it will only get better. The beauty of it, was that coders/programmers/developers/engineers were to bring not only their spouse or significant other, but also their kids.
I took 3 of my own and they LOVED IT. My 10-year-old daughter coded all night long until it was time for her to go to bed after we came home! So cool!
My first session, “So You Think You Want To Write Code?” was a big hit and well attended:
The second was at the end of the day and was titled: “Websites for Smarties”. It was a beginners hands-on-session teaching the basics of HTML. I used w3schools and Google Sites as resources for teaching. I won’t post more on that here.
So You Think You Want To Write Code? Resources
The slides from my session “So You Think You Want to Write Code?” at Dev Fest Fam 2014 for kids age 8 and up.
The videos played:
I also handed out a flyer with the following information.