Always Be Coding – How to Land an Engineering Job

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.<p>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.<p>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.

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:<p><a href="https://news.ycombinator.com/item?id=5730843" rel="nofollow">https://news.ycombinator.com/item?id=5730843</a><p>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.<p>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.<p>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.

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.

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.<p>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.

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...

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.<p>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.<p>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.

<p><pre><code> Re-invent the wheel. You should implement the most common data structures in your language of choice. [...] </code></pre> 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.

&#62; Master at least one multi-paradigm language ... Some good candidates are C#, C++, Java, PHP, Python, and Ruby.<p>They all look imperative to me, what happened to multi-paradigm?

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.<p>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?

Really good post, thanks David.<p>I'm really curious as to how you landed an <i>interview</i> 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.<p>[disclosure: I'm on a 10 year "hiatus" from my senior year in college]

The only recruitment process I know of that works is.<p>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.<p>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.<p>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.<p>There is also obviously personality fit and other subtleties but thats the basics.

Always coding and landing a job are kinda opposite in my opinion. If you are looking for a job, then you have to <i>look</i> for the job and that means little time and interest for coding.<p>You are not also guaranteeing a position where you'll actually code something or help develop something if you happened to get the job.<p>If you want to code, do agency consulting. Agency brings the work, manages the clients, do the accounting, marketing and the stuff. You code.

&#62; “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.<p>Is there a citation for this, or a citation for something similar, or is this just a guess?<p>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.

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".<p>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 &#60;i&#62;you&#60;/i&#62; 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.

Great read. I think you're missing a link in there.<p>"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."<p>Did you mean to link to the top coder algorithm tutorials?

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.<p>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.<p>So you could have a very low ratio of offers for reasons other than your interview performance. :)

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.<p>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.<p>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.<p>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.

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.

Bookmarked for future reference to this comment thread and the original article .<p>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 :(

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've only ever had one on-site interview (and I got the job).<p>According to the formula at the top, my value is 0.

"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.