I'm having trouble thinking of any short code that would actually make that case work.

One of dem tricky stack solutions. Seems like a bad interview question since you either instantly know the method or you fumble around hopelessly trying to write recursive solutions.

How bad is this really? What about if you wrote the code and then tested it against some sample cases? I would prefer the developers do the latter actually.

As are grocers' apostrophes.

I think jumping straight to code is generally a bad strategy. Both in interviews and in real life. I don't really care about the strategy itself in an interview but I think people that think through an example first are more likely to do better.

If you see the "trick" this is trivial. If you don't I could see how'd you chase your tail for a while..

i think it depends if they already "see" the answer or not. if you know how you're going to solve it, writing code first is fine. otoh, if the way you work something out is in code, i think that's (generally) a bad sign. code is a very poor medium for human thought, and i think understanding that programming is not about "code" is an important trait.

there's a 2-3 line recursive solution. solving this with a stack is over-engineering.

I agree with this basically. I would never write code based on some random thinking. I don't know anyone that does but maybe I just haven't seen enough people in action. I am going to guess that Barrin6 had a reasonable approach to solving the problem.

I suppose this puts me in the camp that doesn't think test driven development is that useful. Could be convinced otherwise.

oh many people jump directly into code without knowing what they're going to do. i've seen it a bunch in interviews.

also, i wasn't arguing against TDD, i'm a proponent, but i think being puritanical about actually writing every test first or you're an evil person is silly, especially when you are in an exploratory stage and don't even know what you're building or might completely change your approach. once you know how you're going to do something, though, you should write some tests because they clarify your goal.

Yes that is a reasonable approach, a good approach regarding TDD. I have seen developers, read stuff by developers that are "puritanical" about it.

Interesting about candidates jumping into code not knowing what they are going to do.

It happens a lot and I don't think its always representative of how they approach problems in real life.

Interviews are hard, so I think its always good to have a strategy. Something like:

1. Make sure you understand the question. Explain the question back to the interviewer or go over some simple examples and confirm that you understand the problem.

2. Figure out a simple way to solve the problem. Doesn't need to be elegant or optimized (but shouldn't be ridiculous dumb).

3. Explain your solution to the interviewer - use your judgement on if they'll be happy with your solution (often they will) or if they want you to implement a more optimized version (in which case go back to 2 to find a better solution).

4. Code up your solution while explaining what you're doing. Depending on the problem/situation - you might want to check in with the interviewer to make sure you're on the right track and they understand what you're doing.

5. Review your solution. Do some obvious test cases.


Lots of times a question will be simple and you can skip/simplify some steps here - but I think people that get nervous and/or don't interview well would do well to follow these steps pretty religiously.

There's an amount of panic that sets in when you feel you need to do something productive but aren't exactly sure what.

I would think most newbie devs assume their interviewer wants an answer now go go go, and doesn't realize they can take the time to plan a course of attack.

Feels like this is partly due to resources they've consumed during training. Plenty of coding books (not all ldo) go from problem to solution without explaining how to get from A to B. Just, "here's the problem, X tool addresses it so use X" type stuff.

That's great if I need a problem fixed right now, but if I'm trying to learn how to reason my way through problem solving, it's less helpful. Teaches me to look outside of myself for quick answers rather than think through the problem and how I might attack it.

Well I did think of a recursive solution. However I didn't test enough sample cases to realize that it wouldn't have worked with ((())). It was disheartening when I took an hour to code it to realize it wasn't the correct algorithm

I think we all can relate the feeling of bombing an easy one. Doesn't feel good, but hey, live and learn.

jjshabado nailed it on the head for live interview questions.

For online coding, it's a little harder since you don't have the opportunity to gauge the reaction from the interviewer for hints.

For example, had I went through a few sample problems with my recursive solution with my interviewer, the interviewer may have hinted that I may have overlooked some edge cases.

On the other hand, I should of realized that my runtime complexity was quadratic. In which case, this should of led me to think of some type of data structure to deal with this problem. Because often times you can trade in space to reduce the run-time complexity of an algorithm.

I think next time, I am going to sit down and think through the problem thoroughly before coding at all. Even if I don't even submit the problem, I'll leave it blank, rather than turn in something ****ty that doesn't compile or completes all the test cases.

I also used a recursive solution for that problem. On another problem, probably the easiest one on the site:
https://leetcode.com/problems/nim-game/

I was sure my one line solution would have about as fast an execution time as possible.


So I was rather surprised to learn that my runtime only beats 22.83% of Python submissions! Needs further optimization?

Short program does not imply fast program

It's probably just that your solution doesn't "beat" the other submissions because it ties with them, but there is a theoretical inefficiency in the way you've done it. The & operation requires looking at each bit in n. All that is required to solve the problem is checking whether the two rightmost bits are both 0. Whether there's a way to do that in the Python runtime idk.

The hardest question I ever got was this:

The first 12 digits of pi are 314159265358. We can make these digits into an expression evaluating to 27182 (first 5 digits of e) as follows:

3141 * 5 / 9 * 26 / 5 * 3 - 5 * 8 = 27182
or
3 + 1 - 415 * 92 + 65358 = 27182

with an input function that looked like this:

You are not allowed to use eval() or whatever is in your programming language that would evaluate a string of numbers.

You are not allowed to have duplicate answers, so this would be invalid:

3 + 1 - 415 * 92 + 65358 = 27182

65358 + 3 + 1 - 415 * 92 = 27182


My approach was probably wrong on every level, but this was one of those, if you knew how to do it, great, if not, good luck.

I eventually looked up an answer. It was a good 50 LOC in Python, but it would have failed because it used eval and expressed duplicates.

Probably depends more on the interpreter and the underlying internals.

What if your program was a few milliseconds slower but was more maintainable and you spent half the amount of time another developer spent in coming up with a faster solution, who did the better job of writing the code?

Is what I meant by runtime.

@daveT - What programming skills do you think the interviewer was trying to evaluate with this question?

Doesn't a large part of that revolve around knowing that equation that has e and pi in it?