Tuesday, February 23, 2010

Advice to a college graduate seeking an IT job

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/advice_to_a_college_graduate_seeking_an_it_job.htm]

A lot of eager students will be graduating with CS degrees soon. Realistically, with almost 10% unemployment, out-sourcing, and a rough economy, it can be hard for a college-grad to find a tech job.

Here's a brain-dump:

  1. Condition your mind
    1. Until you are employed, your job is to find a job. Prepare to spend at least 4 (maybe 8!) hours a day actively pursuing job opportunities.
    2. Furthermore, you're not seeking to "get a job", you're looking to "add value" to a company by solving problems in a technical field that you're passionate about.
  2. Prepare
    1. Set up a linked-in account. This is an effective and professional way to keep track of people you meet.
    2. Make the equivalent of a business card that you can hand out as you meet people. Even a card saying something like "Joey Finklestein, my-email, 'Technology Specialist'" is good. The goal is to have your contact info easily available.
    3. Get your resume ready. make sure it downgrades to plain text in case you need to dump it into some online text area. I personally don't think resumes are the biggest deal. Yes, everything counts. But if you're blindly submitting your resume online, you're one among thousands, and it probably won't matter (sorry). If you meet someone in person, the impression you make will probably dwarf any wordsmith-ing on your resume. If you've actually got even a phone screen, the resume has already been sufficient.
  3. Network. Meet people.
    1. Especially if you live in a larger city (like Chicago), prepare to go to a user group meeting at least once a week. For example, Chicago has dozens of user groups (LCNUG, ALT.Net, CNUG, SQL groups, IT, SharePoint, TFS, Design, etc...) Just google it, there's probably a group. Even if the group isn't exactly on target, go to the closet-related thing. Try to meet at least 3 people. Talk to them, ask them what they do, get their business card, give them your business card. Often user groups have recruiters who are trying to fill positions - talk to these people. Even if their position isn't an exact match, they may know of another position, they may have a position that frees up later, or they may just offer you good advice. Plant seeds.
    2. Keep in touch with your graduating class. Maybe they have leads.
    3. Go to job fairs - most community colleges offer these on a regular basis.
  4. Start a corporate and professional online presence.
    1. Contribute to online discussion boards (like http://stackoverflow.com/)
    2. Contribute to an open-source project (check out CodePlex.com)
    3. Consider writing some articles (either start your own blog, or contribute on a free site like CodeProject. Even if you're just writing simple articles like "Joey's C# 101 tutorials", it's still beneficial. It tells employers that (1) you're motivated, (2) you can write (non-tech skills are a great asset), (3) you're pro-active enough to write. It will also make you more confident after you've explained things in an article. Try to write at least two short blogs, or one longer article, every week. Even if you're "not the writing type", employers want people who can write, and having a repository of your articles shows them, as opposed to summary statements at the top of a resume that say "has good communication skills". You can then also list your blog on your resume.
  5. Continual Education - industry is a different beast than academia. The CS degree is great, but that's the beginning, not the end.
    1. Prepare to spend at least an 1 hour a day reading blogs that are relevant to the job you seek. Find who the top bloggers are in your field of interest, and read them. Probably get an RssReader.
    2. Read the job postings on online sites like Monster, Dice, HotJobs, etc.... You want to make sure you know all the buzzwords, and see what employers are asking for.
    3. Do charity projects. Many charity groups could really use the free help. Offer to do a tech-related project (assist with their website, do a data migration, write a tool to help them do some task). It doesn't pay cash, but it does pay in experience and relationships.
  6. About applying...
    1. Ideally you want to meet someone in person (like at a user group). Next best thing is to meet someone in the company who can provide a referral.
    2. If you do apply online (with no personal reference), don't put all your eggs in one basket - apply to several companies. But don't spam Monster. Perhaps submit to a few companies each day, but not more than 10 companies at once. If you don't hear back from a company within 5 days, move on. Many companies send out an automated "we received your resume note", and then only personally follow-up if they're interested.

Tuesday, February 16, 2010

Where 100% Code Coverage is not sufficient

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/where_100_code_coverage_is_not_sufficient.htm]

Sometimes I wish development were as easy as telling junior guys to "follow this one metric", and then they write perfect code. However, it's not. One example is how to know when you've written enough unit tests. Code Coverage is the obvious metric, and therefore "100% Code Coverage" sounds great. But there are plenty of cases where even 100% coverage doesn't do the job.

Case 1: Regular expressions

Take an email validator, something like so:

public static bool IsEmail(string s)
    return System.Text.RegularExpressions.Regex.IsMatch(s,

A single test would give 100% coverage, but obviously there's a lot of other paths to check. Ironically, because regular expressions are often used to validate input data, and it's an in-memory operation (no databases or external files to hit), it's a prime candidate for lots of unit tests to catch all the boundary conditions - as opposed to just the 1 test needed to reach 100% coverage.

Case 2: Single-line expressions

Similar to the previous case, merely calling this method with one set of inputs (say the "less-than" path, such as i1=5 and i2=10), will get 100% coverage. But that wouldn't test the "greater-than" and "equal to" conditions.

public static bool IsGreater(int i1, int i2)
    return (i1 > i2);

Case 3: Missing Asserts (bad logic)

Even with 100% coverage, it doesn't guarantee that the method logic is correct.

For example, say you've got a CSV-parsing method:

public static string[] ParseCsvString(string strLine)
    string[] astr = strLine.Split(',');
    return astr;

That is tested by:

public void ParseCsvString()
    string[] astr = Foo.ParseCsvString("a, b, c");

This will give 100% coverage. However, there are no asserts, so it's really just showing that the method didn't throw an exception. Even if a developer adds an assert, they need to make sure it's asserting the right thing. Say, adding an assert that the returned array is not null, or has a length of 3, misses the logic that trims the white space after each comma. For example, we want elements like "b" (no whitespace), not " b". In other words, we'd want the ParseCsvString method to loop through each item and Trim() it.

Case 4: Mocking giving a false sense of security

Mocking Frameworks, like TypeMock, are very powerful tools for increasing unit test coverage. These tools allow you to "mock out" a method call within code, such as that database or logging call that would be hard to run in a test method.

While this is great for testing legacy code, it can easily be abused. If every line is mocked out, there's nothing real that's left to test. So while it does get high coverage, if used incorrectly, it becomes meaningless.