DEV Community

loading...

Discussion on: I failed an interview because of an algorithm

Collapse
cubiclesocial profile image
cubiclesocial

You're going to kick yourself here: A localeCompare()-based function is probably what you should have passed to sort(). You can tell localeCompare() to handle digits it encounters inside the string as numeric values. Replace '.' with '|' in the callback to avoid decimal issues. It'll (probably) handle all of your test cases like a champ and can be done in one line of code. Although spanning a couple of lines of code and some comments can't hurt either during an interview.

The restriction of not being able to look up information specific to a problem is total cheese. That means they didn't make the problem interesting enough and is a red flag. A better interview coding session is to take a ~2,000 line widget or application that has a specific past bug in it from a real internal application, show the bug report to the interviewee, show them how to replicate the bug one time, and then watch them go through the process of fixing it without any restrictions on what they can do. That's something that can definitely be done in a half hour and is a much better test of critical developer skills: Can you digest a completely foreign application or widget, reverse engineer all the way to a specific URL and then its path on the system, dig in with various dev tools to debug the cause, and finally apply a one or two line patch to correct the bug? Plus you would get a taste of the actual code they write there and can decide if you like that coding style or not.

Little piddly tests about "do you know all 1 zillion functions and features of unstable language XYZ that changes every 6 months" that are pass/fail are largely pointless except to whittle out perfectly fine devs. The official ECMA Javascript specification is a 600+ page long technical PDF partially designed for backwards compatibility with NCSA Mosaic in mind. Neither you nor anyone else has actually read and comprehends the whole thing and, even if you did, your knowledge would be outdated in short order. I've been writing code for a REALLY long time (and I'm a pretty solid C/C++ dev to boot) and MY eyes started glazing over after the first dozen pages. HTML and CSS have similarly long, technical W3C specs.

Keep in mind that hiring is a two-way street. You are evaluating them and whether or not you want to work for them as much as they are evaluating you and whether or not they think you can do the job (and work with them). If you aren't going to enjoy working for them, the interview is the best place to identify that and then just part ways amicably at that point.