We hire with a similar setup, but we try to keep the test extremely simple and close to reality. Something they would likely encounter on their day-to-day.
The majority of the developers fail at it. Senior, mid-level, juniors, etc. It doesn't matter. Which always surprises me. People who claim to have 5-6 years of experience can't even refactor some code. Or they can refactor and can't explain why they'd do it. It's bizarre.
But I would never classify this as leetcode because these are common tasks that any developer should be able to solve and not purely algorithmic questions that will rarely (if ever) be used in real life.
I'm an IC and I could deliver software with all methods in a single class, nobody would care I think, as long as it worked as intended. I happen to like programming and as I am improving my skills every time I touch an existing project I look for things I could have done better. If major changes are being made, I often upgrade frameworks or do a partial rewrite to improve things.
I know people who just do stuff without trying to understand why. If I cannot explain why I am using dependency injection and what problem it solves, I am not doing it correctly.
- 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.
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.
There is of course a possibility that someone has rehearsed their interview happy path down to the word and they can easily describe complex technical concepts without understanding them because they're quoting a script, but an interview that can be gamed in such a way may highlight a problem with the interview.
If most of your interviewees are failing to write basic code, the issue probably isn't the applicants.
I dislike leet code, but you do need to be able to code something (Even if it's syntactically incorrect) on the fly and reason with me about what and why you're doing something.
Masters degrees are a total crap shoot. I honestly ignore them entirely unless there's a thesis.
Deeper question: Did you think about why some people are able to "show me things you've built, tell me how this function you built works", but fail miserably on a straight-forward coding test?
Sometimes, during an interview, it seems obvious the person is very intelligent, but having a bad day. Some part of interviews is pure performance to me.
1. Write code that will find the second largest item in an array on ints.
2. Write SQL that selects the second highest number from a DB table.
I'm floored how few candidates can do these. Many end up giving up or fiddling for 10 minutes before giving something like `SELECT table WHERE 2`.
SELECT num FROM
(SELECT num FROM nums ORDER BY num DESC LIMIT 2)
ORDER BY num ASC LIMIT 1;
lambda xs: None if len(xs) == 0 else sorted(xs)[-2:][0]
1) haven't used SQL in a long time and forgot all the syntax, or else
2) don't really "grok" SQL as a model of computation (as opposed to e.g. a data structuring language or something like that).
But both of those seem like good reasons to disqualify someone from a full stack role?
Here in Europe this sometimes happens (candidates can't code at all), but _very_ rarely, maybe 1 out of 100? Especially as you move eastwards, the base coding abilities start to improve massively for the average candidate - in the UK, if you are stupid you can easily get by on the social welfare system, in Eastern Europe, if you are stupid, you starve. As simple as.
There was a time I used to ask Fizzbuzz-style warmup questions on interviews, but then I stopped because the signal it gave was pretty much useless. The only positive case I can remember was when a tester applied for a dev position.
I'm generally more a fan of keeping skill-based examination too, but making it very easy and language agnostic. Harder than FizzBuzz of course, but nowhere close to dynamic programming.
Ideally, if a candidate has never seen it before, a basic tree traversal is enough. But since 100% of people have practiced that before interviewing, I invent a problem by ripping out a little piece from the codebase I'm working on. It usually amounts to.. Show me some clear control flow, factor that code into a subroutine, iterate over a collection and call that subroutine, contemplate the performance characteristics in a discussion (not bigO complexity, more so consider the I/O device..caching..)
I don't recall the exact message but I think it will emit something along those lines.
I recently got that question after a homework with about 200 lines of python written. If I had failed at this question, the company would have concluded that I had somebody else do the homework for me, so I understood where they came from with this.
I cant say its perfect... But they have a really great Clojure team and everyone else seems to have a difficult time hiring for it. They IPO'ed last year too...
reality is there are just a lot of people who can't really code -- IN THE ARTIFICIAL CONTEXT OF AN INTERVIEW - out there.
FIFY.
I don't think its wrong to do these types of interviews. But interview stress is real, and it affects people in strange ways. I bombed one of these interviews once and the interviewer was convinced I was "not a front-end programmer". I had just left a job where I had written literally hundreds of thousands of lines of (modern) front-end code, daily, for the last several years. More complex than what I'd be writing at that company (I was eventually hired in spite of this particular interview). And oddest of all, that interviewer was (very soon after) let go. Such is the world of programming interviews.
So yeah. I don't think its necessarily the worst. It might even be the best way to interview candidates. But we all need to take our asessemtns with a huge grain of salt and stop being so judgemental.
So, I gave a few interviewees a code test, and they failed miserably. Mind you, nothing hard - it was a test can I give you a simple function to write, and can you 1) declare a function or class that accepts the right inputs, 3) does what the spec asks, and 3) has the correct output format. The test took 10 minutes to an hour, and was totally open book. The result was pretty staggering. 2/3 of developers would fail the test, and not for esoteric reasons. They would fail because they used the wrong boolean operator, make simple type-casting mistakes, or fail to return data in the correct type (i.e. return a string and instead return a bool or an int). When they failed, it wouldn't be just one thing, it would be two or three mistakes.
So, now I code test everyone, and it has nothing to do with your salary. If we expect you to program in your job, we will verify that you can actually string together 10-15 lines of code. I've only had a handfull of applicants call the test leetcode (I think it's a lot simpler than that), but the reality is there are just a lot of people who can't really code out there.