On Hiring and Trivia Questions

I’ve talked about FizzBuzz. I’ve talked about years of experience. But there’s another topic to cover which hits almost every developer interviewing for a position: trivia questions.

Everyone's favourite game of pointless knowledge.

I need to define what I mean by trivia question. A trivia question is a question that has a definitive answer that can easily be searched on Google. These include things like, “What is a singleton?” And, “What’s the difference between a thread and a process?”

Don’t get me wrong, these are questions where experienced developers should know the answer. But, anyone can learn and memorize the answers to these questions. More than that, if someone has the capacity for learning — as all developers should — then these are things people should be able to learn and grasp in a day.

I went to an interview ten years ago for a junior developer position. I thought the interview went pretty well. The interviewers were impressed with my experience from some projects I’d been involved in, but then they asked me to list off design patterns. I thought it was an odd question — I’d never heard of design patterns. Surely, they continued, I must have at least heard of a singleton. Nope.

The thing is, I was using various design patterns. I just didn’t know the terminology. A coworker of mine today told me a very similar story. He had brought in examples of code he’d written, but he didn’t know what a singleton was, so they weren’t interested. He told me that his code actually contained a singleton, but they wouldn’t give it the time of day.

Another coworker told me that during an interview he was asked to give examples of .NET interfaces. I can’t imagine many people who work in .NET would have trouble with this question, but I also can’t see any value in it. It is so easy to learn the names of interfaces that it surely doesn’t tell you whether a candidate can actually write any code.

What’s the number one goal of an interview when you want to hire a developer? Figuring out if the candidate can actually write code that you want to maintain. If the candidate can’t write any code then there’s no point in even going further. Trivia questions do not tell you that a candidate can code, they don’t really tell you anything at all. They do give candidates good stories to tell in the future that might discourage others from applying for positions in your company.

Here’s what I would suggest: when there’s an area you really want the candidate to know about, like design patterns or interfaces, ask the question. If the candidate tells you that they don’t know but they can learn, great! Ask them to prove it by taking a week to code a small demo application that shows off the point in question. Then have another interviewer where they can teach you about the topic.

This shows that the candidate has passion, initiative, and the drive and capacity to learn new things. It will also show you that the developer can code — or show you that they can’t. The reason you ask them to teach you about the topic is so that you know they didn’t just farm out the work or copy it from Stack Overflow without actually learning.

When I’m being interviewed, this is a key tool now. If I don’t understand something or feel I got something incorrect after the interview is done, I will correct myself and write some code to demonstrate. Then I email it to the interviewer. It can only help.

(And for those who are curious, I have learned about design patterns since that interview.)

Using exceptions to break command query separation

I had a conversation with my eight year old daughter this morning about using exceptions as messaging passing.

Me: I hate it when people use exceptions as message passing.
Her: What does that mean?
Me: When you ask someone if something is ok, there are exactly two answers. What are they?
Her: Yes, and no?
Me: That’s right. Using exceptions as message passing would be when instead you either answer nothing, or scream your head off that something has gone terribly wrong.
Her: That’s dumb.

She gets it. My eight year old was able to determine that a yes or no question is not exceptional if the answer is yes or no. Why are there professional developers out there who aren’t able to determine this?

I am tired of looking at code written by professional developers that looks like this:

public void AuthenticateUser(string username, string password)
{
    string actualPassword = Passwords.ContainsKey(username) ? Passwords[username] : null;

    if (password == null || actualPassword != password)
    {
        throw new ArgumentException("Password doesn't match!");
    }
}

What is this? When you are asking if a password is valid, or if anything is valid, there are exactly two answers that are expected: yes and no.

Expected answers are not exceptional.

This method should have read like this:

public bool IsUserAuthentic(string username, string password)
{
    string actualPassword = Passwords.ContainsKey(username) ? Passwords[username] : null;
    return password != null && password == actualPassword;
}

Now it returns either a yes or a no. The user is either authentic or they aren’t.

