East coast technology blog

web development

Post navigation

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.

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.

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).

There are new acronyms being used every day in web development. Here are some of the new ones that are seeing more and more attention each and every passing day.

RIA (Rich Internet Application)

See: web2.0

This term is being thrown around a lot lately. An RIA (rich internet application) is simply put an application on the internet that is closer than ever before to a desktop application. Yes, I know there’s a lot more to it than that, but really in the end it’s all about user experience. Drag and drop. Sortable columns. Asynchronous operations and postbacks etc. etc. The list goes on. The easiest example is an Adobe Flash program, or a Microsoft Silverlight application.

You can do all kinds of neat things in rich internet applications that you couldn’t do before, at least not on the widespread scale that exists today.

CSS (Cascading Stylesheets)

Definitely not a new term, this is still a current acronym because it’s importance is really being driven home lately. Amateur web developers will avoid CSS at all costs because it’s complicated, confusing, or “unnecessary”. Real web developers understand the importance of CSS.

There are tons of reasons to use CSS and I won’t get into them here. The idea is that you can define styles for elements on a webpage (for example, what font to use in a specific location) in a separate file that can be reused throughout an entire site. Easier for everyone involved.

SEO (search engine optimization)

Another current hot topic, search engine optimization is a major money maker right now. The rules of the search game are constantly changing, and companies are trying their best to swim to the top of search results, constantly fighting the riptide.

Since the concepts that keep a site at the top of the page are changing, consultants can charge a lot of money to give simple tips on how to alter their design and development slightly. I’ve heard of firms charging ridiculous amounts of money for what amounts to slightly reworded title tags for their site.

MS (Microsoft)

This acronym is controversial to many people, and I only included it because Microsoft has been doing some amazing things with the web lately. Silverlight is looking to finally put a stop to the RIA monopoly held by Adobe/Macromedia for so many years.

That’s not all they are up to. Microsoft is also implement new strategies like Unified Communications, and really ramping up the Live effort. As lame as me including MS as an acronym is, Microsoft is a big player in the web and it looks like it’s only getting better.

RSS (Really Simply Syndication)

The above acronym is arguably incorrect but that’s generally the accepted term. RSS is really being embraced right now. In case you aren’t familiar, from a webmaster’s point of view an RSS feed is a way of alerting readers that you have new content available. This is extremely useful for finding and maintaining long-term users and visitors.

To the end users, it’s a great way of keeping up to date on many, many different websites at once. And you can only see new content, or recently added content. You can see what date it was added to the feed, and much more.

If you are using IE7 you can click on the orange RSS button (to the left of the printer icon) if it is available. That icon glows orange if there is an available feed, and is gray if there is not one.

There are many plugins that do the same thing with Firefox, although I think Firefox 2 has that functionality added as well.

My first run in with the Adobe Blog Squad was a week or two ago when I wrote an unfavorable article about Adobe Flex. Shortly after, I had received a comment from James Ward.

James Ward is an employee of Adobe. According to his blog, he is a Technical Evangelist. I don’t know if this is an official posting at Adobe, but it almost has to be these days.

Mr. Ward seemed to very nicely critique my article. This is called the Good Cop. He swooped in to graciously and coherently rebut my opinion. Fine, all good so far.

Shortly after, another comment appeared by a man named Mike Potter. A quick background check shows that he is currently involved in marketing at Adobe as well.

So, shortly after posting a negative article, two people from Adobe show up, both involved in marketing or self-proclaimed “evangelism”. Hmm…

Mr. Potter was, on the surface, as amicable as Mr. Ward, and yet here he is posting on my blog like it somehow matters and he needs to quell the uprising before it begins.

It’s pretty obvious what’s going on. Adobe has employees that are scouring Digg and other sites for anything that can be construed as being negative press, and making sure they try to squash it. Whether this behavior is condoned by Adobe or not has yet to be seen.

It would be in the best interest of Adobe to silence these men, in my opinion. Looking at their websites, as well as some of their previous blog comments, you can tell there are some things they are (or were) ignorant of.

One of them is search engine optimization. From a blog posting a few months ago, the author had a few issues with Flex, including the ability to search Google and other search engines for the content inside Flash. This point sailed right over Mr. Potter’s head:

Bravo at looking somewhat foolish. Of course it’s not a terrible mistake to make for a nontechnical person, but for a technical person working at such a public technological company, it is a sin.

In fact, it does nothing but showcase the issue that Adobe, and Macromedia before them, had: lack of knowledge about search engines.

Flash sucks for search engine optimization. Exclusive Flash sites are SEO suicide. This is because the content in the Flash is completely invisible to crawlers. Sure, there is a half-assed tool from Adobe, but without jumping through hoops, Flash is a terrible tool to use in large doses. Same goes for Flex, obviously, as it is just a complex Flash compiler.

Adobe, please leave your crack blog marketing squad at home, and instead listen to people’s complaints and issues without an immediate defensive stance. A little listening, and less arguing, would go a long way.

It’s come to my attention lately that predicting future trends is quite the hot topic lately. Instead of making wild guesses into the unknown, I thought I’d take a look at what wheels are already in motion.

The future of the web seems to moving towards offline applications, as evidenced by Google Gears, and desktop applications, showcased best by the upcoming Adobe AIR. Up until now, web trends seem to be leaning towards social networking through websites. Twitter, blogging, MySpace/Facebook, the current trend is to allow maximum communication on websites between friends.

