Tips for Job Interviews

I’ve helped execute a few job interviews for work this last week and I wanted to pass along a few tips for my readers here who for some reason may not have heard these tips:

  1. Only be yourself if that’s good advice.  If you’re really a jerk, don’t be yourself.  Everyone else: don’t be fake.
  2. If the end of each of the answers you have to any number of questions concludes with something like, “…and that’s why I think I’m perfect for this job,” then you’re more than likely not perfect for the job.  That is of course unless they ask you over and over why you’re perfect for the job.  If they are asking that one question over and over you probably have found a job that is not perfect.
  3. If someone asks you to tell them about yourself, tell them briefly about yourself.  Do not tell them almost about yourself, about what your department does, your sex life, or anything else that is either far too explicit or not actually about yourself.
  4. If someone asks you when was the last time you were dishonest at work the correct answer is always one of two things: 1) I am always honest or 2) When I didn’t tell them I was coming to interview for another position.
  5. If you are asked about your career aspirations give something concrete.  We don’t care if you want to be the first person to discover a unicorn’s remains in the mid-layers of the earth’s crust, but we do care that you have a solid, clear answer.  Dancing around the answer to the question because you’re not sure is way worse than saying you’re not sure.
  6. Use Google to determine even more about the company you’re applying at.  In our case knowing roughly what our company produces (besides a tremendous amount of awesome) will get your far with almost all the leadership.  If there’s a product you can touch, find it to touch if at all possible.  If it’s software, install it.  If it is anything you can look at or experience in a safe, legal way – get it and look at it and experience it!
  7. Be ready to give feedback about the product or products you interacted with.  Be nice, though.  A lot of blood sweat and tears goes into different products so ripping into them is worse than just canceling the interview 🙂
  8. Know the key, broader principles that you operate by so that you can address issues you’re less specific with as specifically and effectively as possible.  Example: I know that there are a tremendous number of programming languages that are available today but I’m competent in a few of them and the principles behind good, clean software development apply to all of them.  If I get asked about C# (which I’ve only tinkered with) I can at least tell the person I’m familiar with Java and would be willing to learn C# if the job required it.
  9. Be punctual – don’t be late, but don’t be 30 minutes early
  10. Come prepared with questions for the interviewers.  They’re going to interview you, but return the favor.  Think of a past job that stank because you didn’t have a great relationship with a manager, or you hated a certain process.  Avoid repeat situations by asking questions about specific details that you either are very familiar with or are able to speak to knowledgeably.  This is probably better than a 2 page resume (with too much information on it) for revealing your competency.

What are your tips, readers?

Flash: Not as Evil as Bad Coders

I’m tired of the argument that Flash crashes browsers, consumes CPUs (and thus electricity and your laptop battery), and keeps your fan going.  Guess what?  Bad code outside of flash, and in HTML5, can do the same thing!  Open Google Chrome and launch Twitter, Facebook, and Google Reader and check your resources.  Is Chrome eating up system resources?  You’ll probably not be surprised to discover that it is.  Advertisers are using Flash and they’re using it in intensive ways.  Flash by its nature sits as a plugin for most browsers (Chrome actually being an exception) but those browsers and Flash rely on developers doing certain things.

Worse, in HTML5 web workers you can set up a loop that will take a machine to its knees even if it doesn’t do anything.  I’d make a demo page, but someone will undoubtedly use it for evil, so just trust me that a bad coder doing bad things can use non-flash things to take down your computer.  I can do it without HTML5, too.  I can probably write bad code in every programming language and probably take down every machine – because it’s bad code.  Don’t blame the messenger [AKA Flash]!  Blame bad coders and people who are using it irresponsibly.   There are bugs, there have been security problems, but Flash is just as vulnerable as the browsers, and even your word processing software (ahem, Office + Macros).

I should also point out: I don’t code/program in Flash.  I have nothing to gain from Flash being anywhere (except of course when I play Scrabble on Facebook, which I quite enjoy). I just don’t like it when people point their fingers at one technology or another like has  happened to Flash pointing to the middle of the problem instead of the root.

Elections

The election results speak for themselves: the American people have spoken and they chose a massive, chaotic amount of wishy-washy political gunk just to make sure that no party blows it as bad as the previously majority-owning Democrats did in D.C..  And to make sure that our government is bi-partison, but pro-lobbyist.  Rock the vote indeed.