Exceptions are great, but they should be saved for situations that you really didn’t see coming or aren’t a valid answer to the question being asked. You want a value from the database, but the database is offline? That could be an exception. You want to access a file on a disk, but file access is locked? That’s an exception. You are dividing by zero? That could be an exception.

Here’s another example:

public void ValidateDateTime(object value)
{
    DateTime parsedValue = value as DateTime;
    
    if (parsedValue == null)
    {
        throw new ArgumentException("value wasn't a DateTime!");
    }
}

This method checks to see if a value is a DateTime. If it is, nothing happens, if it isn’t an exception is thrown.

Here’s the corrected version:

public bool IsValidDateTime(object value)
{
    return value is DateTime;
}

The corrected version is even smaller than the version that throws an exception! It should be easier to write.

Part of the problem here is that, this breaks Command Query Separation (CQS). If a method has a void return, then it should be a command. It should have a side effect. These methods do not. They are queries, they just want to know if a user is authentic, or if a value is a valid type. Since they are queries they should have return types, which is why the corrected versions return boolean values.

The other issue with using exceptions in this way is that you are going to litter your code with unnecessary try-catch blocks that could potentially catch actual valid exceptions that you would want to know about. Returning a boolean does not prevent the calling code from throwing an exception if that is, in fact, the correct way to handle it. But throwing an exception means that any code that wants to reuse the logic here will need to wrap this in a try-catch block in order to interact with the result.

You should be writing your code for maximum reuse in order to get as much value from it as you can. In order to do this, CQS and saving exceptions for cases which are actually exceptional will do wonders in the long run.

The JavaScript Guard and Default Operators

There are two operators used in conditionals that most developers are very familiar with. Those are logical AND (&&) and logical OR (||).

These are short circuit operators, which means that they will not execute the second condition if it is not required.

if (isCondition1 && isCondition2)

If isCondition1 is false, there is no need to compute or check the value of isCondition2.

if (isCondition1 || isCondition2)

If isCondition1 is true, there is no need to compute or check the value of isCondition2.

In C#, each side of the operator is computed as a boolean value. But, in JavaScript, that is not the case. In JavaScript the type is coerced to a bool but not actually returned as a bool, which works as expected in conditionals because you’re not actually returning a value, just checking the boolean coercion..

if (objectA)

is valid in JavaScript, because if the object is not null or undefined, it will evaluate to true, but if the object is null or undefined it will be evaluated as false.

This means that you can perform evaluations such as:

if (objectA && objectA.isCondition1)

The operator short circuits if objectA is null or undefined, so the second condition is never even checked, preventing a null reference exception when checking isCondition1. Just in case you were wondering, this is a great habit to have. In C#, instead of just listing the object as the first check you would specifically have a null check.

You don’t have to save these operators for conditionals though. In C# you can use these operators outside of conditionals in order to assign a bool value to a variable. In JavaScript outside of a conditional, the type coercion is performed to see how to handle the result, but the value returned is not necessarily a boolean value. This means that these operators work differently than you might expect.

var someObject = objectA || {};

What does that statement do? It is the default operator. It means that if objectA would be coerced into false then the right side of the operator will act as a default value, in this case someObject will be an empty object. If objectA is defined, then someObject will be a reference to objectA.

var someObject = objectA && objectB;

This is the guard operator. If objectA would be coerced into false, then someObject will be equal to objectA, otherwise it will be equal to objectB. Outside of conditionals and avoiding null reference checks I get a lot less use out of this one.

The Hidden Pitfall of Being Awesome

What happens when you’re awesome at what you do? Even more than that, what happens when you’re consistently awesome? You get a reputation for being awesome. People start to say great things about you and might even start to believe that you can handle anything that comes your way. Maybe you even can. But there’s a hidden danger here. If you start to buy into the things that other people are saying, you are apt to stop trying.

Sam Flamont related this issue to little league baseball, but the points are every bit as relevant to software development.

