131–140 of 152 posts
Earlier quoted context omitted.
Employment probation. We fired a few people right off the bat within 3 months because they very clearly bullshitted us. One guy fucking used notepad to code. I'm not joking.
What exactly is wrong with using notepad to code? No syntax highlighting?
This looks like a giant list of trivia that has almost no bearing on the day-to-day effectiveness of the candidate. For example, I don't have the slightest clue what the answer is to probably half of these and a lot of my job is to write javascript that gets run millions to billions of times a day. The "code questions", by contrast, were all ridiculously easy. So, would it really matter if you are hiring someone who…
There are some good questions, on there, but as you say, a lot of them read like "Front End Developer Trivial Pursuit". For example, bad questions: * How is responsive design different from adaptive design? - there's no formal definition of either. While it might prompt a discussion, it will probably just make the interviewee feel nervous, when you should be trying to get them to relax. * Why is it called a Ternary e…
I'd be really interested in learning if the amount of technical debt that we don't ever have to pay off is rising (because product lifetimes are shorter, performance is going up, and libraries reduce the total code you write).
This one is a joke right? "What's your favorite feature of Internet Explorer?"
Anyone else feel like there is a lot of esoteric information here? For instance: > Are there any problems with serving pages as application/xhtml+xml? I've never had to or considered serving pages as application/xhtml+xml, there's no reason for me to know the answer to this question and I've been working on the front end for ages. If I ever had reason to serve a page application/xhtml+xml I would thoroughly research…
> I've never had to or considered serving pages as application/xhtml+xml, there's no reason for me to know the answer to this question I think VML's response is valid here, it's to check for experience and if you were engaged enough with the happenings of the web at the time. Background (not a 100% accurate, I'm writing from my admittedly poor memory): XHTML and later XHTML2.0 were being pushed a while ago (early 200…
Earlier quoted context omitted.
>if I were going to work exclusively on the front-end This is the important clause. Imagine looking for a backend developer. A candidate with twenty years of experience shows up. Looking at his resume, you see the chronological buildup of terms: HTML, XHTML/DHTML, JS, JQuery, Prototype, mootools, YUI, Ember, Knockout.js, Angular, Om. "Well, this is an impressive resume, but we're really looking for someone with more…
Surely one is capable of customizing the interview based on the candidate? I'm operating under the assumption here that the candidate has already been working professionally as a front-end developer. Do you really think it's unreasonable to expect someone who's professionally doing exclusively front-end development for a minimum of 40 hours a week to do at least somewhat well on these questions? I didn't mean to impl…
But I think I'd probably have trouble hiring, and I'd start to think there's a talent shortage.
What we're doing, as an industry, is eating our own seed corn. We're eager to front-run on experience and knowledge, but unwilling to sit around and let them cook. And, frankly, this is somewhat justified, as devs aren't famous for sticking around.
What we should be doing is satisficing rather than optimizing.
If you (and now I mean you you, not the indefinite) were going to work exclusively on the front-end, I highly doubt you'd know the answer to these. Hypothetical: you're fired today, I hire you tomorrow to work on my front-end stuff. Is the first thing you do to start looking up JS trivia?
No! Hell no! Because you're a responsible person. You'd work on...what needs working on. Oh, this page is loading slowly, time to learn how to use Chrome's profiler. Hmm, this div is behaving oddly, time to refresh on CSS.
And yeah, you'd get bitten by something on this list. But...so what? There's always something like that, no matter your experience level, and if you do happen to be that mythical person who's absolutely mastered a stack, surprise! We're switching (back) to Backbone tomorrow.
Would any of this make you unsuitable for the position? I don't think so.
Back to the example, yes, if you've got a hairy distributed systems problem, and someone applies with 20 years of experience in distributed systems, yes, you hire them. But if and when they call and say, "Well, Google offered me more millions than you offered me hundreds of thousands, so..." and you're left with candidates with 20 years of experience divided between COBOL, webmastering, AJAX, Rails work, and open-source contributions to Julia and Battle for Wesnoth...then yeah, sorry you didn't get the unicorn, but that second guy will be just fine. Get the distributed-systems guy in as a consultant for a week or two if you have to. If he really is that good, you might not need to hire anyone at all!
This whole thing is a result of developers overvaluing intelligence and being scared of not being the expert on something, employers buying it that programmers are superpeople, and then acting like it's a betrayal of trust when they don't know every small detail of every technology they've ever used, and both parties' refusal to think about what they need, rather than what they want. The tell-tale sign is that "hiring is hard," but there are still technology companies around. Sure, if you're hiring better ("top 1%") people rather than good ("good") people. And developers are just as bad: not everyone can be paid above average.
Earlier quoted context omitted.
I was thinking the same thing. I've built manys a website in pretty much every front-end language imaginable and I would struggle to answer many of these. Yet I feel little shame in saying that I believe myself to be a very competent programmer. What is the significance of having memorized a bunch of arbitrary terms? If you don't know what the difference is between and that doesn't mean you aren't a competent develop…
If you don't know what the difference is between and that doesn't mean you aren't a competent developer. No, but it does mean that you don't know about deferred script execution and possibly do not have a lot of experience in optimising page performance. Hardly the end of the world, but if you're looking for a senior developer you might really want that skillset.
That might have been something that senior devs only did 5-10 years ago, rather than something senior devs do now, though if that's the case one might wonder exactly what we mean when we say "senior."
This looks like a giant list of trivia that has almost no bearing on the day-to-day effectiveness of the candidate. For example, I don't have the slightest clue what the answer is to probably half of these and a lot of my job is to write javascript that gets run millions to billions of times a day. The "code questions", by contrast, were all ridiculously easy. So, would it really matter if you are hiring someone who…
Well, at least it would give a hint whether the candidate ever touched meta-programming. All the other question are mostly about writing correct code, this was the only one about writing less code.
Earlier quoted context omitted.
If you don't know what the difference is between and that doesn't mean you aren't a competent developer. No, but it does mean that you don't know about deferred script execution and possibly do not have a lot of experience in optimising page performance. Hardly the end of the world, but if you're looking for a senior developer you might really want that skillset.
Or you had other ways of indicating scripts were meant for processing after the document had been parsed (which might be smart or even essential depending on your support targets). That might have been something that senior devs only did 5-10 years ago, rather than something senior devs do now, though if that's the case one might wonder exactly what we mean when we say "senior."
Earlier quoted context omitted.
I was thinking the same thing. I've built manys a website in pretty much every front-end language imaginable and I would struggle to answer many of these. Yet I feel little shame in saying that I believe myself to be a very competent programmer. What is the significance of having memorized a bunch of arbitrary terms? If you don't know what the difference is between and that doesn't mean you aren't a competent develop…
If you don't know what the difference is between and that doesn't mean you aren't a competent developer. No, but it does mean that you don't know about deferred script execution and possibly do not have a lot of experience in optimising page performance. Hardly the end of the world, but if you're looking for a senior developer you might really want that skillset.
Perhaps, but as with any question like this, it's a foolish interviewer who draws such a broad conclusion from such a narrow data point. For example, as it happens I do know what does, but that includes the fact that it can't be used reliably before IE10, which is why I've never actually used it on any production site. Not having encountered that particular functionality would therefore have made absolutely no difference to any project I have ever worked on, nor had any relevance to any senior people I was hiring to work on them with me.