soham

Title. I have loved Sam's writing over the years. He deserves more exposure.

Would love to see some small intros. Any links/sources you may suggest?

Amen

By definition and practicality, schools and fields of work will remain a pyramid i.e. at any given time, there will only be a few fields and colleges that "give advantage", being able to absorb only a fraction of students by competition. e.g. field of programming can only absorb a million odd engineers in next few years. (Ironically, when it absorbs more, it will no longer remain a field with high wages).

The remainder of the iceberg hence, will need to go to other lower parts of the pyramid. ISAs won't do anything for that. Only the government will. And the Govt does it for us, with our money, because not providing education to lower levels of pyramid will result in nothing but societal anarchy.

ISAs hence shouldn't be hailed as panacea for education loans which is what marketing makes us believe. The only advantage of ISAs, is that they unlock better education for some "motivated students" (for lack of an accurate phrase) from underprivileged circumstances. That's not a trivial advantage for those who qualify. I don't know what that % of population is, but it can't be much.

In any case, however small, that number sure seems enough to build a business around it with some feel-good marketing (like this article).

But then such schools that predominantly work on ISAs, will pre-select for good students, who are most likely to succeed and also for industries where the compensation is higher. Remainder (which is arguably 90%+) of the students will still be at the mercy of other schools + taxpayer.

It seems, this just provides one more payment option to students who are likely to succeed anyway and a refreshing business model for schools that move early into the space.

It doesn't address the real problem with schools i.e. making the 20th%le student successful and not a taxpayer burden.

Very much this.

A couple of more points to add:

1. There was a time when the pay distinction between working for big companies and small/mid was clear and present. But these days, the line is blurring.

BigCos have realized that startups are eating their lunch and hence they are investing heavily in new ideas and doing better engineering on the old ones to develop those markets even further, faster.

Smaller companies too have realized that they need to compete with the BigCos and hence have started to offer similar comps/perks. More and more of the VC funded fast-growing companies are offering packages competing with BigCos.

2. Hence, for a software engineer, the main reason to join/not-join a company today is less about pay. It's more about the type of work you will get to do, and the people that you want to work with.

3. There is something to be said about having a brand, but given how tech is percolating everything we do, it is also getting very differentiated. There are hence brands in every "flavor" of tech. e.g. if you want to work on self-driving cars, Waymo is a great brand. But if you want to work on healthcare tech, there are others.

I train software engineers to do better at challenging interviews and I do that for a living. The way I see it, the landscape has been shifting in this direction for at least past 5 years, if not more. At least in the large tech hubs of the US.

Unless your customers need you to incorporate, the idea is to incorporate when you start seeing potential liability. One of the earliest sources of potential liability, is when you hire a W2 employee (in the US). So that is a great time to incorporate i.e. before hiring your first W2 employee. And if you don't intend to raise money, issue stock, or setup international offices any soon, then LLC is a far simpler, cheaper (taxation at exit) structure to setup.

Interview Kickstart | REMOTE, SF Bay Area, Bangalore | Full-time, Part-time | Software Developer & Instructor

Interview Kickstart is a coding bootcamp, that is specifically focused on helping software engineers do better at challenging technical interviews. We have been around for 3+ years and have helped nearly 1000 engineers across the globe, mostly in US. Candidates we have trained routinely get offers at top tech companies with staggeringly high compensation packages.

We're looking for Software Engineers who also like teaching Computer Science concepts, and inspiring others to do well via hard work. The role has a great mix of problem setting, software development, and teaching. Teaching is about 20-40% of time, rest is development and/or problem-setting, as per your interest.

It can be done full-time (preferred) or part-time.

If you are looking for a drama-free, no-nonsense workplace with a mission, then we are that place. We also pay highly competitive wages.

I am the founder. Please reach me at my email in the profile.

We are definitely on to tackling the prep thing. Been around for 3 years actually: http://interviewkickstart.com

Looks like Kaplan is not going to be interested in these things after the recent shutdown of DBC.

There are usually several of these $10K ones, especially from angels the founders like and want to have a longer term relationships with. Also, most initial development is either outsourced or done by the founders.

Probably better to hack/FLOSS. But there is a severe lack of structure there. Very easy to get started and get distracted, work on suboptimal projects and in general, never get validation on what you worked on.

For that level of experience, and a great interview performance, big-5 easily cross $225k/yr in total comp. Often much more.

Thanks! Will consider. With that comment on pricing, we just want to deter people who think this can be done cheaply.

