Always Be Coding – How to Land an Engineering Job | Hacker News Reader

Always Be Coding – How to Land an Engineering Job

medium.com

445 pointsdavidbyttow236 comments

To properly prepare for these interviews you have to invest quite a bit of time. At this point in my life (late 20s), my time is one of my most valuable resources. So, the last thing I want to do is spend that time effectively preparing for a data structures and algorithms exam. Each time I sit down to brush up on the details of Prim's algorithm or the exact implementation of quicksort, my eyes glaze over and I start thinking about how I'd much rather be building or tinkering with something. So that's what I end up doing. The interesting thing is that actually building stuff is good enough to get you an interview, and, even though you've proven that you can actually code, you get funneled through the same inane interview process.

And here's the kicker: none of this truly indicates if you have an exceptional software developer on your hands or not. I've seen (read: personally interviewed) people who've aced the current, en vogue style of questioning who turned out to be awful developers and co-workers. Meanwhile, I know several excellent engineers who were rejected. Everyone knows the process only kind of works.

SV loves to complain about a talent shortage. And maybe there are pipeline problems that need to be addressed. However, why not invest more time in finding a process that's more effective with the talent that's already out there? It always seemed like an obvious place to start, IMO.

I feel exactly the same. I can master any and all graph algorithms under the sun if I want to but why? Just for a job? I would rather be building things.

The idea is to get in the door. Unfortunately, the bouncer is extremely flawed and often gets it wrong. But once you're in, you should refocus on building things.

I just don't have that much drive to get a job. Maybe I underestimate getting a job at google or similar company.

The only problem with big companies is, no matter who they are on an average large set ups are almost the same. There are some minor variations here and there. But your net experience will converge or move around the same point.

I don't know much about Google. But from whatever I've heard. The awesome projects where all this nirvana level work happens are very difficult to get into and bulk of the work is really maintaining legacy system.

Or in other words, its your usual large company. There is a possibility that the experience is marginally better. But as I said will on a average converge to any large corporate experience.

But they pay way more right ? That has to count for something .

That is why you must contribute what they deserve and nothing extra.

Do they? I've heard (I must confess it was years ago) that google paid less. People went there because it was cool and all that hype.

http://jacquesmattheij.com/Programmers+Salaries+at+google+25...

Claims 130 is about average engineer salary at the big G.

I think with equity and bonuses it ends up being much, much higher with million/year being possible.

million/year ? where did you get that number ? perhaps its possible in the sales department.

Adding to that its not ever worth that much trouble.

    1. Master algorithms.
    2. Get a job at <insert a big famous web company>.
    3. ???
    4. Get rich.

What exactly is 3) ???.

Really if you are joining a big company. Whatever that company is. Way to financial safety is not mastering algorithms and data structures. Its more like knowing how to do politics, being your manager yes men etc.

And very rarely are you ever going to get some work where its going to demand some algorithms mastery.

For CS graduates from some big name colleges that go to work on Wall Street or other "finance" it is:

   1. Master algorithms
   2. Get a job at <...X...> & Co.
   3. Use Excel all day everyday
   4. Get rich.

I interviewed at 7 investment banks on Wall Street after college. Never took any of the jobs, however, I had friends who worked on Excel spreadsheets that managed 100s millions in capital. This always amazed me.

They just want smart people in general. CS or not doesn't matter. It still baffles me that they ask algorithms and CS questions then sit in you front to Excel.

For an entry level job fresh out of college, I'd be interested in seeing a person implement algorithms. For a more experienced job, I'd look for a person who knows that these algorithms exist and can quickly look up the details. For a top level person, I'd look for skills at organizing and dealing with large code bases using best practices.

Exactly! This is why we, at my job, only hire software engineers after a (paid) two-day test period in which they actually build some new feature on one of our products. Nothing too fancy but interesting enough for them to be a challenge and representative enough for us to see what they're capable of. At least as important: they will have lunch with us, talk with us, have fun with the rest of the team, ... This allows us to very rapidly see if a person really fits our team.

How do you cope with people who are presently employed but want to interview? Do you expect them to find two days of absence from their present employer to test themselves at your company?

I mean for me that's no problem, but I don't live in the US and therefore have pretty liberal employee leave arrangements. I know that many companies in the US are a lot harder on giving out leave. That said, it wouldn't surprise me if this issue is minimised in the tech sector with their progressive business approaches.

I've never been in the job market yet (still in school), but I have seen some of the hiring process for teachers at my high school.

For every position they are hiring, there would typically be 2 or 3 candidates who spend the day in the school (including teaching a class).

Is getting 2 days off of work really that difficulty (if you plan far enough in advance)?

Yes it's terrible.

If you work in the US and have kids for which you take any level of responsibility chances are you can barely keep up with a typical schedule and have very little leave to play with. Pulling two days out of your ass for a job interview is almost impossible.

For a sufficiently awesome job, sure.

Correct. I get 4 weeks leave a year plus have flexible working arrangements (1:1 time in lieu if my work schedule e.g.: meetings permits), but that's partly because I'm ex-government (we were privatised) and also because I work in Aus, where 4 weeks is the base standard. Then I get personal leave (illness, caring for ill family, etc.) on top of that.

I know that in the US, it's often less. I've heard friends mention only a handful of days per year for leave, with sometimes needing to take that for 'sick' leave because of such low limits. For them, 2 days off to do a single interview would be impossible.

Obviously they're at the low end of the leave spectrum in the US, but given that the culture there is on the whole more restrictive I wasn't sure how that would affect interviewing.

Yes, people who are currently employed will have to take a few days off for this. As we're in The Netherlands that is usually no problem. One of the reasons we pay people for these two days is to compensate them for the two days off they'll have to sacrifice.

I forget the exact details but my current employment agreement has a paragraph saying I won't do contract or consulting work while I am a full time employee here.

Ethically, I would never be able to interview for your company. Don't most companies like tech companies operate in a similar manner? If so, aren't you limiting your hiring pool to either programmers without those types of agreements or thise whom are ethically challenged.

Interesting. Many (if not most) of the engineers I met in my earliest jobs were moonlighting. How common is such an anti-moonlighting clause in employment contracts?

Quite common.

But in many cases, unenforceable. For example, every contract I signed (both in the UK and Portugal) have it, and while I don't know for the UK, here in Portugal you can't sign your rights away which this falls under. So people just sign it and know if worst comes, the courts will always side by you.

Legal in the UK I think every contract I have ever signed says no outside work with out clearance from your boss.

You can sign some rights away just not all of them.

It says on the contract, but is it really legal? I'm honestly asking as I mentioned, I know portuguese labour law quite well (my cousin is a lawyer specialising in labour law and as such, she looks over all my contracts and say what is valid or not.) Have you talked with a lawyer about it over there in the UK? I know the UK didn't sign some EU directives about overtime pay for IT workers so they don't fall on the common EU law, but when I was in England, noone I worked with actually knew if the 'outside work' clause was legal. I personally did freelance work (which my leads knew about) and never got any problem for it even though the contract specified I couldn't.

BTW Professionals are exempt from a lot of the Directives on working time and 99% of IT workers are considered professionals.

Um IANAL but I am an "approved person" as it applies in the UK (ie I could represent some one at a discipline or grievance hearing)

In the UK and the USA employment law descends from the Masters and servants act.

The argument used would be having another job without your employers agreement is a fundamental breach of trust between the employer (master ) and the employee (servant)

Most companies even try to own your "thoughts" while employed at them, even for your after hours stuff.

I'm not sure, but that sounds unenforceable in the state of California (where a lot of HNers are). If you work outside of California, sucks to be you, I guess.

Interesting point! As far as I know we've never run into this issue. We are in The Netherlands, so perhaps that makes it easier. However, were this ever to become an issue with a particular candidate, I'm sure we are flexible enough to work around that. The two day try-out isn't set in stone, it's just a way for us (and for the candidate) to see if we like each other. There are plenty of other ways to solve that if a try-out poses legal issues.

How big is your company? I can't imaging this scaling. This sounds good in theory, but I think one could only hire 1) people currently unemployed or 2) new grads who haven't had jobs. Also, I imagine plenty of good engineers balking at this type of time commitment in building out a feature when the company should likely be proving why the engineer would want to work there?

Is your stack that simple that someone can get up to speed on it in a few minutes so that they can actually build out a feature in two days? Most places I've worked, requires significant onboarding to setup dev machines with all the environments and then understanding how the code flows.

We are a small startup, currently with 11 people. You are right about the scaling issue, I suppose our approach would be more difficult in a large organisation. But why would we only be able to hire unemployed people or new grads? I joined this company myself when coming from another job, as did a colleague that was hired later.

