Category Archives: Interview

My How to Market Yourself as a Software Developer Course Is Almost Ready!

If you are a regular reader of my blog, you probably know that for the past few months I’ve been working on a really big project.

I get many emails from developers wanting to know how to boost their career by either finding a new job, starting a consulting business, or even just getting a raise.

I try to help as many of these developers as much as possible through emails and Skype calls, but there is only so much of me and those types of communication don’t easily scale.

I was trying to figure out how to solve this problem

Then, I had an idea…

What if I put together a full program which teaches developers what I think is the most important skill required in boosting their career—marketing themselves?

I don’t mean the cheesy kind of marketing yourself that gives marketing a bad name. I mean the true, down-to-earth, I want to help someone and by helping them I’ll build a reputation for myself, marketing.

I found in my career, this approach to marketing—of providing value to others—was the single most impactful thing I had done to increase the amount of money I make and to open up all kinds of opportunities for me.

So, that is how the idea was born. My Pluralsight courses on all kinds of technologies were very popular, but I feel like the biggest value I could provide—more valuable than any technical course—is to show developers how to get out there and build a name for themselves in the community.

combo image 51 My How to Market Yourself as a Software Developer Course Is Almost Ready!

Here is what I created

I didn’t want to just create a normal video tutorial.  I feel like the material in this course is better served by a combination of video, books, interviews and more.

I want developers who buy the package to feel like they are getting a huge value for the price.  I want to make sure that I am not leaving out any of the advice I would have given my younger self if I had a time machine and could travel back in time.

howtomarketyourself2 My How to Market Yourself as a Software Developer Course Is Almost Ready!

I started out by writing the flagship book for the course, “Why Marketing Yourself Is Important.”  I feel this book is a good starting point for the program and gives readers an understanding of what exactly the value of marketing yourself is and what exactly it entails.

The book is designed to introduce the concepts that are covered in more detail in other parts of the program and to get a reader more familiar with these concepts so that they understand where each piece fits in.

2014 03 13 14 52 451 My How to Market Yourself as a Software Developer Course Is Almost Ready!

Next up, I created the “Building a Brand” video course. The goal of this course is to talk about the importance of building a brand and show viewers exactly how to do it. I want to cover more than just the surface level understanding of what a brand is and really dive deep into what makes a great personal brand and the value having a great personal brand can bring.

I wanted this course to be structured like you are having a real conversation with me. So, I shot a majority of the course in full HD video with me talking into the camera.  In this course I take you from the basics of understanding what makes up a brand all the way to the creation of your own brand and I answer the most common questions related to personal branding that I have received from talking about this topic at code camps and conferences.

2014 03 13 14 53 531 My How to Market Yourself as a Software Developer Course Is Almost Ready!

Since having a blog is a central part of the strategy I recommend, I created a full step-by-step course that shows you how to build a blog from scratch and gives you the tools and advice I’ve learned over the years for making your blog successful.

In this course I go over all the options for setting up a blog, including free hosting, shared hosting and using a full blown virtual private server.  But, I don’t want to just talk about building blogs, so I took the extra steps and actually show you how to create a blog using each possible option.

I end the course by giving you all the tips and tricks I’ve used to build this blog up to a blog that gets over 100,000 visitors each month—around 3 thousand per day on average.

utilimate 3d1 My How to Market Yourself as a Software Developer Course Is Almost Ready!

I feel that learning to use social networks effectively is a very important skill for getting your name out there and spreading the content you create.  So, I wrote another book called “The Ultimate Developer’s Guide to Social Networks.”

In this book, I lay out my overall strategy for gaining traction on social networks. I talk about concepts like building an audience and connecting with people. I cover my strategies for each of the major social networks.  I also give a run down of all the tools I use to manage my social networks effectively and not spend hours each week keeping up my presence in them.

2014 03 13 14 56 461 My How to Market Yourself as a Software Developer Course Is Almost Ready!

One area that I feel is sorely lacking for most developers is the area of creating a good resume.  So, I decided to write a “Resume Advice That Will Make Or Break You” in the form of: do this, don’t do that.  I included all the best resume advice I’ve gotten from recruiters and hiring managers over the years along with tips that I’ve used myself to land good jobs and negotiate higher salaries.

3d1 My How to Market Yourself as a Software Developer Course Is Almost Ready!Next, comes the big topic of getting your name out there. I decided to write “The Complete Guide to Getting Your Name Out There” to cover this topic in detail.  In this book I talk about all the different mediums you can use to get your name and brand out there where people can see it.

I start out by talking about how to get people coming to your blog. Then, I give you some advice on getting published in magazines or other blogs. I cover writing your own book and either self-publishing it or getting it published by a traditional publisher. I even talk about all the tips and tricks I use to create video tutorials and screencasts or shoot high quality YouTube videos.  I also cover the topic of getting on developer podcasts or creating your own podcast—it isn’t that hard. And finally, I give you some practical advice on getting out there in the community either by speaking or through open source. There is a ton of information packed into this book.

2014 03 13 14 58 491 My How to Market Yourself as a Software Developer Course Is Almost Ready!

I really want to make this package valuable, so I didn’t stop there. I created a list of networking do’s and don’ts and I hired a graphic designer to create a beautiful inforgraphic out of it. I am really happy with how this thing came out. In this infographic I reveal all the networking secrets I’ve learned over the years from countless books, articles and just plain old trial and error.

2014 03 13 15 00 021 My How to Market Yourself as a Software Developer Course Is Almost Ready!