[Disclaimer: Shameless self-promotion]

We run something called Interview Kickstart: http://Interviewkickstart.com .

It's a part-time bootcamp focused on preparing for technical interviews at (so-called) top-tier places i.e. places which interview heavily in DS/Algos and Large Scale Design for their core engineering roles, and also make staggeringly high offers. Think G/F/A/Netflix/Amazon/MS etc.

It is intense and also taught by Sr. Engineers working in core systems at these places. There is a rigorous academic take to it, with homework, tests, mock interviews etc.

A little known fact, is that many people come to the program with no intent to look for a job. They are already at good places, paid well, and just want to get better as an engineer, which I think is what you're looking for.

Many have figured out, that the structure and the forcing function challenges them to be better. Most of your peers will have backgrounds in CS/CS, and you'll also see people coming FROM some of the same companies others are aspiring to go to (e.g. Amazon, Microsoft etC).

We start an online cohort every month, where people join from all over US and Canada (and sometimes even other countries).

Feel free to check it out.

Amen. Wish more people understood this.

When asked about salary, people often assume that's a loose ask, and mention their total cash compensation i.e. including bonus. Not including equity though. Bonuses at many companies are in the range of 10-20%, so if one is making 180k, it's easy to round up to 200k in conversation. Plus there are perks and awards.

180k is not uncommon at all. Several candidates from our course have had those numbers. And even otherwise, Sr engineers with a few years of experience, make 180k at most well known tech companies. Of course, not every Sr. engineer makes that much, but those who have had an excellent interview and have negotiated well, very often do.

Elephant in the room, IMHO, is the technical interview process.

In software engineering roles at big/desirable/fast-growing companies, the interview process favors faster (by definition, younger) minds. Both young and old are put thru the same/similar coding interviews at many of these places, and often faster coders are younger, and get the job.

You can't fix ageism without fixing the interview process. Being jovial, healthy, nice and culturally sensitive are necessary and useful things to keep your job after you join, but the gatekeeping itself is biased on the other side, which reduces the intake to a trickle.

tl;dr for me: You’ll need to think deeply about the world and invest years of concerted effort into building a good intuition for thinking about the future. Even then you’ll be right only a fraction of the time. But you can still get much better than random chance.

[Shameless plug] We're one more option for preparation: http://interviewkickstart.com. We're a bootcamp, which continually tries to answer this very same question - where to start and how far to go, when it comes to preparing for technical interviews?

We usually remain booked very far out though. But if we can help you any time in the future, please feel free to reach out!