Proving why an engineer would want to work with us is exactly why we interview with this system of two try-out days. How can we possibly convey that we're doing cool stuff in a one hour talk around the table? Besides, we think the try-out is not only for us to "judge" the candidate, it's also the ideal time for the candidate to see if he fits our culture and way of working, and if he actually likes what we're doing. Hiring someone that decides to leave a month later is waste of time for all people involved :-).

Of course we also do the regular "around the table" interview before we invite someone to work with us for two days. We have a chat of about an hour, tell the candidate we will contact him and then have some internal discussion. If everyone agrees we invite the candidate for a two day try-out. If we feel the candidate fits our company and we like his work, we usually try to make him an offer on the second day.

Concerning our stack: it's all Ruby and Rails, and a lot of Amazon Web Services. Our engineers all have at least 3 years of experience with Ruby and Rails (or similar) and we are usually only looking for somewhat experienced people. We simply don't have the time nor the budget to train a new hire for a few months. To get going on a try-out feature a candidate usually only needs Ruby, git, an editor and a small introduction to our codebase from one of the engineers. Most of them are productive within two hours of entering our office on their first try-out day. Of course these try-out features are very isolated and require little to no background knowledge of the entire codebase. Once the candidate is hired we will take sufficient time to get him comfortable with the code.

> Each time I sit down to brush up on the details of Prim's algorithm or the exact implementation of quicksort, my eyes glaze over and I start thinking about how I'd much rather be building or tinkering with something. So that's what I end up doing.

Nailed it.

Another interesting thing I noticed about myself in technical interviews is that I have a lot of trouble doing things that I would have no trouble with if I'm tutoring someone. Perhaps it's the anxiety, and practice will surely help, but see above, I'd rather spend my time tinkering with stuff than preparing for interviews.

Has anybody here ever actually been asked to exactly implement quicksort?

