soham

First part can be solved with an extension of O(n+m) solution you proposed, but when it comes to streaming, Heap works better, with the same complexity, because you don't have to know the size of the arrays in advance: https://discuss.leetcode.com/topic/2780/a-java-solution-base...

Disclaimer first: I'm a technical interview coach. We run http://InterviewKickstart.com, which provides structured and intense group programs for early and mid-career software engineers, with the sole purpose of preparing for technical interviews.

In an ideal world, brushing up is all what it should take before going into interviews. Practicing Software Engineers shouldn't need to spend months working through books and courses. Interviewers should be thoughtful enough to interview for the thought process and experience, more than DS and Algos.

Trouble is:

* Many interviewers are not that thoughtful. Even for the most well-meaning ones, it takes a few interviews to truly be good at judging someone in those 30 to 60 minutes. If a candidate is caught into the cross-hairs of an interviewer's learning curve, that candidate is not going to get a fair evaluation. Preparation helps in that situation.

* With the plethora of prep material available for past several years, the bar for interviewing has just moved higher and higher at good companies. If you look at G and F (and some others), there is no way you can get away with just knowing the basics of trees and binary searches. It just takes time.

e.g. If they ask you to merge sorted arrays and you don't know that Heap sort is the best way to do it, you've lost the interview no matter how clear your thought process is. Not because the interviewer is not watchful. But because your competition has solved it with Heap Sort. So even if both of you demonstrated a clear thought process, the other person gets the job, because s/he is more prepared.

* It takes a certain level of life-confidence to just go to an interview with what you know and take the rest head-on. Many people don't have that kind of confidence. Many many engineers are introverts, and to borrow an analogy from sales, they are artists, not hunters. They are equally ambitious as hunters, but their confidence comes from systematic, extensive, honest preparation, and not from experience thinking on the feet. That prep easily takes months, especially when they are doing it part-time.

* Most CS colleges do not actually prepare their students for interviews. Some top ones do, but a large majority of them are not calibrated to churning out students capable of handling interviews at top tech companies. If you went to one of those colleges, and want to try for better companies, you have to prepare explicitly and separately. You have to re-learn CS with a level of specificity, intensity and extensiveness that your school never provided. Yes, you only have to do it once, but that one time, it may take many months.

I have conducted countless technical interviews in my lifetime. I agree with the author; it's very difficult to actually become a good interviewer. The skill to judge someone's life and career of several years in 30 to 60 minutes is not something that comes easily. Alas, it's all too assumed to be easy.

When you start, for quite some interviews, you are very likely on either extreme viz. either too strict or too lenient. It takes a while to calibrate your standard, and not give in to an extreme. And that too, only if you introspect, or when someone draws your attention to your interview results.

Many companies don't have a culture which values interviewing as a skill. Rarely if so, I come across a company which has a process of shadowing and reverse-shadowing in an interview, which they take seriously. It is viewed as a cost center, when it's actually a profit-center when done right. And due to my business, I have come across plenty of them. At least in the valley.

http://InterviewKickstart.com

We're a hyper focused bootcamp on coding interview preparation. We're looking for practicing engineers who can teach core Computer Science concepts. We currently have 12 instructors, nearly all from top tier companies. You can be sitting anywhere, as long as you are okay working in PST timezone.

The hourly pay is competitive, but more importantly, it's a very satisfying business to see candidates rise, succeed and crack into great companies.

Interview process involves leading a session and a mock interview or two.

soham@interviewkickstart.com

Probably one of the biggest mistakes developers make, is to treat coding interviews like they are standardized tests with a checklist of evaluation. They are not. They are like a date.

The other person is judging whether they want to work with you, more than anything else. No matter how good you are, you won't get into a long-term relationship (date) if you don't confirm to the (technical and social) beliefs (and biases) of your interviewer (date). The reverse is also true viz. no matter how mediocre you are, you'll get in, if you do.

So, do everything what the author says, but you'll progress faster if you keep your mindset grounded. See this: https://www.youtube.com/watch?v=v1WiCGq-PcY

There already are a few mobile apps for this e.g. coderust, Job Bytes etc. In fact, there are many excellent resources out there viz. books and websites. Existence and availability of material is not a problem and will never be in this connected world.

Problem is, that people don't get a chance to go thru that material properly. It needs a lot of dedication and a strong support system, which many people don't have. And hence, they squander a chance to work for best companies of their times, or even reach their true potential. That is what the course provides.