Finally, I reached out and contacted the most prominent and well know software developers I could think of. I was able to get Bob Martin, Jeff Atwood, Jon Skeet, Rob Conery and a bunch of other developers to let me interview them. I feel like these interviews alone are worth the price of the course—Mark Freedman, even agrees with me.

In these interviews I dig deep into what made these famous software developers so successful. They share plenty of secrets I haven’t heard anywhere else. One interview in particular that I think you’ll find extremely valuable is the one I did with Pinal Dave. Pinal is the creator of SQLAuthority, an extremely successful blog that gets over 1.8 million views per month. That’s right 1.8 million! For the first time, he shares his secrets to success.

I’ll also be updating the package with more interviews and other content as I get feedback about the content. I want to make this package as dynamic as possible.

When does it go live?

So, you might be wondering when this course goes live. Well, if you preordered the package, you’ve already gotten most of the content I’ll be launching with.

But, if you didn’t preorder, you can get the full finished package on March 27th. If you are a subscriber to my email list, you’ll get a nice hefty discount code in your email on the day of the launch.

If you aren’t already signed up, just go here and you can register to make sure you get the discount code and get notified when the full package goes live.

Man, am I tired

I do have to say, I am exhausted from working on this package. I’ve never put so much effort into a single project in such a relatively short time-frame. I spent countless hours up late at night working on parts of the package. But, I think it was all worth it, because I am extremely happy with the way everything turned out. I am 100% confident this course will help developers learn the skills they need to market themselves and boost their careers.

10 Developer Job Interview Tips To Land The Best Job You Can

There isn’t a large amount of advice out there on developer job interviews.

I’ve found that many talented developers have difficulty with job interviews, because they spend more of their time focusing on what they are truly passionate about, technology and development, and not much time prepping their interview skills.

It’s unfortunate, because having good job interview skills can really help you advance your career by giving you opportunities you wouldn’t be able to get without being skilled in this area

.fotolia 40952476 xs thumb 10 Developer Job Interview Tips To Land The Best Job You Can

1. Hire an expert to create your resume

I’ve mentioned this idea before, but it is so important that I’ll say it again.  Unless you write resumes for a living, you are not a professional resume writer.

There are people who write resumes for a living and those professional resume writers probably don’t try and write their own software to use on their computer.

So, if resume writers don’t write software, why would software developers try and write resumes?

Perhaps you can do a good job, but chances are a professional can do a better job.

My advice, if you want to get the largest number of possible opportunities for a job, bite the bullet and pay the dollars to have your resume written professionally.  It is a relatively small investment for the potential gain of landing a much better job based on the large number of opportunities you are likely to have.

2. Research your interviewer

I’m always amazed when I conduct a developer interview and I’ve sent an email out to the developer I am interviewing ahead of time, which had my full name and my blog address, yet when I speak to them in the interview they seem to know nothing about me.

On the other hand, I’ve had interviews where I’ve interview someone and they worked into the interview a mention of a blog post I had written or a course of mine they had watched on Pluralsight.

Guess which developer I was more likely to recommend for a job?

We are all human, we like to know that someone is interested in us.  Dale Carnegie taught me the easiest way to get someone interested in you is to show a genuine interest in them. (Yes, I’m recommending this book again for like the 8th time, and yes, that is an Amazon affiliate link.)research thumb 10 Developer Job Interview Tips To Land The Best Job You Can

Whether this is fair and objective is besides the point.  If you are interviewing for a job, it is just ludicrous not to research the company you are interviewing at and the interviewer, (if you know who it will be,) ahead of time.

Today it is easier than ever to find someone’s Facebook page, Twitter handle or blog.  You can learn quite a bit with just a little bit of research and it shows that you actually are detail-oriented and care about your career.

3. Get an inside referral

Want to know the absolute easiest way to get a job?  Get an inside referral.

You will be twice as likely to be interviewed and 40% more likely to be hired.

Yeah, that’s right, it makes that much of an impact!

It isn’t even very difficult to do, if you are willing to plant a few seeds ahead of time to make sure there are plenty of apples on the tree, when you need to pick one.

A while back I found a company I wanted to work for.  So, what did I do?

Well, I found a developer at that company that I felt had some common thoughts and ideas as my own and I started following his blog.

I commented on his blog and showed an interest in his work and the company he was working for, and eventually I had an opportunity from that situation to get an inside referral.

Many developers say, “well, I don’t know anyone in XYZ corp.”  Ok, fine if you want to give up there, go ahead, but I bet, if you try, you can find a way to meet and befriend someone in just about any company.

But the secret is, you have to network before you need a job, so start doing it now!

4. Learn to solve algorithm based problems

I’ve got a 6 step process I use to solve algorithm based problems that often come up in developer interviews.

I go step by step and teach you how to do this in my Pluralsight course on Job Interviews.

It is an important skill that every developer should have and it isn’t really that difficult to learn.

Many touch job interviews include 1 or more questions where you are asked to solve some programming problem, either on a whiteboard or at a computer, yet many developers, who are otherwise great programmers, become completely paralyzed when asked to do so and flub it.

If you take the time to learn how to solve these kinds of problems, you’ll easily put yourself in the top 10% of developers who interview for most jobs and you’ll be much less nervous about being asked to solve a problem on the spot.

The reason why we get nervous has nothing to do with performance anxiety, it has everything to do with familiarity and confidence in solving these types of problems.

For example, if someone asked you to do 10 jumping jacks, you probably wouldn’t get all nervous and flail around… why?  Because you are confident you can do it.

Build your confidence in this area and you won’t be nervous either.

5. Answer questions with passion

One word answer to questions or one sentence textbook definitions may technically be correct, but if that is all you do, you are missing an opportunity to showcase one of the greatest assets a developer can bring to a team—passion.

