[DoofusOfDeath]

> explain why this code is inefficient and how to optimize it.

That sounds like a trick question. I've done a lot of code optimization. Here are a few generalizations I've drawn:

(a) You rarely know what part of a program is the bottleneck until you profile it on an appropriate workload.

(b) You often don't know why it's slow until you dig into performance metrics like cache-miss ratios, branch-mispredicts, etc. Often at the disassembly level.

[igorbark]

But for a short, isolated piece of code I assume you would be able to suggest a handful of plausible inefficiencies and explain how they could be tested for and optimized for.

[mmcnl]

Well that would be a perfect answer if you ask me.

[bluGill]

No, it would not be a perfect answer, and could work against you: it shows you are not willing to work with me and assume some intelligence on my part (until proven otherwise) and thus you are potentially not going to work well with the rest of the team. I would respond that we have already profiled this code and discovered it is a bottleneck, now answer the question. It won't be hard to overcome the negative impression, but it left a negative that you don't want.

Now if you responded in the form "Of course in the real world we don't look at code until after a profiler shows the need. I see X which is suspicious, let me look deeper". In this case the comment is perfect: it shows you trust, but know to verify that trust. It also has the side effect of giving you time to think.

[mmcnl]

I fail to see why analyzing a problem before solving it somehow translates into "not going to work well with the team". Problem analysis skills are far more valuable than problem solving skills. Anyone can search on Google for a solution to a given problem, but no one on Google can tell you what the actual problem is. If you really thing the answer I was responding to is not acceptable, then the question is a lousy question imho.

"It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do." - S. Jobs

[bluGill]

Remember, this is an interview situation, I can't give you a realistic 500000 line program with a slow hot spot and ask you to fix: we only have a few minutes (maybe an hour). I have simplified the problem to a single function that is a bottleneck, I want you to analyze this function so I can see how well you can analyze things.

Refusing to do something because it hasn't been profiled is not analysis, it is refusing to do analysis. You have been given a problem and been asked to analyze it. That refusal makes you not a team player.

Once again, this is an interview. Noting that this scenario (a single function that is known to be too slow for reasons that can be fixed in 10 minutes) never happens in the real world is good - it shows you understand that real world analysis includes elements not included here. Stating you won't do this because you don't have profile data is not being a team player.

[mmcnl]

I understand what you're saying, but I still fail to see how all of this translates into not being a team player. That really has nothing to do with this at all. If the interviewer still wants a solution based on the facts as they lay on the table, he can always ask again. The first is answer is still the best answer in my opinion, because it is much closer to a real-world situation and it shows a deeper contextual understanding of situation. It also implies experience.

Anyone can repeat someone on StackOverflow who says that function X really is faster than function Y. That's hardly an accomplishment. It's like asking someone to perform a basic non-trivial calculation out of his head -- why bother?

[SilasX]

That's the problem -- you're smuggling in non-obvious, hidden assumptions about the framing of the interview[1] and then penalizing someone who doesn't share them, without giving them the chance to isolate what those assumptions were and why they should use those in this context.

So they're getting rejected for a reason other than technical skill.

[1] "Okay, we're going to talk like I've already fixed problems A, B, and C, but not X, Y, and Z, because we obviously don't have time for a full interaction that is open-ended enough to allow for all of those to be an issue, and you're being judged on how quickly you focus on and solve the X/Y/Z."

[DoofusOfDeath]

I think you misconstrued the intent of my original post. I was merely trying to point out that the interview question was (in my experience) based on a very questionable premise.

I wasn't saying anything about how one ought to handle such a situation during an interview.

I totally agree that a response akin to "Your question makes wrong assumptions. Let's move on to the next question." would be completely inappropriate for an interview, or if the same issue arose in a normal work situation.

[dando]

>No, it would not be a perfect answer, and could work against you: it shows you are not willing to work with me and assume some intelligence on my part (until proven otherwise) and thus you are potentially not going to work well with the rest of the team

I don't know how what was said implies this in anyway.

This is one of the biggest problems with interviews. Every interviewer has some dorky idea that x means y is a terrible developer while another interviewer thinks x means y is a great developer.

"I want an opportunity to learn" - Oh great. We want someone whose interested in learning more and isn't cocky.

"I want an opportunity to learn" - Oh no, that just tells me you don't know much and aren't interested in contributing

[cookiecaper]

Yeah, that's why interviews are nerve-wracking. At their core, they're very subjective. The interviewee doesn't know if the question is supposed to be a trick to see if they say "Well, of course I couldn't optimize it, because I haven't seen the performance data yet!" or if they're supposed to suspend disbelief for purposes of the exercise and say "Well, of course it'd be best to profile, but we could change the way it does X...".

The chance that the interviewer expects some weird thing like that is random, so there's no way to know whether you're getting it "right" or not. Select the wrong answer and you get viewed as an ignoramus or a smartass. Just have to take the gamble you like the most and see if it aligns with the interviewer's preferences.

Once I was asked what kind of software publications I like to read. As a habitual HN user, this should've been the easiest question ever. However, when asked, I guess I was feeling strict that day and said "Well, I don't really read a lot of software-specific stuff, it tends to the more businessey side of things rather than being strictly software related", thinking of highly technical blogs like Lambda the Ultimate. The interviewer said "What about things like Joel on Software?" and I said "Yeah, I've read most of Joel's stuff, but I don't really consider it very 'softwarey'".

I could tell that cost me the interview, but what can you do? Someone else in a strict mood that day may've been delighted by such an answer, happy that I didn't hold delusions and could tell the difference between comedic rants about the business of managing projects and hiring developers and serious, borderline-academic publications that include equations and ponder theoretical dilemmas.

The best thing is just to take the whole process casually without getting over-committed or holding a grudge. False negatives cost companies much less than false positives and they're evaluating you in the context of their other applicants, who are also essentially random, so there's no way to really know anything. It's just about whomever seems least risky and most useful, and as an interviewee, there's no real way to know what that means from the POV of the interviewer, so it's hard to optimize your responses.

The real way to win interviews is to recognize them not as technical processes, but social processes. Admitting this makes engineers nervous, but it's important they understand that humans, not compilers, will be performing the evaluation, and they must learn to speak human to get satisfactory results.