[nicoburns]

> That said I would be a little suspicious as a mid/senior-level developer if I got hired at a place that didn't ask me to do any coding for them at all beforehand.

I'd be suspicious if they didn't ask me to do any coding, but I'd be just as suspicious if the coding they asked me to do was leetcode.

[didibus]

Why are you opposed to leetcode?

While it annoys me as well to have to brush up a little, someone who has both the discipline to review their fundamentals, and that can demonstrate they have the smarts to be good at it, that's a great sign of being a good candidate.

It serves as a great arbiter, if two people seem to have the same experience, how do you pick between the two?

And when hiring a junior, out of school, there will be no experience to go by, so what else would you assess on?

[nicoburns]

> Why are you opposed to leetcode? > It serves as a great arbiter

I'm opposed because I don't think it serves as a great arbiter. At best, it selects for logical/academic ability, whereas IMO the most important skill as engineer is pragmatic decision making and building an appropriate solution. In practice it just selects for people who have studied leetcode (and to a lesser extent, those who have a CS degree)

> if two people seem to have the same experience, how do you pick between the two? > And when hiring a junior, out of school, there will be no experience to go by, so what else would you assess on?

You use a technical challenge that resembles the work that the person would need to fulfil in the job. Perhaps creating a single view of a website/app for a frontend role. Or creating a few API endpoints for a backend role. Or whiteboarding through a technical architecture (with plenty of opportunity to ask clarifying questions).

[didibus]

> Perhaps creating a single view of a website/app for a frontend role. Or creating a few API endpoints for a backend role

Those things are relatively trivial, and easy to coach as well. If someone never did it before, you can easily show them how on the job. You also wouldn't have time to have them work that in an interview, so you'd need to do a take home, and then you can no longer validate they truly did it themselves, how much time they spent to do it, how much googling they had to do, how they approach the problem or delt with issues, etc.

I also find they tend to be framework/language specific, some companies even have internal frameworks and all that so they'd have to relearn part of it anyways.

> Or whiteboarding through a technical architecture

This is normally included as part of a "leetcode" like interview.

It tends to be a half day, where you're asked one or two system design questions, which are of the format you describe, and are asked one or two data structure and algorithms questions, and one or two small programming questions that checks your ability to write readable and maintainable code that is well structured, well organized and well factored. Sometimes the latter two are combined into one bigger question that tests both code design quality and requires an algorithm or special use of data structures to solve.