I asked how many times have you seen the best player become average and the average player become the best? It happens all the time and it happens because the kid who is the best begins to believe his own hype, where the kid is average keeps hearing his parents say, “Get ’em next time.” Well the average kid is sick of waiting until next time, he wants next time to be now, so he works and works as hard and as often as he can, while Kid Greatness is relaxing by a pool or playing video games.

I can almost guarantee that if you are consistently awesome it’s because you work hard. You have the killer combo of passion and drive that people want, but if you start to believe what people are saying then you grow complacent. You no longer believe that you need to work hard to maintain your status, so eventually you just stop working hard.

Once you stop asking questions, and quit pushing yourself you are going to lose the edge that got you that killer status.

Jeff Schmitt created a list of 12 behaviors that are likely to happen once you start believing your own hype. These behaviors can lead to your downfall.

In the past, you challenged conventional thinking. Now you’re the one who quashes your peers’ ideas. Your colleagues whisper that the golden boy who could do no wrong is slipping. A few even claim you hog the spotlight. You’d like to dismiss it all as a bad streak or jealousy. More likely, they sense that you’re losing those qualities—curiosity, openness, humility—that made you so formidable.

1. Dismiss questions.
2. Feel there’s no need for change.
3. Quit asking questions.
4. Don’t reach out.
5. Fall into a routine.
6. Look down on peers.
7. Lack self-awareness.
8. quit pushing yourself.
9. Grow sloppy.
10. Focus on producing hype.
11. Fixate on status.
12. Become dismayed when something’s amiss.

If you can’t believe your own hype, what can you do? Stay humble! If you stay humble you will keep asking questions and keep your drive and your passion. Thank people for the compliments that they give you, and then forget about them. Developers often suffer from imposter syndrome. This can be seen as a negative since you don’t feel competent and you don’t feel like you deserve your success, but when it comes to staying humble imposter syndrome can actually work in your favor.

Jeff Atwood has stated that in order to succeed you need to believe your hype.

However, if you have daily internal struggles with self doubt and indecision, you are almost certainly not going to achieve your mission, whatever it may be. I have found that, to a disturbing degree in this world, you have to believe your own hype to succeed.

He does go on to say that the opinions of others are traps, but says that we need to ignore them to get past our self doubt. I think that if you are lacking in self doubt then you need to ignore those opinions to get a little bit of that self doubt back because it will keep you hungry and strong. His final piece of advice is good: “concentrate on the daily routine of doing what you enjoy, what you believe in, what you find intrinsically satisfying.”

There’s a joke about believing your own hype that is attributed to Warren Buffet:

A very successful oilman dies. He faces Saint Peter, who says, “You’ve been a good man and normally I’d send you to heaven, but heaven is full. We only have a place in hell.” The oilman says, “Any chance I could talk to other oilmen who are in heaven? Maybe I can convince someone to switch places with me?” Saint Peter says, “It’s never happened before, but sure, I don’t see any harm in it.” The oilman goes to heaven, finds an oilmen convention and yells, “They found a huge oil discovery in hell!” Oilmen are stampeding out of heaven to hell, and our oilman is running with them. Saint Peter asks him “Why are you going to hell with them? I have a spot in heaven, you can stay.” The oilman answers – “Are you kidding, what if it’s true?”

Get out there, be awesome, be consistently awesome, but stay humble and stay passionate.

On Hiring and Years of Experience

Over a year ago now, I had an interview for a software development position. The interview went pretty well and I was expecting to hear positive news. Instead I got what I thought was the strangest phone call. I was told, “You’ve got great knowledge of the language, and your skills would be a huge asset to the team, but you just don’t have enough years of experience.”

The funny thing was, I didn’t feel let down at all. Instead I felt like the company had done me a huge favour — they saved me from taking a job working for a company with views diametrically opposed to my own. It’s a company that I can’t ever see myself thinking I might work for in the future.

Jeff Atwood wrote the following:

It’s been shown time and time again that there is no correlation between years of experience and skill in programming. After about six to twelve months working in any particular technology stack, you either get it or you don’t. No matter how many years of “experience” another programmer has under their belt, there’s about even odds that they have no idea what they’re doing.

