Hiring front-end developers
julio-ody.tumblr.comToo true. These days front-end developers are expected to know frameworks and a plethora of lanauges which to me signals a company is trying to get not only a front-end developer but also is trying to get someone proficient in Rails or whatever language without paying more. "Oh, knowing Rails is a plus for this position" translates to, "We are going to pay you a $60k a year salary for a front-end position and get you to do the tasks of a Rails developer as well of which we pay $90k a year to" the line has been blurred you're either mostly front-end with a little knowledge of back-end and web apps like Wordpress and whatnot or you're backend with a little knowledge of front-end.
The wanky interview questions always make me laugh. Developers at their core are hackers, they know bits and pieces but not everything. A great developer doesn't know everything but knows what to type into Google when they need a solution to a problem. Collectively all of these tidbits create a cross-network of information developers share with one another. The questions that assume you are some all seeing, all knowing developer are a farce and you probably don't want to work at a place like that anyway.
The type of questions I would love to see being asked in front-end developer positions would be:
* What's the difference between display: inline-block and float: left?
* What is the default browser behaviour in a modern web browser when applying a padding left or right to an element with 100% with?
* How would you add a class to an element with the ID of, "content" via jQuery?
* Name two CSS browser vendor prefixes
* What is the difference between responsive design and adaptive design (bonus points for describing how and why one is easier and or harder than the other)?
* Which of these is not a valid CSS unit of measurement? px, pm, em, rem, %
* What is the difference between position: absolute and position: fixed?
These are questions good developers should know the answer too without Googling, they're not solutions they're somewhat basic things a front-end developer should know off of the top of his head.
Not:
* What are some of your favourite tech blogs to read?
* Can you please write a for loop that increments a counter?
* What web browser do you use?
* Can you recall a particular time when you found yourself solving a complex problem?
It's a tough economy and companies are always trying to get something extra for nothing. I've always had an issue with companies hiring so-called, designer/developers when we all know a true designer or developer doesn't fragment their time learning two crafts. You either become a great developer or a great designer not a mediocre hybrid who lacks full-understanding of each craft because you're too busy going back and forth with crafts.
A designer with no experience in development has a higher chance of creating a design that's difficult to implement. The amount of time wasted trying to explain to an illustrator CS buff why using vectors flying all over the place will be difficult... is ridiculous.
A developer with no experience in design has a higher chance of missing all of the features and nuances that make a sublime design kick ass (often the details a designer will ask for will be viewed as esoteric or anal..or esoterically anal).
Hybrids will do things like, look at illustrator...look at html5 canvas...and then combine the two into something awesome like Ai to Canvas. Hybrids will cut down your transition between design and development (which can be huge). Hybrids can cut down frictional labor costs. Hybrids can cross pollinate ideas between the two fields.
Case and point is that Hybrids are a class of their own. No, they may not have the extent of "depth" in their skill that a single focused dev or designer would, but that's because they have a "depth" in something different. And that "difference" is often innovative and far beyond what sticking to the "master of one" fallacy will do.
"A designer with no experience in development has a higher chance of creating a design that's difficult to implement."
It's better to educate the designers yourself than have them educate themselves because it's not guaranteed they won't still ask for a design that's borderline impossible to be cut up by tomorrow. The place I work at the designers design and the developers develop and it works great for us. The designers liaison with the developers throughout the entire process, it's not a simple matter of letting the designers have free reign and then expect you to develop it. I might be one of the lucky few, but this is how all places should work. Designers and developers should sit together not be isolated from one another and only speak via a project manager which is how it seems to be at a lot of places. It's an us vs them mentality in the industry.
A lot of places I've worked prior to the place I've been working for a few years now have had this mentality that the designers know best. While a designer who understands what is possible is a viable asset, a designer who considers themselves a developer and gets in the way of the process to the point they're telling the developers what to do is counter-productive rather than working with the developers not against them and vice-versa.
I've encountered hybrids who have adequately been able to do both development and design, not in an advanced capacity but I've encountered lots of designers and developers who can easily design and knock up a Wordpress theme, however I've never come across a designer/developer who can design a complicated interface for a web application and be able to build it as well. I could be wrong and I don't doubt there are some super-talented people out there capable, but I see too many advertisements for hybrids that assume they're as common as trees in a forest.
> I've always had an issue with companies hiring so-called, designer/developers when we all know a true designer or developer doesn't fragment their time learning two crafts.
I find it unfortunate that companies don't hire designer/developers more often. I've worked professionally in design and development roles, but it seems most companies want to keep them distinct, so I get typecast into one or the other. I want to be able to exercise all of my skills, especially when they are so closely linked in modern software.
You are right that time is definitely not on your side to try and do it, but I've been designing since elementary school and programming since high school, and had jobs doing both before graduating high school. I had an easy decade head start compared to anyone who might try the same in college. If you believe 10,000 hours to proficiency, that makes a huge difference.
Truth be told, I'm not sure how to accurately quantify my own abilities. Perhaps I really am mediocre at best, as you suggest. People seem to love the work I do though, whether it be design or development, so that is reason enough to continue with them both. Hopefully one day we can find tolerance of those who have an interest in both, and stop assuming all programmers cannot design.
I would love to hire a designer/developer. Can you get in touch with me via my profile.
That valid CSS unit measurement sounds like inane trivia to me. I've never had to use anything other than em, px, and % before and I've never even seen it in any open source projects.
They are very useful when you want to build modular web components, and for just overall maintainability of your stylesheets.
I wouldn't reject someone because they don't know what rem is though! I'd think of the question as a bonus I guess.
Definitely. You'd be silly to asses the skills of a developer based on such a question. My point was more-so that companies should ask questions developers would know instead of asking questions most developers would probably Google the answers to.
I can answer all except "What's the difference between display: inline-block and float: left?". What is it?
I learned CSS when IE6 was new and shiny. I think there's a gap in the market for books to update skills - e.g. a "What's usable in CSS since IE6?". I still find odd things I can now use as I only have to target IE8+...
If you want to learn more about this, the visual formatting model in the CSS 2.1 spec is very readable: http://www.w3.org/TR/CSS2/visuren.html.
If I were interviewing a candidate, I wouldn't expect them to be able to deeply recall most of that detail (though I'd expect them to be familiar with the basics). I'd accept an acknowledgement that floating an element takes it out of the flow, while using inline-block doesn't, as well as some further detail about what that means, what impacts/side effects it has on other elements and markup.
I like the questions. I do not consider myself a front-end developer although I enjoy working with JS. I don't know the answer to the first two, though.
> I’m not advocating ignorance, but making that a part of the interview process is too much. Leave it. I’ll know that sort of thing when I need to know it by googling.
This is spot on, there are some JavaScript "advanced" topics that people should be aware of, but I don't think someone who doesn't know all the answers to this one: https://github.com/nathansmith/javascript-quiz/blob/master/R... is by definition a bad developer, yes variable scope is one of the things you have to know, and the meaning of "this", but there are things you can just experiment in the console, or as you said Google and not have to memorize and still be a great developer.
These kinds of questions are very different from questions about browser quirks. These questions get at the depth of understanding of the language itself. It is akin to understanding how a C++ program is going to use the stack and the heap, etc. Only after understanding the language fundamentals can you answer these questions and only then can you truly understand the code you are writing. With depth of understanding comes an ability to make better decisions about how and when to use and tool. Almost anyone can use jQuery, but writing it or something like it requires a different level of knowledge.
I've been to a few interviews recently for web stuff. I don't consider myself a developer, but I do know some programming. I think telling companies what they should or should not do is fruitless unless you know the background.
First thing is that many of these companies want something cheap, so they call around and get something built locally for under 10k or call India. The site, that should have taken 6 months to build, is still being worked on after 2+ years. The company finally realized they got screw-balled and now they want to post about as much as they could for insurance.
The other issue that this article ignores is that many times these half-assed dev houses actually do create a quagmire of development technologies that run the mill from WordPress / Magento / Ruby / and every new javascript framework that comes around, and yes, even a mix of HTML, XHTML, and HTML5. Companies could also be asking for this list of products because they want someone with experience. Someone that has been around the block will have programmed in HTML4.1 at some point.
The real problem isn't the customer. They shouldn't know about, or have to care about, technology any more than you should care about, or have expert knowledge, of your lymphatic system. You pay good money to doctors who know this stuff, and unlike the average mill web house, the doctor is actually educated and knowledgeable of the field.
The problem isn't the customer, the problem is that web development is a world of slick-tongued sales people and charlatans. Most of these morons can't code at all and they basically take the money and run. They run into edge-cases and they just pile poo on top of poo, or they just abandon the job when the going gets tough. Companies create these ads because they want to defend themselves from getting screwed over again, and they are hedging their bets the best they could. It's a sad state of affairs, but the web world sort of brought this on itself.
I find that the "front-end developer" title is overloaded.
On one end of the spectrum, it means someone that can create and design UI mockups, and implement them using CSS and jQuery. For that type of job, asking algorithm questions makes very little sense. A strong portfolio would be a much better gauge of that person's skill set.
On the other end, it means someone who's able to engineer a web client using MVC frameworks and say, CORS. In contrast, algorithm questions make a ton of sense here.
The thing that always gets me is when I'm interviewing for a front-end development position, and they end up asking me how to write algorithms during the interview. Do you really want me to write algorithms all day? Or do you really want me to build the front end of your website? I've written very few algorithms in my time as a front end developer, but nearly every day I have to deal with an obscure browser quirk, rendering optimization, or usability problem. Ask me about one of those problems!
I tend to disagree. Why would you ask me about an obscure browser quirk? The interviewer would be much more better off testing my persistent and precise Google and StackOverflow searching skills in this case. Same for optimizations, and usability is quite subjective and truly needs A/B testing and real user feedback to have a conclusive decision. You could test those skills instead of directly asking me to solve one of the problems you cited. Now, writing an algorithm is not something, for the most part, that you would have needed to have memorized in order to answer the question. Developing even a naive algorithmic implementation for a given hairy problem is an actual skill that developers carry with them to be useful anywhere, and in my front end work they have been useful (plus it's so fun when I get to apply them). Granted, I'm currently developing a completely flexible and configurable application, so I tend to get into data structures and algorithms even though my work is exclusively CoffeeScript on the front end.
For 98% of the gigs it really is silly to ask algorithm questions. Most front-end guys don't come from a CS background; they either picked it up on their own, transitioned from design, etc. In these cases the back-end is doing the heavy lifting.
For the other 2% of the gigs, yeah it's really important.
> > You’ll be working on a greenfield project. Any tool you use is fine as long as you know it REALLY well. Except of course for Ext.js. There’s just no excuse for using it ever.
This definitely deserves extra emphasis.
Why? It's a silly comment on ExtJS. It's a huge framework but in the right context, it can be exactly the right tool for the job.
That's the thing, it's never the right tool for the job. Hence the comment that it should never be used, ever, under any circumstance.
If you're interested in a front-end position at SurveyMonkey, feel free to get in touch--we're hiring right now and, having joined recently, I can say it's an awesome place to work.