answer thumb 10 Developer Job Interview Tips To Land The Best Job You CanIf I ask you what polymorphism is, I am not just asking to find out if you can read a textbook and memorize a definition to repeat back to me later.  I am trying to find out what you think about polymorphism.  I want you to expound upon the subject and use it as an opportunity to have a conversation.

Now, not all interviewers think the same way, and you have to be a little cognizant of when it is time to shut-up, but the point is you should try and show some passion in your answers and expound upon them if possible.

6. Avoid “trap” questions

Why are you looking for a new opportunity?

Name your greatest strength and your greatest weakness.

What was the result the last time you and a coworker disagreed on a technical issue?

You should really know how you are going to answer these types of questions before you are asked them and what the interviewer is looking for when asking these questions.

I’ve got some recommendations on exactly how to answer these questions in my course, but you should at least consider these kinds of questions ahead of time and reason through some of the possible answers you can give.

For example, if we look at just that first question about why you are looking for a new opportunity…

In many cases interviewers are trying to find out if you are going to bad mouth your current or previous employers.  It is a sure sign you will do the same to them, so don’t do it.

If you don’t think about this ahead of time, you can easily fall into the trap of saying something negative about your current job and severely hurting your chances of landing that new job.

7. Don’t ever lie!

One of the worst things to do in an interview is to lie.

If you don’t know something, don’t make up an answer.  Don’t pretend like you worked with some technology if you haven’t or make up some story of how you used something in your last job.

Instead, either say, that you don’t know or that you aren’t 100% sure, but you can try and give an answer based on what you think.  It also doesn’t hurt to follow up by asking the interviewer what the correct answer is, because you are genuinely interested.

There is a good chance whatever an interviewer is going to ask you about is something they are familiar with, because they don’t want to look like an idiot if you start talking about the subject.  For that reason, even if you consider yourself a good BS’er, most of your BS will be instantly detected and you’ll immediately lose your integrity, which is very hard to ever gain back.

8. Don’t ever be brutally honest

Many developers go overboard the other direction and reveal too many personal details about themselves, thinking that honesty and complete transparency is the best policy.

While you shouldn’t lie, you also shouldn’t spill all the messy details of your life and all your personal flaws to your interviewer either.

People are drawn in by a bit of mystery and generally don’t like to gamble on whether or not your OCD or obsession with World of Warcraft will cause you to be a flop at your job.

Personality is good, character flaws are bad.

Don’t ever lie, but don’t volunteer up information that is going to paint you in a bad light.  Not only will that information likely hurt you, but it also shows a lack of judgment as well.

9. Know your computer science basics

I also cover this in my Job Interview course, because it is so important and can be learned in less than an hour.

Yes, so many developers claim that they don’t know what linked lists and stacks are, because they don’t have a formal education in computer science or it was too long ago when they graduated college.

I agree that we don’t use deep computer science concepts in most programming jobs, but as a professional software developer, you should at least know the basics.

I seriously doubt you’d want an electrician to rewire your house, if that electrician didn’t know anything about the basics of electrical engineering, so don’t assume that someone wants to hire someone who can code, but doesn’t understand the fundamentals of their profession.

You don’t have to be a computer science professor, but you should at least know the basics that I am sure can be taught in an hour, because I do so in my Job Interview course.

10. Build experience creatively

Last but not least, many developers, especially developers starting out or moving from another career field, lack relevant work experience and have no idea how to get it.

It is a bit like the chicken or the egg problem of which came first.presentation thumb 10 Developer Job Interview Tips To Land The Best Job You Can

How do you get experience if you don’t have any?

The answer is to be creative.  There are many ways to get experience that doesn’t involve working directly for a company as a software developer.

Here are just a few ideas:

  • Join an open source project
  • Start an open source project
  • Build a mobile app and put it in the app store
  • Build a small web app
  • Start a blog
  • Present at code camps or other user groups

There are many ways you can get experience that will look good on your resume and give employers confidence in hiring you, you just may have to be a little creative.

Final words

Hopefully you’ve found these tips helpful.  I’ve found that there isn’t a large amount of good information out there for developers looking for good job interview advice, so I actually ended up creating a Pluralsight course on the subject, which you should check out if you want to find more about the tips I mention here.

If you are astute, you may be thinking to yourself, ah, that John Sonmez character writes a blog post to secretly promote his Pluralsight video, pretending to give free advice.

Well, I definitely got the idea to write this blog post to help promote my Pluralsight video, because, hey that is what I do, I make Pluralsight videos— but I hope that you found these tips themselves to be useful as well.

If you like this post don’t forget to Follow @jsonmez or subscribe to my RSS feed.

So You Think You Can Polymorph?

In the true spirit of this blog I am going to take the complex idea of polymorphism and make it as simple as possible.

polymorph thumb So You Think You Can Polymorph?

Now you may already think you understand polymorphism—and perhaps you do—but I’ve found that most software developers don’t actually understand exactly what polymorphism is.

What is polymorphism?

How many times have you been asked this question during a job interview?

Do you actually know confidently what the right answer is?

Don’t worry, if you are like most developers out there in the world you probably have this feeling that you know what polymorphism is, but are unable to give a clear and concise definition of it.

Most developers understand examples of polymorphism or one particular type of polymorphism, but don’t understand the concept itself.

Allow me to clarify a bit.

What I mean by this is that many times when I ask about polymorphism in an interview, I get a response in the form of an example:

Most commonly a developer will describe how a shape base class can have a circle derived class and a square derived class and when you call the draw method on a reference to the shape base class, the correct derived class implementation of draw is called without you specifically having to know the type.