With that in mind, do you really want to work for a company that still doggedly pursues the years of experience myth in their hiring practices? Unlikely.

That resonated strongly with me, because he hits the exact thought I had — that I would not really want to work for this company.

DHH also wrote about this in a post titled “Years of Irrelevance“:

As long as applicants have 6 months to a year of experience, consider it a moot point for comparison.

This is pretty much the same point made in the book Peopleware. Tom DeMarco and Tomothy Lister state that their research showed years of experience as a productivity non-factor. Only people with less than 6 months with the language did not do as well as the rest.

It’s my thought that ability, passion, and capacity for learning far outweigh other qualifications. If someone is driven to learn, able to learn, and has only one year of experience then there will be a higher likelihood that they will succeed because they will learn constantly and always be improving. On the other hand, if someone has 10 years of experience, but those years are all the same year, then that person will be less likely to succeed, and more likely to stagnate.

At the same time, I don’t want to entirely denigrate years of experience. If someone has 10 or 20 years of experience that build on each other, and still has a drive to learn and improve, I don’t think you’re likely to find someone better to have on your team.

When do decide that a candidate is not right for your team, don’t tell them that the reason is they have fewer required years of experience than you were looking for, worst case scenario is that they turn into someone you want and would never consider you again.

On Hiring and FizzBuzz

Now hiring

I read an excellent article today called, “This is why you don’t hire good developers” written by Laurie Voss, CTO of npm.

In the article, Laurie has a lot of great advice for conducting technical interviews for developers as well as some things that you shouldn’t do.

As I said, it’s an excellent read and I agree with almost every point in it, but I did take issue with one point.

People ask questions in interviews about obscure syntactical features of programming languages, or details of popular APIs. The famous fizzbuzz test simply asks “are you aware of the modulo operator?” If the answer is “no” then they are probably a pretty weak candidate, but it provides exactly 1 bit of data. Yet people will spend twenty minutes on it in an interview, a huge waste of limited time.

I happen to like the fizzbuzz test. Jeff Atwood of Coding Horror fame said the following regarding it:

I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs. That’s a slap in the face to anyone who writes software for a living. -Jeff Atwood, Why Can’t Programmers.. Program?

See, it seems like saying fizzbuzz is a test of whether or not someone understands modulo is way off. Let’s take a look at what basic fizzbuzz 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”. -Imran Ghory, Using FizzBuzz to Find Developers Who Grok Coding

Does that sound like something that just tests knowledge of modulo? It is also testing knowledge of looping, conditionals, and most importantly basic problem solving.

Take a look at Trello’s fizzbuzz problem that they list on their developer careers page, it asks the applicant to take a look at a hashing algorithm and find the original string from an output hash. It is considerably more of a test of basic problem solving than it is a test of modulo.

I know that if I am looking for a developer that I want to work with, I want to make sure that she has an excellent knowledge of requirements and understands and can explain her problem solving process.

Creating and Deploying a Cloud-Hosted, Cross-Origin, Protocol Agnostic Push Server in 10 Minutes

Would you like to enable a push service? Here is a very easy way to create one. This service will allow anyone to connect from their site and enable you to send real time push notifications to them, and for them to send notifications to you, and should you choose, to other people connected to your service.

This is even easier if you don’t want to open it up for others to connect to your service and you just want to consume the service yourself, but let’s not take that easy route. We’re going to make it a little more interesting.

Just for fun, let’s also allow people to connect to your service whether they’re connected to a secure (https) site or just a regular site (http).

Step 1:
Launch Visual Studio 2013.

I know, I hadn’t mentioned the tooling we were going to use. This is going to use Visual Studio, C#, SignalR, NuGet, and Microsoft Azure. I’m sure you could accomplish the same thing with nodeJS and socket.io but I don’t know how off the top of my head, and I don’t want to cover both stacks today.

Step 2:
Start new Web Project.

Create a new Web Project

Bonus: Application Insights is right there so you’re going to get helpful telemetry data immediately, and you can access this data through the Azure management portal.

