There is an occasional event that happens to me while on HN where I see a title that catches my eye because it rings a certain bell in my mind. I click through the link and as the page loads my stomach fills with butterflies as I experience the strange sensation of finding another person has implemented an idea of "mine", at times with frightening accuracy with regards to how I conceived of it.
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.
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.
How did you come up with that name? "InterTechTion" sounds and looks horrible to me. Almost like it could be a defunct semi-conductor manufacturer from the 80s.
I think the problem with this site is that it acknowledges that interview questions are something you can study for specifically.
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.
">>> Riddles are no fun if they have to be solved under pressure."
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.
How is that a problem with the site? It's a problem with how most tech companies conduct interviews.
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.
no not at all, these are examples of some of the things you're expected to know as a competent engineer. being able to solve a puzzle is one thing, being able to solve it at the optimal efficiency is a feature of the best engineers - don't you think the people that can arrive at these solutions would be better products? It depends on your job, but I work on big clusters on machine learning systems and the difference between an optimal algorithm and one that's just ok is huge.
> these are examples of some of the things you're expected to know as a competent engineer
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.
wow, unless you got a different question that I did I am amazed at your response. The algorithm is used often in CS, that you didn't know this kind of makes my point. Sure you can probably work as a programmer for years and not care about writing well optimized code, processors are so damn fast these days you can ignore the code quality and get away with it.
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.
That's quite a loaded and passive-aggressive non-response. It does not befit this forum and certainly does not display the maturity I'd require from anybody reviewing my resume. It's so filled with assumptions I don't even know where to begin. Truly, I do not know how you deduced from my post that I don't care about writing well-optimized code. You clearly didn't understand what I wrote.
Really? When you have problems, they're unoriginal problems that have Google-able answers, defined and to be solved in a vacuum devoid of context, and you're expected to either know the answer already, or figure out the optimal answer in 20 minutes, and code it correctly on a whiteboard while people watch you? That sounds like hell.
In some environments (like yours) it may make sense.
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.
I would walk out of a job interview that asked brain teasers. It's not revealing of anything and tells the interviewers that either you've heard that piece of trivia before, or you got lucky and reasoned it out. And "we just want to see how you think" is evidence that the interviewers hadn't thought about how to actually determine what kind of an engineer you were.
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.
It's been a long time (if ever) since I've heard anybody suggest that abstract algorithm questions are great interview questions or should be used exclusively, but I seem to constantly hear that they are totally useless and if you ever ask such a question you're an idiot and I'm leaving. It seems to me that both perspectives are much too extreme.
I didn't walk out, the company said they wanted somebody who did TDD so I wrote an algorithm that created a function that passed all the tests they defined and sent them the function.
Just visiting the site brings back PTS from past coding interviews. I'm convinced that live coding interviews are a personality / public speaking test, not a skills / knowledge test.
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.
I recently had an interview which was the worst of both worlds.
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.
I wouldn't be that sure. Similar thing happened to me in the past. Two phone interviews (one with HR, one with a developer). Asked to go for a face-to-face and they asked me to do a coding exercise in an hour but what they wanted would've taken a good few days to implement.
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.
As someone who loves in-person whiteboard interviews, I absolutely agree. It seems to me like they mostly just test your ability to remain composed under pressure, think fast, and talk smoothly. They don't necessarily test coding ability.
Now, I don't know if that's a bad thing. Those are all valuable skills that I would probably want in a coworker.
It's the same reason I had to take online maths/reasoning tests and then sit new ones supervised at assessment centres when applying for grad roles - they want to be sure you can do it and not your friend.
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.
Interview questions are great tests of algorithmic thinking, which is why some companies ask them. I don't plan on interviewing for a job any time soon and I probably wouldn't want to work at a company that asks questions like this anyway. But I would like to get better at problem solving in general, and interview questions seem like a great way to focus on developing a better analytical approach.
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.
sounds a little like cognitive dissonance there, not wanting to work for a company that gave you a perfectly reasonable test of your algorithmic abilities.
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.
Because everyone develops on trunk, migrating a >200k commit repo isn't high ROI. Works great for us! (Newer repos, like our real time web messaging and our C++ WebGL game engine, are in git)
I took a bunch of CS classes a few years ago so I could build a software product. Now it's built and launched with paying customers and I have a real developer who has taken over coding. However, I've noticed that my own programming skills have lapse. I guess if you don't use it you lose it. Something like this might just be helpful for retaining hard won skills. Thanks!
ive been a subscriber of their email newsletter for a while now. (Only noticed emails in last few weeks though). but everytime i see one, i always open it, one of the few engaging newsletters.
(i'm not interviewing for any position, just think its decent content and well laid out).
Emailed you guys. I got this question: You have an array of integers, and for each index you want to find the product of every integer except the integer at that index.
But wait, O(2n) and O(n) are the same aren't they? Eg both linear, constant factor doesn't make a difference to the time complexity. Or did you mean to write O(2^n) or something?
You're correct. The point of O(f(n)) notation is asymptotic complexity. Intuitively, this measures how the runtime grows as the input grows--whether the solution does one pass or two over the input, doubling the input will double the runtime, so it's linear.
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 =)
> But wait, O(2n) and O(n) are the same aren't they?
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.
Lots of respect for replying to a pretty snarky comment and admitting that you were wrong with good humour, if everyone was like this internet comments would be a whole lot better :)
Ah crap, did it come across as snarky? I'm not very good at conveying tone through comments, it was supposed to be mildly poking fun while making a minor nitpick.
Being wrong is fantastic, because it means I have learnt something. In fact I recently had to optimize a troublesome loop and got acceptable results (15 minutes down to 2 minutes thanks to branch mispredicts). Given what I saw today I can go back and see if splitting it up will result in any performance gain.
But the whole point is that the so called O(2n) algorithm isn't necessarily slower than a O(n) algorithm if they aren't doing the same operations. Often two fast operations can be done faster than one slow operation.
It doesn't depend on where you work or whether or not it actually is faster. It depends on what terms you are using and you are using Big O notation. 2n =/= n but O(2n) == O(n)
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.