This is one of my least favorite interview antipatterns: multiple small tasks that only show understanding of one of hundreds (if not thousands) of concepts front end devs should understand. Most things here are easily googleable - why judge someone on something that won't hamper them if they blank on it in the day-to-day?<p>Pub trivia is fun in the pub but absolutely rubbish for determining if a candidate is good at what they do.
I like to ask the candidate to do a code review on a pull request. It needs to be something where they'll be able to demonstrate a good grasp of the fundamentals of software engineering, along with a solid understanding of the specific platform they'll be working with. Bonus points if the pull request introduces a couple subtle bugs they'll need to ferret out :)
I never did well in interviews wherein someone asked me to solve a problem while they watch. Too conscious of their presence, I suppose. Give me time to think without someone breathing down my neck and I can demonstrate my aptitude.<p>So, seems to me a better approach for some candidates is to allow them to do some of the work from home or otherwise unattended. It's a more realistic work scenario anyway.<p>But, these types of interviews are de rigueur. Am I that unusual in finding this challenging?
I just hate the concept that there exists such a stratification, such as the "front end" developer.<p>I similarly hate the distinction "qa developer" which seems to the ear like parlance for a hobbled, maimed version of an "actual" developer.<p>It's like HR and technical recruiters are making designs to pay you less, and harp on the fact that you somehow incur less responsibility, solve less challenging problems, and therefore, mostly importantly, deserve to be paid less.
"I mean a large-ish block of real code from the actual domain the candidate will be working in, which will likely offer a strong candidate many opportunities for pointing out how badly it is written"<p>That might be a bad idea. Interviews work both ways, and you could scare away the best candidates with bad code. Maybe it would be better to show them code and say, "Here's an example of code that could be improved - how would you improve it?"
Google has a standard interview process for all software engineers and afterwards you can end up either on in front-end development or back-end development. So they at least think specific knowledge of front-end development isn't necessary coming in.