4 ms·
>optimal solution in less than a minute you're interviewing wrong and i'm surprised that you haven't figured it out given 200 attempts. put yourself in the sho
by throwqwerty 7y ago
>optimal solution in less than a minute
you're interviewing wrong and i'm surprised that you haven't figured it out given 200 attempts. put yourself in the shoes of the interviewer - interviews aren't their main focus in the company and hence they're not invested in being excellent interviewers. they're most likely trying to do a good enough job such that it counts towards promotion and simultaneously not have a horrible time during the interview. so they have roughly a script that they'll follow
1. give the imprecise problem statement
2. give the opportunity for clarifying questions (points added or subtracted from interviewee for asking relevant/irrelevant/interesting/mundane question)
3. give the opportunity for naive solution (points added or subtracted for facility in implementing and runtime discussion)
4. introduce challenge portion (optimization or constraint or whatever)
5. give another opportunity for clarifying questions
6. give opportunity for talking through a solution
7. give opportunity for writing solution
assuming you make it this far
8. give the opportunity for discussion of trade-offs in time/space/code complexity/latency/etc.
that's 6 opportunities to demonstrate that you're smart, fastidious, affable, etc but only 2 of them are really technical. if you're aiming for writing the best/most optimal solution as fast as possible then you're aiming for the wrong thing - it's not a standardized test but an interview (i.e. two people are involved). you should be aiming to impress the interviewer! those aren't the same (the first is a component of the second).
if you'd you should put your contact info either here in a response or in your profile and i'll reach and we can chat about interviewing (i'm not a coach or a business but i do interview well so maybe i can help you a little).
- bradlys 7y agoConsidering I've received detailed feedback from maybe five interviewers - it's hard to decipher what the issue is. I've just tried to brute force my way through most of it since that's all you /can/ do when you get no feedback. If someone follows the routine you set out - I follow it very thoroughly. I know it well and it's what I used to practice for when I first started. Unfortunately, a lot of interviewers don't follow that routine at all. I'd say 80% don't follow any particular routine and 30-40% immediately go to their cellphone as soon as they put the problem statement on the board. I've seen this at Facebook, Google, Uber, etc. I've seen people go from smiling to random coworkers they don't know to immediately frowning as soon as they see me and shaking my hand with regret. I'm not wearing a MAGA or "I love tabs" hat! It's really weird. It happens far too often and is why I'm looking for mock interview resources and people's experiences with them. Sadly - I feel like even doing it online will only give me a minor edge since, again, I don't fail phone-based technical interviews much at all. It's been really hard to get back into the interview prep game since I've only really received offers from startups. (And that leads to a really lackluster lifestyle)
- DubiousPusher 7y agoYeah, I'm the opposite. I never get to the optimal solution in any interview. I've gotten multiple job offers from large well compensating tech firms and work for one now. The main thing I do im interviews is be realy clear about how I'm engaging with the problem. And this is what I look for during an interview too. I almost never need the optimal solution in real work. n^2 on ten things is just as good as long(n) for many applications. So your ability to get me that perfect implemention is negligible. But the thing I'm going to have to do every day is talk about a problem together, read your code, have you explain a solution to me. I've worked with the 10xers writing code no one can touch and I've worked with an entire team of average coders who are using good methods and writing maintainable code and I'll take the later every damn day of the week.