[Disclaimer: I run http://Interviewkickstart.com]

Thanks Aline. Excellent article, as always.

Not that any interview process is perfect, but another reason why the current process is not going away, is sheer convenience, especially for the fast growing core tech companies that don't have a pipeline problem. When you have hundreds of people applying for any open role, and you're under pressure to deliver products quarter after quarter, your incentive is to stick to a process that gives reasonable results, fast enough.

e.g. Google has estimated 40K engineers. With a 10 year average time on job (it's probably less), G is hiring 40K engineers every 10 years just to sustain itself. That's a massive operation and the incentive of any company at that scale, is to design a multi-layer, fast process. They are looking for 40K engineers that pass that process, not necessarily 40k best engineers from their pipeline.

Considering diversity with that little attention span is possible, but very hard to do. And like you said, technology is possibly the only way diversity hiring can be encouraged/enforced.

Comcast <==> NBC Universal

Verizon <==> Yahoo

AT&T <==> Time Warner

<<Pipes>> <==> <<Content>>

[Disclaimer: I run an interview prep bootcamp http://interviewkickstart.com]

As someone who helped set interview process at my previous employer (not Google), and other companies now as a consultant, your reasoning of why these companies have a process like this, looks right. Let's dig a little deeper too.

Consider the following facts:

0. Google has some 30k-40k engineers, with average tenure of say 7 years. So every 7 years, they are hiring 30-40k engineers. That is thousands of engineers every year, even if they are not growing (and they are). It's a massive undertaking.

1. In the field of software engineering, unfortunately, experience has little correlation to expertise. That has been known for a long time. See [1]. And cognitive ability is at least a reasonable predictor of success, better than many others. See [2].

2. Companies like Google have no dearth of applications. Literally millions or engineers apply.

3. Interviewing is a chore, and mostly not fun. Most interviewERs hate spending time on it, and want to get out of it as quickly as possible. Interviewing is also on top of everyday work which is a lot at many growing companies.

4. As a hiring manager, I have to hire people. There is no choice. I must find a way to hire N people in X amount of time, or the company is literally doomed. e.g. if I'm eBay or Amazon, I can't miss the holiday season.

5. You have to involve multiple people in hiring. Just one person talking to the candidate and making a decision is not sufficient.

6. Programming is so vast, that engineers apply from all sorts of backgrounds and domains.

7. Companies are becoming more and more polyglot. You want engineers to move around different languages and stacks freely.

So when you have a lot of people to hire, a lot of people applying, work that's somewhat correlated to cognitive ability and very little time, what kind of process do you end up setting?

When you put these constraints together, you realize that your incentive is to design a generic process that's convenient to the company, and not convenient to the candidates.

You just want reasonably smart people, fast. You don't care about seniority much, and the type of problems asked, as long as it helps you close N people in X time, by putting in least amount of work. A different process might have selected for different kind of N people, but that process would take longer than this. And time is money too.

A process with DS/Algos is less subjective, fast (like you said), can be prepared for (you have to hire), has enough variety that multiple people can ask different questions, lets you interview across domains, and is at least somewhat defensible-ly relevant to the field.

And hence, here we are.

Not saying that the process is understood by everyone and executed well everywhere and every time, but for several years, we're all still looking for process that's lesser evil, and we haven't found one.

As long as the constraints outlined above remain, the process is going to stay. In some form or another. For a very long time. However much everyone hates it, including the interviewers, and the company itself. Many have tried otherwise (including myself), but most have come around to asking DS/Algos somewhere in the process in varying percentages.

[1]. http://www.ida.liu.se/~nilda08/Anders_Ericsson/Ericsson_deli... [2]. http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...

[Disclaimer: I run a technical-interview prep bootcamp, http://interviewkickstart.com. I also worked at a Big4 of my time. And then some]

Your problem is not with software engineering. Your problem is with interviewing. Don't let anyone (including yourself) talk you into conflating the two.

Technical interviewing process at big4 is optimized for the interviewERs (and the company), and not for the candidate. They have to do that, because their hiring requirements are massive. When you are hiring hundreds and thousands of engineers a quarter, you usually land with the quick, brash process they have currently, despite however well-meaning you are. They can also get away with it, because they have a revolving door of candidates.

Don't let that signal reflect on your software engineering skills. As long as you can solve problems in reasonable time (and 2x is reasonable by many measures), you are good.

If you want to get better at technical interviewing, then use brute-force methods to do so. Find a good source of problems like Leetcode or Interviewbit, prepare a regimen and stick to it. Repeat problems. Do several mocks interviews with something like interviewing.io. You can also use us, of course (http://interviewkickstart.com).

But like others have said, you don't HAVE to go that route. There are companies who do similar level of impactful engineering and make enough money, outside of Big4, who don't have a seemingly depressing interview process.

Disclaimer: I run a for-profit in the space of technical interview prep: http://InterviewKickstart.com.

From what I see doing interview training for a living: more practice is the key. Practice with mock interviews until you reach a point of (almost) de-sensitization.

But before you take mock interviews, you must prepare. Otherwise the feedback and the experience is not very useful. Do a number of problems and a variety of problems from numerous sources available. Only then do mock interviews. Preferably with experienced engineers. Use pramp.com for free mock interviews.

The process can take months, but you're bound to get better that way. Practice is the only way anybody gets better at anything, anyway.

Also note, that this interview practice is going to be useful to you in your daily work also. Training for interviews is that beautiful hack, that has dividends in a number of different ways.

Excellent gesture, excellent thought, worth replicating like others have.

OP - I'm also happy to do a mock interview for free. Feel free to reach out (info in the profile), whenever you feel ready. [Disclaimer: I run a for-profit in the space, but we're all humans first]

In an ideal world, I'd say do not join a company that doesn't challenge you. If you are not challenged in an interview, that's a tell-tale sign, that the work is going to be boring and talent mediocre.

But given that the world isn't ideal, there are times when we just want a job - it seems you are in such a situation?

In that case, I'd say start with people who know you and your work. They are likely to recommend you, leading to an easier evaluation.

If you are doing this without anyone's recommendation, then start with companies that are not core tech companies. e.g. Hospitals, academic institutions, cheap dev shops and firms whose needs are just a bit more than IT. Their gauntlet is usually lighter weight.

We run one: http://interviewkickstart.com.

Because nobody saw the massive growth coming, and now it's too late.

Programming (which is different from CS, but is often mixed) is very accessible to learn (all you need is a computer and Internet), because of which it grew very fast and got democratized very quickly.

No professional body was able to catch up to the speed of growth and breadth of penetration. Before the talent crunch hit, it was too late.

I wish I could find some relevant numbers for growth, penetration and ubiquity of programming to support this claim. But for those of us in the industry for a while now (6 years of education + 15 years of working), there is a lot of anecdotal evidence. e.g. I was booed in 1996, for choosing CS as my major. And now every Taxi company out there needs software engineers.

Thank you for sharing your method with us. It worked for you and should work for others. I'd however like to point out, certain assumptions baked into this, before anyone starts to follow it:

>. Make a list of companies that I would apply to and sort them from most interesting to no-way-in-hell-i-am-working-here order

This is easy to do if you're in the valley/NY. Outside of the valley, people often don't know many companies besides G and F. Making such a list is a valuable exercise, but quite hard for many people, simply because of lack of knowledge and credible sources. It'd be useful to mention something like Wealthfront list here.

>. spend a weak reviewing typical algo/data structure questions

There are SO many resources online, that it's very easy to get lost in the search of what's typical, especially if one hasn't interviewed in a few years. It'd be useful to mention to follow some introductory book/resource here.

> . For the companies that I absolutely want to work for, I review every single glassdoor review and write down the interview questions. Remember, most companies have question banks and most interviewers have favorite questions which results in same questions being asked over an over again. You want to exploit that

For companies with shorter history, this is doable. For companies with longer history of this kind of interviewing, browsing through Glassdoor is very similar to dumpster diving. It's doable, but it's super easy to get discouraged quickly. Not to mention very often people paste questions very vaguely e.g. "got asked a Graphs question", or they paste code which is a nightmare to follow, even if you trust that it's correct.

In other words, note that this phase can take a lot of time to do well.

>. Then to get over my interviewing jitters, I interview at a few companies where I would absolutely not work at. This results in no pressure interview practise and you can literally laugh at their asinine interview questions and walk out

Again, how does one get interviews at even those companies where they don't want to work at? Getting interviews is as much of a problem, as clearing them. Added to that, there is always this anxiety about rejecting those offers, because there is no guarantee of getting thru the ones you want to work at.

Additionally, when picking practice companies, it's important to pick ones that have a process with similar intensity as your favorite ones. That knowledge is often not mainstream.

>. Finally, for the companies i actually want to work at, I try my best to get rid of phone screen. This is usually accomplished by dazzling them with my decent size github profile, contributing some fixes to their OSS project or finding someone who already works there that is in my alumni network .

Internal referral is definitely the best way. But majority of people don't have internal warm referrals at most places. Additionally, unless your technical reputation precedes you, most good companies are unlikely to give you a free pass on phone screens. It's extremely rare to have a dazzling Github profile enough to skip a phone screen.

> Then when you finally arrive for the interview, you have real world interview practise, they are already impressed with your github profile/references and biased toward you versus some random joe off the street and you have made sure you have a pretty high probability of getting a question that you have already seen or is similar to a question you already know.

This again, assumes that everyone in the panel knows about your preceding reputation. And that one doesn't mess up even a single interview.

Overall - please don't get me wrong - this is great advice and much better than getting frustrated without it. What I want to point out, that the inherent fragility of the entire process is so high, that one should be careful pinning one's confidence on any particular strategy. The only thing in your hand, as a candidate, is to prepare and prepare well.

Your frustration is justified. However, there is no flawless interview process. You could try and read this for more context: http://www.gayle.com/blog/2015/6/10/developer-interviews-are...

Having been on the other side for quite a long time, I can assure you that despite best efforts by some very well meaning and smart people, this is the only process that has stuck around (and is still growing). That's because it's the most convenient method to interview at scale.

When a company is very small and/or only hiring one or two engineers a quarter, choice of interviewing method doesn't really matter a whole lot. You will have enough time to interview people and any method you follow will give you a decent candidate.

But when you are a coveted company with a strong candidate pipeline and are tasked with hiring 25 engineers a quarter (which was the case with the leadership team I was a part of), or thousand at Google scale, you need a process that is fast, efficient and convenient. You don't necessarily need a process that's best for candidates; as long as the process filters in enough candidates, and doesn't waste much of your team's time, you're good.

There are some other reasons this process has stuck around, but that's one main reason. I don't see it going away any time soon.