But also, seniority doesn't determine if someone knows those things. If I asked you for a list of things I should know by the time I get to mid/senior, someone else will have different expectations. Everyone is kind of inventing their own requirements on what someone ought to to know at junior/mid/senior levels.
It depends what the requirements of the role are. For some frontend React work maybe, but the engineers we were trying to hire would be working on APIs and processes that handle high volumes of streaming data. In that context using sync methods over async would significantly impact throughput.
When asked "why are you using a sync method here" the answer would often be "I want the code to pause here before the next line executes". It's a fundamental misunderstanding of what's happening under the bonnet that IMO is required for this sort of task.
Also - I agree that labels like "mid" or "senior" shouldn't carry a specific list of knowledge requirements, but they are useful to set benchmarks for what a candidate should be able to roughly offer in exchange for the level of comp they are requesting.
thats representative of the job, so it should be represented in the interview. open book interviews test for resource finding and implementation skills.
The main problem with your response is that the threshold for "basic concept" is arbitrary by framework, by language, by time, by interviewer. Revert back to interviewing things relevant for the day to day job, look at what developers actually employed there did over the last few weeks, and interview on that.
Asking about async/sync in JS is completely different from asking someone what obscure features like finalizers are in Java. One is used on an hourly basis when writing code, the other one is never used except in obscure legacy code.
If you do what you're proposing and just ask about projects I think you'll find it's easy for incompetent people who are floundering around and copy pasting from stackoverflow without understanding what they're copying to pass your bar. I copy from stack overflow all the time but I understand what I'm copying and why it works and when it doesn't work.
`async` questions are the most day job relevant questions I can imagine for a javascript developer. It is so pervasive, a such a simple piece of syntactic sugar over basic asynchronicity, that not knowing it is damning along a number of axes.
You can certainly stumble your way to a semi-working app without knowing that, but your mental model of how Javascript works is fundamentally lacking if you don't know that.
and its also not my point about "async in JS", thats a symptom in a field where ever random person pulled in to conduct an interview has their own random threshold of competence, when simply conducting an interview that mimics the day to day on the job would be more accurate
"did you google that in 10 seconds" great!
"did the compiler autocomplete your method name or show you a list of likely possibilities?" great!
"did you post a question on a QA website, while you went to work on other parts of the task while the hints and answers rolled in?" efficient!
"did your compiler show you a syntax error immediately that you corrected immediately?" great!
"did you compile it as you went and rapidly iterate towards the write answer like everyone else working here?" perfect!
whiteboarding, and most collaborative coding platforms, fail to replicate 9/10ths of that. so it tells nothing about the candidate.
I definitely would have failed this a few years back, because I spent most of my time in R & SQL.
2: Could be terrible or totally reasonable... how much of that was "fixed cost of any push to prod regardless of complexity"? I've worked at very few places where I could get a change from my editor to production in less than 10 minutes, except in emergencies. Even at my one person freelancing shop a push to prod took at least a few minutes to go through the pre-flight checklist.
3: Bad but not insanely bad, depending on what's needed for the role. Definitely something they should learn, but not catastrophic especially if they are a huge value add in other parts of the stack.
- multiple "senior" data scientists who cannot write a function definition in python
- a "senior full stack engineer" with 5+ years of web dev experience who took 20 mins to change the width of a div in a web app
- many "mid/senior level" full stack engineers who don't know the difference between sync/async, or have any clue about how the JS event loop works
There are so many candidates out there who have what looks like impressive CVs, but can hardly string a program together.