[0xffff2]

>I try to hire exclusively based on portfolio and having an engaged and in-depth conversation with a candidate about their work. Works great! Doesn't waste anyone's time and I've got many excellent candidates who flat out refuse to take tests or do homework to get a job.

What kinds of positions do you hire for? I can see this possibly working alright for senior positions, but I've interviewed entirely too many people for entry-level positions who seem competent on paper and can talk about technologies on their resume in broad strokes, but struggle to solve even simple problems (e.g. implement an array-based stack) in their environment of choice in a screen-share interview. I started doing these simple exercises intending them to be a way of gaining insight into the candidate's approach, seeing what questions they ask, etc. Instead I find that many candidates simply aren't able to solve the problem, which I would never have guessed from their resume and conversation up to that point in the interview.

[jschwartzi]

These are entry-level positions, and frankly I wouldn't expect so much of someone who is a junior engineer. They should be able to do it with coaching, they may need you to remind them of things from time to time, but I wouldn't expect a junior to be capable of just doing 100% without any coaching.

I would expect them to try to figure out what you're looking for, and I would expect them to do some googling to figure out what that means. But I've met too many juniors who couldn't do what you're asking without some coaching, and they all did fine.

Frankly, software development is a team effort, and you have to work to build a team. I've worked for too many companies that expect their entry-level juniors to competently deliver without any coaching, and it just doesn't work. Maybe we're all having so much trouble hiring because we're expecting too much of people and giving them too little help?

[JAlexoid]

+9000

[malvosenior]

All levels of engineering and engineering management for the most part. I agree that it's easiest with senior people but I really do expect junior people to come in with some sort of portfolio as well. Being self driven and hacking on side projects (the code of which, I can ideally read somewhere) is by far the strongest hire signal to me.

There are a lot of young people with the time, energy and passion to develop stuff on their own. They are the juniors I try to hire.

[JAlexoid]

Unless you're doing algorithm development, you should skip all algorithm related questions. Be much more practical.

[0xffff2]

Well, I am doing algorithm development but that's not really the point, and an intern or entry level developer isn't going to be focused on that. The point is that you need to understand your tools to use them effectively. A basic stack is an extremely simple and fundamental data structure that virtually any developer might need. If you don't understand it well enough to code a simple example (I spell out that they can ignore things like error checking) in 45 minutes, I find it very hard to believe that you understand what a stack is and when you might want to use one.

[JAlexoid]

Fair enough. I had algorithm related questions for an ETL developer position. Really annoys the crap out of me, when I spend 1 hour doing shit that it wholly irrelevant to the job at hand.

On the other hand I had an interview with 4 hours worth of different algorithms questions - for a job where algorithms mattered. And that interview was pretty fun. Even though I didn't get the job.