While this is technically a correct example of runtime polymorphism, it is not in any way concise, nor is it a definition of the actual term.

I myself have described polymorphism in a similar fashion in plenty of job interviews.

True understanding

The problem with just that example as an explanation is that it lacks true understanding of the concept.

It is like being able to read by memorizing words, while not understanding the concepts of phonetics that underlie the true concept of reading.

reading thumb So You Think You Can Polymorph?

A good test for understanding a concept is the ability to create a good analogy for that concept.

Oftentimes if a person cannot come up with an analogy to describe a concept, it is because they lack the true understanding of what the concept is.

Analogies are also an excellent way to teach concepts by relating things to another thing that is already understood.

If right now you can’t come up with a real world analogy of polymorphism, don’t worry you are not alone.

A basic definition

Now that we understand why most of us don’t truly understand polymorphism, let’s start with a very basic concise definition.

Polymorphism is sharing a common interface for multiple types, but having different implementations for different types.

This basically means that in any situation where you have the same interface for something but can have different behavior based on the type, you have polymorphism.

Think about a Blu-ray player.

When you put a regular DVD in the player what happens?

How about when you put a Blu-ray disc in the player?

The interface of the player is the same for both types of media, but the behavior is different.  Internally, there is a different implementation of the action of playing a disc depending on what the type is.

How about a vending machine?

Have you ever put change into a vending machine? vending thumb So You Think You Can Polymorph?

You probably put coins of various denominations or types in the same slot in the machine, but the behavior of the machine was different depending on the type.

If you put a quarter in the machine it registers 25 cents.  If you put in a dime it registers 10 cents.

And that is it, you now understand the actual concept of polymorphism.

Want to make sure you don’t forget it?  Try coming up with a few of your own real world analogies or examples of polymorphism.

Bringing it back to code

In code polymorphism can be exhibited in many different ways.

Most developers are familiar with runtime polymorphism that is common in many OO languages like C#, Java and C++, but many other kinds of polymorphism exist.

Consider method overloading.

If I create two methods with the same name, but they only differ in type, I have polymorphic behavior.

The interface for calling the method will be the same, but the type will determine which method actually gets called.

Add(int a, int b)
Add(decimal a, decimal b)


You might be shaking your head “no” thinking that this is not polymorphism, but give me the benefit of the doubt for a moment.

The most common argument against this example as polymorphism is that when you write this code the method that is going to be called is known at compile time.

While this is indeed true for statically typed and compiled languages, it is not true for all languages.

Consider Add being a message instead of a method.

What I mean by this is that if you consider that the actual determination of the method that is called in this situation could be differed until runtime, we would have a very similar situation to the common shape example.  (Late binding)

In many languages this is what happens.  In Objective-C or Smalltalk for example, messages are actually passed between objects and the receiver of the message determines what to do at runtime.

The point here is that polymorphism can be done at compile time or during execution, it doesn’t really matter.

Other polymorphic examples in code

Since the intent of this post is not to classify and explain each type of polymorphism that exists in code, but rather to provide a simplified understanding of the general concept, I won’t go into a detailed explanation of all the kinds of polymorphism we see in code today.  Instead I’ll give you a list of some common examples that you may not have realized were actually polymorphic.

  • Operator overloading (similar to method overloading.)
  • Generics and template programming. (Here you are reusing source code, but actual machine code executed by the computer is different for different types.)
  • Preprocessing (macros in C and C++)
  • Type conversions

Why understanding polymorphism is important

I may be wrong, but I predict that more and more development will move away from traditional OO as we tend to find other ways of modularizing code that is not so rooted in the concept of class hierarchies.

Part of making the transition requires understanding polymorphism as a general purpose and useful computer science concept rather than a very situational OO technique.

Regardless, I think you’ll agree that is it nice to be able to describe polymorphism itself rather than having to cite the commonly overused example of shapes.

If you like this post don’t forget to Follow @jsonmez or subscribe to my RSS feed.

Getting Up to BAT: Hiring an Automation Lead

This is my first in a series of posts about getting to fully automated blackbox testing, or BAT, as I like to call it.

In my last post in the Back to Basics series, I mentioned that I would begin this series with the intent of showing you step by step how to go from no automation to a quality BAT infrastructure.

By the end of this series you should have the information you need to actually get automated testing going in your organization instead of just talking about it.

First stop on this train is hiring an automation lead.

Don’t doom yourself before you start

If you think you are going to create BATs, but you are not going to have at least 1 dedicated resource to doing the job of getting this all going, you are probably bound for failure.

doom4 thumb Getting Up to BAT: Hiring an Automation Lead

Listen up, because this is the single biggest mistake that most organizations make when trying to get BATs up.

This mistake is thinking that you can get your QA team to get this going and you can part time some developers onto the project, but not having a dedicated resource.

Why is this absolutely absurd and you should expect it to fail?  Because, in order to get an infrastructure to support your BATs, you are going to need to basically design and create a testing framework that is tailored to the business domain of your application.

Blah, what?  Ok, in simple terms.  Someone is going to need to design and build an automation framework.

If you think you are just going to buy some tool and use it to record test scripts, you are wrong.  That approach simply is not going to work.  I won’t get into why here, but I have written on it before in the past, and if you are interested, let me know and I’ll go much more in depth.

Think about this, do you want your QA team, as good as they may be at QA work, designing and building an automation framework?  Give them a few C# or Java classes and have their first real coding work be to design a complex system?

How about a developer who has “real” work and can only devote part time to designing what may end up becoming one of the most important parts of your infrastructure?

