Top 6 Mistakes in Technical Interviews

In the past few weeks I’ve had the luxury of being able to sit in on (and participate in) many technical interviews for various positions. I’ve learned that many people do and say things that are never acceptable in an interview, at least not if they business is worth the time and effort of interviewing at in the first place.

 I’ve come to realize that maybe these things aren’t always obvious, but at the very least maybe someone’ll get a kick out of them. Names have been removed and I probably don’t remember them anyway, but these are all based on real experiences, details removed.

1) Never say you’ve worked for 8 years when you’ve actually worked for 1

Generally, it’s never a good idea to lie on a resume or at an interview. Many people do tell small white lies, or exaggerate, and that’s probably alright, at least sometimes. But never overestimate your abilities by this large of an amount. It will be blatantly obvious to everyone in the room.

If you say you have 8 years of Javascript experience, you’d better damned well know some “common uses of Javascript” and not just stare at me blankly. If you say you’re got 10 years of web development experience, you’d better know some various methods (any methods) of transferring data from one page to another. These are two sample questions and their accompanying responses.

Pure insanity. This isn’t just a “know your shit” lesson. It’s a “if you claim to be an expert, know the basics” lesson.

2) Know the terminology

Sort of tying in to the first point, if you claim to be a member of a group, say, a web developer, you’d  better be familiar with web development terms. Sure you may not have worked with CSS for a variety of reasons, but any web developer who’s never HEARD of CSS is in for a surprise. If you don’t know what a form is, or what a web part is, then you probably haven’t actually worked for long as a web developer, and there will probably be a large amount of ramp up time for you. Then it’s a gamble, are you likeable enough for the company to want to spend the upfront time and money to invest in your education?

Probably not. Be familiar with your field. It seems like common sense, but you’d be surprised at the number of people who are clueless about simple aspects of their field.

3) Don’t assume the jobs “in the bag” because you’re female

Yes, we really want to hire female developers. This means that yes, female candidates can sometimes have an “edge”, intentionally or not. We’ve seen our share of female candidates come in and have a great personality and attitude, act like they’ve already been hired, then completely bomb on the technical portion. Not even close to any kind of technical expertise.

We’ve got 0 female developers at my workplace, and this is not due to any kind of prejudice. It’s because everytime we get a female candidate she seems to fit in great, but is clearly not a developer of any kind, despite (again, back to #1) a resume full of references and “experience”.

4) If you bomb the technical questions, don’t ask if the questions were for a higher position

We had a candidate use this line the other day. Finished the technical questions and he did poorly. Very poorly. Then he asked when we were going to start the technical interview, because all those questions were way too hard for midlevel and were clearly “architect level” questions. Most of the questions were our entry-level questions which were intended as a ramp up to the harder stuff.

This made the guy look like an idiot. Immediately out of the running. Way down the list. One of the aforementioned female candidates very classily failed the technical aspect of the interview, asking “I didn’t do very well, did I?” and then sending an apology followup, saying she was sorry she was so unprepared and thanks for humoring her.

Classy, but won’t win you a job, either.

5) Don’t bottle yourself up

This is a very common thing I’ve personally witnessed with technological positions, especially. Applicants show up and completely bottle themselves up. No joking. No personal information. No small talk. Many people forget that people who are hiring want people they can work with every day. If you get hired you will have to deal with these people for a very long time, maybe even the majority of your waking life for the next few months, or years. They don’t want someone who has no personal life, no interests, and is a complete bore.

Work is boring enough already, don’t add to it. One of my favorite questions to ask at an interview is “Do you have any hobbies?” The responses I’ve gotten are very interesting. One guy we asked seemed really glad that he could talk freely about things he was interested in, and he was obviously passionate about what he did. Music, sports, reading, doesn’t matter what your answer is. His was actually a combination of things, and guess what? We hired him. Not based on his hobbies, obviously, but that was definitely a factor.

If you care about things that you do outside of work, odds are you will care about what you do at work as well.

One candidate answered the hobby question with “Nothing. Well, I installed hardwood flooring in my apartment once. But I don’t really have hobbies”. We didn’t like this answer. We did not hire this person. It was not solely due to hobbies, obviously, because that’s never grounds for dismissal. However, it is a factor, and for good reason.

6) Remember to be yourself, but on your best behavior

Interviews are where interviewers and interviewees both see each other on their best behavior. Everyone knows this. So be yourself, just on your best behavior. If you’re a passionate person, let it show a little. Don’t ever make assumptions about what kind of person a company is looking for. If you assume that, since they are hiring for technology positions, they want a robot with no sense of humor, then you’re probably wrong. If you assume that they want a class clown who will make them laugh at every opportunity, you’re probably wrong again.