Yes, by Microsoft in 2001. (Strangely, by a non-technical recruiter who wouldn't have known if it were correct or not anyway; apparently he was trying to "gauge my confidence".)

More than once. Also, merge sort, heap sort, and some problem specific variations of these.

quicksort, shellsort, then implement it for parametric type.

I am not even sure what implementing it for a parametric type means... can someone point me to a link?

Parametric type means to take the type as a parameter; parent was probably asked to use Generics in C# or Java or C++ templates.

Ah, ok

>I'd rather spend my time tinkering with stuff than preparing for interviews

If we're talking about raw programming skill, I would say that actually learning these fancy algorithms will pay off more than (random) tinkering. It's the difference between directed and undirected practice. Undirected practice only takes you so far. To truly get good at something one must do deliberate, directed practice consistently.

In rea world programming, those algorithms have very little practical use other than the "gee-whiz" factor.

If you understand algorithms in general, then I think thats enough. Its sort of like being able to play a single song on the guitar is great, but to have the skill to play any song is even better. On the same token, being able to write any algorithm is a much better skill than being able to write out a single algorithm.

I agree with you. However, learning the algorithms is different than preparing for technical interviews IMO.

I've learned many algorithms and implemented most of the ones I've learned, but if I haven't recently coded them repeatedly or studied them rigorously, I likely won't be able to code them up on the spot when asked to. But because I learned them in the past, I would be able to recognize which algorithm (from the ones I've learned) best suits the problem.

I totally agree. I happily turn down a company that requires me to do C/C++ exams in the application process. I know my strength, which is coming up with new algorithms, or implementing them straight from a scientific paper, and most often efficiently enough to run on resource-limited robots. I know a lot of languages and technologies, which necessarily means my knowledge of those languages cannot all be in-depth. If I have to implement quicksort for a job interview I am applying for the wrong position. IMHO it's like asking a poet for the number of words (s)he can rhyme with "cat". :-)

Thinking from an employer's perspective, if you cant gather up enough motivation to prepare for the interview process and solve those non-interesting problems, how will you do all the shit work that will inevitably be assigned to you when you get the job?

If the job your interviewing for requires dealing in algorithms, having your eyes glaze over while you look at quicksort means you're not a good fit. (Really. There are plenty of people who enjoy looking at algorithms and their implementation)

Obvious note: Many jobs _don't_ require those skills, they're simply cargo-culting their interview questions.

In both cases, you've learned something valuable about the potential employer.

Hiring is entirely broken. I don't think anyone is listening to developers. I took some data about this (tracking pixel in a Developer Auction profile), but someone did an even better job than me and posted in these comments:

https://news.ycombinator.com/item?id=5730843

I want a company that treats me with dignity and respect, even before and during the interviewing pipeline. How a company treats people during interviews is a huge indicator of how they treat people in general. I would never subject my friends or family to the hiring practices that programmers are exposed to regularly. Be proud about how you hire. Otherwise this weighs heavily when I reject your offer.

I want a "1-hour guarantee" that I'll receive your considered offer after one hour of interviewing, and not multiple hours of hazing. Otherwise, I'll stick with consulting, thanks. Maybe there should be a site that compares the interviewing pipelines of different companies, and then you can focus on the ones that aren't entirely offensive.

Also, it would be awesome if one of you would actually look at my git repositories before the interview and, you know, actually read my code. No, looking at a "repository summary" doesn't count.

> Hiring is entirely broken.

Aaaand tokenadult is submitting his "best hiring strategies" mega-comment supported by Schmidt & Hunter reference in 3...2...1

/I've been here too long perhaps

;-)

Maybe we need to play the role of the monkeys in the apocryphal conformity experiment (http://skeptics.stackexchange.com/questions/6828/was-the-exp...) and post it for him:

https://news.ycombinator.com/item?id=4613543

Bootcamp in the Marine Corps is an example of a tough hiring practice. Are your friends and family doctors or lawyers, per chance? Both professions use grueling hiring marathons which are much, much worse than a software engineering interview (residency and the bar exam). All other engineering professions require a rigorous licensing process, whereas software engineering is one of the cushiest jobs on the planet. In none of these professions do they accept a casual "hey, take a look at this portfolio" means of quality assurance. That's too easily faked. They test you, actively.

Standing in a room for a few hours writing on a wall is not exactly hazing; to say it is reeks of entitlement, especially when many software engineering jobs have a public trust: safety, privacy, reliability, and correctness standards that demand a certain level of rigor. Software engineering is a very hot field right now, and developers are in demand--but that doesn't mean you should turn up your nose at companies that maintain their own stringent standards of hiring.

No one here is objecting to being tested and challenged. People just want to be tested on how well they can actually perform the job and build solid products, not how well they can memorize algorithm implementations. It's like screening Marines based on whether they can build a rifle by hand. It's a cool skill and could be useful in some ways, but it's not the job.

Hiring is a two way process. They're looking for employees, and you're looking for a salary, colleagues, boss, etc. A company that fucks up an interview fails.

My toughest interview process involved driving 200 miles to spend a day doing psychological tests (after my interview). I got the job. Really, the hirer failed the interview, but I wanted out of my current job. Whose fault was that? Turned out to be a great job (my boss told me that he looked at my portfolio and CV and simply said "hire that guy" — the process was hoop jumping.

I have lost jobs based on those bullshit, pseudo-scientific psych tests. Some of them are straight out of the back of an issue of Cosmo. If I was a moral-less dirtbag I would still have scruples about trying to sell a company on personality tests as part of an interview process.

Sorry, but the thing that reeks of entitlement is Google's abusive "we can pass you from interviewer to interviewer, making you do anything we want for days, and you'll take it because there are plenty more where you came from," hiring practices. If Google thinks they have the power to do what they want to a candidate, and the GP poster thinks he has the power to limit how much of his time he'll offer them, I don't see why he is the only one accused of reeking of entitlement.

"making you do anything we want for days"

Days? I believe the median is 5 hours. The decision may then take days... but that's not the same thing.

When I was talking to them I was informed the hiring process usually took around 8-9 weeks. First a screening call, then a phone interview, then sometime later an in person interview, then an evaluation day in a Google building with multiple interviews and talks with various parts of various teams, then they would let you know within a couple of weeks.

Yeah, no thanks.

The process may span 8 or 9 weeks, but you'd probably actively spend about 8 or 9 hours. That's a couple hours on the phone, and 5-6 hours on site.

Presumably, you expect to hold the job for next few years of your life, at a minimum. If you can't budget 10 hours of your time, and you can't wait for a few weeks for an answer, it just doesn't sound like you really want to work there. Unless you're in desperate need for a job sooner... then I'd understand better.

I was unemployed at the time (I'd just moved back to the UK and was looking for work) and didn't fancy hanging around for 2 months, so there is that.

But even if I was employed I'd be looking for an out much faster. I work with 4 week notice periods (max). A two month decision process is just messing you about.

--edit-- I'll add that the work sounded uninspiring, the location wasn't ideal and I was trying to go freelance/contract at the time (successful within a couple of weeks) so their goals and mine were completely misaligned...

Except you're effectively budgeting ten hours divided by the probability you get hired.

I only have details for two people going through their interviews, but one of them took about 16 hours of in person time, and the other involved flying out to a different city for a day of interviews after ~6 hours of phone screening + a clusterfuckload of email time (partly due to some monumental incompetence on behalf of their HR department: when the recruiter involved left they said they had to restart the entire process).

I work at Google. My opinions in this comment are my own and not my employers.

Google gets thousands of resumes and they have to whittle them down. Some are easy to rule out just based on the resume. Others are easy to rule out in the phone interview.

But a large amount of them make it to the full in person interview. Now Google could just take it as first come first served and hire the first people that look decent. Or they could set the bar really high and whittle the pool down that way. They choose to set the bar really high. They can afford to because they get so many applicants.

As an employee I appreciate that. It means that every one of my coworkers is crazy smart. Any one of them can review my code and offer useful feedback. There are no unqualified developers that I'm aware of at Google and Google is a pretty big company so that's a little amazing. Out of thousands of developers there are thousands of amazing high quality developers.

It's partially market driven. When you get as many applicants as Google does and you are as awesome a place to work as Google is then you can afford to set the bar as high as Google does. And make no mistake they set the bar very very high.

Hey there,

I just want to say I interviewed at the Googleplex in June 2012 and it was an amazing experience. When I got the "rejection"(5 days later, which is standard in my experince), I didn't feel bummed or angry - I felt that I was defeated fairly in a challenging game of chess with people better than me. The programming questions I got weren't out-of-bonds ridiculous like I'm always hearing about. While the process took nearly 6hrs that day, it wasn't just for the sake of it. I had real discussions about real-world problems and I enjoyed it greatly. Those 6hrs flew by. Everyone should go through Google's interview process at least once; it will reveal limits that you didn't know you had. I'm a better person, career-wise, because of that experience. Also, I'm sure I was able to get the awesome job I have now only because I was still charged-up from Google-interview-preparing a few weeks before.

P.S., I'm sure I was close. I got a lot of smiles, nods, "yup, correct" and organic conversation that didn't seem rehearsed and they seemed happy to talk about so I suspect I did better than they expected but just... not... quite there yet... compared to some other candidates.

Every one must interview once in a while. Its just to ensure you don't catch rust.

>>Everyone should go through Google's interview process at least once

No, and this is precisely the reason which gives them that 'We are super special so its our way or the highway' attitude.

What every person must do is stop what they are doing, and give themselves a brief moment of introspection. And they should ask, if they problems they are solving are most demanding, challenging or their times. Are those problems something important for which people are going to pay good money? Or at least they must ask how difficult the problem is on a technical scale. And then pick what is most important both in terms of learning technical stuff and money parts of it.

You must do this routinely. Probably every Saturday night. Based on what the outcome of that is, you must have one long term plan and one short term plan. Something that can be broken down to small parts, put in a todo list and tracked next Saturday night.

Getting into Google or any other big web company won't automagically catapult your career to the center of the universe. Its a good brand to carry on your resume, beyond that nothing much. Bulk of Google, is a large company. Its legacy systems + incremental development all over the place.

So any good to your career will come if you do something about it personally.

Two wrongs don't make a right. Hiring is broken in general and it's even more broken in SW and engineering. Not only hiring is broken, but most exams and tests are also broken. It's always possible to cheat, game the system or fake. When we were students all of us experienced studying a subject just before an exam and immediately forgetting it afterwards. Exams don't prove that you really know the topic. More importantly, you may still fail at an exam when you know the topic well but not prepared properly. The underlying assumption in these hiring processes is that the interviewer knows the difference between a good hire and a bad one, therefore she knows exactly what to test. This is far from reality. The truth is that the test is arbitrary and the candidates are expected to comply.

This seems like rubbish to me. Exams work fine if they're employed in the right incentive system. In US universities it's not exams that are broken, it's the incentive system that they operate in. Today, exams are simply a tool for instructors to get good evals, students to get good grades, and universities to maintain accreditation.

Job interviews work fine if done properly. First, interview the right people (filter out hopeless candidates). Second, have the right people do the interview (hint: future colleagues). It's not perfect, but it's not "broken".

If you really knew the subject, you would have passed that exam.

> If you really knew the subject, you would have passed that exam.

Developers pass those exams and still hate the process. What now?

A qualification process is very different from a hiring process. You only pass through engineering exams, the bar exam, or medical residency once. In your life. A coder will probably go through a dozen different hiring rounds over their career, assuming each hiring round actually leads to a long-term job.

In a certain state of the economy, you're right. But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work.

For example, the company for which I work bills me out at $250 / hr. I get something like 15-30 job requests from other companies a week. It would not make any economic sense for me to pursue any of these other companies unless the interview process was dead simple, transparent, and easy (and the total compensation was _at least_ 15% higher than my current compensation). But, 99% of them will only offer modest pay adjustment (%2-3?), and then they expect me to sit through several hours of interviews. And, if I pass that nontransparent process, they ask me to sign a ridiculous employment agreement that signs away all my personal IP. Seriously?

The problem with recruiting today is that most companies who have good talent understand how valuable their best talent is. They treat them very well. And, the companies that want to obtain that talent completely under-offer their side of the deal.

Another problem is that most developers suck at negotiation. I see lots of anger on HN about not getting the 6-figure salary. Well, that's their fault for not asking for it. If they're a relatively good developer (top 25%), they should be making at least 6-figure, easy. And, if they're not, that's their fault, not the fault of others that know their value and how to demand a cut of it.

> But, at least here in the US, we currently have way more demand for good developers than we have supply. Basic economics says that your model will not work.

The problem is that hiring someone who can't code doesn't help me. And a bad engineer is worse than no engineer at all.

It's not like a grocery store where a bad employee is just really slow and a really bad employee steals things costing me a percent of a percent on my margins. A single bad engineer could theoretically destroy a company if they were savvy enough.

Pretty much anyone who does technical hiring will tell you that it's way worse to hire a bad candidate than to not hire a good one and interviews are tuned for that. It's the opposite of the American criminal justice system. A no-hire doesn't mean you're a bad candidate but a hire recommendation is very likely to mean that you're a good one.

Exactly, I prefer this feet-to-the-fire hiring process that we have now by far to the previous "hire him if he looks and sounds good" which results in far too many bs artists working in the field.

> A single bad engineer could theoretically destroy a company if they were savvy enough.

This sentence does not compute.

Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit. This results in crazy interview multi-hour processes.

In the real world, the worst employees rarely ever negate the work of more experienced workers. Thats like saying if you hire a bad teacher, students will forget information rather than learn.

I think bad in this sense is malicious as opposed to incompetent.

There is almost nothing about multi-hour coding interviews that does anything to filter out the malicious, unless they happen to be incompetent as well. Screening out malicious people is a very hard task.

Agreed. Many people parrot this line, but I have not seen anyone put actual data behind it. I have seen made-up scenarios about what could happen. Those usually stick to near worst case situations, though, with no indication of the actual risk.

People also seem to minimize or ignore the cost of a no-hire. If your company has an open position it is trying to fill, it should be feeling pain. Work isn't getting done. Projects or clients can't be bid on. Current engineers are working overtime to meet commitments. If you can look at this situation, shrug your shoulders, and say, "Eh, we're going along fine. We can wait several months for a perfect fit.", then I think you need to re-evaluate why you have an open position in the first place.

I would like to see some actual data to back up this conception. Something that gives the actual statistical risk. As someone mentioned on another story here recently, humans tend to over-estimate the risks of negative events. I think the risk of bad hires in SV has been seriously over-estimated.

In my observation, the rule that people get promoted to their highest level of incompetence holds true way too often.

I.e. the incompetent new guy just has to fake it long enough that he gets promoted. Now his incompetence has leverage. He can most likely shove responsibility onto others, and eventually gets promoted again. More leverage.

If I were to start an organization, I would make damned sure that every single new hire could do what they were hired to do - and then some. Otherwise, the office dynamics may lead to a stagnant organization over time.

> Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit.

I've worked in organizations where the hiring process the OP is advocating for (short one hour, possibly non-technical, interviews) demonstrably led to serious problems in that organization. Have you ever sat in on technical software engineer interviews? It's beyond horrifying how many developers I've seen that have a great resume, a decent portfolio, talk a big game, but literally can't solve a fizzbuzz-style problem on a whiteboard. I'd say the percentage in my area of developers who fail at this is at least 80%!

Think about that... if your hiring procedures are lax, possibly 4 out of every 5 developers on your team will be ludicrously incompetent. I don't care how tight the hiring market gets; dumbing down interviews is simply not an option with those kinds of odds.

If you haven't already seen it, you should read Atwood's article on the same subject: "Why Can't Programmers.. Program?" [1].

[1] http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

Youre under the assumption that "can't do fizzbuzz == can't program", "can do fizzbuzz == can program", which isn't true.

I'll tell you a secret. The first time I was asked to do fizzbuzz in an interview I got it wrong. It was about a year ago. I have been programming sine I was in middle school (I'm 29 now). Walking out of that interview was probably the worst day in my entire life.

Ever since then, two things have happened. First, the lines of fizzbuzz are forever etched into my mind. I can recite fizzbuzz verbally now. I don't even need any writing utensil. For i in xrange 1 comma 101 colon if i mod fifteen equals zero colon print "fizzbuzz" elif... [and so on]". This has come in handy in interviews since. All you have to say is "fizzbuzz" and I go ahead and write away. I don't even need the interviewer to explain the actual wording of the problem.

And the second thing is that I now have absolutly zero interrest in hiring a company that has fizzbuzz (or any other live coding portion) as part of it's hiring process. If I'm at an interview and the interviewer tells me "we're going to write code now", I'm done. If the problem is interesting I'll do it, but if it's fizzbuzz or anything having to do with reinventing something, I'm done. Not gonna work there.

I've struggled to put into words how to describe why I think live coding is such a terrible thing to ask candidates during interviews. Joel Spolsky makes a great point thats hard to argue against. If you're hiring a guitar player, you want to hear him play. If you're hiring a programmer, you'd first want to see them write code. I think the problem is that programming is kind of more like song writing. You can't ask a song writer to go the white board and bang out a new song. Even if you tell him exactly what the song should be about. Song writing is a process, and so is programming.

> This sentence does not compute.

Meaning. Someone who is bad at programming but savvy about interacting with their coworkers, bosses, etc. Someone who might be able to keep a job long enough to really fuck stuff up even though they're bad at what they're doing.

Six months in you realize that they've built a bunch of terrible stuff into the system and now you need multiple people to tear it out and rebuild.

If they're a relatively good developer (top 25%)

How does one know that one is a top developer?

I'd imagine it's easy to have a false knowledge of being in the top 25% (what with Dunning-Krueger and all) but how does a true top 25 percenter know that he is such?

I think it's relatively easy if you work within companies of a certain size. If so, compare yourself to another 100 developers that you've worked with. If you only work with start-ups, it may be more difficult.

Questions to ask yourself:

- Do you consistently get higher ratings than your peers?

- Do other developers come to you first if they want advice on the correct way to do something?

- Have you produced features that cause applause in sales teams or customers?

- Have all of your products been successful (maybe allowing for slips in schedule or budget)?

- Do people understand your code? (i.e. do you get a lot of emails from people asking to explain things?)

- Do features that you have created have significantly fewer bugs than other features?

- Do tech leads or product managers seek you out to help them build products or features?

This is also a good scale to use: https://michaelochurch.wordpress.com/2013/04/22/gervais-macl...

On an unrelated note, I'm curious to know which company this is that hires you out? I'm guessing SAIC is the current client and not the parent company (or am I looking at the wrong LinkedIn profile!)

$250/hr is great, but may I ask you - is it a regular job? i.e. 40 hr/weeks for say 1-2 years or so... Or you negotiate for each small tasks, thus having some overheads?

I think engineering is a tougher path than you do. It's as if physician had to pass a whiteboard exam on a randomly chosen topic from organic chemistry every time he or she interviewed for a new job.

While I agree that the premed curriculum and med school are rigorous, attrition rates in engineering are very high. It's tough to get into med school, but it's tough to major in CS or engineering, and getting into a top grad school in engineering is very selective. Attrition rates at top med schools are typically below 1%. In engineering PhD programs, attrition rates are above 35%.

I agree with you, but also keep in mind that leaving an engineering PhD program early ("Mastering out") still keeps your job prospects wide open. In comparison, leaving an MD program early leaves you very few options in the field, in my opinion.

Oh yes, I agree, there are all kinds of differences between the two. A partially completed degree at any level of CS helps you in your career (in fact, the blog post was written by someone who does not have a college degree).

I've discussed this with people on HN before, and I really wish I could find better stats on MS attrition rates, especially at good schools.

I was once a PhD student at UC Berkeley, and I felt it was pretty much a horror show of failure and attrition (the experience caused me to view claims of a "shortage" of US grad students in a very different light). It's tough to get into med school (or a top law school), but looking at the numbers, it doesn't appear to be any worse than top engineering grad schools (where GPAs and GRE scores are sky high). But in the professional schools, once you're in, attrition rates are very low. Yale law school, for instance, has no 1L attrition. Columbia's 1L attrition rate is 0.3%. Attrition rates for elite med schools tend to be well below 1%. Something odd is going on when congress claims that there is such a severe shortage that we need to start awarding green cards to anyone who gets a grad degree in STEM from a US university [1], yet attrition rates start at 35% (in engineering) and only get worse from there.

I think that engineering, math, physical sciences are a pretty grueling path compared to the professions - a point of view supported (at least at the PhD level) by a RAND position paper:

http://www.rand.org/pubs/issue_papers/IP241.html

Anyway, none of this is meant to refute your point - you are right about the MS issue. Though I really do wish we had better info on MS attrition rates. When I was at UCB, there was some attrition from the MS program as well, though it was not anywhere close to as high as the PhD program.

[1] I support this, however, I don't support the reasoning behind it - that a poor educational system is the cause of the non-participation of US students in STEM grad programs. I believe the aversion is rational and market driven, and any policy to expand the engineering workforce at the graduate level should consider this carefully.

Oh, looks like some research has very recently come out on this.

http://www.cgsnet.org/study-finds-completion-rates-stem-mast...

This was part of a study done by the council for graduate schools that recognized that attrition rates from MS programs were understudied compared to undergrad or PhD rates.

The full study is behind a pay wall, but still some interesting data.

STEM MS degrees appear to be completed within 4 years about 2/3 of the time - though that number drops to the low 40s within 2 years.

Unfortunately, there's only so much you can draw from this. MS programs aren't nearly as regulated as Law or Med school or PhD programs which tend to be offered only by very academically serious schools. Also, one of the big reasons for failing to finish a MS, according to the article, was work. So many students pursuing a MS are already employed in the field - something you can't do without a professional degree. Still, dropout rates were much higher than for MBA programs, so this data clearly means something.

It would be more interesting to know the attrition rates for MS students in STEM who are more like professional students at top colleges. In other words, what is the attrition rate for MS students who are enrolled full time at a top college.

Maybe these answers are behind the pay wall :(

The bar exam is a licensure process, not a hiring process. The hiring process at a large firm (analagous to a big software company) is a 20 minute screener where you chat about the weather, followed by a callback where they put you up in a nice hotel, and you have a series of 20 minute chats about the weather punctuated by a nice lunch at the local steakhouse. Gruelling it isn't...

Not that I would suggest replicating it mind you. The interviews are simple because they're literally just screening for people who can't have a converstaion about the weather. 95% of the substantive decision is just looking at the rank of your school and then your GPA. 90% of the candidate pool is excluded by arbitrary cutoffs from the get go. Which is an awful way to hire.

The bar exam is a part of the hiring process, its just that its outsourced to a licensing agency. In the software field, each company just does it themselves.

It's really not. At least at large organizations, it is taken for granted that anyone you hire will pass the bar exam. It doesn't factor into the hiring decision at all.

So I could walk into a Law office and if I talk a good game I'll get hired without having passed the bar? If not, then it is a part of the hiring process, as it is a pre-interview filter.

By extending this logic, kindergarten is part of the hiring process. Better make sure you get into that top-notch preschool if you want to get a job at Google in 20 years!

I don't think this follows. No one is going to check whether you passed preschool before interviewing for a job at a law firm. Presumably, someone in the process is going to check whether you passed the bar before you have a sit-down with the CEO. I'm guessing that for anyone who sets foot in an interview for a law firm, the interviewer expects he or she to have passed. This expectation comes from the fact that someone or something filters out the non-passers ahead of time. There is no expectation regarding kindergarten; they are completely indifferent towards it.

> I'm guessing that for anyone who sets foot in an interview for a law firm, the interviewer expects he or she to have passed.

Most large firms draw their entry-level associates from their pool of summer interns, which they hire two years before they graduate law school and take the bar exam. They also usually give people a mulligan on failing the bar exam the first time, so people might work somewhere for 6+ months before passing the bar.

Also, you only have to take the bar once (assuming you remain in an area where your bar membership allows you to practice). You don't have to re-pass the bar exam every time you interview.

Yes, if you are set to graduate from a top law firm and have a good GPA you'll get hired before you even take the bar.

But you will have to pass the bar to actually work for them.

I've often wished software dev interviews were as simple as passing a test I took on my own time and didn't have to share the results until I passed.

I saw your article before it disappeared from the front page. Nice work.

> I want a "1-hour guarantee" that I'll receive your considered offer after one hour of interviewing

...I wouldn't have hired many of my fellow engineers after an hour. I would at least want two interviews, one with me (the line manager), and one with my team.

To flip it the other way round, I don't think I could get a good enough feel for an employer from a single hour. I'm not sure this works for everyone.

I would, however, hire a consultant after an hour's interview. The difference is, at least in the country I live in, is that I can fire the consultant with almost no notice, whereas a FTE is more of an investment.

I don't make major financial decisions in an hour, either, and hiring an engineer is a 6 figure commitment.

You don't have to decide during that interview. You can take your time. Look at the candidates' source code on github, bitbucket, look at their mobile apps, disassemble them, take a look at how well they write software, etc.

How could you verify the code is actually theirs in just one hour, and not something they've been coached on? The stakes are so high that we already have an awful lot of blatantly unqualified people trying to bluff their way through in-depth interviews, and making that easier is a huge step backwards.

Its usually pretty damn obvious Ask them to explain what the code does and why they wrote it. If they backpedal and aren't able to say anything then you can assume they didn't write it.

> How could you verify the code is actually theirs in just one hour

You don't have to review the code inside of one hour. You can take as long as you want on that. The point was that when talking with them either on the phone, in person, whatever, you take only an hour. Code review can take as long as you please. I highly encourage you to look at source code before making a hiring decision.

>> Also, it would be awesome if one of you would actually look at my git repositories before the interview and, you know, actually read my code. No, looking at a "repository summary" doesn't count.

actually, this I find is the biggest annoyance of all. Every company I've interviewed with over the last few years has said "show us your github".....so far, not one has actually looked at it. It's kind of like walking into an interview with a company that has a web-presence and saying "so, what line of business are you in?".

> How a company treats people during interviews is a huge indicator of how they treat people in general.

I fully agree. I think a possible fix is to publicly share the experiences people have when interacting with HR. If this is done centrally, perhaps the industry will take notice and improve.

The threshold for using "broken" now is the presence of any imperfection in any process, its an abuse of the word. Hiring is imperfect, but its been moving in the right direction.

Most companies ask programmers to come in, solve some problems on the board, and then pay them a generous salary if they succeed at it. How is this in any way "broken"?

A casting couch is an example of "broken" and corrupt hiring, we have nothing of the sort.

> Most companies ask programmers to come in, solve some problems on the board, and then pay them a generous salary if they succeed at it. How is this in any way "broken"?

For starters, because those "problems" are usually unrelated to what we actually do.

My interview at Amazon (where I am currently) fit those requirements.

* It lasted 3 hours, not all day. They suggested business casual dress.

* No trick questions or trivia puzzles. Just coding on whiteboard.

* The interviewers had clearly looked at the work I'd been doing (no one asked "what do you do currently," etc.

* I had an offer, with numbers, about 50 minutes after the interview.

* I countered, they took less than 24 hours to respond and accept.

It was really enjoyable.

Startups exist because hiring is broken.

Every time I read the word passion in one of these articles I cringe. This has to be the most overused word in silicon valley. It's really just a convenient way to abuse people. Can't work 90 hours? Not passionate enough. Have a family commitment? Where's your passion? Passion. We get it already.

It doesn't happen nearly as often, but I also cringe when I hear the word "stability" used as a euphemism to indicate a desire for someone with a mortgage and family. Discrimination comes in many forms.

Ha, you forgot this list:

"disrupt!"

"only the beginning"

"ninja"

"agile"

"seamless"

"social media"

Disrupt is a good one. I love how organizations will use it, and then when you join said organization you're encouraged to do anything but that.

"rockstar"

"beautiful." particularly when speaking of UI

The thing people forget about passion is that it doesn't last. Passion is for kids. By all means, work on what you love, but remember you're an adult and set the right pace.

Absolutely this. I used to be passionate, in the first months of my (poorly paid) first job. I won't commit the same mistake again, I learned quickly that life is more important than work.

I also cringe whenever I see 'Now building things' in a person's profile. What were you doing before?

Every time I read "engineer," I cringe. I don't give a crap how fantastic you are at programming, if you don't have a college degree then you aren't an engineer.

So your title isn't dependent on your accomplishments or abilities, but only your schooling?

Can you call yourself a lawyer because you enjoy reading your state constitution? Can you call yourself an MD because you read r/poppit? No.

Engineer is a professional designation. It requires a BS, a series of exams, and years of work experience. Engineers are regulated by professional organizations. Unless you've gone through the training and the tests, you aren't an engineer. You're a developer.

I disagree. In the vernacular, the term engineer is more casually used, like scientist. Lawyer means member of the bar, Physician means licensed to practice medicine. Engineer has multiple meanings depending on the context. A patient in a hospital would be confused by a literature PhD claiming to be a Doctor. I don't think a "sound engineer" or "special effects engineer" should apply for a job in a construction firm with the title "engineer", but I don't think the public is endangered by the ambiguity here.

That said, I strongly discourage software developers from using the term "engineering", mainly because I don't want the PE folks to start thinking they have any sort of business licensing software practitioners or getting involved in evaluating their competence.

As a math major (abet one with an MS in Industrial Engineering), I put no claim on engineering, and I dispute any claim engineering has over software. I think CS is more a branch of math than of engineering - so if the PE folks want to interfere in this, they can start by going back to college and taking a couple years of real analysis, abstract algebra, complex analysis, advanced linear algebra (with proofs, not some watered down "applications" course), and number theory. When they're ready to pass an in-depth exam on those subjects in order to get licensed to write code (after failing the first time), they'll have a taste of what regulatory capture really means.

> I think CS is more a branch of math than of engineering

It is, but designing software isn't CS any more than designing bridges is physics.

I agree completely. I think that requiring an exam in these subjects to obtain a software engineering license would be absurd - my point is that I don't think its any more absurd than licensing software "engineers" under the PE license.

I'm not really in favor of a professional license for software "engineering" - but if there were, I'd say it should stand completely apart from the PE.

The PE exam writers should feel free to include whatever software questions they like as they license, say, civil engineers, but they should stay in the business of civil engineering.

Yes, a title that refers to schooling is dependent on schooling.

If you want a title to mirror your ability, choose one that refers to abilities. (And again, yes, due to hystorical reasons, those are rare. Want to start a trend?)

Even with a college degree in computer science and math, I don't think that engineer applies to me.

I'd say that you get to be an engineer if the "Engineer" is printed somewhere on your diploma.

Unless you drive trains.

I think I would agree when the profession is well defined to require such a qualification. For example, Doctors, Attorneys, CPA Accountants, all require certifications to hold a legitimate title. Engineers, Chefs, CEOs, etc do not require a degree or certification to be legitimately titled and qualified for those positions. I would never reject an engineering candidate on the sole basis of their degree.

Engineer is a professional designation.

Only in some jurisdictions. In most of the US, Software Engineer is not a regulated title. I believe Florida and Texas are the only exceptions.

Thanks for this. I've burned out before. I enjoy my work, respect what my company's goals are, and am working to get better at my job and programming in general. I also like having a social life - try to think about how many people from past jobs you are really in contact with?

You can build a startup in the time it takes to thoroughly prepare for these interviews/positions. Willingly subjecting yourself to this rat race is essentially the same thing as stamping yourself as an "ibm man," in the words of Jobs.

Who cares if you don't know the intricacies of all the hot algorithms of the day. Spend your time creating actual value for the world, instead of practicing just for the sake of impressing someone.

This seems silly.

If nothing else, following the advice here will help you hire better engineers for your own startup.

Really?

Most true startups are in need of developers who can actually ship something of value in an efficient manner. The last thing they need is an "engineer" obsessed with algorithms and data structures who turns a practical development task into a computer science challenge.

That's a false dichotomy. It is certainly possible to know your algorithms and data structures and still be able to ship code. I can implement quick sort for you, but I know well enough not to actually do it in practice.

That's fair, but when your entire interview process is focused on algorithms and not real-world implementation, you're far more likely to hire the person who can implement quicksort but little of real value. And make no mistake: these engineers exist.

The truth of the matter is that most startups aren't Google or Facebook. A good percentage, perhaps the majority, have a CRUD application of some kind that, even if relatively complex or widely used, will realistically never require engineers to reinvent the wheel, let alone even understand the internals of the programming language the application is built on.

These startups should absolutely fear hiring an engineer who can't knock out a simple internal dashboard, integrate with a third party API, create a half-decent database schema or customize an instance of [insert popular open source CMS or ecommerce platform] more than they should fear hiring an engineer who can't implement his own quicksort.

This is applicable for big businesses, too. As a consultant my heart sinks when I open somebody else's code and see a custom-developed sorting library inside a a home-grown MVC framework.

Disagree unless you're startup is building a library that implements solved computer science algorithms.

Are you suggesting that building a startup is merely an exercise in programming?

I do agree that one should not participate in the idiotic way programmers are currently being recruited by some companies. But that doesn't mean there aren't good, BS free jobs out there. Jobs that are full-fulling and economically adequate. Not everyone aims to be on the cover of Forbes. Some people just want to program, and go home with the family. Oh, and fish on the weekends. That's a perfectly good life to aim for. Better than what the rest of the world may have.

I'm merely suggesting that most engineers who take the time to study for these interviews are probably good enough to make money on their own somehow. Whether that is a startup, consulting, lifestyle business, or something else... If people just focused on doing a lot of great work, then the jobs will come to them.

I hate to see talented people wasting their time preparing for these interviews. The opportunity cost is too high. These current hiring practices are robbing the world of great software–code that will never exist because the time was instead spent on superfluous interview tasks.

Yes, I understand your point. And its valid. Though I disagree with the part where people who are good enough to do X might be good enough to start a business, or consult. From my experience that has not been the case. I've met and helped a lot of brilliant programmers along the way, and few of them were capable of running or learning how to run a business. Note that I don't mean that people can't learn, but my experience has shown otherwise. I wish to be wrong.

Meh. Running a business is a different thing from software engineering or coding or computer-science. Why should everyone be suitable for a business role?

No but I think his point is about 'how you spend your time'. If you see that you are spending bulk of your time preparing to win in a rat race. You might as well spend the same time doing a start up.

And ofcourse sales, marketing etc and all that comes a part of doing a start up.

Yes, some startups are actually exercises in programming. Real talk.

Seriously. Do people actually think Tumbler, Instragram, et al were the product of some Harvard MBAs with a genius business strategy? Many times success is fully explained just by the product + timing.

Couldn't agree more with that sentiment. Timing, luck, connections, execution, doing something you love. That's Instagram.

Not everyone has a "monetizeable" startup idea worth pursuing at any given time.

And friends, and contacts, and capital, and a huge amount of free time, and unabashed faith in that one idea.

And the ability to get health insurance without being under a megacorporation's umbrella.

Seriously this, solving the health care problem would free up so many people to start companies and innovate growth, it would be the biggest boom to our economy.

IBM do some good engineering, generally treat their employees well, have favourable maternity benefits, and employ some great people.

Probably not going to be your first choice if what you want is a small, dynamic, startup atmosphere, but as an employer I wouldn't fault them.

(yes, ex-employee)

At the time Jobs said that IBM was still very much the "blue suit required" IBM.

Their corporate culture has changed a bit in the past few decades.

If I could support myself with a three week project instead of spending all day sitting on malodorant trains and an office chair, you'd be damned sure I would do that

One of the problems that I have with this list is some of the stuff I just haven't had to deal with since college, like implementing all those data-structures like bubble sorts//binary search, linked lists, etc...In 15 years, I've never had to implement one (when I was a C/C++ coder in the '90s, we used 3rd party libraries like Dinkumware). Interviews that ask these type of questions are really skewed at hiring young people just out of school, and favor people who memorize things by rote, not necessarily create/problem solve. Even the author almost admits this by stating he solved problems for two weeks prior to his interviewing...

If someone gave you the specification of a linked list, binary search, etc, could you code up a mostly correct implementation off the cuff? This is precisely what these types of questions test for. Just having it memorized gives an interviewer very little information. Can they work through a logical problem and code up a solution? This is strong signal for programming ability.

I've never memorized any of these algorithms, but I can code them up pretty easily given the specification. If you can do this it doesn't matter how many years you've been out of college.

What you're claiming is a straw man of the processes I've personally seen. In most good interviews they ask you something specific to implement, such as how do you implement a code complete feature in an IDE or an event logger. There will be some obvious naive solution that would be slow with any reasonable amount of data. They want to see if you can use the data structures in practical way.

The expectation is that if you're smart enough you can reason to a more optimal solution even if you haven't seen a trie in 15 years.

Agree...maybe I read too much into the listed algorithms, because you're suggesting real-world scenarios where some of these concepts can be applied.

But I will say, as never having used a graph search like Dijkstra's in any of my work, the idea of studying this to take a hiring test still goes with my theory of learning something by rote. If someday I need to implement the concept, or use it, I'm sure I'll go figure it out. I had to do this awhile ago with a Levenshtein distance for computing similar string matching. Had someone asked me in an interview, I'd have completely failed at it.

I've been a junior developer for almost 2 years now at a fairly large company. At my current position, there hasn't been a single task thrown at me that I have not been able to complete with ease. I've worked with multiple languages and technologies that I was not familiar with at all when I started. I tend to figure them out pretty quickly and get on with the task at hand. I've built a bunch of side projects (not all of them completed) and have put them on Github per this article's suggestion.

Having said that, I get paid very little and am generally bored with the work I'm doing now so I'm looking for a new opportunity. I do very well on phone interviews but I'm absolutely terrible at onsite interviews that involve any white board algorithm problems, algorithm optimization questions, etc. This is a combination of low self esteem/intimidation I feel during these interviews. I've done maybe 3 or 4 of these and they've all gone terribly. It's come to the point where I have stopped applying for positions that interest me and that I feel that I would be a great fit for because I know the style of interview that I'll be facing. I've determined that I either need to come up with an idea of my own that I can turn into a steady income or that I need to leave this field and find something else to do.

What do you guys think? Am I just a terrible developer or is it just a matter of practice? Like someone else mentioned above, I try to sit down and practice but get distracted by the fact that I could be building something interesting.

The fact that you're easily doing your tasks and looking for more challenge (and the reward that comes with it) suggests you are a good developer. What is it about phone vs on-site interviews that makes you do less well? I would try to think about why and ways you can mitigate that. For example if you think it's just talking in front of people, then get out of your comfort zone and give a talk at a local meetup or similar. Another thing to thing about is to present yourself honestly to the hiring manager as you are here... tell them that your work on github and your phone interview will be better than what you can do in-person. The important thing is to show them that you can do the job somehow.

It seems like you just need to decide what you really want. If you really want one of those jobs, then just buckle down and jump through the hoops. It won't take all that long to memorize the stuff.

On the other hand, maybe your resistance to the hoops is a warning sign that you should pay attention to if you don't want to end up bored again. Hiring processes like these will tend to select the people who prefer homework problems and tests to actually building things, which might be unlikely to create the kind of environment you'll be happy in.

Have you tried going to meetups and doing some networking? Getting to know people outside of the official channels seems to be a way to short circuit some of this nonsense.

I have some ideas that would help address this problem and improve hiring in general. I might take a stab at it eventually, if I'm ever no longer running my current venture.

"I've determined that I either need to come up with an idea of my own that I can turn into a steady income or that I need to leave this field and find something else to do."

What about consultant / project / contract work? Generally "the hiring process" treats candidates for full time employment relatively poorly and unprofessionally, but treats consultant / contractor types more professionally.

Think about other professions. If you're hiring a plumber's apprentice, its funny to ask them if they know which end of a plunger to hold, and watch then squirm under the pressure. But if you talk to a real genuine licensed and bonded independent master plumber and ask him to demonstrate unclogging a drain before you'll offer a remodeling contract, he'll probably tell you to F off and walk away to a more professional job. You can treat employees like dirt, but not contractors.

Great example. I've thought of this many times myself -- how no customer would ever treat a trade contractor in the way that companies treat candidates. My electrician is not going to spend his valuable time letting me grill him on questions about electrical power generation and distribution, RF engineering, or even Ohm's law for that matter. When I think of it, I'm hiring him because 1) he's not a n00b, he's a journeyman, 2) he's been around - has some staying power, and thus has most likely done satisfactory work, 3) the BBB is happy with him, he must not have done any awful work, and 4) if he's on Angie's List at all, most of the people there are happy with his work. If I were to try to cop the attitude of "I'm thinking of hiring you, but you're going to get a good, humiliating hazing first" I'd fully expect to be told to F-off and I'd deserve it too.

You don't mention how you're finding jobs, but my main advice would be to get referred to jobs. Let everyone you work with, and which you share a mutual respect with, know that you're looking -- seed your network. Also go to meetups and any sort of external events you can (user-groups for software products, etc). Because, as others mention, being referred helps immensely.

Also as others mention, confidence in the interview is something you can develop. Practice. Practice speaking, practice the white-boarding (somehow... maybe record yourself at home with video and watch it), or use the public forums (the meetups). I've taken to recording myself reading the Harvard Sentences, to hear how I sound. Whatever works for you.

Finally, it's just a numbers game, the long game.... It. Takes. Time. The whole process always takes longer than I expect. Keep searching, try to not get emotionally attached to it, because it's such a roller-coaster ride ('I had five rounds of interviews, we had good rapport! .... [two weeks later, after silence: no-go decision]), and lay low in your current job because a paycheck is nice to have in the meanwhile.

This is one unexpected way in which I think my academic background has served me well: We give presentations and take questions about our work all the time, or have whiteboard discussions with colleagues about how things work. We also giving practice talks before giving important ones, with a friendly audience taking notes, asking questions, and giving you feedback on what was good and what was not.

If white board algorithm problems terrify you, the only thing that will help is practice. Take the opportunity to try to discuss different solutions with colleagues at work. Or, if you can't do it at work, try to get a couple of friends together and just take turns presenting and asking questions. Yeah, you won't get the adversarial atmosphere that way, but you will get used to the setting.

I sympathize 100%, I feel much the same as you do. I have decades of experience, doing real work, creating systems, making products. Back In The Day, these kinds of quiz-cage interviews simply did not exist, and, having sat on both sides of the interview table a great many times, I can confidently say that they don't need to exist. I would no more ask a candidate to implement a quicksort than I would ask a candidate for a trumpet chair in my orchestra to recite to me the frequency of every note in the F major scale or demonstrate how to weld a new bell onto this extremely broken horn that I just happen to have with me. The whiteboard stuff you describe is -nothing- more than hazing, as you, I think, have instinctively surmised.

At this point I don't bother to apply to corporate jobs, or even to jobs at startups that are larger than a few people, because I know I'll get the same kind of idiotic hazing each and every time. I'll found my own company (there have never been more opportunities than now) or do freelancing for companies that will treat me with respect. In your case, since you sound like you're sharp, I think that freelancing might be a good choice in the short term. You can bring in some bacon while you work on product ideas, do some networking, and find partners.

You sound like a good developer and the problems that you have with these interviews (which I share) are no reflection on that fact. This may sound a bit odd -- but do keep an open mind about leaving the field. There's a lot of interesting work out there in the world, some of it creative even. Software geeks tend to live in this very narrow, ant-farm-like world, have a hard time seeing outside of its walls, and assume that beyond the glass is a land that can only offer just drudgery and pain, which is simply not true. Best of luck.

    Re-invent the wheel. 
    You should implement the most common data structures 
    in your language of choice. [...]

While I agree that it helps a lot understanding those data structures by implementing them, it might be good to add "Don't use them in production!" paragraph.

Agreed. Working in games you really do get to work with smart people, yet with the power of C++ everyone wants to recreate their own String class, data structures etc. Game industry largely hates STL. There is also a distain for boost, another large collective of reviewed and hardened standard libraries (POCO is another nice one). The ego is immense at places like this. Programmers feel like they have to do this to compete or deliver over shipping and delivering products that work. Granted there are reasons for doing this such as keeping memory allocations through a common engine library to reduce memory and fragmentation but in most cases it is a moot point.

Performance does mean the most many times in this field for the AAA games out there, but not for most games. In web or app development if you are using custom data structures instead of native, in most cases that is wrong. How about consistent data structures that have been built and tested outside the company? The thing is though when the programmer that makes your 5th string class and data structures moves on it will be rehashed by the next, as other developers won't be as effective with them and recreate.

It is much more important to understand what data structures to use when and what impact they have on performance. Most of all can the developer ship and understand what is best for the product (not the ego or what will make them look like the hardest programmer of all time -- i.e. Rewriting the string class again and it is 10% faster, even though that is not a problem at all). I have seen some horrible, leaky, buggy data structures in situations like this, because they thought that was the job as led on by the interviewing. I have only really seen this while working in the game industry which I love but it is a problem with shipping product when this bike shedding happens over improvements to the game, engine or real custom needs i.e. the UI libs, event/messaging systems, naming/conventions are typically horrible in situations like this.

I also blame consoles for many of these problems as the libs are so jacked, incomplete and old that performance becomes a huge issue and you have to have custom structures just to use the hardware right especially in graphics, physics + networking libs. Yet mobile I have seen less of this problem even though there is less hardware to work with. The next time you play a game and the networking totally sucks, or a game takes forever or simply doesn't ship, understand the culture of the company and the industry might have something to do with it.

Yeah, the funny thing about all the data structures & algorithms quizzes is that the simplest solution is usually a recursive one, and the big-O performance is sort of irrelevant because chances are you're using a language that doesn't have tail-call optimization and you're going to blow the stack frame for any large value of n anyway.

Many recursive algorithms only require log(n) entries in the stack. Even if you do start overflowing the stack, it is simple to take a recursive implementation and turn it into an 'iterative' one, where you just manage the stack yourself.

> Master at least one multi-paradigm language ... Some good candidates are C#, C++, Java, PHP, Python, and Ruby.

They all look imperative to me, what happened to multi-paradigm?

Would not for example C# or C++ count as multi paradigm as it can be considered to support both imperative and object oriented programming?

OO is a subset of imperative.

Can you name me an OO language which doesn't support imperative programming?

Smalltalk is pretty damn functional, actually.

C# and C++ counts are part functional.

Whilst I can't speak for the others, C# has some interesting facets which most other languages do not. For example first-class functions and lambdas, LINQ, type inference. It also has some nice syntactical sugar like the coalesce operator.

Why do so many people advocate reinventing the wheel? As far as I can tell, it wastes a LOT of time, especially in the interview process. One of the companies I interviewed with before I landed at my current job asked me to use pencil and paper to re-implement a bubble sort in Python. Why? My job is to build a house, not forge a hammer. And the fact that it was a bubble sort instead of something... better... was like using a rubber mallet to pound in nails.

I understand that, when you're learning algorithms and such, that there's no substitute for implementing them, to learn them. But when someone with several years of development experience comes in, with a portfolio to show, why waste their time?

Its a step up from Fizzbuzz, but its the same sort of test. It tests whether you have the capacity to think logically about a problem and code up a solution. The mental faculties exercised when coding bubble sort (or any of the so-called "CS puzzles") is the same sort of faculties that are required when orchestrating the various modules when generating the response to an HTTP request. This just strips all the fluff.

Really good post, thanks David.

I'm really curious as to how you landed an interview at Google (let alone a job) without a college degree. My understanding is they are very strict about that and it's hard to even get a foot in the door without a degree.

[disclosure: I'm on a 10 year "hiatus" from my senior year in college]

I had six years of experience in video games and was a hardcore C++ programmer. To be honest, I was surprised they called me.

Nowadays, showing a body of work speaks volumes. Show, don't tell!

Couple of points for your article:

Regarding the C++ self-assessment, it depends to whom your talking to. If it is a 10+ years of exp. hard core C++ programmer, then your point is right. But if it is some recruiter clerk - who just writes down your answers to compare with other candidates' answers later, then it is 10/10 :)

Another answer could be: "for your company, it is 10/10" depends on the company, of course.

But all in all, I find this score based questions quite stupid. Instead, you should ask for past projects using that particular language.

Now regarding your algorithmic part. Tell you honestly, the fact that the candidate implements the Dijkstra's algorithm quickly, because she implemented it twice, 2 weeks before the interview tells me just that - that she implemented it 2 weeks ago, twice....

I'd more value a candidate who have never implemented it, or implemented it 10+ years ago but doesn't remember details - when given the details/specs and a sufficient amount of time, and can implement it.

Overall, I prefer when the candidate can come up with the higher level solutions - knowing when to use e.g. Red-black (or any other balanced) tree, shortest path algorithms, suitable containers - data structures, etc... for some particular problems. The actual (hence 2 weeks ago) knowledge of every specific details of how to implement these is not that important.

Have you written a blog post about leaving and your time since then? I'd love to read.

I was contacted by Google without them knowing I had a degree, although they knew by the time I was scheduled for an interview. Apparently washing out in round one of Google Code Jame 2012 was enough for them to seek me out. I performed to expectation by similarly washing out of the interview.

Steve Yegge wrote that you should apply to Google, no matter whether you think they'll take you or not, because it's a desirable position and the cost of failing is low. I spent $200 on a hotel room (not reimbursable), $150 on transportation from and to the airport (not reimbursable), $50 on baggage fees (reimbursable), and two days of my salary (since I wasn't at work when interviewing) (not reimbursable) in order to apply. This could be described as "significant".

I feel compelled to add to this: degrees are used as a filter for graduate level jobs. I do have a degree, but it's a studio art degree (i.e, painting, drawing, etc). I've had interviews with Google in the past, and like the parent it was just through recruiters getting in touch. At a certain point, your experience matters significantly more than the degree.

I also washed out, but it was pretty enjoyable. I certainly wouldn't describe it as a hazing.

They don't reimburse travel expenses for interviewing? That's surprising, and a shame if its true.

They reimburse airplane tickets (well, actually they pay for the tickets directly), but they don't reimburse "private transportation", e.g. getting from the airport to the hotel.

This presumes that a) You want to work at Google and b) You consider Google to be doing interesting stuff that it would be worth applying. I don't. They aren't.

What was your excuse for that two missed days in your then current job?

In my case, being recommended by a Googler was enough to get the interview.

They don't require a degree if you have significant experience, and a referral from a Googler helps.

(Source: don't have a degree, interviewed at Google)

The only recruitment process I know of that works is.

Step 1) Send the candidate a small unattended coding test they can do in a couple of hours. If they pass great if they dont offer them feedback.

Step 2) Invite them in for a pair programming test this should take max one hour, they can spend 15-30 minutes with one or two people on the team solving a problem.

You wouldn't believe the amount of people who have amazing looking CV's but when it comes to actually coding they just are not up to scratch.

There is also obviously personality fit and other subtleties but thats the basics.

Note that many programmers get stress from the interview and perform substantially worse.

"If they pass great if they dont offer them feedback."

I've only personally encountered it once, but if you ask someone to spend a few hours of their free time on your coding challenge you absolutely owe it them to give them feedback, even if you don't like what they've produced.

Always coding and landing a job are kinda opposite in my opinion. If you are looking for a job, then you have to look for the job and that means little time and interest for coding.

You are not also guaranteeing a position where you'll actually code something or help develop something if you happened to get the job.

If you want to code, do agency consulting. Agency brings the work, manages the clients, do the accounting, marketing and the stuff. You code.

> “On a scale of 1-10, 10 being the highest, how would you rank your knowledge of C++?” ... Bjourne Stroustrap himself would rate himself probably an 8 or less.

Is there a citation for this, or a citation for something similar, or is this just a guess?

If it's actually true, then score++ for people who complain that C++ is too complex.

Log(1)=0 If you interviewed once and got the job, your score would be 0.

Intentional. The idea is that 1/1 could be a fluke. :-)

For x == 0, this also blows up.

And for x > 1, which base you use matters. E.g. if x == y == 2,

    >>> from math import log,e
    >>> 100 * log(2,2)
    100.0
    >>> 100 * log(2,e)
    69.31471805599453
    >>> 100 * log(2,10)
    30.102999566398115

I'm aware it's meaningless, but which base did you intend? :)

Similarly I'm 8 for 10 and have been working for nearly 20 years. So I get a score of 80.

If I had an 80% success rate, but was 18 for 20 I'd score 117. To get that, I'd need to be changing jobs every single year.

The score is not only totally made up but pointless and adds nothing to the rest of the article. It's just there to suck you into the article.

If you had an 80% success rate but were 18 for 20 you'd be some sort of wizard. :))

Anyway, I think the author is assuming that each time you apply, you're applying for multiple jobs, getting multiple offers, and turning down all but the best one. I was a little surprised that my score was so low, too, given that (as a junior) I've only had 2 on-site interviews but have received 4 offers, which gives me a score of 60. Meanwhile, interviewing for 100 jobs and getting 60 offers gets you a score of 120.

It's funny to me that items 1-6 in your technical tips pretty much boil down to "be an A-average student in a CS/CprE program".

I think there's an alternative, and it fits into your ABC. Build useful software. If you've got an idea, implement it, and if possible, open-source it. In the process, you'll likely rely on a bunch of open source software, and maybe you'll run into some limitations. Every limitation is an invitation for <i>you</i> to contribute. And if you can build a bit of a track record, instead of proving yourself with textbook algorithms, you can do by showing your portfolio of actually code.

I've rarely had interviewers actually seek out my github/bitbucket/xxx repositories, bug reports, and code reviews.

I assume it's because they're busy "filtering" through hundreds of candidates and don't have the time to read the thousands of lines of code I've written.

Great read. I think you're missing a link in there.

"Spend at least 40 hours coding solutions to different types of problems. One of the best resources is TopCoder. Read this. Then try solving problems."

Did you mean to link to the top coder algorithm tutorials?

Thanks! Fixed.

Good tips, although I'm not sure if the ratio means anything. When I was young I'd happily apply to jobs even if I didn't match on everything in the ad, even though the end chance of getting the position was lower no matter how well I interviewed.

Now that I'm older and have a job I like I usually pop out a really high salary number as early in the process as possible to scare away any companies that would take a lot of work to interview with and then not be able to afford me.

So you could have a very low ratio of offers for reasons other than your interview performance. :)