This skeptical message was brought to you by the committee to elect no-one.

“I’m Randy Peterman and I do not approve this message.”

If You Don’t Vote Tuesday

If you don’t vote on Tuesday then it’s like a vote for the Texas Rangers.

If you don’t vote on Tuesday then it’s like a vote for Pamela Anderson for Sunday School teacher.

If you don’t vote on Tuesday then it’s like a vote for the terrorists.

If you don’t vote on Tuesday then it’s like a vote for my beard to grow out to the point where I actually look like a mountain man.

If you don’t vote on Tuesday then it’s like a vote for eating a sewage shake.

If you don’t vote on Tuesday then it’s like you don’t count.  Make your Tuesday November the 2nd count.

HTML5 *Is* Ready

In what has to be one of the weirdest declarations of 1990’s Netscape4 vs. IE4 thinking the W3C’s Philippe Le Hegaret has suggested that we not deplay HTML5 yet in web projects.  I’m pretty sure that if we wait until all the web browsers are ready for HTML5 we’ll get the go-ahead in 2036, about the time I’m ready to retire.  Some poor blokes will still be on IE6 with more malware and viruses than Windows ME can deal with and the W3C will be telling us that we should still step into the HTML5 pool with gingerness.  Forget about HTML5 as a stable standard since we have things like HTML5Boilerplate, and JavaScript patches as well as things like Google Chrome Frame.

The idea is not that we should try to implement every fringe, unverified hack and standard, but we’ve been working with bleeding edge HTML4.1/ECMAscript and de facto browser standards for over a decade.  If that’s not clear to the W3C then I’m pretty sure they’re not prepared for 2011 when every major browser vendor will announce that they’re HTML5 ready.  Will there be interoperability issues?  Certainly.  Will there be hacks to get around them?  There already are!

HTML5 is a great concept and I think it will be the de facto standard moving forward from 2011 further.  I’m going to be updating all of my blogs to use HTML5 as time allows.  HTML5 will save money (working on a blog post for that) for companies that deplay the markup, ISPs who have to have provide bandwidth, and save time for end users who do almost nothing but upgrade their browsers to HTML5 ready versions and get the benefit.

One of the problems that made the HTML4/Netscape 4/IE4 wars so difficult was that bandwidth was scarce and unless AOL shipped yet another CD to your house with IE (5 or 6) on it, upgrading could take so long that your grandma’s call on the dial-up connection could be blocked.  However, with DSL and various other broadband mechanisms in place on top of auto-updating browsers the cost of the upgrade is minimal at best.  HTML5 is not the future, it’s the present.  Google pushed Google Wave as HTML5 goodness May 27th 2009 as a presently capable, functional application.  That means that very large corporations reaching millions of users have been using HTML5, even if it required a sub-set of browsers, for a hear and a half.  That means that my iPhone, my BlackBerry, my Droid and an array of other devices running Webkit and my desktop browser are all generally HTML5 capable.

I believe we can use HTML5, even if we don’t get to use it every single day for every possible feature it could provide if cross-browser perfection were achieved.  It’s ready.

Design & Development Links

Along the line of software craftsmanship on the web here are some handy sites I’ve seen recently:

JS Patterns
JS Patterns is a site dedicated to the design and development patterns that are not only industry standards, but also patterns that are native to JavaScript (which C++ or Java cannot do natively). This is definitely worth adding to your RSS feed reader.
Dustin Diaz
Dustin happens to work at Twitter, but his site is loaded with good JavaScript tips. If you’re not following his writing I’d suggest you consider doing so.
BlackBerry WebWorks
The WebWorks development/widget framework for BlackBerry devices looks interesting [disclosure: I work for a RIM subsidiary and have nothing to do with this project]. Download the toolkit from github or from RIM’s site and check it out. It’s focused on giving web developers a web-focused interface to develop for the webkit based smartphones.

Toolkits, Frameworks, and Libraries, Oh My!

On Monday the 4th of October Chris Coyier of CSS Tricks wrote on Twitter:

What they call themselves: jQuery = Library YUI = Library ExtJS = Library MooTools = Framework Prototype = Framework Dojo = Toolkit [cite]