It is fine to pull a developer off of the main product and put them in this role until it is up and running, but make no mistake, you need a dedicated resource.

You are going to want to a well designed maintainable automation framework, because the ease of use of that framework will determine how easy or not it is to write automated tests that use that framework.

I recommend getting someone who has done it before

Why?  Because creating an automation framework is much different than developing your software and it is much different than writing tests.  It really requires a special skill set that is not so easily acquired without the experience of having done this before.

I also think it is fine to use a developer resource, but if you do, you want to try to get a more senior developer to take this role.

Here is a list of some of the skills that I think are important which may also make it much more clear why I am recommending a specialist in this case:

Development of APIs (In the end the automation framework will be an API that is used to write automated tests.  The better the API is designed, the easier it will be to write tests against it.)

Design of reusable base components (Much of the framework consists of repeated concepts with different variations for different screens in your application.  As a result, the core of the framework will be a basic design that allows for variation without too much repetition… reuse)

Ability to quickly acquire domain knowledge of the software (Someone writing an automation framework needs to really understand how the system under test works, so that they can model the framework after it.)

Pragmatism (Many “accepted” good software designs are actually bad automation framework designs.  Static methods can make an automation framework’s API much more simple to use, especially for non-programmers, but would not be a good design choice in your main product.  A person who designs an automation framework should be pragmatic enough to “break the rules” in order to make the framework easiest to use and maintain.)

Experience or understanding of QA (It is important to understand the users of the framework, the QA team.  Understanding what kind of tests they will likely write or how they will think will go a long way in coming up with a good framework design.)

Communication skills (Good BATs read like English.  It is critical to make sure that the person designing the framework facilitates this to make the BATs as useful and understandable as possible.)

HTML / XPath (This specific skill set is very important for web based products.  Creating an automation framework built on top of one of the web browser drivers will require intimate knowledge of HTML and probably XPath to be able to access attributes and elements on pages in your application.)

I’ve written a few automation frameworks and contributed to the design of several others, and I can tell you that my version 6.0 of an automation framework was much much better than version 1.0.

There are a huge number of patterns that emerge that are unique to this problem domain.  So, I do believe having experience in this area specially is a huge benefit.

What does this automation person do?

We’ll get to more specific in my later posts in this series, but the basic responsibility should be:

  • Figure out the technology and tools to be used
  • Create the initial automation framework
  • Create smoke tests for the application under test
  • Get those smoke tests into some kind of automated build
  • Train developers and QA in the use of the framework
  • Drive the adoption of the framework and automation for all features
  • Set up rules for consistency in writing automated tests
  • Design of hierarchy and structure of automated tests

You want your automation person to be responsible for pushing and driving forward the goal of getting to the point of being able to automate each feature being created with minimal effort.

This is one of those jobs that can actually be “done.”  What I mean by that is you may have the automation lead end up creating the framework, developing it enough to push it out to your development teams and train them to write automated tests along with QA, and you really don’t need an automation lead anymore.

This is great though, because now you have a developer that really knows your product and is a good bridge to QA, or you can keep them improving the framework and overseeing it if you want to go that route.

Bottom line is:

  1. Make sure you get a dedicated resource
  2. Make sure that resource can write code and design a framework
  3. Make sure they train everyone else, one person cannot automate your entire application
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Solving Problems, You Better Learn How

It is astounding how many developers can write and maintain large enterprise systems dealing with all kinds of complex logic, database access, etc and cannot for the life of them solve a moderately difficult programming problem given in an interview in less than 30 minutes.

It is also astounding how many developers that can not write even a single line of code can fail the same problem exactly the same way.

Based on those two statements, your first assumption might be that asking someone to solve a programming problem as part of an interview would be a bad idea, because it isn’t really telling you if they are good and just crumble when asked to do something like this on the spot, or if they can’t program at all.

thinker1 composition5 small2 thumb Solving Problems, You Better Learn How

Let’s look at some possible numbers to see why this is wrong

In poker you can use a combination of pot odds and the likely holdings of your opponents to deduce in many situations whether or not you should call a bet.

Pot odds is simply a ratio of how much money is in the pot (what you can win), versus how much it will cost you to call the bet.

For example, if a pot contained $9 and I bet you $1, you would be getting 10:1 odds on your money for a call (you have to risk an additional dollar to potentially win 10.)

So in that example, if you have a better than 10% chance of winning, you are making a profitable play by calling.

I don’t have the exact numbers (actually I am just guessing at them from experience), but here is a realistic estimate:

  • Good programmers – 60% can solve the problems
  • Great programmers – 90% can solve the problems
  • Don’t know how to program, lied on my resume – 1% can solve the problems by some sort of divination or black magic, or memorizing sequences of symbols which solve the problem.

Given some statistics like this, if you have someone pass this kind of a test, you can calculate the rough probability of which of the three groups they belong to.

  • 40% chance they are Good
  • 59.5% chance they are Great
  • .5% chance they are a black magic practicing witch or warlock
  • 99.5% chance they are either good or great

So, even though you may be throwing away some good candidates and some great ones, the chance of you getting someone who doesn’t know how to code at all is almost reduced to nothing.  This is very important!

Why?  Because if you hire someone who doesn’t know how to code at all, it will cost you a huge amount of money, but if you pass over someone who is great, but still end up getting someone else who is good or great it doesn’t really cost you anything except in the rare case that the great programmer failed out of the test and you ended up hiring a good one instead.

Even still, that is a small loss versus hiring someone who can’t write a lick of code.

I’ve talked about how I think having code in an interview is a good thing before, but now the numbers are here to back me up.