I made it clear that this doesn't mean "applied to" but actually onsite interviews.

But your'e right, the ratio doesn't mean anything. ;)

While I might generally agree that the interview process is asinine and a rat race, I actually use some of those formal methods and algorithms in my day-to-day work--and I'm not even a computer scientist, nor do I have a CS degree.

I'll bet things are different in the startup world, but I've encountered several instances where having a very crude understanding of time complexity served me well. Hashing has been an especially powerful tool in my work, where the size of the data I work with really highlights the difference between an O(n) operation and an O(1) operation.

I would consider the interviewer asking questions about algorithms to be a sort of Fizz Buzz for the more technical positions. Perhaps it is misapplied to be asking technicalities of algorithm questions to people that will be doing more design-oriented work, just as it may be inappropriate to ask your sales force applicants to write programs during their interviews.

That said, most of the interviews I've conducted would not have been able to discriminate well the qualities that I believe make a great programmer. A focus on code longevity, discipline in conducting code review, dedication in writing unit tests, and how they search for information they don't know the answer to are important qualities that a technical interview will largely be unable to see.

Off topic: I know that formula is made up but it made me think of something. How come nobody has fixed the log base 2 vs log base 10 problem of using log on the internet? Probably the CS article vs Math/Physics article is a good inclination but none the less it seems like a problem we should have solved by now.

