[throwaddzuzxd]

In my team we do technical interviews in three steps:

- an algorithmic challenge. It's related to what we do day to day. I work in domain names so we ask to parse a domain name. There are oddities with domain names so we check multiple things: does the candidate know what basic string manipulation functions exist? do they ask questions to get more info? how do they react when we give additional info that break the code they did so far? What we don't check: whether the code compiles or actually works. We don't care. We explicitly tell the candidate they can write pseudo code or comments defining the steps of the algorithm. We're interested in their reflection.

- an architecture challenge. We ask the candidate how they would scale an API worldwide. There's no code, it's an open discussion. They can talk about whatever they want: asynchronous, statelessness, load balancing, replication, anycast, whatever. We can also guide the candidate to know whether they know some specifics concepts (for example I can ask "what would you do if you have a GET REST endpoint that returns the same thing every time" and expect "cache its result", even with this question I get different answers (which is great), some will talk about HTTP cache headers, others will talk about Redis or in memory caching, rarely do candidates talk about both)

- a refactoring challenge. We work with tons of legacy code. So we show the candidate a crappy piece of code with performance issues and no tests and ask them for what their strategy would be. No writing code here, just thinking and discussion.

So yeah, just a quick screening to check if the candidate can write basic code (you'd be surprised of the results), and open discussions on our day to day problems.

[BatteryMountain]

This is great, I would totally like to interview like this.

The best one I had was a task where you have to basically brute force an api endpoint that uses a semi known password (you have to generate all permutations of a string with alterate spellings ex "pA$Sw0rD" and one of them will match), if you succeed the endpoint returns a url & token to upload your zipped solution. So you end up with a console application that has: network requests, string manipulation, concurrency/parallelism/throttling if you want (I did it to impress, wasn't a junior role), file access (zip & attach & send async), some error handling, good console outputs/logging and comments.

When you go to the interview we basically discuss the code I uploaded with one of their senior developers, what compromises I made, how would I improve it and so on. I got the job back then but since moved on. But that was the best interview process I've seen in my career. No leetcode etc, just a basic application that test if you know how to do a bunch of different things, without it being a whole framework mess or a whole product in some cases. it took about two hours, so the balance between spending time on and getting judged for my skill was good; it felt fair & realistic.

[galdosdi]

This kind of exercise is underrated. A similar one from a former job: the takehome assignment was something like "Here are some CSV files with sanitized real data from our business. It needs to be converted to XML. Use Java (the language our team mostly used then and there) and expect to be judged on your code readability" IIRC there may have been something along the lines of "Bonus: Now we want to be able to convert to/from JSON and perhaps other unknown as yet formats. Refactor your code accordingly"

Other than not using a library, nobody can complain it's unrealistic. Real enterprise devs spend a fair amount of time munging data from one format to another or otherwise "gluing" pieces together. And the kind of person I'd want to hire should be able to complete it to quickly to complain about a "time consuming take home assignment"

And it provides plenty enough opportunity to make sure you're hiring someone who writes code that is pleasant for their teammates to work with.

IIRC the process before that was just the usual 5min recruiter chat and after it was a single on site panel interview before offer.

[fatherzine]

"an architecture challenge" oooh, these are the worst :)

I can usually research a decent solution for most "architectural challenges" in 15-30 mins, but I find it so difficult to have on my brain rolodex a wide variety of possible answers and probe live which of them will not disappoint a specific interviewer :)

[throwaddzuzxd]

Again, this is mainly for screening and understanding what the candidate knows. There's no single right answers: some candidates will talk about assets caching, others will focus on software optimizations, others on infrastructure, or database...

High availability is one of our core problems, so a candidate must be familiar with at least some of the answers. And again, we still guide the candidate on the different points if they're stuck ("what about the db?", "what if the clients are in the US and in Europe?", etc.)

If an interviewer expects a single "right" answer, they're doing it wrong.

[qikInNdOutReply]

In my old job we used to have combined problems for job interviews. First were some easy leetcode, little Big O, all that. But then it got tricky, the problem turned into a "design" part were you could see how the applicant would setup a new system, wether s/he would overdo complexity etc.

Finally we had tests for communication skills. For a unprecise formulated requirement, would the applicant ask us or would s/he over-implement?

Usually there was also something which was noch archievable, for which we substracted points if attempted unsystematically and at all.

It was a good test, because the simple leet code calmed the apllicants, and for the rest you goto see something much more valuable. Their approach to work, their thought process, their output, wethere they would go for Quantity or Quality and could self-manage their workflow.

[xtracto]

The problem with the "easy leetcode" problems is that a lot of them are "gotcha" type of problems: you either know the formula/puzzle-logic/solving-strategy or you'll fail.

I remember asking the typical "traverse an array in spiral" or "traverse this array in diagonals" a long time ago. The problem is that, if the candidate solved it, I just knew they knew how to play with array indexes. And if they didn't do it, I just knew that they got nervous and were not good using indexed arrays... it didn't give me anything.

That's why FizzBuzz is good: it has no false negatives. If a developer candidate can't do it, it means thay cannot code.

[beckler]

This is pretty similar to what we did. We didn’t offer a refactor problem though. We just had a basic problem to create a calculator from a string, only supporting addition and subtraction. Then a high-level question on how would you architect and scale a simple API/service.

We didn’t reject people if they weren’t able to complete the algorithm, because it’s a lot of unrealistic pressure. For both questions, we mostly just want to see how they think things through, how they identify pain points, how open they are to feedback, and discuss their approach.

Even though we would tell people this, I think they still put a lot of pressure on themselves because of the status quo of leetcode interviews.

[Doolwind]

I really like the refactoring challenge idea. Any tips on what’s worked or not? Do you do domain specific code or try and keep it generic? I think having them not write code is particularly good way to handle this.

[throwaddzuzxd]

> Any tips on what’s worked or not?

- Showing code is optional. A bit of storytelling to set the scene is enough. So you can keep it generic, or you can add some details, as you wish! Just make sure that the candidate understands the scene. If you present something generic and feel they don't understand, tell it again with more details. If you think you've lost your explanation in details, start over with less details.

- Be sure to know what answer you want. The number 1 thing we want is for the candidate to talk about adding (non-regression) tests. But the candidate can talk about many different things: profiling, tracing, A/B testing of the new implementation, etc. If they don't talk about the #1 thing you want, try to subtly bring them to that point ("how do you ensure that the new implem works as well as the previous one?")

Not specific to the refactoring challenge:

- Ask for feedback. After each challenge, we ask the candidate their honest opinion on the challenge.

- Grasp a feeling of whether or not you'd like to work with this candidate. Try to challenge them, correct them, ask them to explain things in more details and see how they react.

- We do it with 2 interviewers: main and observer (watcher?). Both from the technical team (so 2 devs). We encourage anyone from the tech team to do it if they want, even juniors.

- We do the 3 challenges in 1 hour but that's a bit short. 1h30 would be better, if the candidate is ok with that.

[canyonero]

This is wonderful and IMO the answer to the “broken” software dev interview. Leetcode is a hazing ritual that needs to end.

My engineering org focuses on tasks that are as real-world as possible. Areas we evaluate on:

- Have the candidate update some code based on a feature request close to real world requirements

- Have the candidate do some code review

- Have candidate describe how they productionize an app

[jimbob45]

>you'd be surprised of the results

I wouldn't because my company has been burned before by hiring people who would otherwise have been filtered by your test. I'd say your test is the kind of responsible, yet reasonable test I'd like to see every company adopt some form of.