Keep it non-committal. "I am happy where I am, and not in a rush, but it would be nice to talk to the HM. Maybe I get interested in what you guys are doing?"
463 karma · joined August 27, 2007
https://www.quora.com/profile/Soham-Mehta-1/answers
soham @ interviewkickstart.com
At the least, connect with them on linkedin. Those will come very handy when you're actually looking.
[me: I run http://InterviewKickstart.com in NorCal. It's very common to be heavily recruited by first-party tech firms over here, both big and small]
[I run http://InterviewKickstart.com for a living]
Following are some very common mistakes people make when preparing for technical interviews.
1. They code, but they don't invite feedback on their code. Nor do they compare their code with other people's code. So they solve problems, but they never know if their solution was sufficient. They don't get better, despite solving problems.
Avoid this mistake: When you prep on leetcode.com or some such, read other people's solutions line by line, understand and compare. Yes, that takes time.
2. They don't do mock interviews with practicing engineers
Avoid this mistake: Find a friend or mentor who works at a brand name company and do a strictly graded mock interview or two (or more). That will reveal a lot of things your coding practice won't. You could also practice with fellow learners (interview each other), which will help lower the stress in actual interviews (though won't be as useful as doing it with a practicing engineer).
3. They practice very few problems
Avoid this mistake: If you're coming from a top-20 4-year CS program, or you have an IQ of 130+, you won't need a lot of practice. But for everyone else, don't stop until you've practiced at least about 150 problems. Anything less won't help and worse, might give you false confidence.
And when you're in the interview, try asking the interviewer if you can solve the same problem on your computer or on a piece of paper. You'll be surprised how many people will let you do it.
HTH.
I like leetcode and hackerrank too. Though we don't use their problems, we do ask our candidates to get additional practice there. Some solutions are very good there, though they can be cryptic to understand.
The only issue with these competitive programming-like sites for interview-prep, is that they encourage final perfect code and execution speed. That's often not the goal of an interview. The first goal of an interview is to express your thought process, in a limited time. So if you're only doing leetcode, and are doing well there (e.g. you can solve medium to hard problems without much agony), then you should follow your practice with a few mock interviews with practicing engineers.
On the spectrum of human interactions, interviews are closer to a date, than they are to an exam. If you make a connection with your interviewer during that hour, (via whatever topic it is), they will go at lengths to hire you. Yes, you're expected to solve the given technical problem reasonably well, but beyond that, you have to leave it to "chance" and "pray" that you get a good panel.
That's how it SHOULD also work. Because YOU are also interviewing them at the same time. If you don't get inspired with the interviewers, you should also not join that company. i.e. you're also looking for a human connection.
I train for technical interviews for a living, at our exclusive bootcamp for interview prep: http://InterviewKickstart.com . Our entire theory is based on this premise i.e. that interviews are not a standardized exam; they cannot be gamed. All you can do is practice technical stuff really really well. In the end, who gets hired is not in your hands. And that's okay.
Appreciate your disagreement, but why anon? :-)
> According to the article he made about $750k over four years at Box ($95k/yr salary + $350k in options total), but would have made nearly 60% more, or $1.2M, working for a more firmly established post-IPO tech company during the same time (say $160k/yr base salary + $40k/yr bonuses + $100k/yr in restricted stock).
This was in 2009, when salaries at established companies were not that high. I came from eBay, where neither of the three components were anywhere near what they are today. Also realize that he was in IT, where salaries have never been that good.
> Still wouldn't have been able to buy a Bay Area house (not sure why you suggest it could),
I didn't say 'buy'. Just down payment.
> but he would have had all of the other payouts you listed, with basically no downside risk at all.
I prefer to define "downside" with not just money, but with the whole experience. Defining upside/downside with money builds mercenaries; not missionaries. And in a startup, whatever level one gets in, one should be the latter. If you can't be one, then IBM is a better place to be and to stay at.
If you are primarily focused on monetary payout, you won't be able to do the best work of your life, which is an opportunity a fast-growing organization provides, which nobody else can. And when a 1000 people do the best work of their life, everyone invariably gets rewarded.
At that point, 350K or 500K doesn't matter. What matters, is that you've spent 4 years of your life with incredible people doing incredible work. That will always open far more doors than it'll close.
> Seems like pre-IPO companies like Box are increasingly a bad deal for the employees. I'm genuinely sorry you guys ended up getting the short end of that stick.
That's the point. We didn't get the short end :-) Even Sutton says, that overall he is fine. Because he too, understands that it's about the whole experience and the future credibility. He is just ranting about one piece - viz. mismatched monetary expectations and doesn't want us to generalize.
I have worked with him for all his 4 years there. He is a good, competent, typical startup guy who fits better at an early stage. But I think that the way he is (and many others in the valley are) measuring payout is flawed. I hope this audience doesn't generalize and extrapolate Jeff's observations. Especially in the context of Box.
For those who have never worked at Box, it's very hard to describe how special that place is. The culture is (or at least was) hands down one of the best I've experienced. The bar to entry is high, both culturally and technically. Everyone has a drive to do the right thing for the customer, and has had a meaningful opportunity to contribute. All of us there have built amazing relationships and grown (tremendously) professionally over the years. Many of us have even gone on to build successful businesses, on the strength of those relationships (e.g. http://interviewkickstart.com).
THAT is the payout.
The fact that Sutton can now hop from one good startup to another in the valley is the payout.
The fact that companies look at his resume and trust him to help their IT infra grow from 40 to 1000, is the payout.
The fact that he can proudly recount to his friends, that he worked at Box early, is the payout.
The fact that he can call upon any relationship from those years and they pickup his phone, is the payout.
The fact that he is not worried about his next startup job in the valley anymore, is the payout (that wouldn't have happened had he stayed at IBM).
The fact that he can put down payment to a house and raise a family in a decent part of Bay Area, is the payout.
And btw, the fact that his IT management helped 1000 of us serve a million+ customers to organize and secure their data, is also the payout.
In a startup, you value people and an opportunity to do meaningful things, above everything else. You want to be a part of that small group, that moves the needle in this massively morbid and unpredictable world. Anything else, is bonus.
Interviewing, by definition, is not a standardized test with a standardized evaluation. On the spectrum of human interactions, it's closer to a date, than it's to a test.
In doing interview coaching/training for a living (http://interviewkickstart.com), I see this every day. It's frustrating to a certain degree, but also very powerful once understood.
Also see my Quora answer here: https://www.quora.com/What-are-the-biggest-mistakes-that-eng...
Interviewing is not a standardized test with a standardized evaluation. On the spectrum of human interactions, it's closer to a date, than it's to a test.
In doing interview coaching/training for a living (http://interviewkickstart.com), I see this every day. It's frustrating to a certain degree, but also very powerful once understood.
I also think that the dynamics differ based on the mode of interviewing viz. Faceless (like http://interviewing.io does) vs face-ful (like normal onsite or video interviews, or the way http://interviewkickstart.com does).
I have an observation to share for the latter kind of interviews:
When I was hiring at Box for one of my teams (or even now), I'd generally go towards the end, to meet the candidate and talk to them about how the day went. I'd ask them about specific interviews, the interviewers and how they think they did on the given problems.
I found that it was surprisingly rare to get a candidate who was aware enough of how things went (positive or otherwise).
Digging into it, I realized that the correlation of what the candidate perceived, was simply to how expressive the interviewER was. If the interviewer was friendly and chatty, the candidate would feel like they have done well (or at least forgivably well). If the interviewer was more silent, the candidate would feel they haven't done very well.
Now that I do interview training for a living, I try and hammer this point home: that interviews are like a date. It depends a lot on the other person (in this case, the interviewer). Understanding this well often works like magic.
Average 10% spend by an engineer towards hiring is quite normal, from my experience. Obviously, it's average, so there are some who spend way more than 10%, and there are some who don't spend any. 4 out of 40 hours a week including phone-screens, on-sites and deliberations is easy to get to.
I'm sure you know, that a lot of hiring at that scale is systematized and (hence) heavy-lifting is done by non-technical recruiting people.
Just so the readers don't miss the context: By definition, most companies referred here, I'm guessing, are startups. And startups will definitely want more product-focused engineers, in order to keep moving fast.
Interviewing in general, is closer to a date, than it's to a standardized test. The smaller the company is, the more pronounced that characteristic is. For even slightly larger companies, it's a different story.
When I was a Director of Engineering at Box, the engineering team was tasked with hiring 25 engineers in a single quarter. For several quarters. When hiring at that scale, it's hard to hire based on personas and elaborate preferences. At that point, process is more important. Anyone that meets a consistent process gets hired. There are always biases at resume selection, but those are only to benefit the later process, and not so much of a preference.
[About us: http://InterviewKickstart.com]
In other words, an interviewing is not so much of an standardized test, as it is a date. Half of it depends on your interviewER. Just like a date, both of you move on if it doesn't click. There is no formula to "crack every date" and there never will be.
Prepare well, but be yourself. It's true for a date and for interviews.
[About us: http://InterviewKickstart.com]
There are other mock interview services too, but I'm not sure if they are any good.
Core issue is, that the area of interview-important DS and Algos is vast. And most people who are good at it, are too busy working. Careercup sets a high bar, and so do we. And you don't want to go to people from Academia.
(BTW, we do accept remote students in the program. Our batches are small, and increasingly getting full way in advance, but if you'd like to chat, feel free to hit me up: soham@interviewkickstart.com.)
My answer to this on Quora (among other answers):
https://www.quora.com/Programming-Interviews/I-want-to-find-...
Interview Kickstart is my passion-business that focuses on preparing software engineers for technical interviews at top-tier companies.
We are currently looking for a Marketing lead (in valley speak: a growth hacker).
Looking for someone who:
1. Knows how to take advantage of existing strong position. We've been around for a year+, with several awesome success stories. We are profitable with great growth.
2. Wants to do meaningful work. Helping engineers get jobs at best companies of the times has long-lasting dividends on their careers and families.
3. Is familiar with marketing to technical talent (experienced and fresh) and generally understands the process of looking for core technical jobs.
4. Doesn't mind getting their hands dirty with social media marketing, as well as high-level strategy.
If this is you, then please send me an email (found on the site).
That's exactly why it pays to prepare for coding interviews. If companies are not going to be thoughtful about interviewing, candidates can either reject those companies, or prepare for those interviews. My belief is that if more candidates are professionally prepared with those closed-ended questions, this will eventually force companies to be more thoughtful.
For core or senior engineering roles at big Internet companies, you're generally competing with candidates who have practiced for months. So unless you happen to have an astronomical IQ or you happen to get lucky, it pays to practice.
Parker is awesome and I love InterviewCake. If you want to come do more bootcamp-style intense practice, feel free to reach out to us: http://InterviewKickstart.com :-)
Interview Kickstart is my passion-business that focuses on preparing software engineers for technical interviews at top-tier companies.
We've been around for a year+, with several awesome success stories. We are profitable and grew 4x in our first year by revenue.
We are currently looking for instructors with the following qualifications:
1. CE/CS degree
2. Currently working at a top-tier company, or have worked in the past. All our teachers come from companies like Google, Box, LinkedIn, Microsoft etc. Interviewing experience at these companies is a huge plus.
3. Love of teaching. That skill to make difficult topics easy to understand.
4. Believe that many engineers are good at their work, but only bad at interviewing. Look forward to the mission of making those candidates better at interviewing, such that they can land into their dream companies.
5. We'll seed you with the curriculum for the topic you want to teach (Recursion? Linked Lists? System Design? etc). You're free to refine it your way.
6. You'll need to do mock interviews as part of the gig. That gives you much-needed feedback on how to improve your teaching.
7. Time commitment is anywhere from 4 to 10 hours a week. Evenings/weekends. We're relatively flexible.
8. Location is onsite in Sunnyvale, CA.
9. We pay $100/hr. For people driving from SF, we'll even pay $100 more for commute.
Please email a link to your LinkedIn profile (no need for a resume) and a quick note about your interest to soham@interviewkickstart.com!
Interviews are not standardized tests. They are closer to a date/sale, than they are to a test. Same answer in an interview is likely to be interpreted differently by different people, very much like you're on a date.
The more you think of interviews like a test, the more you'll agonize about it, and the more you'll feel writing and believing such gospel-ic articles like this. True, there are a few basic common things, but beyond that, it's subjective by definition.
Whoever YOU think fits your values and ideas, is an A player. Everyone else is "B", because they are not exactly "compatible" to your thinking.
At http://InterviewKickstart.com, that's what we find. Every company has a different viewpoint of what a great engineer is. After a generic training for interviews, it's about compatibility with the companies.
At http://InterviewKickstart.com, we sometimes borrow problems from these competitions. They are hard as hell.
I wish there were a collection of such things, where data-structures and algorithms are used in real life (or even at places where it's not visible in everyday life, like inside the Operating Systems).
At http://interviewkickstart.com, we love these little nuggets. They make interview coaching fun and very real.
i.e. the interviewer depends as much on the interviewER, as it does on the interviewEE.
i.e. The questions you ask do matter, but what matters far more, is how the interviewer judges the interviewee on those questions.
I've worked with Nicholas Zakas before. He is a sharp and thoughtful person. Plus, he has probably given this question hundreds of times, to have a strong BS detector. And there will be several followup questions, to separate the wheat from the chaff. I bet he is going to get what he wants, from this question.
Is this the only question that can identify great candidates? No. Is this one good one, that fits his evaluation style and his values? Yes, and that's what he is sharing with us.
[About me: I run http://InterviewKickstart.com in the valley. We prepare candidates for technical interviews, and deal with a variety of these situations every day]
i.e. the interview depends as much on the interviewER, as it does on the interviewEE. Questions matter, but what matters far more, is how the interviewer judges the interviewee.
I've worked with Nicholas Zakas before. He is a sharp and thoughtful person. Plus, he has probably given this question hundreds of times, to have a strong BS detector. And there will be several followup questions he will ask, to separate the wheat from the chaff.
So, is this the only question that can identify great candidates? No. Is this one good one, that fits his evaluation style and his values? Yes, and that's what he is sharing with us.
[About me: I run http://InterviewKickstart.com in the valley. We prepare candidates for technical interviews, and deal with a variety of these situations every day]
Same experience here, running http://InterviewKickstart.com. Having a background in CS is very helpful and often the differentiator in how palatable you find Google/FB interviews vs not. Without CS background (degree or not, but something similar), candidates find it very challenging to even get through the course, much less appear for core CS interviews.
Degree is not just a certificate; it's a proxy to 2-4 years of working through interesting stuff under guidance (professors) and with a group of like-minded people. It ain't a panacea, but it's a great opportunity for those who recognize the importance of that controlled setting of learning.