Being yourself will help everyone. You’re not pretending to be someone else, so you’re not hired or fired under false pretenses. The interviewer gets to see who you are as well, and it makes the decision-making process smoother.

Questions? Comments? Feel free to leave a comment, or email me, James Martin.

StyleSheetTheme – the Unsung Hero of .NET 2.0

I had an issue today that was not clearly covered in blogs that I found on the subject, so I thought I would write a little post explaining what the problem is and what my solution was.

My issue was on a .NET 2.0 page. As simply put as possible: Using a Theme was causing my browser-specific css to get ignored.

My Masterpage was using a simple IE-conditional to include css written specifically for IE7 (and another for IE<7). We also had a generic basepage that every page inherits.

 For some reason (and I’ll explain why in just a second) my ie7.css file was just not getting recognized by any of my pages. I quickly checked the source of the page and found that the order of css on the page went: ie7.css in the conditional, followed by all my Theme css files located in App_Themes/Themename/css.

Introduction to Themes 

In case you are new to .NET 2.0 and Theming, the general idea behind it is that you have a special folder called App_Themes. Inside this folder, you can make subfolders. These folders should be the names of your theme, so if you want a blue theme, the file structure would generally look like ~/App_Themes/Blue, and then images and css directories under that.

 Why is this useful? .NET 2.0 includes the ability to set a page directive called “Theme”. At the top of a page, there’s some junk thrown in there by .NET, like MaterPage, Title, etc. You can add to that: “Theme=’Blue'”.

What happens next is that all that css is imported automatically. Presumably as well that css should have a relative path to the images. You can have skin files and all kinds of things in the Theme. The magical part is, if you want, you can also set the Theme programmatically. If this is the case, you could have some kind of Session variable, in theory, that “knows” where on the site you are, if you have different areas, and then set the Theme to the appropriate area. For example a Green area that has article.aspx and news.aspx.

In the Green/Blue example, if you used the same css class names (or even the same css FILE, copied in two different directories) you can literally just swap the image colors and automatically have two completely different looking websites running off of the same exact aspx/cs files.

The best part of Theming this way is that all you have to do in a codebehind is say, literally: “Page.Theme=”Green”;” and you get the Green Theme.

So what was my issue?

The Issue

The Theme css is imported automatically. Anything inside the Theme folder gets grabbed and added to the page in a <link rel=…> tag. This is fine. It’s not what it’s doing, but where. These are added automatically at the END of the head tag, by default. Good by IE conditional statements.

The IE conditional statement is supposed to pull in a stylesheet with extra or different definitions that override the current css in the case of IE. However, with css, the last version of a definition is used by default. So it was like my IE files were not even there.

The Solution

StyleSheetTheme! This is a second kind of theme that differs from the “Page.Theme” version of .NET 2.0’s theme system. (Geez the word Theme is starting to lose all meaning to me at this point… sorry 😦 I didn’t name these things!) A StyleSheetTheme differs from the regular theme in two ways:

1) The way it is added to a page programmatically

2) Where it positions the css on the page

StyleSheetThemes are specifically designed so you can alter the css with other stylesheets. Instead of placing everything last, it places it FIRST. This is incredibly useful for things exactly like browser-specific css files, or small little inline things you may want.

The reason I think so many people ignore this theme type is because of how it is implemented. On an aspx page you can statically declare it similar to the other theme, in the @Page directive, just by saying StyleSheetTheme=”Green”.

Programmatically, though, things are different. There is no Page.StyleSheetTheme. Instead, you have to override a property. That code would look like this:

protected override string StyleSheetTheme

{

           get { return “Green”; }

}

This can happen in the basepage, which makes the most sense, honestly. You might notice that this is also static. Using a variable won’t help much, either, since it’s not executing at preInit or onLoad, it’s a separate method. What you CAN use, though, is a Session variable, as long as it’s not null.

Conclusion

This simple solution saved me a LOT of hassle today. I recommend more people check out StyleSheetTheme instead of Theme, since Theme requires hacks in order to get it to work well with alternate css paths.

SEO – How to sell it to your company

Learning about Search Engine Optimization is one thing. Anyone can load up some articles, read about some techniques, and try to apply them to your website. But what do you do when your company needs to adopt SEO practices?

Here’s something I learned through trial-by-fire: selling the concept of SEO is an incredibly easy task. Selling the practices, though, is difficult. Everyone wants to reap the benefits of increased traffic and better placement, but no one wants to commit to changing their behavior and work style.

Anecdotally, I recently took the plunge and introduced the concepts behind SEO to the company I work for. The idea was met with enthusiasm, for sure. The tasks were laid out, and it was decided that, experimentally, we would try it on one of our products.

This is where first resistance was met. Interestingly enough, the people who were fine with changing their ways were not the ones I expected. Content writers were fine with changing how they wrote, PMs were fine with building it into their schedule, Marketing was fine with a new method of keyword analysis and selection, and all three of these groups were fine with working together. In terms of the technical side of things, though, there were some bumps.

