Thoughts on interviews part two

I’m going to turn my attention now to giving an interview and hiring in general. When talking to a candidate, you’re looking to answer several questions:

1. Does the candidate have the technical skill needed to perform the job or can she learn it in a sufficient time period?

You should always have the candidate write code. It doesn’t have to be on a computer, but at least on a white board. I’ve had interviewees explain concepts and algorithms perfectly only to find out that they have NO CLUE how to write what they just explained.

Never hire someone into a position above their skill level. Sounds obvious but I’ve seen it happen. Hiring a mid-level developer into a senior spot means you’re overpaying for the work you’re getting and you will most likely have disgruntled seniors who actually earn their high wage.

2. How well can the candidate solve problems?

I don’t mean technical problems. If there is an issue in your application, will the candidate be able to figure out what she needs to do to find the cause and ultimately fix it? Of course there is a technical component to this, but also logical and common sense components. Other problems include writing software without detailed (or any) written requirements, dealing with deadlines, managing multiple projects, etc.

3. Will the candidate fit in with the rest of the team?

If the candidate is not going to fit in with the team, don’t hire her. You’re developing software, not babysitting egos.

4. How long will this candidate work here?

If you’re interviewing for a permanent position, be wary of someone who’s worked 3-6 month contracts for the past 5 years for two reasons. Is 3-6 months’ work at a time really enough to gain valuable experience such as supporting code after the project is done? Does this candidate really want to settle down or will your organization be just another notch on the bed post?

Trying to land a senior developer for mid-level pay is a good way to have a vacant spot for a long time. Even if you manage to find someone that is willing to be underpaid, don’t expect them to stay content for long. Perhaps they’re just ignorant of their market value or maybe due to a previous layoff or a tough market they just really need a job. Either way, you’ll have to rectify the situation BEFORE you’re handed a resignation. Once your employee tells you she’s quitting it’s usually too late, she gave up on the organization months ago.

5. Does the candidate care about her career?

I prod this one out by asking questions like “how do you keep up to date on new technology?”, “do you work on any open source or side projects?”, “do you blog, what blogs do you read?” Questions of this nature show a candidate’s interest level in improving her skills and thusly her career.

Finding a good candidate is hard work. At times you may feel like you’re never going to find a qualified person and start to lower your standard. You may need to reassess your needs, that is fine. What you should never do, though, is settle for mediocrity.

 

 

Thoughts on interviews

Lately I’ve been interviewing a lot of candidates for an open position. If you happen to have an interview lined up anywhere, here are a few things to remember.

• If it’s on your resume, you will be asked about it. Just because you know how to spell MVC doesn’t mean you know MVC. Don’t put a topic on your resume if you’ve never used it or can’t answer basic questions about it.
• If you don’t know the answer to a question, say so rather than going quiet for 20-30 seconds.
• Don’t respond that you’re a fast learner when you don’t know something. EVERYONE is a fast learner. Show why, even though you don’t seem to have a particular skill, you would still be a valuable asset to the organization.
• If you’re interviewing for a .NET position, please know what IDisposable is and how it works with the using statement.
• If you’re applying for a senior development position, you had better know how to write basic queries using SQL. This includes ADVANCED TOPICS such as Group By, Having, and even WHERE.
• “I don’t know much about interfaces because we don’t use them where I work” is NOT a valid reason to not know about interfaces. Just say, “I want a job but I don’t want to be bothered with learning.”
• Web surfing is not a hobby.
• If interviews make you nervous, try some role-playing with some trusted friends and colleagues. Clamming up in an interview is a good way to NOT get the job.
• Learn the terminology for your skill sets. You can’t give an awesome answer if you have no idea what you’ve just been asked. An example would be claiming to know SQL and relational databases well but not knowing the name of the relationship you just modeled on the whiteboard is called a many to many.
• SQL may be pronounced “sequel” but it’s still spelled SQL.
• GUID rhymes with squid, not fluid. Why? Because Don Box says so.
• Remember, you’re selling yourself. You need to stand out from the crowd of candidates they’ve already screened. Be energetic, personable. Be someone that you would WANT to work with.
• Don’t forget that an interview is a two way street. Come prepared with questions about work environment, corporate culture etc. You must decide if this new job is right for you.

Ultimately, you’re in charge or your career. Put forth the effort early on to master the skills (technical, people, management) you will need to be a valuable asset to any organization. Software development requires constant learning. Never stop. I can only say that learning new things becomes much easier as your body of knowledge grows.

Finally, Good Luck.

Database Version Control

Raise your hand if your database is under version control… That’s what I thought. Almost all developers will agree (unfortunately not all) that keeping your application’s source code under version control is a must. But if you think about it, your application is nothing without the database it uses to store all that important data. Why is the database not under source control?

Of course I don’t mean the acutal database data and log files but the schema and static data needed by your application to run.

Here are a few tips on how to effectively version control your database.

1. Create a baseline script.

First things first, you need to create a script that will generate your database as it is right now. This should include all database objects (tables, views, procs, etc) as well as insert scripts for all your static data tables (enum tables, lookup lists, etc). Tools like Red Gate SQL Compare and Data Compare work great for this initial script creation.