More and companies are realizing the truth about this situation and companies like Codility are popping up to offer a service to test candidates for you.

What this means for you?

You might not get asked to solve a problem or write code in your next interview, but there is a growing chance that you will.

You may think to yourself, ok even if I bomb the code writing part, I will do great on the rest of the interview and be able to convince them that I know how to write code, besides any company that would toss me out of the running for failing some stupid online test is a company I don’t want to work for anyway.

To that I say a company that doesn’t know how to do math is a company that you don’t want to work for. If my numbers are anything close to accurate, the mathematical best choice is to almost always throw out someone who fails the coding test.

The simple solution is to learn how to solve these kinds of problems.  Learn how to write an algorithm under pressure in 30 minutes.  It’s not that hard to practice and the skill will help you in many other areas of your career and probably your life in general.

I’ve written before on TopCoder as a great site to practice these kinds of problems, and if you haven’t checked it out that is a great place to start.

Another option is to get the book Programming Pearls.  It is a bit dated, but has some nice programming problems for you to try to solve.

I’ll follow up this post in the coming weeks with some hints and tips on how to take a programming problem, break it down and finally code it.  Learning how to do this properly can make some of the more difficult algorithm type problems very simple.

So get to it!  Start learning how to solve programming problems.  Reverse strings, sort linked lists, help grandma pick the highest yielding grandsons and a granddaughters to send Christmas cards to!

If you are following my back to basics series, don’t worry, it is still on.  I’ll probably pick back up with it after the holidays.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Why Hard Developer Interviews are Good

I’ve never understood the shock people have of hiring a programmer and then finding out that he can’t actually write any code or that he completely lied on his resume.

This is a very simple problem that can easily be solved, yet not too many hiring managers or developers responsible for doing interviews are willing to do it.

All you have to do is increase the technical difficulty of the interview.

stumped thumb Why Hard Developer Interviews are Good

But I don’t want to ask hard questions about a specific technology

Often I hear the point made that a good programmer can learn any framework or language, so asking difficult C# questions or asking details about EJBs will exclude those candidates prematurely.

While this statement is partially true, I don’t consider it a very good excuse for not asking hard questions.

There are many difficult subject matters in software engineering that exist beyond the domain of a specific language or technology.

You can always ask hard questions about object oriented design, design patterns, or general language constructs.

If you have the resources, you can always tailor the interview questions to the specific skill sets the candidate has indicated on their resume.

The truth is a really good programmer is going to know a lot about a lot of different areas.  A great programmer should also know a lot about some specific areas and languages.

What if all the candidates fail?

They all should fail.

Your technical developer interview should get increasingly harder, until it ultimately results in stumping the candidate.

Make your questions progressively more difficult until you reach an area beyond the knowledge of anyone on your team.  If you ever have a candidate that makes it that far, you know they are an instant hire.

You expect that no one will make it all the way through, and that is good.  It gives you a very real and easy comparison gauge on the different candidates.

Not that you should base your decision on how many interview questions the candidate gets right, but it can definitely provide you a comparison of two candidates that you wouldn’t be able to see without escalating difficulty questions.

For example, if candidate A can only get through the basic questions and candidate B makes it to the expert level questions, that should give you a pretty good idea of their relative talents.

Besides, failing is good.  We all fail every day.  I always want to see what a person is going to do when they don’t know the answer.  Do they have the humility to ask you the answer so that they will know it in the future?  Do they bring up that they will research that area?  Do they blow up and make excuses or try to justify a wrong answer?

I hate hard developer interviews, so I don’t want to give them out

Do you really hate difficult interviews?

Or do you hate pointlessly difficult interviews?  There is a huge difference.

Asking someone to use bit manipulation to reverse a string is stupid and pointless.

In most cases, asking someone to implement a quick sort algorithm is also stupid and pointless.  (Any programmer worth his salt would never trust himself to implement a well known sorting algorithm and would instead look it up.)

My point is that there is a big difference between asking hard questions and good hard questions.  If you ask relevant hard questions, you are going to quickly turn away the “fakers” and “con artists” and you are actually going to make a good programmer pretty happy.

Nothing I hate worse than walking out of a developer interview, as the interviewee, feeling like the interviewer didn’t ask me hard enough questions.

I feel like if an interviewer asks me easy questions that anyone should know, I don’t get to demonstrate my real skills and talent.  When I leave a developer interview, I want the interviewer to think.  “Damn, that guy got almost every single hard question right, no one else was able to do that.”

So in reality, if you ask good hard questions, people won’t resent you for it, they will appreciate it.  It is nice to “slam dunk” a difficult interview, because you know that you likely have the job.  It is not nice to “slam dunk” an easy interview, because it doesn’t give you any confidence that your skillset was noticed at all.

Don’t forget to have them write code

Programmers should be able to write code.  In a high stress situation, it might not be pretty, and it might not be absolutely semantically correct, but it should be obvious that the candidate knows how to write code.

The best approach I found is to use a simple programming problem.  A problem that anyone should be able to solve, but can be solved many different ways.

The idea is that the code should be what you are looking for, not if they can solve a difficult logic problem.

I’m pretty happy to say that the company where I work now, TrackAbout, has a pretty difficult developer interview process which does involve writing code.  I am very happy about this because I feel that it allows us to hire the best programmer, which allows me to work with the best programmers.

If your company is taking the easy way out of doing technical interviews, you are basically playing the programmer lottery.  It is definitely worth a little more time to ask harder questions and be a lot more confident in your decisions.

So You Want to Become a Better Programmer? (TopCoder)

Let me ask you a question.

