Weekly Coding Interview Problems by Email
interviewcake.com
interviewcake.com
I use "mine" because obviously the idea is not mine. It's an idea I'm sure hundreds of us of have had.
This particular site/product was one I "dreamed up" immediately after a very disappointing interview performance. The sting of that experience made me want to fix it for other people by giving them a clear path for being prepared for "Google-esque" interviews. This particular implementation looks to be fairly well executed. I signed up and hope it works out because I think it could be useful.
What these experiences confirm for me is something we all already know. There are really no new ideas under the sun. Or at least they are very, very rare. Just pick a problem you know you can solve and then solve it the best way you possibly know how and if your best is better than anyone elses best, and it's a good idea, and the timing is right, you'll probably be successful.
On another note, I think it's interesting the creator choose the "2 egg problem" as the example problem. I believe it is the prime example of everything that is wrong with engineering interview culture. Not sure if that makes it ideal material for a site like this or pointless trivia.
Started taking up a lot of time though and stopped sending emails a while back.
[Inter]view [Tech]nical Ques[Tion]
My only revenues are from people paying to come for practice with some very good teachers/interviewers.
I help them thru their job search afterwards, but don't take any placement revenue from anywhere. That helps me advice the candidates (and the companies) in a neutral, truthful way, without conflicts of interest. Candidates like that and that's maybe one reason why my batches are going full.
I've poured myself into making this successful. Fingers crossed for the future. All ears for suggestions and advice.
Interview questions as a whole apparently have nothing to do with ability to really code. That's just sad isn't it? Riddles are no fun if they have to be solved under pressure.
I find this statement tenuous at best when the example question has absolutely no programming component of any kind and is entirely a little math puzzler about determining the highest floor from which one can safely drop an egg.
It's certainly an interesting problem, and the explanation is presented incredibly well, so I don't fault the site itself. I'm also aware that this is something of a pop culture question for "programming" interviews. However, I don't believe that it is in any sense true that it is necessary to excel at this sort of question in order to be a competent programmer.
This might seem representative of the experience of trying to design a novel algorithm to solve a new problem, but in fact it couldn't be less representative. I've had to write some hairy code in my job a few times, and not once was I under time pressure or expected to have the critical insight within five minutes. Any problem that has any sort of creative or exploratory or "research" aspect to it should not be under time pressure, and ideally it should be mixed in with other work so that you can rest from the problem and come back to it later. The vast majority of candidates who will pass this particular test all the way to the end are ones who just memorized it online.
Also if you couldn't reason your way to the answer how would I have any confidence you could reason any other problem of similar difficulty level. This kind of problem shouldn't you more than 5 or 10 minutes to figure out.
Sorry, we pass on your application :)
In the vast majority of the cases however, you can get away with writing un-optimized code and it generally makes no difference. Considering the egg problem, any computer would not care two shits about running through all 100 floors to drop the egg every single time.
Unless this particular piece of code is a bottleneck for your organisation, there is very little reason to check for/think of an optimal solution to this problem (if you don't know it yet).
That does not make you a bad programmer, just an economical one.
Yes, it's sad, and at least these days people are aware of how useless these questions are for most positions. But if you're planning on applying for jobs, it helps to be good at them, and this site looks great for that.
If anything, the site is actually fun, since you're not under the time pressure that you are in during an interview.
I agree. I've said this before, I never produce anything good during under pressure. They make it seem like programming is "cram solutions, answer quickly and forget", just like the educational system these days.
Its another reason why I'm not applying to software developer jobs that insist on these pressure cooker questions. I'll stick to programming as a hobby and let my projects speak for themselves.
Aside from my rather opinionated rant, I think its a cool idea and congrats to the developer, I guess it will be useful for people who need to go through these code interviews.
The best interview I ever had was basically a small amount of spec work accompanied by a writeup of why I did what I did.
Needless to say I didn't get the job.
What's wrong with giving the candidate a take home problem then brining them in to walk through their solution / reasoning? I've hired this way before and worked out exceptionally well.
For me, I like the problems in an abstract sense not to actually use in an interview but to just improve my ability to see/solve the whole problem. So I'll sign up for fun.
I was given a take home problem under the guise that they did not do live whiteboard coding interviews. I did the problem, and it was impressive enough to get me on the phone. I was impressive enough to get from the phone to an on-site.
What do you think happened at the on-site? Yup, standard whiteboard coding interviews. Nervousness and pressure means I didn't have a very good showing, although I did solve the problems.
Was told that very day that I wasn't going to be a good fit. Any feedback from the interview where we finally did talk about my solution to the take home problem would not have been taken into consideration as I was told it wasn't a fit right after that interview and nothing was said between the two people.
I really do think that the only thing they found out about me was that I can not do those sorts of problems while nervous and under pressure. What they didn't find out was anything about my actual abilities.
Anyway, my solution worked. We went through my code and discussed a few possible performance improvements. I was also asked a few theoretical questions which I answered confidently and was under no pressure at all.
They got back to me two days later just saying 'no'. No feed-back whatsoever. It was because the two developer who interviewed me were the world's most miserable developers and the moment they walked in I could tell they have no interest in talking to me or interviewing me. Not even trying to engage in small talk. I wasn't going to take it even if I was offered the role because I wouldn't want to work with them. And they probably found me too friendly and sociable and instead wanted to work with an introvert.
Bottomline is it all comes down to the chemistry. This sounds like I'm talking about romantic relationships but it's more or less the same whenever you're about to join a new social group. That's why all these coding exercises, in my opinion, are just a waste of time.
Now, I don't know if that's a bad thing. Those are all valuable skills that I would probably want in a coworker.
I wonder if anyone else studies these types of problems and gains something from it, or if they're just asked during interviews and then forgotten.
it's not whether you immediately forget the question/solution, it's about reasoning your way to the solution. It doesn't matter if you forget after because you've proven that you can get there.
"We collect the most popular real-world coding interview questions and carefully craft wrteups that are ridiculously easy to understand."
wrteups = write-ups.
(I'mma wait on pushing the fix until traffic dies down a bit.)
Oh, yeah, we are hiring, and don't ask the egg question during interviewing. :-)
(i'm not interviewing for any position, just think its decent content and well laid out).
Your answer is actually O(2n) time :). Here's O(n) time: https://gist.github.com/jcdickinson/8026c04dfc0d46bcce76
I guess it depends on where you work, I guess I've grown used to the more accurate complexities we use around here and forgot about the concrete theory. For us, twice the time is twice the time no matter how you sugar coat it.
So, uh, my bad. You are correct.
Which is funny, because your method still uses 2n multiplications, it just computes them in the same loop.
If you have a golden hammer, every problem looks like a red thumb.
Regarding the GP's approach in general, chasing constant-factor improvements on problems like this isn't always worth it. Doing one pass isn't necessarily faster than two if (for example) you do twice as much work at each step.
Not to mention that measuring performance in "number of operations" is pretty vague to begin with unless you're digging all the way down to the generated assembly code and know how many clock cycles an ADD takes vs a MUL, etc. At that point you should probably just pull out a profiler =)