610 Design » business

Interviewing Web Developers – Good Questions to Ask

schoey — Tue, 04 May 2010 14:05:26 +0000

The company I’ve been working for is currently looking for a new web developer/designer. Prior to conducting the interview, I wrote up a list of technical questions I wanted to ask. I decided to build upon this list of question and put together a larger one that everyone could use – both for interviewers and interviewees.

The list is not specific to any particular type of development position, but I tried to balance it between both the design/html/usability side of things and the back-end/database/programming side. I’m just focusing on web development related questions – you should obviously ask the usual barrage of questions like “Why do you want to work for [some company?]” I’m not covering those types here. Also, this list isn’t in any particular order.

What industry sites and blogs do you read regularly?
This question can give you an idea of how in-tune they are with the latest industry trends and technologies, as well as how passionate they are about webdev. It’ll help separate the people who do it as a career AS WELL as a hobby from those who might simply be in it for the big developer paychecks.
Do you prefer to work alone or on a team?
This is an important question to ask depending on the work environment. If your project is going to require close interaction with other developers it’s very handy to have someone who has had that kind of experience. On the other hand, many developers thrive while going solo. Try to find a developer that fits your needs.
How comfortable are you with writing HTML entirely by hand? (+exercise)
Although their resume may state that they’re an HTML expert, often times many developers can’t actually write an HTML document from top to bottom. They rely on an external publisher or have to constantly flip back to a reference manual. Any developer worth a damn should at least be able to write a simple HTML document without relying on external resources. A possible exercise is to draw up a fake website and ask them to write the HTML for it. Keep it simple and just make sure they have the basics down – watch for mistakes like forgetting the tags or serious misuse of certain elements. If they write something like: , it might be a good hint to wrap things up and call the next interviewee.
What is the w3c?
Standards compliance in web development is where everything is (hopefully?) going. Don’t ask them to recite the w3c’s mission statement or anything, but they should at least have a general idea of who they are.
Can you write table-less XHTML? Do you validate your code?
Weed out the old-school table-driven design junkies! Find a developer who uses HTML elements for what they were actually intended. Also, many developers will say they can go table-less, but when actually building sites they still use tables out of habit and/or convenience. Possibly draw up a quick navigation menu or article and have them write the markup for it. To be tricky, you could draw up tabular data - give them bonus points if they point out that a table should be used in that scenario
What are a few of your favorite development tools and why?
If they say notepad you’ve obviously got the wrong person for the job. Not only can this help you gauge their level of competence, but it’ll also see if they match the tools everyone else uses in-house.
Describe/demonstrate your level of competence in a *nix shell environment
See how well they work without their precious GUI. Ask some basic questions like how they would recursively copy a directory from one place to another, or how you’d make a file only readable by the owner. Find out what OSs they have experience with.
What skills and technologies are you the most interested in improving upon or learning?
Find out if their future interests match the direction of the position (or the company in general).
Show me your portfolio!
A portfolio can say a lot about a developer. Do they have an eye for aesthetics? Are they more creatively or logically oriented? The most important thing is to look for is solid, extensive, COMPLETED projects. A half dozen mockups and/or hacked-out scripts is a sign of inexperience or incompetence.
What sized websites have you worked on in the past?
Find a developer that has experience similar in size to the project you’re putting together. Developers with high traffic, large scale site expertise may offer skills that smaller-sized developers don’t, such as fine tuning apache or optimizing heavily hit SQL queries. On the other hand, developers who typically build smaller sites may have an eye for things that large scale developers don’t, such as offering a greater level of visual creativity.
Show me your code!
Whether it’s plain old HTML or freakishly advanced ruby on rails, ask for code samples. Source code can say more about a persons work habits than you think. Clean, elegant code can often be indicative of a methodical, capable developer. A resume may say 7+ years of perl experience, but that could mean 7 years of bad, unreadable perl. Also, make sure you ask for a lot of source code, not just a few isolated functions or pieces of HTML. Anyone can clean up 20-30 lines of code for an interview, you want to see the whole shebang. Don’t ask for a full, functional app, but make sure it’s enough that you can tell it’s really what their code is like.
What are a few sites you admire and why? (from a webdev perspective)
Find out what inspires them. While it doesn’t necessarily “take one to know one,” a great developer should always have a few impressive favorites.
Fix this code, please.
Give them some broken code written in the development language they are expected to know for the position. Have them go through it line by line and point out all the mistakes.
I just pulled up the website you built and the browser is displaying a blank page. Walk me through the steps you’d take to troubleshoot the problem.
This is a great question to determine how well rounded their abilites are. It tests everything from basic support skills all the way up to troubleshooting the webserver itself.
What’s your favorite development language and why? What other features (if any) do you wish you could add to this language?
Asking about feature additions is a particularly valuable question – it can reveal if they’re skilled in programming in general or if their skillset is pigeonholed into their language of choice.
Do you find any particular languages or technologies intimidating?
I’ve often felt that the more I learn, the less I feel like I know. Solving one mystery opens up ten others. Having the interviewee tell you their faults can reveal a lot about what they know.
Acronym time (oh boy!)
Some might argue that knowing what acronyms actually stand for is trivial, but there are certain acronyms that a developer should have hard-wired into their head ( HTML or CSS, for example). This is the kind of question that might be better reserved for the phone interview to weed out those who are very unqualified.
What web browser do you use?
There is a right answer to this question: all of them. A competent developer should be familiar with testing cross-browser compatibility by using all the major web browsers. Obviously they’ll have a primary browser they use for surfing, but their answer to this question might be a good way for you to segue to asking how extensively they test cross-browser issues. Also, if it’s some kind of css/html position seeing what toolbars they have installed can be a good metric of their skillset (I personally find the web developer toolbar for firefox to be invaluable)
Rank your interest in these development tasks from 1 to 5 (1 being not interested at all, 5 being extremely interested)
Write up a list of tasks the job requires. Having them rank these items according to their interest level can help you find who is the best suited for the position. I know debugging uncommented perl code from 1997 sounds seriously awesome to me.
What are a few personal web projects you’ve got going on?
Almost all developers have personal web projects they like to plug away at in their spare time. This is another question that can help differentiate the passionate developers from the clock-punchers. It’s also a good question to end an interview with, as it’s usually easy (and fun) for them to answer.
What do you know about CSS3 and HTML5?
You can judge how up-to-date this person is one web trends.
What side of the Adobe -vs- Apple war are you on?
A fun question with no clear answer, since both sides can be argued. While this is a “fluff” question the interviewee should know about Apple’s iTouch, iPhone and iPads not supporting flash. Why Apple’s not support flash on those products and ways around it.