I'm one of those. I understand the intent of this article. It's however unfortunate that the author has not come across enough success stories. Here is mine, which is arguably very small, but came out of exactly the same situation of an employee branching out:

* I saved, I was clear about not only what I like to do, but also what I'm good at.

* I couldn't get to it in my 20s, but I did get to it in my 30s.

* Yes, there was privilege, but not any more than so many of my friends and acquaintances have. I didn't come from money either.

* Yes, there was luck, but not any more than what I'd have needed to survive as an employee.

* Yes, there was agony of survival, still is, will continue to be, and only increase. But I expected that going in, and I carefully created a support system for it, which comes in handy in those tough times.

* Yes, there were unexpected events, including existential threats, but not any more than what I'd have had while working as an employee.

* It has only been a year and a half, and I'm in no position to sermonize, lecture and draw conclusions. But I know that I'm having a blast. I am answerable to nobody but reason, I have flexibility with my time like I never had, and I have immense satisfaction of being the first one to introduce a new useful thing to this planet and make an impact in lives of several of my customers.

But most importantly, it has afforded me life lessons which I'd have never had otherwise and I can accelerate my kids into. Yes, I'm making more than I'd have made in my job, but who is even looking at that?

[For the curious, I run this: http://InterviewKickstart.com]

We don't think interviews can truly be gamed though. They are much like a date, where often the person's true personality will come out before committing to a long term relationship.

They can however be practiced, the concepts can be brushed up and confidence can be built, with the rest left to your interviewers to judge.

Your frustration is understandable. But you also have to ask and understand how our industry has come to this point. There are concrete reasons for it, and despite this process not being the best, it's the least evil when hiring is done at scale.

The process is here to stay. If you want to work at some of those companies, don't overthink it. Just prepare for interviews. It'll also give you a refreshing perspective to software development.

We've since learnt a lot about what makes successful engineers. While nearly everyone who goes thru us (and is actively looking) gets placed somewhere nice, the people who crack some of the hardest interviews generally fall into ONE or MORE of the following categories:

1. They are just bright from the get go. A high IQ.

Haseeb, from the little I've read about him, seems to fall into this category. They can get by with normal amount of practice viz. brush-up.

2. They are extremely prepped.

A crude measure of prep, is how many algorithmic problems you've practiced. Some of these people have crossed 300+ problems. Written code for each. And repeated it. It takes several months to a year to do this with diligence and focus.

3. They have been coding for a long time. Almost precocious-ly.

They have written so much code, that a lot of constructs are now muscle memory. All they need to do in an interview, is to intuit the solution. After that, they impress the heck with their coding fluency.

4. They are competitive programmers for some time

They don't have to be toppers or winning competitions. e.g. Yellow on Topcoder is sufficient.

5. They went to a particularly strong and competitive CS program

Some programs in the country prepare you for such interviews. Rare, and difficult to get into, but they do.

6. They got a soft interview-panel.

Interviews are heavily dependent on who interviews you. Especially at large companies, there is a wide variance in grading standard, experience in interviewing and beliefs, and hence there is a wide variation in talent, despite centralized hiring committees.

You need a bit of luck anyway, but sometimes you get an entire panel that you happen to gel with. A little bit of preparation and getting such a panel puts you over the magic line.

It's an excellent heuristic. It doesn't separate good vs bad programmers; it identifies programmers who love solving problems, and see their careers as problem solvers instead of as limited-view coders who are assigned a javascript task.

Like you said, it also takes time to develop this. So it also identifies programmers who have taken the time to hone that kind of problem-solving intuition, which is far more difficult to develop, than throwing up a webpage with bootstrap.

I run a successful coding interview prep bootcamp for a living. Among other things, we also go thru several Data Structures and Algorithms. Primary objective is to practice intuition on some of these problems. Those who work hard at it, invariably develop irreversible intuition to this stuff.

[http://interviewkickstart.com]

  1. triplebyte.com
  2. interviewing.io (disclaimer: investor)
  3. hired.com
  4. agoodengineer.com (disclaimer: advisor)
  5. angel.co (not a recruiting firm, but close enough)

In other words, it's not sufficient that you be good at algorithms. You also need to get a panel of interviewers with whom you gel well. What interviewers you get at a company, is not in your hands.

You can try a few things:

1. Do mock interviews with experienced interviewers.

Get used to being judged. Repeatedly.

2. Don't interview with the agony of getting a job. Just go to solve the problems.

Listen to this: https://www.youtube.com/watch?v=v1WiCGq-PcY

3. Interview at companies that bias towards take-home tests.

If you haven't already, then try triplebyte.com. They can help you find such companies.

--

I make these observations based on my experience running a successful bootcamp for interview prep (http://interviewkickstart.com) and also being an early engineer and a hiring manager (Director of engineering) at Box prior to that.

How do you tell if the person you're "dating" is crappy/toxic? That judgment is very subjective, by definition. e.g. I've had my fair share of people I've found "crappy/toxic", that others have not. And vice-versa. You want to find the person/manager that you get along with.

The only way for you to truly tell, is to

1. Spend more time with them at the right time:

- The best time to do so, is when the offer is made, but before you've accepted it. That is your best time; most companies will do pretty much everything they reasonably can, to keep you interested in that phase. Make use of that time, to ask for more conversations with the potential manager/team.

I used to work in engineering at Box for several years. Box is very thoughtful about their interview process. We used to invite candidates we liked, for dinner with the team and multiple conversations with the manager. They were also very selective about promoting people to management positions.

2. Do backchannel references:

- Hit up past employees on linked-in. Especially the ones who stayed at the company for a long time. They'd likely know your potential manager and will be able to correlate them with the culture.

Don't feel shy in doing so; it's routine. Of course, BNBR with their time.

Generally speaking, in interviews, you have to optimize for "fit" with "you". Do the best you can in the time that you have, and then leave the rest to chance. There are many good people and strong teams out there.

[I make these observations based on my past life as an early engineer at a couple of companies, as engineer and Director of Engineering at Box and as someone keenly interested in interviewing as a topic. These days, I pour myself into running a bootcamp for technical interview preparation: http://Interviewkickstart.com. We believe that all good engineers deserve a chance to work for best companies of their time, and interview preparation should not stand in their way]

However, once you start practicing, a funny thing happens: assuming you're doing it the right way, with the right mindset, you start to enjoy doing those problems. Your intuition hardens and a certain level of system-design clarity sets in by seeing similar problems across topics.

In some ways, that's what I'm looking for as a hiring manager, by definition: do you enjoy a problem that is new to you, but still up your alley? Do you have an urge for efficiency? Can you express your thought process and work with me to build a solution? The problems asked in the current interview process are good enough to tease these things out.

Take home assignments and OSS contributions are also another credible method of interviewing, and has its own pros and cons. To see a good treatise on different ways of interviewing, see this: http://www.gayle.com/blog/2015/6/10/developer-interviews-are...

1. Take mock interviews from experienced engineers

Go one topic at a time e.g. Recursion or Trees or DP or Multithreading etc. Before you walk into the interview, practice well. Do at least 20 problems on that topic, if not more.

2. Do practice interviews at companies you don't want to work for

Don't feel an imposter in doing this. Realize that companies also go thru several candidates before they pick one. They are normal people like you, they have a learning curve to fill the position, and so do you. Finding the right company, at the right stage of your life, is not a trivial thing to do; it's a project and needs to be managed like that.

Going thru various interviews hardens your skills of negotiation, your understanding of business models, and more importantly, gives you clarity about what your strengths and limitations are.

3. Practice the right mindset

Never go to interviews with a loaded agony of getting a job. Go simply with the intent of solving interesting problems with interesting people ("to add life to your character"). Nobody explains this better than Bryan Cranston (possibly one of the most successful TV actors of recent times): https://www.youtube.com/watch?v=v1WiCGq-PcY

I make these observations based on my experience running a successful bootcamp for interview prep (http://interviewkickstart.com) and also being an early engineer and a hiring manager (Director of engineering) at Box prior to that.

[Edit: specifically mentioned Bryan Cranston by name, based on the comment below]

If you got in with cramming, you very likely would have gotten in without.

Not to mean otherwise; one should definitely prepare for the process, because interviews are competitive. There is no worthwhile competition on the planet where you would go without preparation. It is almost insulting to the ecosystem if you don't prepare.

But preparation is not cramming. Depending on your level of practice, you may end up memorizing some things, but that is different from cramming to "beat the process".

I make these observations based on my experience as someone who runs a successful bootcamp for interview prep (http://interviewkickstart.com) and being an early engineer and a hiring manager (Director of engineering) at Box prior to that.

We have seen that candidates who prepare well with the right mindset, are at a distinct advantage over those who don't. And those are also often the right candidates. If you are working on an important goal, I, as an engineering manager, want you to have prepared for it. Interviews/job are just another goal, and it better be important for you that you want a job here.

Hope this helps; not a popular perspective, but closer to reality in my experience.

After all, it's an 8-week intensive course, mostly for CS grads, that grills you hard, and is not cheap. As a consumer hence, I'd highly prefer to talk with someone. Not to mention, all educational institutes have an enrollment process that needs you to talk to a human.

At some point, when it becomes more common and well-accepted, we will condense it, but it feels a little too early to do so.

The process of DS/Algos doesn't necessarily find wrong people. It's just the fastest way to find engineers who are good enough.

In some sense, they almost secretly WANT you to succeed, by "standardizing" the process.

Pricing is also nuanced based on whether you're an experience engineer or student, whether you're taking the course remotely or on-site. Plus, there are recruiting firms who have access to our pipeline, who return a significant portion of our fees to you directly (we don't take a cut).

And those who are super curious, can always google it :-) In fact, most people who call have already googled for it before calling.

Rest assured, we're a real business, running classes every week. Batch after batch. Those who work hard, are getting their work rewarded.

I want to take the time to talk to everyone who is interested in the course. Because the concept is new, people have all sorts of questions. Can't possibly address all of them in writing. I don't have a team of salespeople and haven't spent a penny on advertising.

If you still prefer email, please feel free to send one. It's on the site. It may just take longer to do back and forth.

Thanks for considering!

This method of interviewing has been around ever since, and is going to be around for the foreseeable future. Nobody loves it, including the interviewers, but there just isn't a better way to do it at any sort of scale. Especially when there are much bigger problems to solve when you're running a business. And a lot of other reasons.

It's best to take the bull by the horns. I run http://InterviewKickstart.com, which is a bootcamp for preparing for such technical interviews. We do almost exactly what is in the blog post. It works. Spectacularly well.

In my last job, I was a Director of Engineering at Box. Every job post we put up, had hundreds of applicants (thanks to job-boards which let candidates apply to jobs like putting in a shopping cart). What do you think we, as hiring managers, are going to do at that point? We'll have to start forming biases. And if we have to start forming one, it's better to start with good schools and good companies. (I'm sure VCs have a more severe problem).

Problem gets worse when you're hiring at scale, and you want to hire before the holiday season nears, because if you miss the season, the company is doomed. At that point, there is almost panic. A resume with brand names on it, naturally gets higher preference.

Homework projects could work well if the hiring requirements are small, but won't work well when a company has to hire say 25 engineers a quarter, which we had to. At that point, the process becomes too long, and it's easy to lose good candidates to a long process.

This method of interviewing has been around ever since, and is going to be around for the foreseeable future. Nobody loves it, including the interviewers, but there just isn't a better way to do it at any sort of scale. Especially when there are much bigger problems to solve when you're running a business.

It's best to take the bull by the horns. I run http://InterviewKickstart.com, which is a bootcamp for preparing for such technical interviews. We do almost exactly what is in the blog post. It works. Spectacularly.

This method of interviewing has been around ever since, and is going to be around for the foreseeable future. Nobody loves it, including the interviewers, but there just isn't a better way to do it at any sort of scale. Especially when there are much bigger problems to solve when you're running a business.

It's best to take the bull by the horns. I run http://InterviewKickstart.com, which is a bootcamp for preparing for such technical interviews. We do almost exactly what is in the blog post. It works. Spectacularly.

He is not hiring drivers; he is hiring mechanics and manufacturing engineers. And yes, they both absolutely need to know how an IC engine works.

Yes, tools are doing their job, yes they will only keep getting better and I want them to keep getting better. But that is no excuse to not know how they work, and what are the tradeoffs of using one over the other. e.g. There are plenty of ORMs for PHP. Why would you use one over the other? If one ORM generates more efficient queries at the cost of some programming discomfort, I'd much rather have you choose that.

By definition, tools solve generic use-cases. i.e. you can get away with tools as long as you're solving simplistic generic problems that have been solved before. But the moment you transcend that boundary and need to do anything custom, especially at scale, you will totally need to know how things work under the hood. You may still end up modifying an existing tool, but you'll only do a good job at it when you understand the insides.

Also, the urge to look under the hood is simply a proxy to curiosity. That is exactly what starts to separate better engineers from mediocre ones.

[About me: http://InterviewKickstart.com]