Ok knowing CSS precedence rules is not a requirement. It was a gotcha question. It isn't that hard to imagine that an interview candidate might get defensive over a gotcha question. As I posted to muttiah, experience over a 12 year period doesn't necessarily mean that they are completely knowledgable of every thing they worked on over a 12 year period.

So being an expert isn't required. I could probably learn the basics in a day or two. I guess it depends on what the criteria for basics is.

What programming assignments were you actually interviewing for? What would be the duties that the developer would have?

Again apparently being an expert in JavaScript wasn't a requirement to complete the assignments that the developer would be undertaking. I could learn how to declare a function in JavaScript in a day or less

A bit of devil's advocate here, but it might just be that the person has always worked with an existing code base and so hasn't had to do a lot of writing code from scratch with no other references.

It's s bit like people who use gps so often they don't know the way even after driving a route many times.

That being said, writing a function is pretty basic.

I was just doing my standard timewaste on StackOverflow and saw a doozy of an interview question (which didn't really belong on the site but whatever).

This guy got asked in an interview: which software design pattern does Air Traffic Control use and why?

I'm confused about what your point is. I could learn that an atom is larger than an electron in a matter of 2 seconds, but if I don't already know that when applying for a job as Lecturer in Physics, that doesn't imply good things about my general knowledge of physics.

Knowing the syntax for declaring a function in Javascript isn't being an "expert". It's about as basic as knowledge of the language gets.

I'll also warn that if someone has 12 years of experience then they may not be fresh on everything. And syntax is something that goes pretty fast, imo.

None of this is to defend the particular candidate blackize had. They were there and saw him. Just that the general comments aren't quite as simple as they may appear.

From time to time I interview candidates and I am sure I will do more. I get a sense of their experience form the resume. The number one thing I want to know about is what the candidate is what they are passionate about. That will tell me a whole lot about that candidate. They will want to go into detail about their passion. I do anyway. It isn't necessarily an easy thing to do and of course some people are duds.

I also want to know how they view the process of developing software. What are their thoughts on how to deliver high quality software in a timely manner? This is especially true with experienced candidates. I feel this is critical to a candidate's success. If they are going to reject/be non compliant with the software development process in place then things are not going to go well.

Of course you have to take into account the learning curve a candidate will have for the role you are interviewing them for. If they are high priced of course you'd expect a short learning curve if any. I really don't waste time with gotcha questions.

Maybe we should have thread describing what people are passionate about. That is one thing I love about DaveT he is passionate.

And something that has a very short learning curve. How can something that has a very short learning curve be that important to being successful?

To the teacher's credit, they have taught me a good skill: don't use two lines of code if you can do it in one. Really has given me a new way to think about what I'm writing and why, as well as using less memory when it's not really needed.

In my interpretation of that slashdot article, it's some butthole asking the question to show off how smart he is, while his job has absolutely nothing to do with security or encryption. In other words, he thinks knowing X may be some hugely important thing for any and all software developers to know, where in reality it might just be his pet project that he cares way too much about relative to what his job actually is.

Be careful with this line of thinking. Finding the clever one-line solution is more of an academic exercise than a practical one. In real-world environments, it is much more important to write clear, readable code. It's often preferable to take 5 lines of code to do something that you could have done in 1.

Well, here he was stressing efficiency for embedded systems, which isn't something id thought much about (how few resources your microwave has, for instance)

That makes sense.

Ah, good. Glad I'm not misremembering it and looking like a dope.

Eh..yes. All company data should be encrypted.

SF.

I forget syntax of all languages I have worked with at an alarming rate...however how hard is it to spend 30 minutes writing code in each language you listed on your CV before an interview?

My interview "gauntlet" is basically FizzButt+5 sort algorithms+binary search. I code through that a couple of times in whatever languages I list highest/showcase in my CV just to feel better/calm my nerves.

You're not asking them to write a function to test that they know how to write a function. It's a fairly reasonable assumption that if someone can't write a javascript function they can't do most other things in javascript.

Interviewing is all a really ****ty game where you can only gather a very limited amount of data and from that you need to make a representation of a person and decide if you should hire them or not.

I don't have a problem with not hiring someone because they don't seem to know basic CSS/Javascript functions/concepts if thats something they should know given their resume/experience/position for which they're applying.

But I do think its a mistake to confidently classify that person as bad at their job or as someone that's misrepresenting themselves. An interview is a very artificial environment and the information you can gather isn't very good.

I think this is good practice but its still not quite that simple. I've only done one technical interview in the past 9 years and I spent all of my time prepping reading/refreshing higher level concepts. I knew I needed to be able to talk confidently about the 'big data' ecosystem, various high level design decisions, etc.

Isn't knowing if an applicant is capable of doing the job way, way more important than asking "bad" questions like making them write a function in the language they'd be using or finding out what their passion is? If they can't do the job, who cares about any of that? The best way to find out if they can do the job is to ask them medium-level technical questions in the language or framework or whatever they'll need to use. Right?

I would think giving five applicants an hour to solve a problem that should take about 45 minutes to solve would be a good test. Some people just suck at immediately solving problems in a sit down, face-to-face interview. I'm sure I will.

But let me skulk off into a dark corner for a few minutes and I'll get you a good answer quicker than most people in the room.

Although that's true real work is done collaboratively, not sitting in a dark room alone. Good engineering work, solving hard problems is usually achieved by 2-3 smart people sitting around on a white board and bouncing off ideas/solutions.

Don't think you're solving hard engineering problems with 1-2 other people at a job interview though.

Point is, or maybe should be, to emulate as closely as is feasibly possible, the actual work environment.

But what's the one (or three, or five) tasks that sum up a position you're hiring for?

Agree and disagree. In my experience, its planning a bit collaboratively, then retreating to take individual looks and approaches at it, then rinse/repeat till something works well

I don't have a company that I'm hiring for, nor any relevant experience with which to make such a decision, so someone else will have to field this question.