If you drive your car every day, do you think you are becoming a better driver?

Now, let me ask you another question.

If you competed in races with your car, frequently, do you think you would be becoming a better driver?

Let’s reflect that paradigm at programming.  Many of us, if we are fortunate, get to write code every day.  Unfortunately, a large amount of the code we write is fairly mundane.  We are rarely writing code in any form of competition.  When you are first starting out, writing code makes you better at writing code.  After time, when you have been writing code for a while, just like driving, you stop making gains.

You may have heard someone say there is a difference between a programmer with 10 years of experience and a programmer with 1 year of experience 10 times.

How to start making gains again

What I want to talk about today is just one of the ways you can start making gains again in your programming skills.  There are many others, and I have talked about some of them before.  But, today I want to talk about a very specific way I have found to break through the barriers and really improve your programming skills.  Specifically, I want to talk to you about a programming competition that I really enjoy called TopCoder.

TopCoder is a website that has a nice little competition arena that allows you to compete against other programmers solving some pretty difficult problems.  They have built a web launcher that opens up an IDE where you can view a programming problem and write your code to solve it.  You can solve the problem in any one of their supported languages and get immediate feedback through their system tests.  You can also view other people’s solutions to the problem and challenge their solutions with your own input.

There are other kinds of competitions on the site, but for what I am talking about you’ll want to go to the site, then click on develop, then click on algorithm, and launch arena.

ss 2010 04 02 08 00 03 So You Want to Become a Better Programmer? (TopCoder)

Once you are in the competition arena, you are brought to a chat lobby, where you can switch to a competition room (if one is currently underway), or to a practice room, where you can practice some of the past competitions.

ss 2010 04 02 07 39 47 So You Want to Become a Better Programmer? (TopCoder)

Once you are in one of the rooms that has problems, you can select a problem to launch the IDE.

ss 2010 04 02 07 40 18 So You Want to Become a Better Programmer? (TopCoder)

There you can type your solution to the problem right there and compile or test your code.  I’m not going to go into all of the details of how the competition and scoring works here, because I want to focus more one why TopCoder, and other types of training like this are so beneficial.

Why will this make me a better programmer?

It is kind of hard to explain why this works so well.  I think one of the major reasons is because we are challenged to solve much more difficult problems than what we usually solve in our day jobs.  When you start solving those problems, the easier problems you encounter on a day-to-day basis seem to get a lot easier.

One thing that really helped me was the ability to see other people’s solutions to the problem.  When I would finish coding my problem, and look at the other solutions to the problem, I would always find new ways of using some of the base language or library features that had never occurred to me.

When you try to challenge someone else’s problem, you are forced to read some code that can be very obscure and quickly understand it.

You can also use some plugins to code in your favorite IDE and then have the code mirrored in the TopCoder IDE, but there is a nice gain in mastery of the language that can be had if you choose to use the TopCoder IDE which does not have auto-complete.  (Especially if you ever have to write code on a white-board during an interview.  It can be pretty embarrassing when you are unable to produce the syntax for a simple statement because you are so used to relying on auto-complete.)

You don’t have to do the competition, you can just do the practice rooms on the site, but I encourage you to try a competition or two.  There is just something about competition that seems to make us better.

Post me some comments if you try this and it helps you.

Selling Yourself: How (Part 2)

See Part 1 Selling Yourself: Why

There is a right or good way to market yourself.

Selling yourself tastefully takes some practice and thought.  It really is a soft skill that must be acquired and thought about.  It takes some amount of social engineering.  Like all products, the better the product, the easier it is to market.  Here are some tips I find useful for marketing yourself as a professional developer.

1. Create a weekly report of exactly what work you did each day of the week. The report should include a brief description of the major and minor accomplishments each day and perhaps a summary or highlight of any major accomplishments you did.  Especially mention mentoring or helping other people.  Send the weekly report voluntarily to your boss and CC your boss’s boss as an FYI.  I know it’s a bit difficult to find a good way to CC your boss’s boss, but try to find a good way to do it that is tasteful.  (For example, something like “I thought you might also like to receive these weekly reports I am sending out just as a FYI.” )  The benefit of doing this is two-fold.  First, you will be highlighting all the good work you are doing to your boss and his boss, in a way that isn’t like “tooting your own horn.”  Second, you will provide yourself a documented history of work you accomplished which is useful for reviews, protection against wrongful termination, and resume building.

2. Update your resumé periodically, and your public profiles, LinkedIn etc. By keeping your resumé constantly up-to-date, you are ready to find a job quickly if you become unemployed.  This will give you a safety net, which will allow you to feel more comfortable being a professional and sometimes saying “no”.  In addition, opportunities will come to you when you have your public profiles up-to-date.

3. Get a library of books and put them up for display. (Read them, or you are just faking it.)  If you have a mountain of books you have read, but they are sitting in a box at home, they are not marketing you.  When I walk into a developer’s office and I look at his or her books I can tell many things about them already.  When managers walk by and they see someone with a large number of programming books, it says something to them about your dedication and knowledge.

4. If you have certifications frame them and put them on your wall, or on your cube. Yeah, I know it may seem cheesy, and you may get poked fun at a bit.  But take it light-hearted and don’t brag about the certification, deep down inside the people poking jabs about certs really are feeling threatened they don’t have certifications.

5. Help other developers, all the time. Be they guy that everyone asks their development questions to.  When someone needs help figuring something out, volunteer.  Help train the junior developers.  Doing this will give you a reputation of being knowledgeable and helpful.  Answering questions on Stackoverflow counts towards this if you have time.

6. Prepare some power points and offer to give demonstrations or presentations on a project you did, or a new technology or methodology you want to introduce.