Sources: seomoz, Dey Alexander, Tech Interviews

How to Fail at Your Design Business

610design — Thu, 11 Feb 2010 21:58:52 +0000

This is it. You’ve worked many long, hard hours developing your Pen tool skills in Illustrator to the point you could probably add “Pen Tool Ninja” to your business card. You’ve learned so much about graphic design that your head is bigger than Rush Limbaugh’s waistline. You know so much about web design that you pretty much invented the Internet. Now’s the time.

You’re starting your own design business.

Running your own design business is part awesome, part OHGODWHATHAVEIDONE. You’ll find tons of How to articles online, dealing with how to be a successful designer slash businessman. But where can you find an article on how to fail at your design business? Right here, readers. Read on for step 1.

Suck at design

Step one to failing at running your own design business is to be terrible at design. Use Comic Sans. Have a cute mouse follow the cursor on websites you build. Why use a subtle gradient when you can use a yellow-to-purple gradient, plus embossing, drop shadows and letterpress technique? Be careful though; you can learn to NOT suck if you listen to your peers and seek out constructive criticism on your designs. Avoid this at all costs.

Lesson: be good at what you do, and seek feedback to keep getting better.

Do everything yourself

If you want to fail at your design business, then you should do everything yourself. I’m talking about developing a marketing plan; doing all the accounting; sales; project management; web design; print design; content-management-implementation; identity design and more. Yup – if you do everything yourself, not only will you fail spectacularly – you will probably be bald and malnourished by the time you get to the point of fail.

Lesson: learn to let go. Hire or subcontract to people you trust, and give them the power to make decisions.

Deadlines are for losers

You know what sucks? Conan O’Brien getting the boot from the Tonight Show. You know what else sucks? Deadlines.

Deadlines totally hinder the creative process by making you work efficiently and in a focused manner. Plus, deadlines mean that you actually have to get your work to your client at a pre-determined date so the project can move forward. Such rigid structure in a creative field? No thanks. Plus, your clients actually don’t want you to hit their deadlines. By missing their deadlines, you’re essentially saying to them “You can’t hold me down. I’m a creative REBEL – like a deadly combo of James Dean and David Carson”. Clients find this sexy and will totally call you the next time a project comes up.

Lesson: learn to work with, respect, and hit both yours and your clients’ deadlines.

Treat design like art, not business

The phrase “design business” is sort of an oxymoron, because design is art, like everyone knows. It’s sort of like saying “check out my wicked angel tattoo” – we all know angels aren’t wicked except in that new Legion movie (which totally looks great and definitely not like the worst movie of all time).

I digress. Make sure your clients know that design is art, and if they don’t like your proposed design concepts, it’s because “they just don’t get your art”. As well, a surefire way to effectively gain new clients is to speak YOUR language (art) and not theirs (business). For example, if you’re trying to land a new web design job, be sure to talk about very specific art principles and theories in order to impress them. Avoid, at all costs, talking about how the website you can build for them will increase sales/their bottom line/conversions/anything measurable. Your clients are business people, and business people hate measurable results.

Lesson: if you’re starting a design business, recognize it is a business and treat it like such. Learn the language and best practices of business and combine that with your creative skills to be successful.

Remove ‘No’ from your vocabulary

If you want to your design business to fail, always say “Yes”. No matter what the deadline is; no matter what the budget is; no matter what else you have on your plate – always say yes. This will ensure failure just like signing Michael Bay on to direct your film will ensure lots of explosions (and deep, thought-provoking dialogue).

The problem with saying “No” is that you end up being selective with your clients and taking on projects that suit your style and goals. Since we’re talking about failure here, we need to say “Yes” to everything – that $50 logo design job that needs to be done tomorrow, that $200 web design job proposed by that guy whose belt is made up of the bones of past designers – everything. So make a rule and hang it in Comic Sans above your workstation: “No is not in our vocabulary”.

Lesson: sometimes it’s tough, but you have to learn to be able to say no in order to succeed. Not every job is ideal, and not every client is a great match. Learn to see the good ones in advance, and know your limits.

These are only a few way to fail at your design business – there are many more. What are your favorite ways to fail?

Source: inspiredm