Most of the times I've seen logs it doesn't matter, because it usually shows up in big-O. However, the only unambiguous abbreviations I've heard of are ln for log_e, log for log_10, and lg for log_2.

These kinds of interviews essentially ask: are you willing to put in the time to be one of the best in the world at what you do? Are you gritty, or wishy-washy? If the answer is no, don't bother to apply. That's not an unreasonable way to hire, in my opinion.

It's also a matter of attitude. If you're not willing to put up with having to study for what you perceive to be arbitrary interview questions, you probably won't do well with all the other annoying things that can't be changed that big companies tend to have.

Which is kind of what many people in this thread are saying when they say they don't want to work for a company stupid enough to use algorithms and data structures questions as their main interview method.

It's the worst method out there--except for all the other ones. The problem with the "here's my portfolio of work" screening method is that companies generally expect a certain level of productivity (and IQ), and there's no way to tell how long you worked on your portfolio. Did you write that code in two hours or two years? Any code can be made to look good given an infinite amount of time to polish it and test it. Behavioral interviewing questions, on the other hand, just don't work for coders; too easy to bullshit.

The arguments against coding interviews seem weak, to me. They appear to be rationalizations for not getting the job--an insult to the ego that must be rectified by bending reality. They essentially boil down to, "I shouldn't have to sweat these details; they're beneath me." But all of the greats sweat the small stuff, almost obsessively, and pay their dues.