Briefly mentioning to some colleagues of mine some SEO concepts, I usually ran into disagreement. Things like how to redirect a page, or not to use Javascript to link were met with dissenting opinions. After some time, I was able to convince them, but at first there was backlash. I suppose that when you’ve been doing something for a while, it’s tough to hear that you should do it differently.

Another roadblock was from the design side. They wanted to have a specific way of naming images to make it easier for them, namely the idea of adding a prefix (m for menu, l for link, etc) to every image, including the page name in there, and using underscores. I suggested that, instead of using image names to convey organization, use folders and subfolders. /images/home/topnav/keyword-image-name.jpg, for example. That idea did not go over very well, not to everybody, and so the image names were not optimized.

To show you how important image names and other image-related factors can be, consider that just yesterday, I received a spike in traffic on this blog. After some investigation, it turns out I have received a TON of referrals from google image search, because my Macbook review page is the first result in a google image search for the term “macbook”. This garnered some serious traffic, so don’t try to argue that image names are irrelevant!

Another roadblock in selling SEO to the company as a whole is people who want to use SEO to cover their asses, or just improve their products before it is ready. One of the more important aspects of enterprise-level SEO is having a process in place. A process will severely reduce overhead for SEO and make it virtually transparent, once initial education costs are over with.

It can be tough in the meantime, as word of SEO and related success is sure to spread around the company. If you are the one taking this initiative, prepare yourself to get an onslaught of requests to implement SEO into sites. You’ll get lots of questions, like “how long would it take to implement on my project”, and “just tell me what to do so I can do it myself”. You’ll need to know how to deal with these kinds of requests, since your sell will likely garner these kinds of requests once or twice a day.

In short, you want to sell to the people that will allow you to quietly set up a process that will eventually get disseminated to the rest of the company. It can be really tough to do, sadly, but the payoff is more than worth it.

.NET 3.5: A LINQ to the Past

With the release of Visual Studio 2008 comes .NET 3.5, the newest iteration of the .NET framework. Unfortunately, .NET users are also greeted with a rise in popularity of the age-old question: Stored procedures or in-line SQL?

I won’t bore you with the details of LINQ (Language INtegrated Query) itself, as nothing can beat Scott Guthrie’s nice introduction on his blog. Something I’ve noticed about these new piece of technology, though, is that debate seems to rage up about how exactly to use it.

 LINQ has the nice ability to eliminate the need for many data layer projects and simplifies everything down significantly. To put it rather succinctly, you have the option to make a database object and call pre-made stored procedures like methods, or perform “in-line” LINQ to SQL commands.

The temptation to use in-line calls is tempting. That eliminates any database work besides initial creation and relationships. No more creating stored procedures and then calling them from code. Everything is contained in one place. You can even view your entity relations from inside of Visual Studio 2008.

However, many people point out that in-line SQL is not very efficient. The database optimizer doesn’t get a chance to be run on the query, not if it’s created dynamically. Therefore, traditionally stored procedures have been the “optimal” choice for database calls.

With LINQ, however, this may not be the case, or at least not as much as would be expected. Visual Studio magazine explains that LINQ can use eager or lazy loading to run its queries.

Eager loading loads up a ton of data at once, entire entities and relations. Lazy loading is a more “on-demand” type loading. What this means in more simplistic terms is that with lazy loading, there are many many roundtrips to the database, each one retrieving a smaller amount, whereas eager loading makes fewer trips for more data.

It seems that with LINQ, the hot topic is performance, and how to maximize it. Ultimately, you will probably take a slight performance hit from switching to LINQ. Is it worth it? That’s the question many many people around the world are asking themselves right now.

There are many methods of optimization, though, like pre-compiling in-line queries and just sucking it up and using stored procedures (which, as I mentioned earlier, can still be added to Visual Studio as methods of an entity object).

If anyone has some comments about LINQ I would be happy to hear them!

How to find and avoid SEO scams

A friend of mine brought this topic to my attention recently (thanks T!), so I thought I would riff on it a bit.

 Search engine optimization has become a pretty hot topic recently. Everyone wants a piece of the SEO pie (which is a topic I am saving for another day … oy vey), but where do you look for enlightenment on the subject? The market is chock full of people who know their stuff – even though many people disagree on certain finer points or how to specifically implement things, most people agree on a lot of ideas and topics.

Unfortunately there are a lot of people who simply do not know what they are doing who are making assloads of money off of it. How do you spot the good from the bad?

The best defense against people running an SEO scam is a little bit of knowledge. You can find tons of free advice on the internet. I mean, tons. There are forums, communities, portals built off of the idea of sharing thoughts on optimization. If you are truly clueless about SEO, I can tell you right now that it would be a waste of your money and time to attend a seminar headed up by a guy whose website looks like this: http://www.1seomichigan.com/ .

