[anderber]

This sounds very forward thinking and I like it. Would you be willing to share a bit more on the process? What does it entail? In the past I was hired on just 2 interviews, and all we did was talk as peers. It felt comfortable and honest. It's the reason I said yes to switching positions.

[vikingcaffiene]

Thanks! So, I'll say that we are still tweaking and trying to get things just right but, as of the time of me writing this, here is the process:

- HR call 30 min.

- Talk to hiring manager (me) 30 min. Get to know each other and feel out if there is a mutual fit.

- Technical panel 1hr. Speak with several engineers on the team who share your discipline (front end or back end for example). Again no live coding. We just talk through stuff.

- Talk to the team PM. 30 min. Get a sense of how you collaborate with our product team partners to build new features in our application.

After that it's the usual comp negotiations, background, and reference checks. Assuming all that works out then hired!

We're hiring so, if anyone is interested in finding out more, contact info is in my bio.

[ceeplusplus]

Sorry, but this just sounds very easy to bullshit. Unless you're doing real in depth quizzing of stuff people wouldn't know if they didn't work with it (e.g. in HFT, explaining what a potential implementation of std::string could be and what the tradeoffs of each design choice would be), generic backend principles are very easy to spew correct answers for without actually knowing how to code. How are you going to filter out people that just memorize the concepts for their chosen language and are good at talking but can't code for their life?

[vikingcaffiene]

> generic backend principles are very easy to spew correct answers for without actually knowing how to code

I'm not sure I agree with this. IMO trying to get someone to explain the ins and outs of a particular facet of the technology your team works in is less effective than getting a sense of how a candidate architects their code and manages complexity. That type of "art more than a science" craftsmanship is not something you can easily fake in my experience. Maybe I'll be proven wrong. We shall see. So far I've had pretty good luck with the approach and gotten some really great teammates.

[gorbachev]

That's not my experience.

It's almost always obvious whether the candidate really knows their stuff. They go into details, when you ask probing questions they don't revert back to generalities or repeat what they already said.

Where this does not work, however, is interviewing junior developers. They don't really know anything at all yet (well, some do, but again, that's almost always quickly obvious), so you're hiring for potential rather than actual skills.

[vikingcaffiene]

Yeah you have to use the appropriate strategy for the interviewee. In the case of a junior, you are looking for potential and teachability as you said. You tailor your questions towards that angle. I've yet to see any take home or live coding challenge that answered those type of questions for me. All it told me is what I already knew: they were more junior and needed mentoring.

[anderber]

This is really great and it sounds like an ideal situation for someone interviewing. I wish you guys the best of luck with this process. I will work in my company to push more towards something like this.