For the vast majority of mindless coding jobs out there, you don't need to hit the high notes. But when you're moving the state of the art forward--indeed, civilization forward, inventing what has not been invented before--you need complete mastery. If you just want to build stuff, on the other hand, these skills are unnecessary. But that's not engineering. That's construction work, for construction workers.

“Any code can be made to look good given an infinite amount of time to polish it and test it„

Sorry, but no. Some code turds are beyond polishing... All you'll get are polished turds.

Google's how-to-prepare-for-an-interview e-mails used to say "give yourself at least 2 weeks to review and hone your coding, algorithmic and problem solving skills."

That's fine if you only want the unemployed and new graduates - how well do you suppose it works out for people with full time jobs?

Bookmarked for future reference to this comment thread and the original article .

I find that always coding mantra is just one version of a method that applies to many other disciplines.

I am a soon to be college grad and am currently going through the hiring process at many companies. This article is pretty in line with what I have been seeing so far.

Contrary to the title he is mostly talking about algorithms and CS stuff. I think he just home-schooled his degree without actually getting a degree.

The page won't scroll on chrome for android :(

I've been noticing this recently, it's amazing that such a basic issue is unresolved. Apparently overflow: scroll has been broken on android browsers since 2009[1], but was fixed as of Android 3.0. For me scrolling works fine in the native android browser, including overflow:scroll, but shockingly not in Android chrome.

[1] https://code.google.com/p/android/issues/detail?id=6864

"SPACE" for scrolling doesn't work on firefox (os x desktop) either.

I reported this Firefox bug just moments before reading your comment. <:)

https://bugzil.la/874766

I reported this to Medium a week ago as well.

Could I get your UA string, it works fine on Chrome on my Androids.

I'll have to get back to you on that when I get home.

Little bit of nitpicking: If x = y = 1, then value = 0. I wonder why he didn't just choose value to be 100y/x.

I suspect the log is in there to give you points for experience in interviewing. I would argue that `log(x+1)` would make more sense, to avoid that 0 issue.

I've only ever had one on-site interview (and I got the job).

According to the formula at the top, my value is 0.

One data point yields no information.

One data point definitely yields information, just no usable conclusions.

"Bjourne Stroustrap"? Yeah, I bet he'd get under a 9.

So you learned how to interview well, so what?

Always be shipping.

heh... a variation of always be coding is what I went with for my blog name a while ago.

Reply on news.ycombinator.com