1. Basically I am looking for what is it that you goof up and you are out from the remaining process ?
  2. Are elimination rounds a fair way to judge a person ? Anyone can have a bad hour :-(
  3. Should you code the best possible or should you get the Algorithm right ? I generally first code a workable solution and then work on it till a level I think it looks beautiful to me. Is this a wrong approach ?

Recently I had a telephonic interview in which I was asked to write a variation of Level Order traversal in 20 minutes. I could get the Algorithm and working code in 20 minutes but couldn't get the Exception handling and the coding convention right, after which I didn't hear back from them :-( All the other questions in the interview went very well this was the only thing which was 'not upto the mark'.

Needless to say I like the company and will apply again but want to get it right the next time :-)

Please share your experiences and valuable suggestions.

closed as too broad by Ixrec, user40980, user53019, durron597, yannis Jun 2 '15 at 7:59

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Keep in mind the relative costs of misjudging a candidate. A false negative (not hiring someone who would have been a good employee) has only opportunity cost to the employer, while a false positive can be very costly, and can have organization-wide consequences, and nasty ones too. – Chris Bye Oct 1 '12 at 17:25
  • @Chris : You are right. +1. – Geek Oct 4 '12 at 7:07

When doing technical interviews, I'm honestly looking for people to hit a home run. If the candidate doesn't look like they know their stuff, they're not going to be effective in their role (I'm talking senior developers positions here).

Look at it this way: Would you rather have a tough interview where you don't get the job (because you're not a good fit), or an easy interview where you do get the job, but then get let go after 90 days because you're in over your head?

I've seen far too many developers in the latter camp. If you didn't get the job because you flubbed the technical part, consider it a blessing in disguise. If you don't like rejection, bone up on your technical skills.

  • 4
    Very well said Marcel. Somehow I feel that not everyone(no matter how good) might get everything right in an unknown problem(time is a constraint). If someone sails through a problem, he probably has written the same code or similar code before. One question though in an elimination round do you know someone is not good enough if he goofs up a question or two(unless someone makes a blunder). The point I am trying to make is 'Elimination Round' while you seem to be moving from a Hypothesis 'you know that some1 is not good enough'. Yes a bad guy ?? Obvious No Hire.. – Geek Sep 16 '10 at 12:53
  • Interviewing is a difficult art for sure, and I don't claim to be an expert by any means. But in my case, I'm not trying to play a game of "gotcha!" - where I'm just waiting for someone to get something wrong. Instead, I'm probing their knowledge, trying to see how deep it is. Can the candidate easily explain how a hash table works, for example. It's usually pretty easy to see who ends up in the win column and who doesn't. – Marcel Lamothe Sep 16 '10 at 13:14
  • @Geek - would you rather be the person who got it right and was passed up by someone who didn't? It could be a coding challenge or some soft question about how you work with problem team members, but eventually, all the candidates but one have to be eliminated. – JeffO Oct 1 '12 at 18:13
  • @Geek: "has written similar code before". Perhaps they have written grossly similar code. Level-order traversal is a variation of tree traversal, which should be familiar to every CS graduate. If it's not familiar to you, then you missed something somewhere. You did take an algorithms class, didn't you? – kevin cline Oct 1 '12 at 21:18
  • @kevin : Level order traversal is easy mate, if I could rephrase the question as "Given the time constraint, what are the things you can skip and still be considered good enough". I think Chris Bye has a great comment up with the question. – Geek Oct 4 '12 at 7:10

When people ask you to code simple algorithms in a very limited amount of time, coding conventions and exception handling would be the last thing they look at. Unless you're doing something awful, of course, like naming your traversing function func, and all variables a, b, c. Perhaps, there was another reason why they didn't call you back.

Of course, anyone can have a bad hour. But it's a bad sign if you're likely to have one bad hour out of those five you spend on several interview rounds, and if you can't get prepared to important actions.

Personally, I think that getting something that works and improving it then is a wrong approach. Many people (including me) think that if a person writes code that looks like a mess, he has a mess in his head as well. I'd suggest you to write code slower, but in a more thoughtful way.

And even more personally (and, perhaps, offensive), I don't think you're good enough at algorithms. Solely because you spell it as "the Algorithm" with the capital A. You don't spell something you're not afraid of like this.

  • 5
    Lol.. I liked the last paragraph :-) Notice the capital L in 'Lol'. I am Sorry but English is not my first Language. BTW I learnt algorithm has to be written without a capital A :-) – Geek Sep 16 '10 at 9:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.