Step 3:
You want to make this an Empty project, hosted in the cloud, with no authentication. While I always recommend unit tests, none for this because we’re keeping it simple.

Project Settings

You’ll also need to complete some Azure settings to publish this in the cloud, such as where your service is going to be hosted.

Complete Azure settings

Step 4:
Right click your project and select Add SignalR Hub Class (v2).

You’re going to need to enter a hub name. For this demo, let’s call it PushNotificationHub.

This is going to generate a SignalR hub, which will handle the server aspects of the communication. We’re keeping this with the auto-generated stuff for this demo, but you will want to place methods here that do more interesting things for your clients to consume.

Step 5:
Right click your project and select Add OWIN Startup Class.

Startup makes sense for a name, so let’s use that.

This will generate a class that ties in with OWIN middleware and will automatically startup your hub when this code is running in the cloud.

Step 6:

Add the Microsoft.Owin.CORS NuGet package.

Adding CORS support.

This will enable adding CORS support to the service.

Step 7: Add this to the Configuration method of the Startup class:

app.Map("/signalr", map =>
{
  map.UseCors(CorsOptions.AllowAll);
  var hubConfiguration = new HubConfiguration();
  map.RunSignalR(hubConfiguration);
});

This maps incoming requests made to the signalr path on your site to the SignalR hub — very important. It also tells the application that CORS is enabled for all domains. This can be limited or removed based on your needs.

Step 8:
Add the Microsoft.AspNet.SignalR.Utils NuGet package.

Adding SignalR utils

This does nothing for your code, but does provide you with a tool in your packages file to manually generate the JavaScript proxy file that will be used by the clients. This is going to be needed to add protocol agnostic support.

Step 9:
Create signalr.exe.config for binding redirect for json.net since there is a reliance on json.NET 4.5.

Sadly, this tool is currently dependent on json.NET 4.5. That’s a great library, but because the official release is now at a higher version, we’ll need to add a binding redirect so that dependencies on the old version are automatically sent looking for the new version.

Create a signalr.exe.config file next to the signalr.exe file in the packages\Microsoft.AspNet.SignalR.Utils.2.1.0\tools folder.

The contents of the file should be as follows:

<?xml version="1.0"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <!-- Redirect SignalR JSON -->
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="4.5.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>
</configuration>

Step 10:
To create a proxy file, perform the following steps:

  1. Install the Microsoft.AspNet.SignalR.Utils NuGet package.
  2. Open a command prompt and browse to the tools folder that contains the SignalR.exe file. The tools folder is at the following location:
    [your solution folder]\packages\Microsoft.AspNet.SignalR.Utils.2.1.0\tools
  3. Enter the following command:
    signalr ghp /path:[path to the .dll that contains your Hub class]
    Tip: The path to your .dll is typically the bin folder in your project folder.
    This command creates a file named server.js in the same folder as signalr.exe.
  4. Put the server.js file in an appropriate folder in your project, rename it as appropriate for your application, and add a reference to it in place of the “signalr/hubs” reference.

Step 11:
Place server.js in a relevant folder and add it to your solution.

I prefer to have it in my scripts folder.

Added server.js to scripts

Step 12:
Update the server.js file.

Update the hub connection address with the protocol relative url of the site where the server is going to be hosted. This enables simultaneous support for HTTP and HTTPS.

Updating the hub connection address

Step 13:
Right click the solution, hit Publish and publish to Azure.

Publish to Azure

Now your service is hosted in the cloud. Was creating the service as bad as it sounded when we started?

Step 14:
Add the necessary script references to the client pages.

<script src="//superpushers.azurewebsites.net/Scripts/jquery-1.10.2.min.js"></script>
<script src="//superpushers.azurewebsites.net/Scripts/jquery.signalR-2.0.2.min.js"></script>
<script src="//superpushers.azurewebsites.net/Scripts/server.js"></script>

That’s it! The whole thing is done. The clients can now use JavaScript to consume the methods that are on your hub. Now go out there and create something!