Let's say the problem is to convert a string into an integer in Javascript. There are two solutions: use parseInt() and check for overflowing integers, or do the actual implementation of parseInt() and spend maybe an additional 20 minutes on the latter solution.

I've read some discussions/forums online saying that you should implement it the long way because that shows the interviewer how you solve problems. But when would you EVER need to implement parseInt() in the workplace? You'd just use helper functions instead and be done with it, right?

My question is, what should you do when a simple question like that comes up in an interview?


This may be different at places like Google who like going through these things, but my experience is this:

My company is there to deliver a solution in the most efficient way possible. Someone defaulting to hand rolling a solution when it exists in the framework points of either over-engineering, or a lack of understanding of the framework, both red flags.

So, if you can do it in a couple of lines using the framework in 5 mins, better that than trying to dazzle me by spending 30 mins writing from scratch as I'll assume that's how you do it for real. Lets spend the time talking about WHY you did it that way, and what the alternatives are, and why your solution is best.


They're often looking to see if you know how to use features of the language, or address corner cases with robust code. You'll sometimes get explicit instructions not to use certainly functions in the language because it defeats those goals.

It'll show mastery and confidence if you say "I could just use x, but if you want to see how that works under the hood, you would do this..." and go on with the longer answer. That way you cover both methods.


Short answer: no, interviews are usually not turned off when one is using helper function.

A bit longer answer: it depends on context, but this context is usually clear.

First, at any interview try to just solve the question, then try to improve specific part (for example, use firs just parseInt, then substitute it with your implementation if needed). Second, never try to re-implement any standard function call unless it is clearly stated in interview that you actually should do that.

For instance, when you are asked to implement, say, Fisher-Yates shuffle, most probably nobody expect you to implement random function. At some job interviews, especially when it comes to security/cryptography positions you indeed can be requested to implement random number generator and explain why it is actually pseudo random but yet practical and so on and so on.

So, back to your question the assumption that you are supposed to implement parseInt on your own is wrong. If you don't asked, don't do it. In case of any doubts it's always better to ask interviewer. Nobody will bite you.


When I've been asked questions like that - where a built-in language construct could do the task, I've written the code using the construct, then explained that I could write the construct myself, but that my version would be untested, and probably lack a feature or two. For a parseInt question, I'd say something like.

I can write out some code that does this, but you should really use parseInt as is tested code, and because it supports more features than mine would, such as the radix parameter.

I doubt any interviewer would "knock you" for using parseInt first then offering to do it the hard way. You spent MAYBE 30 seconds writing the answer with parseInt, if asked, you'll have plenty of time to write the method.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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