I just got some crap for “not knowing the difference” – which I don’t. It’s just semantics (literally) as far as I know. [cite]

While I think it’s absolutely bad form for people to attack him on his use of those terms synonymously, it connected two apparently opposite ideas in my mind.  It resonated with some ideas I had about a debate that’s been going on in the last few months since Rebecca Murphey suggested that jQuery was not up to the task of being used as a framework in a browser based web application [cite].  Then there’s the jQuery forum discussion of adding JavaScriptMVC as an enterprise branch of the jQuery project [cite].  But here’s the big “revolutionary” idea: jQuery is just a library.  It is not a framework.  It goes well beyond a simple toolkit, but it is an excellent library.

Now, let’s get down to brass tacks.  In the first 10 years of web development there was a lack of craftsmanship and instead a lot of do it yourself or self-directed education by the community as we all learned the emerging web technologies.  I learned my first bits of HTML from HTML Goodies.  I then spent time on other sites and read a few JavaScript for Dummies type books when I got started over a decade ago.  Terms like Library, Toolkit and Framework were never discussed.  However, from an academic level these terms imply things about the code’s purpose and therefore are a critical part of the discussion.

Toolkit
A toolkit is a combination of classes or functions that do not define or limit the design of an application.  A toolkit may have a small handful of functions that allow you to do rollover events (see also: Dreamweaver’s JavaScript tricks).
Library
A library is a collection of classes or functions designed specifically to interface with one particular complex task.  Examples of a library might be an image manipulation library or a canvas manipulation library.  jQuery is a library because it was fundamentally a DOM manipulation library.
Framework
A framework is a collection of classes or functions designed to implement a certain pattern for a specific class of software.  A framework is for specific domains or types of applications such as web applications.  JavaScriptMVC is a framework for developing Model-View-Controller based web interfaces.

Did you see what I did there?  I just diffused a bomb.  OK, not really.  Rebecca Murphey’s direct problem with jQuery (and she has stated this) is not that it is a bad library, it is that it is not a complete framework.  That’s OK, because John and the rest of the jQuery developers have not been trying to make a framework.  John Resig doesn’t want an MVC framework as a direct branch of the jQuery library because JavaScriptMVC goes well beyond the purpose of the jQuery library.  However, the work done to build JavaScriptMVC as a framework that uses the jQuery library is really, really cool and powerful.

Across the spread of the web horizon lies the Dojo toolkit, which has expanded beyond just being a toolkit and really has taken on a multi-tiered approach: it has a toolkit presentation due to its name, but it really is a library (for the DOM like jQuery), but it also has a framework for creating MVC styled applications and taking on the details of a larger built application (See the Dojo Builder for Eclipse or the dojo toolbox).  The purpose of the build tools is to allow you to compile the appropriate libraries from within the larger Dojo framework into a final, smaller file (or files) for inclusion in your project.

So fundamentally you need to ask yourself what your project needs: does it need a toolkit?  I would suggest it just might given that there may only be a handful of tasks that you really need to accomplish.  Does it need a library?  If there is very much DOM manipulation you should evaluate the various libraries and confirm that one of them meets your needs (or has the smallest learning curve, or whatever specifications you have) .  Does it need a framework?  Are you making a website or a web application?  If you’re making a web application you probably need a server side framework such as CakePHP or Ruby on Rails.  You probably want to consider what client side framework you’ll need.  Having rolled my own I can confidently say that rolling your own won’t kill you, but you should absolutely consider the frameworks that do exist because it could save you time and be very extensible in the future when your project goes for another iteration that needs more meat.

This hasn’t been a journey down the yellow brick road to the emerald city, but whether you see lions, toolkits, or bears be aware that the terms do have a technical implication and your use of them may help clear up confusion.  And it could help you in that next interview when the project lead asks you if you prefer to use one religious war starting technology over another more holy religious war starting technology 😉  I’m going to stick with using my new favorite library: vapor.js.

I Speak in Rabbit Trails

A friend from church said to me, “I speak in rabbit trails,” while we were discussing a Sunday school class environment.  That quote made me smile a big grin and I asked her for permission to use that quote on my website.  So now it is the sub-title for my blog.  It’s not original to me (obviously), but I feel like it is reflective of the places this mind wanders to.