2. Create a database change policy.

This doesn’t have to a beauricratic nightmare requiring signatures in triplicate, but it should be strictly enfored. Code that requires schema or static data changes SHOULD NOT be checked it without an appropriate script to make the changes. The script should be re-runnable. It should check for the changes using clauses like IF NOT EXISTS so it can be run repeatedly and not fail on subsequent runs.

3. Integrate with your CI process

You don’t have a CI process? That’s a post for another day. If you do have a Continous Integration process, include these change scripts in it. Set up your build server to run scripts against a development database to verify that they work. If the script fails, the build fails.

4. Developers SHOULD NOT be working against a central database. Each developer should have their own copy of the database. Trying to work off a single instance will cause developers to step on each other’s toes as they make conflicting changes. It’s like having everyone work on code on a network share instead of a proper source control system, it doesn’t work.

So what are the benefits of doing all this work?

–You’ll be able to see every change that happens to your schema as it was made. No trying to remember when that column was removed or that datatype changed.

–Developers will be able to work faster. Your developers want have to worry about pulling down the latest code and not being able to build or run the app. They can simply grab the scripts and run them to update their copy of the database to the version they just got from source control. No downtime downloading an restoring the dev server backup. Unfortunately, several organizations work this way an it make getting source update a real nightmare.

Some version control don’ts.

DON’T create a script for every database object, use change scripts instead. Creating a script for every object in your database quickly becomes unweildy as the number of objects grows and usually the scripts are not kept up to date, especially for table objects.

DON’T simply rely on tools. While tools like SQL Compare are great at creating change scripts, they do fall down in some situations. Don’t just do a compare and check it in. The scripts need to be re-runnable. Also, tools like Red Gate don’t catch situations where you want to add a new NON nullable column to a database with existing data. If you don’t specify a database default, the script will fail. However, you may not want to have a default on the column but of course, you need to specify data to fill in for the existing rows. In these cases, you will have to create the script yourself or do something like create a default value and then delete the default clause from the column at the end of the script.

Experiment with these guidelines above to find out what works for your time. I’m confident that integrate database version control into your process, it will pay dividens immediately.

Raise your hand if your database is under version control… That’s what I thought. Almost all developers will agree (unfortunately not all) that keeping your application’s source code under version control is a must. But if you think about it, your application is nothing without the database it uses to store all that important data. Why is the database not under source control?

Of course I don’t mean the actual database data and log files but the schema and static data needed by your application to run.

Here are a few tips on how to effectively version control your database.

1. Create a baseline script.

First things first, you need to create a script that will generate your database as it is right now. This should include all database objects (tables, views, procs, etc) as well as insert scripts for all your static data tables (enum tables, lookup lists, etc). Tools like Red Gate SQL Compare and Data Compare work great for this initial script creation.

2. Create a database change policy.

This doesn’t have to a bureaucratic nightmare requiring signatures in triplicate, but it should be strictly enforced. Code that requires schema or static data changes SHOULD NOT be checked it without an appropriate script to make the changes. The script should be re-runnable. It should check for the changes using clauses like IF NOT EXISTS so it can be run repeatedly and not fail on subsequent runs.

3. Integrate with your CI process

You don’t have a CI process? That’s a post for another day. If you do have a Continuous Integration process, include these change scripts in it. Set up your build server to run scripts against a development database to verify that they work. If the script fails, the build fails.

4. Developers SHOULD NOT be working against a central database. Each developer should have their own copy of the database. Trying to work off a single instance will cause developers to step on each other’s toes as they make conflicting changes. It’s like having everyone work on code on a network share instead of a proper source control system, it doesn’t work.

So what are the benefits of doing all this work?

–You’ll be able to see every change that happens to your schema as it was made. No trying to remember when that column was removed or that data type changed.

–Developers will be able to work faster. Your developers won’t have to worry about pulling down the latest code and not being able to build or run the app. They can simply grab the scripts and run them to update their copy of the database to the version they just got from source control. No downtime downloading and restoring the dev server backup. Unfortunately, several organizations work this way and it makes getting your source code up to date a real nightmare.

Some version control don’ts.

DON’T create a script for every database object, use change scripts instead. Creating a script for every object in your database quickly becomes unwieldy as the number of objects grows and usually the scripts are not kept up to date, especially for table objects.

DON’T simply rely on tools. While tools like SQL Compare are great at creating change scripts, they do fall down in some situations. Don’t just do a compare and check it in. The scripts need to be re-runnable. Also, tools like Red Gate don’t catch situations where you want to add a new non nullable column to a database with existing data. If you don’t specify a database default, the script will fail. However, you may not want to have a default on the column but of course, you need to specify data to fill in for the existing rows. In these cases, you will have to create the script yourself or do something like create a default value and then delete the default clause from the column at the end of the script.

Experiment with these guidelines above to find out what works for your time. I’m confident that if you  integrate database version control into your process, it will pay dividends immediately.