Blog Moved

My blog has moved!

Sunday, June 14, 2015

Identifying Talent....literally half the battle

So got a lot of positive feedback about last week's post which is great. Thank you all for the feedback and emails. All very much appreciated.

So I wanted to continue following through on last week's post and talk about how to develop great developers for your team. But to do that the very first thing we need to talk about is hiring. Let's face it, if who you chose sent matter the NFL draft wouldn't be that big a deal.

Over the past few years, a decent part of my job has become doing technical interviews for not just my own development teams, but for other teams as well.  Its something that I've done quite a bit of for a while now.  I've probably done upwards of 100 technical interviews in the past 3-4 years or so.  This is one of those topics that many developers write off, and that fact alone proves to continually come back to bite people in the butt when they end up hiring a bad resource.  There are lots of developers out there, and finding a good one can be like trying to divine water.  

If you want to build something you need that strong foundation to build off of. And that foundation isn't something you get to create. Think about it this way, I can have plans to build the most amazing house. But if the property I choose is the Sahara it is just going to keep sinking. It's why the three most important things in real estate are location, location, location.

So how do you make sure that the candidates you choose to hire have that foundation?  The most important thing I've found, isn't necessarily a background in the technologies you are looking to use, but instead a passion to learn.

It's worth noting here, that I'm talking strictly about hiring Jr. Developers, not necessarily mid-level or senior developers.  There are very different types of things that I recommend you look for there.

If my time as a college professor has taught me anything, its that you can teach anyone to program.  Absolutely anyone can learn.  All it takes is drive, and hard work and anyone can learn this stuff.  And that's where passion truly enters the picture.  Without passion that drive to learn, and work ethic quickly evaporate.  You can teach anyone to code, provided that they want to learn.  

So that being said I recommend looking for the following items when identifying a junior developer:
  1. Broad Experience:  Most people look for people who have had an extensive computer science background, or a background in a single language to be on their team.  In my experience this turns out to be a mistake.  Look for people who have a variety of skills.  Like someone who's experiments with HTML, CSS, Javascript, and Java.  This shows that the candidate has a drive to learn, and is willing to pursue new things that might be outside the scope of their current learning.  This shows that they have passion but might need a little guidance to point them in a direction to pursue.  That's something that will occur naturally when you assign them work.  
  2. Personal Projects:  A big bonus that you should definitely look for is personal projects.  These show that the candidate has a drive to apply their skills in new and different ways.  If they have a GitHub link on their resume, go check it out before the interview, or ask them about those projects and that types of things they are trying to do and how far they go.  Any experience on a personal project is absolutely worth its weight in gold.  This also shows that they are a self starter who seeks out ways to make the things they are working on better without needing a senior dev to do so.  
  3. Don't Discriminate on platform:  As much as I recommend not being concerned with the background in the sense that if you are working on a .net project, don't eliminate someone for not having .net on their resume.  Its not their fault if their school only taught Java, and truth be told you are going to make them learn to write code the way you want anyway.  The hardest programming language you'll ever learn is your first.  After that they are pretty much the same.
  4. Make them talk about their skills:  Even if you don't need those skills on the project, don't be afraid to ask them to talk about them.  This makes them give you a context for how deep their skills go.  You don't want someone who lists things on their resume they heard about in class, you want actual skills.  So asking them to explain a project they used java on, or what kind of work they did with MySQL is a good way to gauge the depth of those skills.  
  5. Ask general software development questions:  All programming languages are essentially the same, and because of that you can ask generic questions.  I usually do a "lightning round" with these, and ask questions like "Explain inheritance to me?", or "What are access modifiers?" or "Explain the difference between Primary and Foreign Keys?"  Any program worth your time should have covered these concepts and these make up the foundation for how someone will approach their next language.  If they don't have a strong background here, they aren't worth your time.  
  6. Ask about their process if they run into a problem they can't solve:  Nobody likes a needy developer.  And the last thing you as a senior dev needs is to have someone hovering over your desk every time they get an error message.  So you want to know what their plan is, listen for the basic debugging process and see if they have a process they mentally go through.  
  7. Pay Attention to the non technical:  Its easy as a developer to focus in on the technical part of the interview.  But remember, you have to work with this person...So pay attention to things like whether or not they are client facing (Can I take them to a client meeting?), or can I communicate with this person?  Do they seem like they would be a personality fit for my team?  Do I think they will crack under pressure?  These are important things to keep in mind when looking at a new candidate.
Many developers look at these interviews as a hassle and something they can show up to without any preparation.  But honestly these are like the NFL draft, and your the coach.  Are you prepared to live with the decision you make in 5 minutes?  Getting a good developer can make all the difference and can give you someone you can grow into a fantastic resource.

Monday, June 8, 2015

Teaching isnt just for the classrom

Lately if I'm being honest I've been burning the candle at both ends. Well more like 5-6 ends. Whether its been preparing a talk that I had to give, working on projects or estimating others. More than a few things going on. But that being said I thought it a good idea to take a step back and look at some soft skills.

Specifically looking at grooming new developers. Now this is a topic I've had quite a bit of experience with. I grew up with a family of educators. Mom a high school math teacher, dad a college professor. My grandmother even taught first grade for 35 years. So it shouldn't be surprising that the idea of teaching is something that has always been in the background. A few years ago I started as an adjunct professor, and taught an intro to web development course. Additionally I've over the past few years been working in a mentor capacity for our interns and Jr developers and building a curriculum for both.

Not trying to toot my own horn, just trying to frame the conversation. I argue the act of teaching is something every developer should embrace in some capacity. And is absolutely essential to growth in your career. As we grow through our career our developers, its only a matter of time before we are a technical lead or in a situation where we are being given Jr developers to delegate work to. Now in those cases, our ability to teach those young devs is the cornerstone of our ability to succeed in what we do.

So the trick is how do we get to teach developers effectively:
1.). Get to know the student: Not to go all kung fu master but each person you work with is different. They all have different passions, and drives. Our education background and interests are different. Get to know your Jr devs. Where did they go to school? What type of work do they like to do? Web? Database? Mobile? What do they hope to do in this career? Are they married? All of these things provide key points to how people learn. Not only that, getting to know your devs builds trust. A trust that is essential to their confidence that you are there to help them and not just some tyrannical boss.

2.). Learn their strengths: Everyone in this field has something they are good at. They either like client side script or database, or C#. All that being said this is important to establish a foundation. When assigning work to a junior dev, its important to make sure at least some of it stays within their wheel house. This is important because it prevents frustration. It allows them to grow skills they already have and fall back on when the new challenges become frustrating.

3.). Push their weaknesses: Just as its important to give your Jr devs work they are comfortable with, it is also important to push them in new directions too. If you have a guy who's fantastic with JavaScript, assign him a SSRS report. People grow through adversity and being tested. So its important to make sure that your Jr devs are working on things that are new and different.

4.) Explain yourself: Remember when your parents used to tell you "because I said so.". And man did that become infuriating. Well its just a frustrating in the corporate world. If you don't take the time to make teaching a part of your job it will never pay the dividends you want.

Just some quick thoughts on teaching and importance to this job. This is something I intend to continue to talk about in the coming weeks, but consider this the opening salvo.