Some of the newest technlogy from the web’s biggest players, Adobe and Google, seem to point towards the desktop, of all places.

Google Gears is something I covered briefly, but it bears a closer look. It appears that Google Gears works by installing a database engine on your local machine. From there, any website that uses Google Gears (I assume that Gmail, Google Docs, etc. will be fully compatible, as will hopefully all future Google applications) can synchronize the database on your machine with the information that is stored on the web.

The upshot of this is that using Google Gears on your site, you could pull information (say, emails) from either the internet or your local machine. Local data has the added benefit of being much faster than the internet, but the downside until now is that it’s difficult to keep in sync. It looks like if everything goes well, as the beta is suggesting, this problem could be solved. Now we have to wait and see it remains in beta status forever, like most of Google’s previous projects. Gmail, still a beta? Give me a break!

But the big question here is, is Google Gears a gimmick, or is it something that will change the way the web works? Still hard to say, because it has the capacity for both. It could be something that is used in a few websites once or twice and then never gets used again. Maybe the general population isn’t comfortable with the idea, or maybe they won’t quite “get it”. My money, though, is on the fact that Google is on to something here.

Adobe AIR (Adobe Integrated Runtime) is a little bit different than Google Gears. First of all, let me express my dislike for the name. I think it should either be AIR, or Adobe IR. If you parse out the whole word it becomes Adobe Adobe Integrated Runtime. Calling it just AIR (as it sometimes does in Adobe Labs) is fine, but they also call it Adobe AIR all over the place. My guess is they wanted both the neat acronym and branding, and kind of tripped over themselves.

Adobe AIR programs run on your local machine similar to how Java applications work: you first download and install a runtime environment, and then you can download .air extension files and run them. Adobe currently has a few examples of AIR programs on their Adobe Labs site. The ones that seemed most useful and most like “real-world application” and not just demos were the Google Analytics frontend and Twitter application.

In short, they are just desktop versions of those tools, Google Analytics has a similar front end, and Twitter works similarly as well. Adobe is trying to blend together the desktop and web experience, this time for internet-enabled users. Nothing I have seen indicates that it works like Google Gears in offline mode. This means that Adobe is aiming for internet users who do not wish to actually use the internet to get to their data.

The idea behind AIR is the concept of building Rich Internet Applications. It uses Flex, Flash, Ajax, and HTML/Javascript, and deploys the results onto the users desktop instead of onto an internet site. The applications then essentially use existing websites like webservices instead, grabbing the data and displaying it in the program.

What use will this have to the average web-user? Time will tell. It is a neat concept, for sure. But again, this product seems to be aiming for internet users who want to use desktop applications in place of the web. The big question here, and one that is probably in the minds of Adobe right now, is whether or not that’s what people want, and whether people will accept this new presentation.

My experience with the new runtime was that the applications were slick, looked nice, but seemed ever so sluggish compared to other desktop applications. It’s to be expected, since it’s drawing information from the internet, but will the average person get the distinction between an internet-enabled desktop application or not? The sluggishness of the program was enhanced further by transition effects that seemed to try and mask the responsiveness.

Overall the web seems to be heading in an interesting direction. The big question on everyone’s mind is, will it stick?

Adobe Flex, heralded by many as the coming of a newer age of web development, is evil.

I will admit right off the bat that the version I used was 1.5, and they are now on higher iterations of the product. I still maintain that, while in theory the concept of Flex is intriguing, it is way too seductive to web developers who simply don’t know what they are doing.

Flex promises to make it easy for web developers to build Flash applications for the web. The idea is that programmers do not have either the capacity to learn the animation-oriented Actionscript-based programming model of Flash, and so Flex is a simple alternative. Build a Flash animation for a website using a different method of programming, using an XML-based programming language called MXML. Then, provide little documentation on how it actually works.

The result was a rash of programmers back when Flex first came out who scrambled to jump on board. Some websites integrated Flex nicely, although I imagine (and know from experience) that it adds a layer of complexity to the maintenance of sites that use it. It requires a Java-based web server like Apache to run as well. This complexity is added when you consider smaller companies who are reliant on IIS learning both a new programming language, but a new web server at the same time.

The call of Flex is hard to resist, though. XML-based content delivery into a Flash file that is compiled from a command line interface? More programmers would be comfortable with that then Flash.

If you ask me, Flash programming is a strange combination of programming and web design. I think that web developers can program Flash, and web designers can program Flash, and that sort of makes Flex completely unnecessary and redundant. The one major advantage is that you can easily add dynamic content from an XML file – at least, that’s how some people sell Flex over Flash. Those same people, of course, don’t realize that Flash can do the exact same thing easily.

In the end, Adobe was only competing with themselves when Flex was developed. There was no real competition to Flash like Microsoft Silverlight is proving to be. There are a few differences between Flex and Flash, but even wikipedia is really stretching to list them. “Drag and drop” and “charts and graphs” are not features unique to Flex in the slightest. In fact, to me that sounds like marketing spin to try and make it sound like Flex is the latest and greatest in Web 2.0 (which most people associated with the term “drag and drop”, for some reason).

Flex is a needlessly complicated, redundant piece of software. In the end anyone would be better off hiring a Flash developer over implementing a Flex-based site. Flex can be nice for the occasional small integrated application, but is the overhead worth it?