[Kichererbsen]

The last few interviews I've run, I've shown the candidate sample code and asked them to review it. We have samples that have at least one bug / problem per line. Then some modeling task (whiteboard). We have some simple exercises (fizzbuzz style) to figure out if juniors actually can junior and as a springboard into discussing topics like runtime complexity, memory layout and stuff. This is all highly interactive, depending on how well the candidate does. The idea is to figure out if the candidate somehow faked themselves through screening as well as to somehow get a feeling for cultural fit...

[throwaway346434]

Send the candidate off with a broken unit test to fix, own tools, comfortable environment like home, 1 hour time box. I like to do something horrible based on timezones, or phone number validation, with a Wikipedia article that is the spec. At the end, ask the candidate about their solution, and do a code review session.

The (best) seniors just use a library. The good candidates roll their own, but can explain the tradeoffs. The juniors get the test to pass and stop.

[drewcoo]

> something horrible based on timezones, or phone number validation

What? Do you have something against zip codes and email addresses?

I like to ask something to do with strings - English sentences. I tell them it's intractable in the time we have and that I really want to see how they whitebox-test the code they write, so take ~10m timebox to write the code, then write some tests - at least one test that finds a bug.

[codegladiator]

I use this

https://github.com/emilybache/GildedRose-Refactoring-Kata

in their favorite language. Has been a very effective filter

[ptsneves]

Looks great and will give it a try in the future. Refactoring is one of the fun things in our job so making it as part of the interview is great.

When I make interviews I also come with the code, normally a few line snippet and have the person tell me what it does or whether there might be a bug and talk about it.

Reviews are also great. They take away the show-cooking aspect where many people feel nervous and makes it more conversational. It is also very easy to evaluate as well because everybody debugs code at some point.

I personally dislike even fizzbuzz because there are always clever ways to go around it that are totally irrelevant.

I was once asked to implement sort a list in python, so I just took the list and passed them to sort. But no the interviewer wanted me to implement a specific type of sort…this was for a distribution maintainer job and I almost failed it because of that. Fortunately the other stages were actually technology related and I aced them.

[kristopolous]

I'd give a bit of guidance. This can go so many ways. I can see many right but totally different answers.

In any interview, I kind of presume that the interviewer has a "perfect answer" in mind and is playing some game where I basically need to guess what number they're thinking of.

I'd make it clear that anything is ok. Just go some direction

[codegladiator]

Oh definitely. I start with very basic syntax level changes. I want to hear the candidate say "switch case or if/else tree" within the next 20 mins at the least (for SDE I).

And the problem can be scaled to any complexity. Distributed/Design/Data Storage

[kristopolous]

I'd actually ask under what conditions leaving it exactly as-is is the right decision.

If they give a compelling enough set of answers, I'd just skip the rest of the exercise and be done.

After learning how to do anything, the next 20 years is about learning when not doing anything is the right move.