[azoapes]

The day before yesterday, I held an interview much like this one. I presented a candidate with a problem of easy-to-intermediate difficulty (Fibonacci) and asked him to explain his thought process while coding. I did interrupt his thought process two times to ask what he was thinking, both times when it felt obvious that he was stuck (extended staring followed by a couple of heavy sighs). But my principle was to only provide him with advise when he asked for it. I told him beforehand that his performance was not evaluated or affected by getting stuck or asking for guidance, but that we would not leave the room until we had come up with at least one solution together. I stayed in the room but was drinking coffee and reading e-mails. I told him that the excercise is expected to take up to an hour, and that he didn't need to hurry. When I tested this problem on two of my colleagues it never took more than 15-20 minutes.

This excercise in particular took a little more than an hour, because even though I explained a few solutions in various ways he had a hard time actually completing any code. I wrote a whiteboard solution and explained it using arrows and walk-through examples, but he couldn't translate the solution into actual code (using a language of his choice). In order not to break the hour limit we ended up with me writing and explaining code one line at a time for him. I reassured him that it's okay that he can't come up with the code right now, we're not evaluating the result etc.

I turned this candidate down. I feel that while my methodology (close to OP's) has flaws, it does help me with filtering out the worst candidates. I simply can't hire someone that doesn't manage to, with an unlimited amount of help and a generous timeframe, code a Fibonacci sequence in his/her favourite language.

[bitshepherd]

I can design, architect and build scalable, performant and maintainable systems. I've been doing so for over 15 years. In a professional setting, I might be "the guy" you go to with the problems nobody else can solve.

Put me in a room with a couple of people, a not-real-world problem, a compressed timeframe and tell me to go, and it's a different story. After that time is up, you'll swear I don't know the first thing about technology and go to the next guy.

Why is this? Interviewing psyches people out sometimes. In my case, the act of being judged by my peers gets me to the point where I actually do blank out.

[mrcold]

Quick question. How often do you solve Fibonacci in your production code? It doesn't seem like a problem a software business would encounter very often. And if it's not encountered on the job, I don't really see why it's asked during a job interview.

By the way, I failed my very first interview just like the guy you talked about. Complete brain freeze. Luckily, I got an internship and here I am with 7 years of software development under my belt. You probably might not care. But it really makes me wonder about all that wasted potential. Not everybody is as lucky as me.

[quadrature]

With all due respect, its fibonacci. Even if you aren't thinking recursively it is simply adding the last two numbers you've seen and it demonstrates that you can use iteration and variables at the very least.

[aerovistae]

I agree with you.

However, my challenge was to implement Conway's Game of Life from scratch, which I consider markedly more difficult than Fibonacci.

[brooklyndavs]

Also, this is a SOLVED problem. A quick search on Google, or on gitHub, or in various programming books will result in code to solve Fibonacci in any language of your choice. I would wager to guess that most developers had a hard time solving problems in this sort of environment because its not the actual way most of us work. My ideal technical interview as a candidate would be for me to be presented with an intermediate level problem that your company is facing right now. Provide me with a laptop that includes all the tools I would have on the job. If the team is big on collaboration let the candidate know where you will be, either in person or via a chat, in case the candidate has any questions. And then leave them the hell alone. Ideally this should be around an hour so time is not wasted on both ends.

Interviewing candidates is hard. I know because I've done it before. It's much easier to have a boilerplate CS 201 problem that you give to every candidate vs tailoring the interview to each candidate each time. However, I've hired some of the smartest people I know based on this tailored, specific to the business, approach. Most of the candidates I helped hire were still at the company when I left.

If you do boilerplate CS questions you'll get either students right out of CS programs that have these concepts fresh in their minds or people that have been unemployed for a while who have brushed up on their algorithm skills via Cracking the Coding Interview. Maybe these are the types of people you want because they might be cheaper? Most of the software work I've done in the past 7 years has been taking existing frameworks, libraries, systems and adding in some custom logic. Maybe that custom logic becomes a new library on its own and maybe not. You know what's more important to me than the ability to solve Fibonacci? Do you write clean, documented code? What is your ideal software development methodology and can you ship code in that environment? Do you test? Are you a dick or not? What does your gitHub account look like?

Software development employment isn't college. The hiring process shouldn't be a "hazing" as others have stated. I recently had an interview where I as the candidate partially spaced out a problem that was similar to Fibonacci (duh on my part). However, at the end of it the interviewer I think recognized the situation and said "We are all a team here and we help each other out. I'm OK if you are a little weak on generic algorithms in this situation because you know things I'm weak on." That was a good experience and hopefully I'll get a chance to be on that team.

Overall, I'm guessing most companies out there aren't trying to solve "Google" like problems. We should stop interviewing like we are.

[azoapes]

There are definately "Google" problems that are hard to solve if a mental meltdown is ongoing. There are problems that, even if you get the solution explained to, you might not "get" initially.

Fibonacci is not such a problem. It includes declaring one argument, a handful of variables, one for loop, a couple of assignments and a return statement. And he could not do this with open and explicit guidance.

As he was applying for a senior backend developer position, I can only conclude that morphing complex data structures and calculating shopping carts with taxes, rounding and campaign deductions will be a problem. Maybe I'm wrong, and I should mention that there were additional interview steps and questions where my interview partner didn't have confidence in the candidate, but I really feel that this excercise tells me something. And that's the problem with these kinds of interview techniques I guess. That they do feel very relevant.

[brooklyndavs]

Maybe next time have the candidate try to do a shopping cart calculation? You could explain that this is a problem our business faces a lot. Give him or her a laptop with tools and internet access. If they can't come up with anything then yeah, maybe not the right person. If they come up with something but it's not optimal it might be a judgement call at that point. Do have a good personality? Do they understand other development fundamentals? Are they smart overall and can they pick things up quickly? Some of this talent shortage buisness talks about I think is related to hiring and what buiness expects of the developers they hired. Most people are not going to be the perfect technical fit. A lot will have the capacity to grow and learn in the position.

[ask5]

quick question, are you one of the individuals ;-)

[azoapes]

Yep, when I got hired, 4 years ago. And I liked the experience so I keep using it today. When completing an imperative solution (with a little guidance, due to nervousness) I went on and made a recursive one, just to try to show off. And it got me the job.