7. Be vocal. Make sure that you are speaking up.  In meetings, in design sessions, in general have something to say.  Make sure you are not talking for the sake of talking, but contribute information and ideas.  Doing this will help demonstrate your knowledge and critical thinking.

8. Make occasional visits to the boss. Make sure you are being seen by management every once in a while and when you do, mention new ideas you have of ways to make your team better or more efficient.  Offer to spearhead the implementation of those ideas.

9. Take some risks in order to make things better. Sometimes you have to bet big to win big.  Sometimes you have to do a controversial thing, or not get permission before you do something that will greatly improve development quality or output.  Increasing developer quality through creating developer tools is very valuable and very visible.  Just make sure if you take a risk that if you accomplish it, it will have high returns for the company.  People who do stupid things without permission get fired.  People who do brilliant things without permission get praised.

The bottom line is, if you’re not selling yourself, you’re selling yourself short.

Selling Yourself: Why? (Part 1)

I know many good developers who are under the impression that they either don’t have to sell themselves, or selling yourself is wrong, but is that really true?

First, let me clarify by defining what I mean by “selling yourself.”  I don’t mean “selling out,” I mean marketing yourself, what you’re doing and what your skills are.  Especially to your organization.

I don’t need to sell myself, my code speaks for itself.

Really?  Do you think your pristine code says enough about your skills, especially to a non or semi-technical person?  Think back about how many products with fancy UIs beat out excellent products with crappy UIs.  The simple fact of life is that marketing is effective and required.  Imagine creating a really good product and doing no advertising at all because you think that the product speaks for itself.  No one will know about how good it is and no one will buy it.

The only person who can recognize the quality of your code is another developer of equal or greater talent. Now I realize that someone of lesser skill may be able to recognize that your code is “good,” because it is easy for them to read and it looks pretty, but just like a connoisseur of fine wines can distinguish the small differences that really count, it takes a developer of significant talent to recognize excellent code from good or even great code.  Being armed with this knowledge, it is easy to see why your code will rarely speak for itself.

As a professional developer you have to consider your audience.  Mostly the people influencing your career in development are not the highly talented developers who can appreciate your code.  In my experience, it is a collective of all developers, project managers, and recruiters.  Because of this audience, you must do more than write good code.  That good code must be seen and the effects of it must also be seen.

It’s wrong to sell myself, it is politics, I don’t do politics, I just write code.

If it’s so wrong to do, how come so many of us do it when we are interviewing for a new job?  It’s like a courtship when they guy is taking the gal out to dinner and buying her flowers and romancing her, but as soon as they get married where did the romance go?  Many of us developers are just like that.  We polish our resumé and go out looking for the job, dress up in a suit and tie, present ourselves as professionals, but then we get the job and settle in, and we turn off the charm.  It’s not wrong to keep the charm turned on, not only is it not wrong, it’s expected.

What about the politics of it?  Well yes, there are politics involved in selling yourself, but thinking  you can be a technical person and completely ignore politics is a sure way to dead-end your career.  Most developers want to reduce the amount of political situations they have to deal with, and I agree with that, but trying to ignore the problem to just make it go away is like trying to make a hungry lion go away by closing your eyes.  Even if you are the best hacker in the world, people skills are important.  It is my strong opinion that every professional, developer or not, should read How to Win Friends and Influence People, by Dale Carnegie.

I think there is also a large difference between tasteful marketing of a product or service and offensive or annoying marketing.  Just like the XXX spam mail that shows up in your email unrequested, a developer can market themselves in an unsolicited and annoying way.  On the other hand…

See part two of the series here: Selling Yourself: How

Lambda Extensible FizzBuzz 2.0 With LINQ

Many of you have probably heard of the FizzBuzz challenge:

Jeff Atwood blogged about it here

I think it started from here

Anyway, if you don’t want to click those links and you’re not familiar with it, it is a small programming problem designed to screen someone who can actually write code from someone who pretends to write code.  The problem is:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”

The point is this is a simple problem.  Just simple enough to be interesting.  I actually got asked to solve this problem this week.  I solved it after bumbling through it way more than I should have (I was trying to think of an elegant solution on the spot.)  But it kept bugging me.  I knew there was a solution that I wanted to give it that would make me happy with feelings of maps, function pointers and linq.  Pretty much 3 of my favorite things.  So I thought about it for a bit and here is the solution I came up with (3rd cut.)

        public static void FizzBuzz()
            Dictionary<Func<int, bool>, Func<int, string>> rules = new Dictionary<Func<int, bool>, Func<int, string>>();
            rules.Add(x => x % 3 == 0, x => "fizz");
            rules.Add(x => x % 5 == 0, x => "buzz");
            rules.Add(x => x % 5 != 0 && x % 3 != 0, x => x.ToString());
            rules.Add(x => true, x => "\n");

            var output = from n in Enumerable.Range(1, 100)
                         from f in rules
                         where f.Key(n)
                         select f.Value(n);

            output.ToList().ForEach(x => Console.Write(x));

That’s my crack at it. If you’re not familiar with all the C# magic going on here, basically it works like this:

You have a map which maps one lambda expression which defines the rule we are checking for to a second lambda expression which is what string to return if that rule matches.
Then we have a LINQ query that does a Cartesian join on the set of numbers from 1 to 100 and the 4 rules.
Finally, we take the output and for each string we write it out.

The 4th rule in the set makes sure that after evaluating the set of rules for each number a newline gets put in.

It is kind of interesting how thinking about different ways to solve a fairly simple problem can help you think about the tools you have in new ways.