Hacker News Reader

Comment by weego | Hacker News Reader

Some if these are just kinda...why does it matter. Honestly who cares what a doctype does/is for when you only ever use one from a boilerplate.

For most people in most companies weeding out the overly zealous, the ones who are unable to be pragmatic and the ones who can't play well in a team or in front of clients instead of biasing selection on technical knowledge is far more beneficial to the business.

Spending some time pair programming in an interview doing something actually relevant to the job is much more enlightening than throwing questions.

View on HN

The problem is that there's a lot of "fake it until you make it" in the industry, and we don't have time to actually interview individually all of the applicants you get for a job opening.

I use a set of questions during phone screenings similar to this one (but way shorter, of course). During them, I'm not expecting regurgitation or even a full description, but a general understanding of the underlying mechanisms of a language. I don't care about the difference between `call` or `apply`, but I do care about this person being able to know what they are, and when can they be used.

Then, during a face to face interview, you should forget about all these things, and get your hands dirty with the applicant.

Depends whether the company is hiring for someone who can just get the job done, or whether they’re hiring for someone who understands the underlying reasons behind the choices they’re making, the things they’re using, etc.

Some companies only need the former, but many - particularly tech-heavy companies - want the latter. That isn’t unreasonable, but it means that the people who can get the job done, but don’t have the depth of understanding, won’t be suitable.

"...who cares what a doctype does/is for when you only ever use one from a boilerplate..."

This sums up many of the front-end candidates nowadays. Reminds me of "why do I have to know what XMLHttpRequest or a browser event is, I just use jQuery .ajax() and .on() anyway" from a few years ago.

This same logic can literally be applied to anyone working on anything. Engineers, carpenters, pilots, literally anyone.

I bet there are many people who know everything about "XMLHttpRequest", but know nothing about congestion control. Or how a network stack comes together...

You do realize "XMLHttpRequest" wasn't even a thing until several years ago, and it's safe to assume further down the road it may well be phased out (in favor of better/more secure APIs).

Instead of asking about "XMLHttpRequest", wouldn't it be better to talk about the general need for "websites" to communicate with a backend on demand, at runtime, after everything has been loaded and rendered? Or, put "XMLHttpRequest" on the table, and talk about how one would implement such an API within the context of a browser?

xmlhttprequest has been obsolete for 3-4 years.

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

It's used everywhere though, so you'll likely still encounter.

In fact you'll probably encounter it in code your coworker wrote 15 minutes ago.

Reply on news.ycombinator.com