I will not do a tech interview

"I finally stumbled upon the cure when I interviewed at a small startup that had a different approach. I met the leads for lunch, then followed up with a social chat with the whole team. We talked tech, but they didn’t try and vet my skills."

Meeting potential employers outside the office like this (over lunch or coffee) has been so much more effective for me as well. It takes the pressure off on both sides and lets everyone really get to know each other. If you can't sit down with someone over coffee or lunch, how are you going to work with them?

We're gathering companies who are interested in this approach to hiring (and trying to make it a trend). Employees at the companies offer coffee meetings (their treat) that anyone interested in the company can request. If there's mutual interest, they meet for coffee to chat about the company.

www.treatin.gs

I guess it depends on the industry/clientèle, but meetings are fundamentally very similar. You are worried about what "they" will ask and if you will be able to answer the questions.

With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles.

In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have something memorized, but to check your familiarity with the subject. Everyone sits with a browser while they code - I don't think that's a unique workflow. The thing is, if you've done this HTML -> CSS conversion a hundred times before, you wouldn't need to look it up. They're trying to gauge your experience level and if you've done this stuff hundreds of times before. I bet even a highschool student could find that with Google.

EDIT: I think a more relatable example would be if the interview gave you a simple geometrical problem and you were upset you can't look up the Pythagorean theorem. You're not being tested on your ability to memorize the Pythagorean theorem per se - it's just that everyone is expected to know the Pythagorean theorem b/c it's so fundamental to the sciences. Super simple problem with no google are testing if you have domain familiarity and experience and are a metric of whether you will hit the ground running or not. They're not gauging you problem solving ability, or your ability to memorize crap.

I find it very bizarre that anybody would say something like this. Are you afraid of people who are more confident than you? Would that deter you even if they demonstrate superior technical skills?

Unless you're literally looking for someone who can be productive within the first 2 or 3 days of hiring (which means your product/stack is fairly generic and you're hiring some specialist), I don't think this is a great kind of hiring methodology. I recognize you say "we don't have months to get them up to speed", but I think your whole post would be more true if you said "one month" or "2 weeks" rather than "months to get them up to speed".

Personal anecdote/case study:

I interned on the frontend team at Mixpanel in 2011. I had written about 200 lines of Javascript prior to starting work, not a ton of HTML, and literally no CSS. I had however done quite a bit with Python/Django (which they used). My first month consisted of me "getting up to speed" where I was working at a lower rate than others on the team. By the end of summer, I was a fairly productive member of the (3 person) team, building products with tools I had previously had very little experience in.

Fast forward 2+ years:

I've now done 2 years of college. I spent one summer writing distributed machine learning tools for fraud detection, and another summer during deep learning research. The majority of my computer science classes are just theory (no programming), but I've done a bit of programming in C/Python/Rust (for a choose your own language thing) for school and also a bit of programming in Python on the side. Now I apply for your frontend job.

>I'm going to ask them to explain how a closure works

Closes over internal state, talk about read-only (Python)/ read/write (JS) closures and how read/write closures allow you to make basic objects out of functions.

>How they deal with AJAX

Use a callback? Not sure what this question is really asking. Potentially do some kind of client side queuing for some special cases. How to implement server-side push is more interesting.

> What they think about "!important".

Overrides all other CSS rules iirc. Not a best practice thing to use, but still a useful hack to keep in the toolbox.

> Things to be careful about with floats.

I don't remember specifics, but I remember floats can be a bitch. Just Google any problems I'm having. I believe the type of container that floats are in matters.

> How CSS precedence/specificity works.

Could probably work out an example. In general, element inherits all rules that apply to it, and more specific rules overwrite less specific rules. I don't remember the non-trivial ordering for more specific -> less specific (ie id is more specific than class), but would be very easy to look up.

> How to architect a webapp

Would be more comfortable talking about the server-side component, but could talk about client-side code design.

Summary: I'd probably do alright but not exceptionally on your interview. You might give someone else the job. They would probably be more productive on day 1, but I don't know about by the end of week 1.

The twist: If I was interviewing for a frontend job, I'd take a few days to study all of this stuff and significantly increase my interview performance. Would that make me any better at actually doing the job? Probably marginally.

The traditional recruiting/hiring pipeline in the software industry is clearly non-ideal. The current tradition favors superstitious meta indicators & ritual over realism, it often features under-qualified or too-young interviewers asking/doing stupid/irrelevant things, it favors unpaid unilaterally-imposed work and bureaucratic hoop-jumping (and mindless paperwork and not-work-related personal snooping), over professionally compensated mutual reciprocity, and, to make it even worse, it's biased to reaching false rejections (because they are so afraid of regrettable hires).

Let's do the opposite of all these things!

I've recently started writing down an attempt at providing a better replacement I hope to begin following and enforcing 100% without exception going forward. My own system has similarities to what the OA advocated. I call mine RYR, which stands for "Realistic, Yes-Finding and Reciprocal."