This guy’s site, Michigan SEO or whatever he wants to call himself, is an SEO disaster. This is his sales pitch to the world, and he failed. Miserably. And then, what’s more, he tricks you.

SEO basics

 First of all, the basics of SEO are not present. You may notice as well that the site looks hideous. How pretty your images are does not matter, fortunately. Anyway what does he do wrong?

Right off the bat, there is a large chunk of the top of the screen that is made up of images. That is not great, because keyword position on the page (also called prominance) can affect SEO. Next, the header there is large, and yet does not help his SEO as much because it is styled with CSS instead of using a CSS-styled <h1> tag. Header tags matter, yet they were ignored here.

What I’m trying to get at here, folks, is that this guy doesn’t use basic SEO techniques on his website. There are more, rest assured that it’s not very good from an SEO standpoint. Using a neat SEO keyword tool I found while cruising around one day, I did a keyword analysis of his page. Ideally you want a few keywords (I usually use 4 keywords, sometimes of multiple words) with between 4-7%. More than 7% is okay, but more than 10% is bad. This is “density” on the page so your keywords need to be used a lot. The more words, the more times the keywords need to be used to even be considered keywords.

Now look again at that guy’s site. He has a LOT of words. Lots. He has more than a homepage should ever have. So looking through his page for keywords, there are, literally, none. The highest density is around 2.86%. To really be considered a true keyword, you should have at least 4%. To be considered a minor keyword, you’re looking at between 3 and 4%.

According to my friend, this guy recommends you have 10 keywords of 4% each, and so your keywords should account for 40% of your page’s content. This is, obviously, terrible advice. And to put the icing on the cake, he doesn’t even follow his own advice. He recommends 10 keywords at 4%; he has 0 keywords above 3%.

Sales pitch

This guy’s sales pitch is his images. Clearly, they are there to attempt to show off his awesome SEO skills with which he uses to own Google. Let’s look closer at these claims, and I can tell you why they mean nothing.

Claim #1: 7 out of the top 10 sites!

Myth: This makes him a good SEO person

Fact: He is using obscure search terms in that image, to make himself look better.

Seriously, look closely. Sure he has 7 sites on that page. But look at his search term.  “bonacure michigan” is the term. Guess how many TOTAL sites use that term? 184. Guess how many people a month search for “bonacure michigan”? How useful is that 7/10 now?

Claim #2: These are our keywords, we beat out 160,000 sites, we occupy 3 spots

Myth: This proves that his SEO methods work

Fact: Not so. Again, he uses an obscure keyword. While it may or may not be impressive to you that he has three sites in the top 160,000 sites, remember that most likely very few people are actually trying to optimize for “ope michigan” or whatever that term is. With your website you will have competition, people who are actually TRYING to beat you will if you listen to this guy’s advice.

Keep this in mind: if this is proof of greatness, I am at least ten times as great as this guy at SEO. Do a search for my name plus SEO, “James martin SEO”. This blog is the first result, and I beat out over a million people for that spot. Again, though, how useful is that? Not many people search for that!

Rampant claims

This site, and keep in mind that this guy, for the sake of this article, represents all SEO scammers everywhere, makes grand claims about Flash here. Some of them I made myself, and was corrected by Adobe. He claims:

MYTH: Search Engines Cannot Read Flash

TRUTH: Search engines see Flash as a Black Box. It cannot see what is actually going on inside of it – so a lot of your text and words get read as artwork…. Which doesn’t do you a whole heck of a lot of good!THE REAL WORD PERSPECTIVE: As of this writing only
one search engine can read the keywords that you place inside
of your Flash movie….This is somewhat wrong as well. There are ways you can take Flash and make it useful for SEO. I have talked about it before on this very blog. Ways like SWFObject can allow you to stick content where the Flash goes and the search engines can see it. Plus, Google can index Flash content. Not superbly awesome, and it (rightly) ranks it way lower than actual html content.

Scammers will use Flash as an example of something to avoid at all costs. This is not true. You should avoid using all Flash, for sure, but you can use Flash on your site without worrying if you have a competent SEO person behind the helm.

Conclusion

I could go on about what this guy is doing wrong. So how do you find someone who is doing things right? The best way would be to search for meaningful terms. The next would be to learn a little yourself about SEO and apply that knowledge to the SEO person’s site.

Of course, if you’re learning about SEO in general, what good is hiring someone? The benefit here would be to help you apply SEO to your specific site, instead of to teach you the basics.

You can also remember that if you plan on spending a lot of money learning SEO techniques, you could always contact me instead! I probably charge less.

Questions? Comments? Feel free to email me James Martin, or leave a comment below!