Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
How to Pass a Programming Interview (triplebyte.com)
1020 points by runesoerensen on Mar 8, 2016 | hide | past | web | favorite | 552 comments



Interesting article.

For a while, we had a non-typical interview strategy: A take-home project. We would give the candidate a week or so to work on a smallish project, the requirements of which we would specify. After they completed the project, we would do a group walkthrough with them.

We've hired five engineers over the last three years. For the first two, we did the take-home project. But, then I started to wonder a bit about if it was reasonable to ask programmers to work a weekend on a project. There were a bunch of persuasive comments in HN threads on the subject saying it was unfair -- a job seeker would have to spend an incredible amount of time on each application. And one candidate that I really liked aborted the interview process once I told him about the take-home test.

So I changed the process to something much more typical, with live, in-person coding exercises. We hired three more engineers under this system.

So, how did they compare? Well, the engineers hired when we were doing take home projects have worked out INCREDIBLY well. They are independent and very resourceful. They are excellent.

The engineers hired under the more typical system have not done well at all. We had to let go of two of them, after months of coaching, and the third isn't doing that well.

Random chance plays a huge role here, I'm sure. Maybe we just got lucky with the take-home project engineers. But personally, I think it makes a lot more sense to have the interview process match the work. /shrug


Right there with you; we do take home tests. It's all about the expectation. We outline out front what we're looking for (logical code separation, FP-inspired, sound code), and what would be nice to see (testing etc.)

Mostly, we want to see how well the developer can explain their decisions throughout the process. Maybe they made a shitty decision. If they know it, and explain why it was shitty, that's a pass.

When I joined the company, the exercise took me about 3-4 hours. I don't think that's a ton to ask, especially if you make the onsite interview less intensive (which we do).


I instituted take home tests within my group. We're up front that the interviewee should not spend more than 4 hours on the project and that we don't care if it works.

I am more interested in whether or not I can read the person's code, follow their logic, and if they think about logging, unit testing, etc.

Coding skill, while important, is a very small part of whether or not I am interested in a candidate. Soft skills are a much stronger part of the equation IMO. I could care less if a person can write a recursive function or if they don't know the performance difference between different ways of doing things.


Take-home projects are just a more complete and accurate representation of the development experience someone would have on the job. You have much more data about them than a 30-60 minute live coding session.

Though my current company doesn't do them, I was hired for a previous position from a take-home project and generally support them. As an engineer, I'd rather put more effort into a smaller number of take-home projects than a larger number of live coding sessions...


I really wish that at some point during my CS education I would have realized how typical programming interviews worked and just how impossible they are for me. None of my internships had this sort of stuff and after a long string of failures interviewing after graduating, I can openly admit that being able to solve algorithm stuff just isn't in my blood.

It doesn't matter how many books I read or questions I practice, I just can't work these kinds of problems. If I had an inkling of what it was like beforehand, I would have switched majors or dropped out. Half a decade of hard work, tens of thousands for tuition and a useless degree at the end.

I don't know whether to laugh, cry or jump off a cliff. Maybe all three.


One thing that helped me was to actually implement things that made use of the "algorithm stuff." Not just practicing in front of a whiteboard, but real executable code!

In particular, anything involving a Tree was never very intuitive until I tried implementing a script to search for files by name. Suddenly both the recursive and the iterative approaches made sense. I understood the trade-offs because they applied directly to my work. That opened the door for more complex algorithms, like a Huffman Coder (which I wrote in C, as part of a CS class).

The other thing that helps me in interviews is to just talk through everything I am thinking. It feels like I'm stating the obvious over and over, but a good interviewer will be able to follow your thought patterns and help you along when you get stuck. Also it just helps to hear yourself say things outloud sometimes. If you just stand there silently decoding a problem in your head, the interviewer can't help you and has no idea how you'd approach a real problem on the job.


> actually implement things that made use of the "algorithm stuff."

Part of the problem is that the overlap between "concepts used in technical interviews" and "practical things I would actually implement" is very small. So to take your approach, I'd have to go out of my way to implement something that, in the end, would have no utility to me.

Granted, there are developers out there who do take on really technical projects for fun. It seems like every language has at least one implementation of the GNU `coreutils`, which I'm sure requires at least some algorithm expertise. And there are, of course, jobs where the technical is really important (systems-level, research divisions, etc).

But for the most part, the types of interview questions they ask in no way correspond to the actual on-the-job requirements. I find it strange how common it is to interview web developers (or, engineers whose job will effectively be web development) as if they are C programmers.


> The other thing that helps me in interviews is to just talk through everything I am thinking. ... If you just stand there silently decoding a problem in your head, the interviewer can't help you and has no idea how you'd approach a real problem on the job.

This.

Most important thing for me as an interviewer is for you to talk out loud about what you're doing and what you're thinking.

Just let it flow - all of it.

Programming is often a solitary thing - we go through a lot in our own heads when writing code; e.g. say I ask you to write some code to iterate through some website log files and build a site-map from the URL paths in the log entries. I bet that your mind - even as just a reader of this comment - has already started working out some of the steps to do this ... "load the files, iterate through line by line, some sort of map or DB to store the files, some way to handle duplciates" etc. You might even already have some questions lined up about number of files, frequency of running, shell-scripts vs "real" code etc. Great - but I need to know that you thought about that stuff and I wont unless you talk about it out loud.

Standing silently at the board is not giving me the interviewer as much to go on. Even if you get stuck and/or make a mess of it and dont have a working solution at the end, if you've talked out loud about what you're doing, why you're doing it (and why you're NOT doing something else etc) might be enough on its own to get you pass that interview despite your solution not working (everyone has off days, but show me your thoughts!)


I am sorry that CS education has not worked out for you so far. I want to emphasize the "so far" part of that. I hope that that's hyperbole at the end of your post. If not, I have to encourage you to reach out to friends and family, and maybe take a break from interviews. You can get in touch with me (email in my profile).

There is a huge amount of randomness in interviews. I usually say this as a bad thing, but in your situation now, it can actually be a good thing. Interviewers look for a WIDE variety of traits. Most ask algorithmic questions. But if you do enough interviews, you will find a company that values the skills that you have (I am assuming here that you can program productively). Smaller companies particularly have more variance in what they are looking for. I encourage you to just treat this as a numbers game, and get applications out to as many small and medium companies as you can.

This sucks. But it can and does get better. After you have a few years of experience under your belt, companies will look at you in a very different light.

EDIT:

Also want to add that we made Triplebyte to help people like you. We'd love to have you apply.


There are a lot of people who leverage their CS degrees for non programming jobs - anything from QA, to Product Management, to Sales Engineering. Please don't discount the value of your degree so easily! It's not a waste - you will find a way to leverage it in a related field.

There is a real need for people who understand programming, even if they aren't heads-down, programming geniuses themselves.


Don't get discouraged. Many companies don't do these kinds of interviews.

I've been in almost a dozen programming interviews and maybe only 1/3 of them have taken the shape of programming whiteboard problems.

Many just asked general technical questions or questions about my particular stack with no whiteboard problems.

The remainder of them hardly asked any technical questions at all beyond asking about my experience and background.

I'm not saying that those companies gave good interviews, but there is a lot of work out there for people who can't pass whiteboard interviews.


Calm down, buddy. There are a lot of places where you can apply your CS and software dev learning without having to have an encyclopedic knowledge of algorithms. I would even go so far as to say that those jobs are in the minority.


Are you committed to working as a professional programmer? If not, a rapidly growing area where lots of help is needed is the intersection of computer science and law. Lots of bad laws exist on security and privacy, because the people who drafted them don't have a CS background.

If you do want to work as a professional programmer, try just typing through solutions and understanding them. After lots of exposure, you'll start picking up patterns. Dynamic programming and greedy algorithms are taught so quickly that I'm surprised students generate intuition for them! Feel free to get in touch if you're struggling. Best of luck.


Would working at the intersection of law and CS require going to law school, do you think?


I feel ya buddy - come and join the wacky world of front end development where these things matter less ;)


I wish. I've been asked these kinds of questions for jobs that are just gluing libraries to JSON coming from a backend.


That's our version of Google's "I just write protocol buffers all day" joke.


There are jobs for CS that care about other traits.

System design, user interface design, HCI, software engineering (methodologies, management, architecture), infrastructure, etc that don't lean as heavily on the algorithmic side of CS as they do other aspects.

I know that while interviewing where I work, a candidate's attitude and enthusiasm for programming are much more important to me than their ability to solve some riddle in half an hour. It's not the solution I'm looking for, it's how they get there.


There are jobs where you don't have to answer this crap. You'll probably enjoy working in those types of places anyway. Have you tried companies that use software as a tool instead of being software companies? e.g. banks


> This situation is not ideal. Preparing for interviews is work, and forcing programmers to learn skills other than building great software wastes everyone’s time. Companies should improve their interview processes to be less biased by academic CS, memorized facts, and rehearsed interview processes. This is what we’re doing at Triplebyte.

Thank you! This is a good write up and just like it concludes it's far from ideal.

I'd love to see more interviews based on real-world type things like maybe code a project, come in and explain the architecture, reasons for your data structures, performance questions, etc. Shows how you code and communicate and even better: work with others and maybe walk someone through extending your project or something similar.

Honestly though my biggest issue with interviews is the lack of response with a negative result. For instance one of my last interviews I spent literally months with the company interviewing on and off on the phone and in person. I never heard a SINGLE negative thing from anyone, always answered every question correctly, shot the shit with many of them and everything seemed perfect. Even the team lead asked me not to go after something else because he wanted me. Then I was ultimately declined with the only reason given was "lack of experience". But I had over 12 years of experience, all of the interviewers told me I went above and beyond, said they agreed and liked the solutions I came up with, that I talked through them well, etc etc. I was never able to get anything else out of that.

If something is wrong with a candidate and they don't fit that's perfectly fine. But please give them accurate and detailed feedback where possible. This leaves me absolutely nothing helpful and instead of possibly improving on something I'm left thinking they made a mistake or everyone just simply lied to me during the entire process. I was even exchanging some texts and emails with the lead up until I was given the negative result and then nothing.


  Honestly though my biggest issue with interviews is
  the lack of response with a negative result.
Exactly mine too. However:

  If something is wrong with a candidate and they don't fit that's perfectly fine.
  But please give them accurate and detailed feedback where possible.
Detailed feedback is hardly ever possible. Not only because of a fear of litigation (which is a big factor too) but also because the hiring decision is a matter of balancing so many different points.


> Detailed feedback is hardly ever possible. Not only because of a fear of litigation (which is a big factor too) but also because the hiring decision is a matter of balancing so many different points.

You're right but if a candidate is going to spend hours or days working with your company I think it's the least they deserve. If there is a legitimate reason for not hiring them I'd like to think litigation would be rare.

I mean when you work with a sales guy to buy something and ultimately don't buy you usually tell them why especially if you've been working with them for days. The inverse is true as well if you decide not to sell a product to someone. It just seems weird to me that a person can spend so much time with a company and possibly not even get a good learning experience out of it (when you're left with the impression that everything went as smooth as statistically possible and then you're declined without any useful data how do you know how to improve if at all? Hell maybe someone was just better than you or they decided they needed something else for the job; telling the person could save them so much trouble).

If you want someone to spend hours or days trying to join your company I feel like you should be able to give them feedback. I don't like the trend of big companies not giving anything. Interviewing is a two way street but there is just a weird stigma or legal worry preventing feedback.


There is also a power imbalance that is exploited. You need a job a lot more than the hiring company needs a new recruit.


Maybe? I like to consider myself pretty valuable (ego++) :D

But you're right. I wonder what the statistics are for interviewing; are more people interviewing while they don't have a job or do have a job and are looking. I feel like it has to be the former like what you were suggesting but I haven't seen data either way (not even sure on the logistics on collecting that in a good, representative way).


I totally agree with this. Companies should give (constructive) feedback when they say no. They do not partially out of a fear of being sued, but also because they often don't know really why the reject people. The default state at most companies is rejection. If no one really liked you during the interviews, at most companies this will result in a rejection.

We're doing this differently at Triplebyte. We give everyone we don't work with (who does our final interview) a several hundred word personal email, with an explanation and advice on how we think they can improve.


I think another reason is a fear of starting an endless argument with the candidate, when candidate believes he was actually right and the company made the decision already so it's rather pointless. Not sure how likely is it happen though.


True I could EASILY see that happening. I think the important point is to provide the feedback then stop communication (unless it's like a simple thank you or maybe some clarification you could give them or something). Arguing back and forth with an employer who already made the hiring decision isn't going to help things but it's hard not to be defensive if you think someone is wrong.


Not to excuse your case but a company I work for just got funded and posted a job ad on AngelList, it's been a week and there are 50+ applications sitting in the mailbox. We produce and sell a physical product so one of the founders keeps the operations going, other does biz dev and I do tech. This year alone we need to hire about 10 more people. It's overwhelming. Especially so when hiring the first key employees for roles you don't have experience with.


I've always heard there's a substantial legal risk in saying anything other than 'no'. Not sure how true it is, though.


I've interviewed for a lot of YC companies and companies that frequently post in the "who's hiring" thread and the programming interviews they give are absolutely horrendous. I've had programming test where companies look at my resume and go "so you are very experienced in Ruby? Great, solve these algorithms in C++ for us. I've actually had someone give me a ACM-ICPC world finals question.

I don't have a problem with pushing someones limits and see where they stumble but a lot of these interviews seem intentionally trying to screw you over with the abstract way these questions are asked and the brain teasers they give you.


Hiring talent is a skill most founders do not have because they haven't done it before. It seems like the most egregious oversight ever for an investor to make.. "oh you have a really good core team of 3 people who you've been friends with for years? Here's a million dollars go expand your team with 10 new people".


I've actually had someone give me a ACM-ICPC world finals question.

What company, do you mind if I ask?


Would rather not disparage the company. They do good work they just have terrible interview practices.


I don't think it's disparaging, I want to work there lol


I think the interview questions and process they choose has more to do with the founders' backgrounds than anything about YC itself.


Late to the party but I'll just add in my $0.02

I remember the best interview I had was at a company offering open source software. For the coding components of the interview they give applicants a task (they cherry pick one of the easier ones) from their JIRA backlog and told applicants they've got two weeks to come up with a patch. It didn't matter if the applicant could fully solve the bug/feature, since it's not particularly fair to expect the applicant to be familiar with the ins and outs and gotchas of the system they are working with, but what did matter is that they A) submitted something, and B) could talk their way through their thought process and how they arrived at their current solution.

This sort of process really clicked with me. Obviously it's not as straightforward for some organisations that may offer proprietary software, but the process could certainly be adapted for a lot of organisations, in my opinion.


This is interesting because without knowing how their system is architected or designed, it allows you to state assumptions and you can use that time to assert knowledge of best practices of a given framework. Sort of an implicit test for depth though.

Edit: I missed where you said open source company. Though I still think this thought for a closed source company that uses open source pieces (like a web framework) could be useful.


What if designers had to go through a similar interview process? Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect? Why is red font on blue background bad, please justify? That would simply be hilarious.


> Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect?

"Please arrange these colors in complementary, analogous, and triadic color schemes". This is color theory 101 -- something every visual designer should now.

> Why is red font on blue background bad, please justify?

Again, a valid question. It all depends on the brightness/saturation of the colors, and how much contrast is between them.

Edit: Obviously these are ridiculous and unnecessary interview questions because frequently a designer provides a portfolio of work that demonstrates their skill. This may not be possible in a programming interview if the candidate has been not been working on open source code or side projects.


Many (most?) times you provide samples for a software engineer job, they don't get looked at or serve to provide much help to your cause. That you have samples seems to help get an interview but after that it's at if the samples were never even provided. I link to many samples right from my resume so interviewers don't have to depend on HR or whoever passing on extra files. I've often asked the interviewers, "just curious, what did you think of my samples?" Almost without exception they say sheepishly say something like "sorry, didn't have time..." Which is probably true but geez you'd think a portfolio would matter more and merit a required look.

On a related note, I love the story about the Homebrew guy getting rejected by Apple because he couldn't invert a tree or some such thing. Even if it was sensationalized (or plain false for that matter), we aren't even surprised by headlines like that anymore given the current interview climate.


When interviewing, I'm interested in seeing the process a candidate takes to get a result, not just the result. I like looking at code samples to get a feel for code quality and software engineering practices (everything from variable naming and program structure to Git commit messages)

Real-time coding during the interview shows me how good a candidate is at collaborating when solving a problem. One good indicator is asking follow-up questions to make sure requirements are clear. Other things to look for are, e.g. TDD, which can help solve a problem with predictable correctness and pace. I have interviewed quite a few candidates who throw a bunch of code into the editor and start pseudo-randomly tweaking the code to try to make it work -- this is not a recipe for successful problem solving. Some aspects of code quality can be evaluated during the interview as well, which probably explains why many interviewers don't bother looking at code samples.

It's important to ask for a solution that can be easily deduced -- trick questions are bad for both parties, because the candidate is often stumped, and the interviewer thinks they are bad because knowing the trick makes the question simple. Many classical algorithmic questions are "tricky" in this way.

The questions also have to be "real world". Like you mentioned, you can be a successful engineer and not know the specifics of inverting a tree. If you can correctly recognize the need for the algorithm and implement it from pseudocode, you have solved your problem, which is what engineers are paid to do.


I have a portfolio of past work (I made games that are still available, I even bring an iPad with them playable on them). I still get asked a ton of technical questions, and I'm lucky if I can even show them my past projects, because they never trust that I was the actual programmer on these projects (even though in the credits for a couple of them it says 'Lead Programmer: [cableshaft]').

It's a totally broken perception, and it needs to end. We're one of the few professions that are routinely asked to prove our abilities in every single interview we attend. It wastes so much time on both ends and there needs to be a new way.


Why wouldn't they trust you? Sounds bizarre. Especially if you're listed in the credits.


Well really, they don't even usually let me get to the point with showing my work where I can show my name in the credits. My point is they could have checked that ahead of time and seen my name in the credits if they wanted to verify that I actually did what I said I did in my resume, and they don't.

The handful of people I've had to interview I always checked the interviewees portfolio ahead of time if it was available.


Perceived contrast depends on media. The only question designer answers in real life - is he ready to subdue his taste and skill to PMs whim or not.


I've had interviews with some notable startups that gave a take home design test, such as here is problem x now design a solution and show your process. I did it once in my naive young years when I really wanted to work for a specific company. Now, I'm fine with telling them I deserve to be paid for a day's work if we're going that route.


You jest, but my family members in the restaurant industry asks similarly technical questions of a potential chef. Stuff they may not need to know on a day to day basis, but is the technical knowledge of their profession.

I discovered their interviews and mine are largely the same. Technical questions, some time-management questions, and some soft stuff to make sure they'd fit in the team.


The typical Silicon Valley style interview equivalent for a chef would be to have said Chef participate in Chopped. Plenty of professional chefs do awful in Chopped, because the required skills have little to do with what you need, day to day, in a kitchen. However, it's easy to judge. What is missing is the correlation between a hard test and actually on the job performance.


Designers have portfolios where the interviewer can see the previous work they've done


Many developers do these days too, if they work on open source projects, or if they have significant side projects that are open source.

I definitely look at open source code of job applicants, and sometimes a part of the interview is asking them about it.

Of course that has downsides too, like anything.


You say this in jest, but I would expect a competent designer to be able to answer these (or similar) questions.


> "That’s exactly the point. These are concepts that are far more common in interviews than they are in production web programming."

The list includes things like Big-O analysis. While, formal analysis is certainly not a day to day occurrence of most programming, knowing what the runtime complexity of the code you are writing is almost always important.

While, I generally don't care for most algorithmic problems, I am honestly concerned when someone can't tell me that something runs in O(n^2) and good probably be optimized.

EDIT: I should note, I'm not necessarily looking for them to use precise term here, but they should be able to clearly articulate it.


So, I see where you are coming from (I actually love academic CS). But the VAST majority of the programming work out there does not require any Big-O analysis. It just does not. It's used as a tool in interviews to (essentially) look for rigor. The problem is that this harms people who are rigorous as hell in low-level details of JS and V8 (something I'd posit is actually more useful to many more companies), but never studied academic CS. There's nothing wrong with valuing the skill of complexity analysis. But there's a mismatch in how common it is to look for this.


    But the VAST majority of the programming work out there does not require any 
    Big-O analysis.
Your point is simultaneously valid and irrelevant. The vast majority of programming doesn't involve any Big-O analysis. But if you can't do Big-O analysis, there are problems where you will be stuck. Your code will be running slowly and you won't know why, and all the micro-optimizations in the world can't make a O(n^2) algorithm run faster than an O(n) algorithm on even a moderately large data set.

To make an analogy with driving: the vast majority of driving doesn't involve parallel parking. But you still need to know parallel parking to pass a driving test.


You don't need to know how to prove a big-O to optimize an algorithm. Anyone who can think about what their code is doing will have at least some sense of how much it is doing.

Honestly, I don't think calculating the O(f(n)) is ever worth it outside of academia. Intuition is only slightly worse, and it is just so much time-cheaper.


    Honestly, I don't think calculating the O(f(n)) is ever worth it outside of 
    academia. Intuition is only slightly worse, and it is just so much 
    time-cheaper.
Sure. I've never been asked for a formal mathematical proof of the Big-O complexity of my algorithms in an interview. And, as an interviewer, I've never asked. Intuition is exactly what interviews are looking for. If an algorithm has a nested for loop, and the inner loop is traversing the full data set, you should be able to say, "Oh, yeah, that looks like O(n^2) time complexity." If an algorithm is storing every element of a data-set in memory, you should be able to say, "That's O(n) space complexity."

Big-O notation, in practice, is a handy shorthand for talking about various classes of algorithms, and ranking them in order of how much time/space they take.


But if you can't do Big-O analysis, there are problems where you will be stuck. Your code will be running slowly and you won't know why, and all the micro-optimizations in the world can't make a O(n^2) algorithm run faster than an O(n) algorithm on even a moderately large data set.

That's actually incorrect. Not knowing Big O does not prove that you do not know how to optimize an algorithm.

However, it does mean that you don't speak the common language of computer science, that would allow you to easily communicate the effect of your optimizations to other programmers.


>To make an analogy with driving

The whole point of the argument is the difference between what's on the test and reality, though. And simply "being on the test" doesn't make it valuable.

Needing to parallel park on the driving test has little relation to you being a good driver. In reality, your actual ability to park is hardly relevant, because you could avoid those parking spaces, or even half-ass it by driving in forward, or whatever.


> But if you can't do Big-O analysis, there are problems where you will be stuck. Your code will be running slowly and you won't know why, and all the micro-optimizations in the world can't make a O(n^2) algorithm run faster than an O(n) algorithm on even a moderately large data set.

This may be a result of the domains I have worked in, but I have never encountered a situation where I could change the order-of-growth on an algorithm. In fact, most algorithms I have worked with have been defined by non-computational performance.

I don't know formal complexity analysis, and personally think the resolution of Big-O is far too coarse for practical analysis anyway. I can still look at any piece of code and give you approximate polynomials for its runtime, memory requirements, and other computational features.


> Your code will be running slowly and you won't know why

Ever hear the expression "tools, not rules"? Using big-O analysis while coding is almost the textbook definition of what makes someone a bad developer.

That's of course not true if you're developing some foundational tool meant for other developers like Redis or whatever, but for the average developer doing complexity analysis at work is probably a red flag that they're prematurely optimizing their code, using company time to work on a side project, or otherwise doing something that's not contributing to the success of the business.


You do not need to know parallel parking to pass a driving test, in Illinois and probably many other states.


I have more than once in my professional career run into programmers who tested on small inputs and assumed the timing would scale at least close to linearly.


Fair point. But is it not much more common to encounter a programer who cannot break a complex system into loosely coupled components? Or who does not use consistent naming conventions? Or who is smart but lazy? I'd rate all of these as equally important things to try to evaluate in an interview.

I am a strong believer in looking for strength in an interview. Someone really rocking complexity analysis is a strong positive (shows that they are smart and pedantic in a good way). But so does clean, smart code and great loose coupling.


Oh, I'd never disqualify an interviewee purely for not knowing this stuff, but it is useful to know.

[edit]

Also, I care far less about whether they can solve some problem on paper about asymptotic complexity than if they have some sense of what it means. Someone with little formal training who discovered the classic python "Add to the end of string" algorithm is N^2 and figured out a working knowledge of N^2 vs. N is better than someone who memorized a bunch of math but can't apply it because it went in the "math box"[1]

1: http://zenoferox.blogspot.com/2009/10/deep-inside-math-box.h...


There are a lot of situations where a "worse" algorithm will be significantly faster that another algorithm that's faster in theory, due to memory locality. In practice, it is very hard to know beforehand what parts of your program will scale and what parts won't.


This is categorically untrue if you are talking about large numbers and asymptotic complexity. It is true that algorithms with a constant factor larger number of operations may have such properties, but O(n) will always beat O(n^2) eventually, and in nearly all real-world cases at a fairly small n (1000 L1 cache accesses is slower than 1 memory access so n=1000 will be enough to counter any locality issues).


> But the VAST majority of the programming work out there does not require any Big-O analysis. It just does not.

I just don't agree with this. Maybe it's true for people doing strictly front end web development (i.e. pure HTML and CSS), but basic algorithm analysis comes up all the time when writing any kind of real code.

I think your attitude is actually part of the reason software sucks so bad nowadays. People act like efficiency doesn't matter at all and Big-O is useless and then turn around and act surprised when browsing a website causes Firefox to use 800 Mb of RAM, or their top of the line server only handles 50 connections a second. There's a connection there.


If someone else is well versed in complexity then it's fine to hire a js person with no knowledge of it.

If you're expecting the candidate to produce performant code, they may need said knowledge.


I'd have to disagree. I think the interview process desperately needs an injection of pragmatism. If the actual job never requires Big-O analysis, then asking it during the interview is a waste of time. I've never had to do Big-O analysis in the real world, but I have had to fix N+1's. Ask about that.


Maybe I'm missing something but isn't N+1 the difference between O(1) and O(n)?

Edit: Anyone want to explain how I'm wrong rather than just downvoting?

Edit 2: Understanding a N+1 problem is the equivalent of understanding the difference between O(1), i.e. fetch all data with a constant number of queries, versus O(n), i.e. the number of queries scales linearly with the number of elements.



Yes, and when you solve your N+1 problem, you've replaced a O(n) algorithm with a O(1) algorithm.


Because your question makes so little sense that it seems sort of like a joke.


Thanks for your comment, I've tried to clarify things.


I strongly agree here. I wouldn't want someone to implement the "get it done version" of a request, where I am expecting a rushed implementation to be O(n^2), then somehow this dev produces an unmaintainable mess that performs in O(n^2n+api.Google.com*n).


It seems like there is a large middle area of concepts in between low-level algorithms/data structures and high-level system architecture that are left out of many of these interview prep guides:

* Principles and patterns of object-oriented (or functional) design

* Relational (or NoSQL or analytics) database design

* Unit, integration and system testing

* Logging, profiling and debugging

* Source control (e.g. branch/PR/merge flows)

* Deployment and devops

Do these subjects really not come up in some programming interviews?


From my experience, if they do come up, it's only because I was asking them what they used. I don't think I've ever been asked about any of these topics, with the exception of database design.


It's a shame, since these topics could make for a rich conversational interview that probably has more to do with the actual job than whiteboarding an algorithm. Just taking source control as an example, a hypothetical interview question could be something like:

"You've been assigned to implement feature X in our product. Assume that the specs are clear and you have a pretty good idea what code you are going to write. Also, assume that your teammates Joe and Jane have been assigned features Y and Z respectively with roughly the same due date as your feature. Ideally, describe how you would make your changes, test them and coordinate with your teammates to get all three features merged into the master source code."

Obviously a lot of details are missing, but they can be fleshed out in conversation (during which the interviewer should also describe the current process used on the team the candidate is being hired for). This would give both parties some insight into experience and expectations.


Sure they do. "Model a parking garage in code" or "design a database with customers, orders, etc" are classic interview questions.


What is expected from something like "model a parking garage in code?"

Something like a garage class that has properties like numberOfCars, maxAmountofCars, maxHeight and methods for insertCar(), removeCar(), isGarageFull() ?


Probably that and, I don't know, maybe modeling a Car class and various subtypes that inherit from it?


Probably keeping track of how many parking spots are available as cars enter/exit, and denying entrance if you're full up.


When the the job interview become a quiz show? I've spent plenty of time on both sides of the interview table. Sure, I've asked problem-solving questions. It was never to pay stump-the-candidate or to see if they could come up with some CS proof on the fly. It was to examine their approach to problem solving, and the way they interacted (back-and-forth questions). The right answer never entered into it, and if the interview question has a "right answer" then it is probably a lousy interview question.

I knew a college recruiter at Large Semiconductor Maker. She had been around the company many years, starting out as a mask designer. She knew nothing about engineering, but had worked with engineers on a daily basis for 10 years. She was great as a recruiter for new-grad engineers. One of her favorite questions was: "My back yard is 60 feet wide, and I want a brick fence across it. How many bricks do I need?" You would be surprised how many people never said another word, worked out a numerical answer, and told her the number. boggle. The point of the question is to find out how good the candidate is at uncovering and understanding the customer's wishes and what the customer's vision is of the desired end result.

Somewhere along the line there has evolved a group of people who never learned how to interview job candidates for problem-solving oriented jobs. A quiz-show lottery is a lousy way of finding out if someone can flesh out under-defined problem statements, replace a stupid problem statement with a better one, and creatively explore the dark corners of a solution space.

Let's stamp out the quiz show now.


> If you’re interested in what we’re doing, we’d love you to check out our process.

Well, I say this as someone who was apparently blacklisted on TripleByte despite ostensibly getting a perfect result on the programming taks, getting an interview would have been a start. Or at least getting told what and why it happened, instead of trying to request a pre-screen phone interview without result over and over until I "got the message".

I understand the TripleByte team is perceiving problems that exist in the programmer hiring process, including the fact that interviews are not necessarily designed to gauge a candidate's qualities as a programmer. I also understand that you probably can't change the status quo in that space without first establishing yourself firmly in the existing field. But my own experiences make me skeptical about how transparent TB really wants to be.


>Similarly, most programmers just want a good job with a good paycheck. But stating this in an interview is a mistake.

Just like everyone only hires the best, they only hire people who are "passionate" about <blub>.



Wow! I regret I have but one up-vote to give for this comic.


> Use a dynamic language, but mention C

I take issue with that recommendation. You should use whatever language you feel most comfortable with. If it's C, use C. If it's Java, use Java. You don't have the luxury of an IDE or anything like that, so you need to have enough of the language in your head to write a program without looking something up.


I haven't used C professionally in a long, long time, but I naturally gravitate to it when doing technical interviews.

One of the reasons, I think, is that the language itself is "small" enough you can actually hold most of it in your head.

That, and for certain problems it gives you the opportunity to demonstrate understanding of things like pointer arithmetic that you wouldn't have if you used Java. I remember an interviewer at a Java shop being impressed a few years ago when I used C and pointers to reverse a string in place (I wasn't very comfortable with Java back then).

All that said, I'm getting old and cranky and whiteboard interviews are starting to get really annoying.


How I did it for a Microsoft interview: cram for a weekend with a good algorithms text book. I do UI development where 99% of the work is figuring out the UI framework but the study session definitely got me into the right mindset for interviews.


It really makes the whole thing feel like school right? Every time I'm on the job hunt I have to study all the stuff I never actually use while I'm working.


I still think you can learn valuable things and become a better coder this way. Preparing for a Google interview was eye-opening for me, I learnt a ton of things that I immediately started applying day-to-day.


Another great post from Triplebyte, but I am confused about their model. Why would candidates want to apply to Triplebyte, if they still have to go through the companies' full interview process on top of the Triplebyte process ?


If you apply to Triplebyte you don't go through the full interview process at the companies we introduce you to. You skip the technical phone screens (most companies do 1 or 2 hour long phone screens before bringing candidates onsite) and go straight to on-sites.

Where we can really save time is focusing on the matching process of candidates to companies. Interviewing is tiring and we find candidates often stop talking to companies they were initially excited about because they're exhausted from interviewing (usually after 4 on sites) and just want to accept an offer

We wrote before about how much hiring preferences vary across YC companies (http://blog.triplebyte.com/who-y-combinator-companies-want). By using data we get from the Triplebyte interview, we can send you to the companies where you've the strongest likelihood of passing the technical onsite. The result is getting the best set of offers to choose from, rather than picking from what's available before interview burnout sets in.


I don't really see how you are relevant if I still have to go through a technical interview - it still means the interview process takes way too much time and I am better of finding a way around it.


Usually the only way to circumvent the technical phone screens at a company are if you're coming in through a strong referral. That's great if you already have a strong network, not so much if you either don't have personal connections or a resume with the credentials recruiters are trained to look for.

Just focusing on interviewing time, if you're talking to 3 or more companies that's approximately 3 hours of technical phone screens (usually repeating similar problems). With Triplebyte, you interview for 2.5 hours and save 3 (or more as you talk with more companies).


I think the main draw is that Triplebyte will get you past the initial screening mechanisms. This is particularly useful if you can write good code but have no formal education or otherwise cannot put together a resume.


Triplebyte is also great interview practice that happens over the net. You can do pretty intense (2.5 hour?) interview without missing a day of work if you are on the east coast.

You can schedule the interview by first taking a simple quiz for like 15 minutes and then selecting from a calendar, you don't need to negotiate with a person, go back and forth, etc.


As a junior in university looking for internships this summer, I can attest that going through the programming interview process is a pretty foreign process compared to traditional interviews. I just stumbled through my first programming interview last week.

I believe in the future point 3 will be especially helpful. The hardest parts for me were trying to figure out how appropriate it was for me to be rambling as I coded (something I'm not used to doing at all), and trying to understand what was and wasn't appropriate to ask the interviewers about my code.

Time to brush up on breadth-first search and hash tables!


What I've realized is that interviews are like anything else in life. People will tell you to expect x, y, and z and your own experiences will look like a, b, and c. Interviewing, like a lot of other processes, is something that can be "hacked".


It gets better! After a few interviews you start to get the hang of things and can begin to read the situation and understand what's in your best interest to do. Some interviewers like to test your knowledge of C.S. curriculum like you just mentioned, others prefer a friendly person who isn't afraid to ask questions and be honest about what you can and cannot do, others prefer both.

It gets better.


I definitely will be far more prepared for my next programming interview from the experience I gained going through the process once already. It's just sad that my first interview process had to be with a higher-profile company that would have been a ticket into silicon valley. Those interviews don't come easy in the first place. Haven't heard back from anyone else yet, but I trust they'll come along.


You'll look back at it in a year or so and laugh. Personally my resume and interviews were absolutely atrocious (I thought an online resume builder was a good idea..).


I've built alot of stuff and apart from hash tables, never really needed to understand:

  Hash tables
  Linked lists
  Breadth-first search, depth-first search
  Quicksort, merge sort
  Binary search
  2D arrays
  Dynamic arrays
  Binary search trees
  Dynamic programming
  Big-O analysis
I guess it depends if you are going for a job that REQUIRES these techniques then yes it is important, but for web application development - even sophisticated web application development - not needed.


You should know a number of things on this list if you do back-end webapp development, particularly for large/hairy enterprise stuff. So maybe you are referring to front-end only.


Almost all of those are handled by a standard library, so why bother. When issue arises then you look for a book/website and fix the problem. Source: Doing backend (and some frontend) web stuff for the last 10 years.


Sorting algorithms can be a little arcane, but the rest of that stuff should be fairly intuitive to anyone with a CS education.


When I interview candidates I sit with them for half an hour or so to get to know them. Then I give them purposely broken, poorly written piece of code which I tell them to pull apart. This proves incredibly effective as even if they miss some of the more obvious errors I can at least point them in that area and then see if they can see the problem on their own. There are about 100 different things to talk about so it really gives me an idea of the level they are at, and also the type of programmer they are; passionate, lazy, smart, meticulous, inexperienced, confident etc.

Then if I feel they are worth a second interview, I get them back to sit with me and my team for the day to see how they fit in with the team. Then all being well I offer the job.


Love this idea, doesn't take a lot of time and I think it's a pretty good measure. Anyone have anything against this?


Programming interviews aren't pass/fail, they're match/no match. Imagine how it would read if this said "how to pass a first date".


But they're conducted as if they're pass/fail -- quite often before any real (two-way) discussion can take place.

Imagine if prospective dates gave you a 4-hour take-home test before making eye contact. That's actually the way many employers like to start of the conversation process with candidates, these days.


That is sort of the premise behind a whole slew of very successful dating apps isnt it?

Spend several hours perfecting a profile to increase your odds?


If dates involved asking questions with a definite right answer, that article might exist.


Interviewing should now be part of most CS educations, if not its own three class/semester course. Its that weird, and that important.


Isn't it already? I feel like all of the interview questions come down to things you learned in a Data Structures or Algorithms course. I suppose the design questions aren't necessarily taught in school but presumably you would learn that as you program more.


But the people who'd need that the most are the ones furthest out of school.

I shudder at the thought of ever having to do another programming interview. Well, alternately shudder and laugh. What a joke!


It's my belief that the best experienced programmers don't have to go through programming interviews. Even if you don't actively make an effort to network, you have a network of people who know you're good enough to outright hire without the whole rigmarole.

Companies who aren't finding people like this are missing out on many of the best.


> Even if you don't actively make an effort to network, you have a network of people who know you're good enough to outright hire without the whole rigmarole.

Not sure why you think this is the case. It is really easy to end up with a worthless network (I managed), and many larger companies insist on forcing every applicant through the HR hiring funnel for compliance reasons.


It's been my whole career. Yeah, I've had to go in and do the grip'n'grin interview and talk to people for a couple hours to make sure I'm not a martian or something. But every job has always come about because someone at the company either knew I was competent (from working with me in the past) or asked someone I knew who told them I was.

I've never had a job that involved whiteboarding or any sort of coding test.


Yes, but why do you think your experience generalizes to anyone else?


Then we shall call them a sales (or whatever) training, not the CS.


Alternatively we could come up with a better system for interviewing. Instead of concentrating on being able to remember algorithms and write them out in a completely non-normal way (white board) we could, instead, give them a very small project to do then have them come in and explain it, walk someone through extending it and / or work through a problem together. You'd get real experience seeing how they write their code, work with others and their ability communicate.

Drilling someone to do tree traversal or various Big-O exercises doesn't exactly come up in the real world. Yeah performance and understanding data structures is important but that's why you give them something real, see what kind of data structure they come up with and why and go from there.

Well at least in my opinion. I've interviewed a lot of people and have been interviewed myself. I've unfortunately haven't been able to gather the data to see how effective my method is BUT I like it a hell of a lot better.


> we could, instead, give them a very small project to do

one objection to this I've heard is that it disproportionately disadvantages people who don't have the free time to do it


While true in the end I would expect it to take less time to do a small project, come in and review / work with it than the typical 1-2 days of interviews. Not sure if it would actually happen that way in practice I admit.

I'd like to try it and attempt to gather data in either case.


We used to have something called the "recitation class" one hour a week for solving homework problems out loud. I was under the impression these were making a comeback as classes "flipped" to watching the lectures outside of class. People would skip recitation sometimes because they werent learning new material like in the lectures or doing their problem sets which took enough time already. If these were made more mandatory somehow, they'd be like interviews.


I'm sorry but could someone explain who tripplebyte is and why they are so "precious"? This blog post in my opinion is symptomatic of of this bizarre silicon valley interview culture. This whole "how to ace the programming interview" bullshit is really disturbing. Are you looking for people who are good at test taking or people that can produce good product? Yes CS fundamentals are important - data structure/algorithms, but I'm much more interested in whether a candidate understands the problem space and can reason about it. I want to know about systems they've designed in the recent past why they made the choices they made. Being able to code up Kruskal's spanning tree perfectly on a white board while being timed is a neat parlor trick but if you don't understand the bigger holistic picture of systems I don't think it means that much.

As far as these take home assignments go, I find this a disturbing trend as well. Especially egregious is telling someone there is a time limit on your working for free. If you're going to pay me for my time awesome lets talk, otherwise lets maybe look at some code I've already written.

This industry seems to get more up its own ass every day.


From their website:

We help programmers find great jobs at Y Combinator startups. No resumes, just show us you can code.

* Our Company

We believe hiring should be about what you can do, not what you say you can do. Our mission is to build the world's best technical hiring process.

We don't care where you went to school or which companies you've worked at. We only care if you can code. If you can, we'll do everything we can to find you the best startup to work at. *

That mission statement plus the blog post means that they are recruiters for financially unstable companies (aka startups). Makes the blog post that much harder to believe since startups are beggars not choosers when it comes to hiring.


The practice section doesn't mention anything other than the book. Are there any other resources that people use to prep for an interview? Looking for something that tests algorithms and data structures more than solving tricky problems.


I think Cracking the Coding Interview is very popular if you're specifically targeting interview questions. There's also the accompanying website www.careercup.com

I personally also like to do problems on hackerrank, SPOJ, or Code Jam, but are probably overkill (especially Code Jam) as they're much harder than what you probably should expect in an interview. Still, I find that it helps my nerves when I solved harder questions because then the interview questions seem much simpler so it might help you too.


I use a combination of Coursera and Udacity to learn the algorithms, and Hacker Rank to find places to implement them.

I actually just cruised through this course and found it super useful. Edit: By cruised I don't mean did it easily but instead just watched the videos, because I was cramming whenever I could fit time in.

https://www.coursera.org/course/algs4partI

It covers Binary Search Trees pretty well and some other things on the list. I also really like this teacher.

https://www.hackerrank.com/domains/algorithms/warmup/difficu...


My go-to resource for practicing is http://leetcode.com. There are a lot of questions ranging from easy to hard and an online judge to check your solution by running test cases. If I remember right, there's also a discussions section. They hit a lot of classic interview questions that help you prepare for those questions that wrap those classic problems in obscurity.

For a refresher on algorithms and data structures, I also like the Harvard CS50 videos up on YouTube. They walk through sorting algorithms and cover the bases of various data structures.


I've had fun practicing on http://www.codewars.com/

You can choose your languages and it's all wrapped in a nice leveling-up game style. You pass and rank up based on your solutions to predefined community problems, and have a test-driven approach enforced in the editor.


If you're looking for a visual guide with code in (c++, java, python or javascript), check out Coderust (https://www.educative.io/collection/5642554087309312/5679846...)


I've been interviewing in the past month as I need to find a new role and it is just crazy.

It is SO random, a lot of useless questions, small startups having a long hiring process harder than the big 4.

Just one example: I've received an offer from one of the big 4 after going through their process. I was lucky in the questions - things I had studied.

I also applied for around 40 start ups / small companies. I made through the final on-site interview in only 5 of them. Lots of white boarding, silly technical questions that don't proxy to day-to-day work and etc.

I really think that passing in a process in a company like Facebook and not passing in other companies working in a much less complex environment says a lot.

Another thing that annoyed me a lot was that in some companies, when I froze upon a problem and was in a dead end, instead of them trying to help me or give constructive advice they would just keep adding pressure. It's craaazy. You're in a white board in a position of someone judging you in a on-the-fly-absurd-problem and the guys is trying to talk you down instead of help.

Crazy stuff.


Perhaps the smaller/scrappier startups are trying to have more rigorous processes because small startups don't have as much resources to train new hires when compared to 'big 4' companies, so they really need engineers that can do it all themselves, quickly and under-pressure. They also may be more risk-averse when it comes to false-positives, because if your entire engineering team is 5-10 people, you're much less likely to be able to afford to get it wrong and hire someone that won't end up working out.


It's always been strange to me that tech interviews tend to check for basic CS, rather than deep engineering.

When was the last time you had to implement bsearch() in a real project?


It is widely believed that if you are able to do deep engineering you should also be able to get the basics right. It takes a lot of time evaluate a real world project and most of applicants would not agree to do one anyway, so basic CS is the easy approximation.


What makes implementing qsort/bsearch/etc "the basics"? It seems rather arbitrary, and it mostly measures how well you are able to recite from CS books.


The weird thing is that some of the "basics" aren't even particularly basic. Finding cycles in a linked list was an open research problem for a while. One can argue that interviewees need to know about the Tortise and Hare algorithm, but it's crazy to think that someone who hasn't should be able to come up with it on the spot.


They are the stuff you should understand anyway if you build software and are easy enough to figure out in an interview session if you have any analytical skill.

On the other hand, many so-called real world questions measure only how well you are able to recite from API documentation of interviewer's favourite framework or at best the language specification.


Yet it is certainly false that if you are able to get CS basics right, you will be any good at deep engineering.


I hope you mean that:

It is certainly false that if you are able to get CS basics right, you will NECESSARILY be any good at deep engineering.

There are people who get the basics right and are good at deep engineering. The question is whether one predicts the other.


Just out of curiosity, can you give examples of people who have done so-called deep software engineering but stumble at the basic CS concepts?


Right; my "false" applies to the entire statement (if p then q).


A large number of bad things influence interview decisions (credentials, targeted practice, how well you know the specific algorithms that come up again and again in interviews). I hope that more programmers getting better at interviewing skills will help move companies toward measuring actual programming skill.


My credential represents hundreds of hours of programming projects over several years. For that reason alone it is a much better signal than an interview will ever be.

It also establishes depth and breadth of familiarity with a variety of fundamental topics demonstrated through exams and large programming projects: program design, networking, operating systems, security/cryptography, team software engineering practices, algorithmic techniques and analysis, etc.

You fundamentally cannot assess this as well as my alma mater can because my alma mater has 4 years of me working under realistic conditions (laptop, internet, colleagues, deadlines on the order of weeks) and you have, what, 5 hours of me standing at a whiteboard?

Credentials are seriously underrated.

CS programs are not created equal. If you find that candidates from a particular school aren't necessarily competent, then you should value candidates from better, harder schools. If you find that candidates from well-respected schools aren't necessarily competent, then you should respect them less (US News isn't always right) and respect other schools more.


You're not being compared to people who lack hundreds of hours of programming projects. You're being compared to people who have that same experience, either at a worse school, or on their own. Credentials correlate with being good, absolutely. But many, many more people lack credentials than have them. This means that there is a large number of great programmers who don't have them (I think a larger number than who do). There are also bad people with good credentials. Strong filtering on credentials harms companies who miss good programmers, and harms programmers who can't get jobs. Using credentials as one factor among many in a screening step, however, makes good sense (although we don't do this at Triplebyte because we want to force ourselves to get as good at possible at directly measuring skill).


>You're not being compared to people who lack hundreds of hours of programming projects.

I don't think that is quite right. Interviewers claim coding interviews are necessary to weed out the large fraction of our industry that cannot write code at all. If they cannot code, then they did not successfully complete a good undergraduate program's worth of coding projects (they cheated, rode on the coattails of group members, were graded way too easily, or something). Otherwise they can code.

>Strong filtering on credentials harms companies who miss good programmers, and harms programmers who can't get jobs.

On the other hand, strong filtering on whiteboarding unnecessarily filters out people who don't do well under that kind of pressure but may be great programmers given a computer and a more realistic deadline. They also privilege people who have optimized well for whiteboard interviews but may be destructive in the longer term.

Which is why the optimal solution seriously considers both factors. (I'm arguing with you because you called credentials influencing hiring a "bad" thing).


Credentials and prior experience are used in all companies to establish your title, level, salary and position - things that actually matter when you start working.

Coding interview is just a baseline that everyone hired is expected to exceed. In most companies it does not really matter how well you did in coding interview - the only thing that matter is that you passed it. After that coding interview results are not really considered when choosing level (other than for junior engineers). Nobody expects senior engineer to be much faster when coding simple loop but he sure should be able to code it.

On the other hand design and behavior interview results are often have much more influence on final salary and level.


Your experience doesn't directly translate to what is relevant for the company you are applying to though. You may _think_ it does based on their general description, but it may not. One of the questions we give has you design a data model to store certain information and then query it out. It's not complex at all, and they are in full control of the design. You'd be surprised how few people with 15 years of experience in senior level positions are unable to query out the information using a data model they designed themselves.


I guess that's possible, but I think you might also be surprised how much better people are at SQL when they have access to references and ability to develop iteratively with feedback from a real computer.


Obviously I'm biased because I'm building a company around it (interviewing.io), but I don't think biases around credentialing are going to go away until interviewing is anonymous.

The other stuff is harder to crack. I'd really like to see interviews that are more tightly anchored to real work/layer complexity by building on themselves, etc etc.


A candidate has an impressive STEM field educational background, say, Bachelor's, Master's, or Ph.D. degrees, has peer-reviewed publications of original research in the STEM fields including in computer science, has taught computer science in world famous US research universities, has created original, fast algorithms in computer science, has written successful software for a wide variety of applications in a wide variety of programming languages, and, then, somehow needs to learn some additional, special lessons on "how to pass a programming interview"? Such an interview is by the Queen in Alice in Wonderland or from someone well qualified in computing?

Why the heck the needs for special lessons to do what the candidate has been doing successfully for years?


Because passing a programming interview is not what the candidate has been doing for years.

Interviews are artificial, stressful situations which in many cases do not resemble what you will actually be doing at your job.

Like well-known blogger Steve Yegge once commented about Google's interview process, sometimes it gets so bizarre that two interviewers in your queue wouldn't have hired each other! Focusing on the details one interviewer likes will make you lose points with the other. He calls this phenomenon "the interview anti-loop".

I guess being well-drilled about common questions and tricks helps counterbalance some of the pitfalls of the interview process.


So, right, programming interviews are from Alice in Wonderland and not about programming.

Gee, I'm glad I'm programming, for my own startup. Wait while I ask my founder, CEO if my programming is good -- got an answer back right away, my programming is fine!


> So, right, programming interviews are from Alice in Wonderland and not about programming.

I don't understand your irony. No-one is saying that. We're saying that programming interviews are often not ONLY about programming, and unfortunately the parts NOT about programming tend to overshadow the parts that are. Therefore, interviewing requires preparation.

Are you bitter that programming interviews are like this? If so, fine. So am I.

Are you saying that programming interviews are NOT like this and do not require training for? You are mistaken. It's a fact of the world, whether we like it or not.

Or are you saying you lucked out and didn't have to go through this hell? If so, congrats! It's known to happen. But still, it pays to be prepared for the average case of difficult, stressful interviews.


I'm saying that programming interviews have descended into tea leaf reading.

People with obviously high qualifications are being rejected for no good reasons.

The situation was not always so.

Apparently the people doing the interviews are more interested in being nasty than hiring people to get more work done. For this situation to hold, there has to be not much demand and a big supply. So, the process is free to descend into totally silly games. It's the Queen in Alice in Wonderland and "Off with their heads".


Academia is not industry programming. So the candidate had highly specialized knowledge and skills, big whoop. Guess how much of my original academic research I use? None. If that candidate wants to use those skills they should go into research.


> The good news is that interviewing is a skill that can be learned.

When I hear folks complain about programming interviews, I point to that.

The month I spend gearing up for coding interviews usually guarantees me a job, that offers at minimum a $10k raise. I consider that a very good use of my time.


There is a problem. (job interview are selecting incompetent people)

Ho, but there is a solution to walk around the problem of job interviews being unable to select good developers: so let's avoid investing in being a good developer and fix the problem at hand and just be good at interviews.

Problem solved.

Brilliant!

Are not interviews kind of de facto selecting scammers by giving them an unfair advantage, then?

Is it not causing a problem of credibility of the profession, hence the of the value of our earnings?

Growth is shrinking, recession is coming. Will they keep people whose values are uncertain when time will come to get rid of the fat?


> There is a problem. (job interview are selecting incompetent people)

Of the developers you hired, how many nailed the interview process, then went on to being classified as a bad developer?

From my experience hiring candidates, the typical software interviews that I have been a part of, tends to produce very few false positives, and instead do produce false negatives.


"They eat large sprawling problems for breakfast, but they balk at 45-min algorithm challenges."

Care to guess what we're looking for in screens and interviews?

Some of our best performers were poor interviewers. Likewise, we've had interview aces not pan out. Rather than expecting the world to become interview clones (and make our hiring decisions even more difficult), we're learning how to be better interpreters of people to get to the answer of our real question -- is this person an engineer we'd like to have on our team?

It's still a work-in-progress and we're nowhere near perfect, but we're simply not going to outsource our decision-making to the status quo of technical interviewing in 2016.


Given that none of the most popular dynamic languages know how a good hash table should be implemented with dozens of half-way experienced programmers over many years, and most of them would not be able to write a proper binary search, these questions are certainly too hard for a jobseeker. Those languages still survived with improper implementations for decades. So will TripleByte.

A good programmer must be able to survive mediocre colleagues and terrible managers. How to check for that in an interview?


While there are several resources to practice the use of algorithms and data structures, I find there aren't as many good resources to prep for the 'system design' interview.

If one wants to switch from a completely different domain - like working in investment bank tech or embedded development, there is no way one can have prior knowledge to tackle the design of a Google Docs style system.

It seems like something that can only be gained through on-the-job experience. Is there no hope for newbies?


If you can't talk about design implications quantitatively, nor have a rigorous understanding of how to build data structures - not memorize anything - you can't get mad that I make $100,000 more than you do and work half as much.

If you're a career programmer, and you've never bothered to hone these skills, don't be surprised when you can't easily find work in 10 years. The cheaper guy or girl who comes with less risk will beat you.


My solution has always been pretty simple -- I do poorly in exam interviews, and usually I don't get the job. Regurgitating Algorithms 301 -- nope, not for me. They'll end up with someone who's great at regurgitating. They're happy and I'm happy.

I can explain very clearly how I would go about solving a problem, maybe whiteboard it, flesh out a design, ask them some key questions to show I'm a thinker and not just a follower. That kind of interview usually goes well for me.

As a result, I usually end up with jobs where I have a lot of creative latitude, where I can think up new product ideas and prototype them out, where I can solve problems my own way.

I wish I could pass those Google tests, though. It would be nice to have it all. But some of us just have limitations, I guess. Luckily, it hasn't held me back from having an enjoyable and relatively well compensated career.

Probably today the thing is to have a couple of apps on the Android or Apple appstore, a Github page with some interesting toys and experiments, some open source contributions, and of course the old-fashioned networking that is how many of us still get our best jobs and most successful business relationships.


At my startup, I've had some success hiring mobile devs through "audition programming" on Google Hangout.

I create a "real-world-lite" task like "connect to this simple JSON API I built and implement a recursive product category browser on top of it". I've done this task myself already with a timer and am confident that it will take about an hour to implement. Then I ask the candidate to share their screen and implement it in Xcode while I watch. As they develop, I can get a sense for how they attack problems (quick and dirty, slow and methodical, stack overflow copying, etc), and afterwards I can ask questions about their thought process.

If they did well in the first one, we block out a second one for another hour, and a third for another hour after that, each one testing different skills.

This avoids the time imbalance inherent in take-home projects, because I'm spending just as much time as they are. And it avoids the painful "implement a red-black tree" whiteboard questions by focusing on real-world work in their own dev environment. It also means I have a decent sense of their skills before I ever invite them to an on-site interview.


Edge cases, running time, and correctness. If you're not hitting at least 2 of these perfectly, then you're not writing good code.


It very much depends on the gig, but I would add another item to the list: Show a basic understanding of UX design. Companies need people who can mediate between designers and programmers. While demonstrating an understanding of Photoshop and Illustrator says nothing about your skills as a programmer, it could be the thing that makes you stand out from the crowd.


We've not seen very much focus on design in interviews (very few companies talk about this when telling us why they like/dislike candidates). We do see a lot of focus on interest in what the company does. I think that pitching design skills as a passion for making the company's product better is the best way to go.


But "an understanding of Photoshop and Illustrator" is to "a basic understanding of UX design" as "an understanding of vi or emacs" is to "a basic understanding of distributed application architecture"


The only reason I mentioned Photoshop and Illustater is because they're easy things to put on a resume. "Knowledge of design principles" is a little more amorphous.


Sadly, very few companies care about UX when interviewing.

Well, actually, most companies I have interviewed with care about core CS fundamentals and nothing else.


To past a sane interview with sane people, focus your mind on the "how to be a good programmer" question - programming as a cooperative human endeavor.

Of course, it may that a bit of craziness may be involved and they'll ask ridiculous little or big problems but someone with a reasonable amount of can answer those.

Or it may be that a lot of craziness is involved, things veer into bit-twiddling assembly, top management steps in unannounced to shoot random questions, suddenly syntax or whether you are "server side oriented" or whatever matters a lot - "we want the absolute best programmers on the market and we cement their loyalty by paying well under market rates..." etc.

Now, the more craziness appears, the less you'll actually want the job. But markets being what they are, you may need the job. By the end, there are no easy answers. Keeping is probably the main advice.


While not strictly programming I just finished interview number four/five with a company about an hour ago. SQL and data modeling. First, one non-technical phone interview, one technical phone interview, one online take home test. Today, two different sessions, second one primarily technical, and lunch.

White boarding a simple data model of a real world scenario was surprisingly difficult even though the interviewers were very cordial. The exercise was used to gauge my question asking skills (interviewer was acting as subject matter expert) as much as data modeling and SQL. It was kind of fun as I used it as an opportunity to expand my ability to problem solve in stressful environments.


The company says: "We help programmers find great jobs at Y Combinator startups."

What's so great in Y Combinator startups? I mean why do they narrow only to such startups? Wouldn't it be better to just say they help with finding jobs in startups?


I had an interview some years ago which demanded a difficult CS problem to be solved and besides coding the offer stated that you should happily accept being helpful with the IT needs of the marketing guys installing their Antivirus, email...


I was saying to someone the other day that timed programming tests (codility seems popular) are really just youth tests.

They are meant to weed out older programmers, in favour of younger cannon fodder...I mean candidates.


I had a bunch of interviews in my life and everyone had its own "special sauce"...

My first one was with a Java company and the hiring manager wanted me to draw UML diagrams, which was the only thing that I learned in the software engineering course in university.

Another one was about programming a game. Nothing much, but it needed a few 2D transformation I knew nothing about, so I failed miserably.

Most jobs I got were just "talks" about what I can do.

"You know web development? HTML? Nodejs?" - "Yes" - "You're hired!"


What's the least stressful way to pass a programming interview?

Not to have one at all!

This obviously doesn't apply to people just starting out, but I've found the easiest way to get a job is to have worked with someone at the company in a similar role. Many of the issues that interviews are designed to highlight (attitude, flexibility, stick-to-it-ivness, culture fit) simply are non issues if you have someone on the inside who has experience with you.


If you have an unbounded abundance of good candidates, it is a different story then when you are a new startup fighting for talent.

At highly targeted companies such as Google, Facebook et al, I'm sure that if they have a dryspell of good candidates in a given month (can't think of a reason why), then they revert to things like: "We don't care if you don't get the 'trick' immediately, we'll give you hints" and "we just want to see how you think and how you code" and "just talk through the problem" and "you should not learn specific problems and if you see one you know just tel your interviewer" or "cracking the code interview type of questions are banned".

But the reality is that people who apply to Google (or Apple or Amazon or Facebook or Microsoft...), are very smart, and want to work there very much, so while they can probably do well without preparation, due to the fact they will have competition with all this year's new Stanford / MIT / CMU graduates on a limited amount of positions, they take no chances. I have a friend who has a masters degree from a target school and it took him 4 attempts to get into Google. He is smart, he probably did well in the interviews, but you are being compared to others, so until he went and worked on those pretty useless skills of: practicing writing fast on a whiteboard, getting interview books and practicing tricky problems, doing a lot of online judge problems, he didn't get in. Why? because if you have two candidates, both smart, one has practiced whiteboard coding for all of the problem sets on geeksforgeeks / careercup / glassdoor, and one haven't, then even if both are presented with a new problem, most chances it might be a variant of one of those other "usual suspects". e.g. after I solved the famous water trapping problem (tough one if you don't get hints), the idea for the largest water container problem just pops to mind, and if you know that you can find the only non duplicate number in a list in O(1), then the problem of finding if an unsorted list of numbers is an arithmetic series with just O(1) memory is practically the same trick.

So think of two developers, both are awesome, both know CS and both are fast coders.

One practiced whiteboard coding and knows the XOR trick for duplicate numbers, his code for such a question will be written in 1 minute

    public int findDupe(int[] nums){
        int dup = 0;
        for (int num : nums){
            dup ^= num;
        }
        return dup;
    }
The other guy, who didn't see these kinds of problems will probably use a hashmap and x2 more lines for the same problem.

Both are O(N) time an O(1) complexity, but the hashmap guy might accidentally say it's O(N) memory (common mistake for frequency maps)

Bottom line, both are good candidates, and the only reason the first one thought of the XOR solution in 1 minute without a hint is that they either saw it before (it's not that rare) or a real genius (statistically less likely, but still possible)

If you don't have enough good candidates, you might have the time and energy to really see which one of these will perform better at work using work related questions other than tricks like this.

But if you have unlimited good candidates coming in, the one that will solve it in 2 minutes will be the one that will stand out from the crowd, there is simply no other good way to filter out so many people. I'm sure they have tons of false negatives. (and probably also a few false positives, but I doubt it's too many)

So the system is broken, but also SATs and GREs are broken. Popular schools, popular jobs, will have to put filtering systems that are not only directly related to the ability to do the job. Someone at Google is simply writing CRUD apps for a living all day, I'm sure. But I'm sure his interview tested him on a much harder set of problems.


>But the hashmap guy might accidentally say it's O(N) memory (common mistake for frequency maps)

Wait why is it O(1) memory for the frequency map? As you keep adding elements doesn't the hashmap have to resize to prevent too many hash collisions?

> finding if an unsorted list of numbers is an arithmetic series with just O(1) memory

Is the strategy to solve this to first find the common difference `d` with one pass through the array (by finding the largest and smallest) and then sweeping through one more time xor-ing each element a[i] with a[i] + d and checking if the result is equal to the (minimum) xor (maximum + d)?


> >But the hashmap guy might accidentally say it's O(N) memory (common mistake for frequency maps)

> Wait why is it O(1) memory for the frequency map? As you keep adding elements doesn't the hashmap have to resize to prevent too many hash collisions?

Presumably because you'll have a constant number of keys (I'm not sure what the exact problem he's referring to is).


The problem was to find the only non duplicate number in a list.

I'm not sure how you would have a constant number of keys. I mean I guess if you consider a worst-case hash table with bucket for each integer you would have 2^32 keys (which is technically O(1) space since the size remains fixed regardless of list length).

But using Big-O in this case is clearly disingenuous since the space allocated is far, far more than the one for xor solution.


My bad, I meant for a variant of the question that uses chars and not numbers. With numbers the hashmap will be still constant memory just like you said, but it's a big constant (2^32) - but still O(1) memory. This is because the input is of ints, and it can only be one of ~2^32 numbers for either values or keys. And since we only count the number, we don't need a map, we can just use a set (a map with boolean value true if the element is in the set) we add to the set and remove when we see the element again, the only element left is our non duplicate item. But the max we can have is sizeof(int)/2-1 duplicate numbers + 1 non duplicate, so memory can't be more than a constant.

In the char variant, the worst case number of keys in your hashmap is the total number of chars in Unicode. You can't have more than that no matter how big is the input.

So both cases are a very, very big constant, but still a constant.

Time complexity however is theoretically unbounded as you can have any size of input, but again, this is limited to the max size of an array, so TECHNICALLY the time complexity is an integer in Java at most 2^32 as well.

But I would not risk saying that in an interview, O(1) memory will pass, saying O(1) time because the size will never be longer the the max array length sounds more risky.

if it's an int though, it's an O(1) and O(1) memory if you really want to be technical. So are all interview questions involving an array of integers I guess :)


Ah that makes sense.

And what was the intended solution for finding if an unsorted list of numbers is an arithmetic series in constant memory? You say it's the same xor trick, but I don't see how it's applicable. Do you xor all the values with all the values shifted over by the common difference?


"arithmetic series" and "unsorted list" are mutually exclusive statements. Unless you mean something like "the sorted version is an arithmetic series".


Yes Or a randomly shuffled arithmetic series


In Java this prints -4

    int [] nums = { 2, -2, 0, 0 };
    int dup = findDupe(nums);
    System.out.println("dup="+dup);


This only works if the numbers are in a known range (say sequential from 1 to 100), and you XOR in the index (plus 1) as well. Then each number is XOR'd two times, except the duplicate, which is XOR'd 3 times (and thus remains at the end). The fact that the code is wrong shows why this question is a very bad interview question.

EDIT

The given code works to find the only non-duplicate item in a list (perhaps that was what was intended)


yes,that was the intention, I can't edit by now. I had to leave fast and then got "noprocast" on and couldn't reply / correct

but it is nice that people got what I said through the lines!

it should have been called findNonDupe and the var should have been called nonDup.

Hope I'll do better in a real interview ;)


The problem was formulated as to find the only non-duplicate number.


Yes, my wife was waiting on me for lunch so I made tons of typos, yes I meant find the only non duplicate number. and I meant O(1) memory O(N) time complexity.


findDupe isn't O(1), it's O(n) since it has to look at all the elements in the list.


It's O(1) space complexity but O(n) time complexity.


Oh sorry, that's right, I just assumed parent was referring to time.


Recruiting is F*&^%$ No matter what you do to the interview process Hiring managers are looking for @#$#% and they may be #%@%@ and their company maybe $@%@ and their team dynamics are ##%# Candidates are looking for $@#!@ and they may be $@@$ and their personal situation is $$@@ and their salary expectation is ##%@@


This is a very good piece of advise, matches my past job seeker's experience really well. I think I got most of my jobs largely thanks to enthusiasm I had for the stuff the companies were doing. It was genuine but I'm sure it could be pretended as well. Everything else spot on, very honest stuff.


I think it's also important to mention that you should come in with some good questions of your own that you've prepared for them. A lot of times the interviewer uses this to see how much homework you've done on both the company and the job you're applying for.


Recruit people who are smart, work hard, solve problems, enjoy learning and get stuff done. Joel knows.


I'm pretty sure I could never get an engineering job at companies that interview like this. I've shipped tons of real world products over the last 20 years, founded companies, and just reading about what it is like to interview scares the shit out of me. I'm a firm believer in proving real world skills, not silly/irrelevant high pressure short time domain stuff.

Safe to say, we don't interview with whiteboard hazing. We do a phone screen mainly for personality and to see if the candidate deeply knows about a project they recently worked on. We dig in a bit there and look for the spark of passion. Then, if we are moving forward, we give a take-home project in a private git repo that is relevant to the role and tell them to spend 4-8 hours on it depending on their availability and ask them to time it and be honest. They choose the scope of work they want to accomplish. If the code looks reasonable we have a video conference where we do a code review and dive deep and ask "why" a lot.

We have been really surprised at the difference in quality of these take home projects. Some people can barely get started and struggle to produce anything. Others build full on, useful, applications.

Obviously we are screening for people that are self-starters, so being able to choose scope and regulate and make larger decisions is important to us.

An example project for a full stack c# developer:

Feel free to search around and work on the challenges as if you were on the job. Let me know when you think you can have this stuff done by. Please do this on your own time, with your own equipment and tools, and not your employer's. We don't want any lawsuits or IP ownership questions. Also, for the code, you can retain copyright if it's something you'd like to publish on GitHub, etc.

Clever Code Can you send me a code snippet in the language of your choice of something you have done that solves a hard problem in an elegant way?

For instance, here's one of my snippets from a few years back. It solves the complex problem of transactional optimistic concurrency control using ~30 lines of code. The usage of lambda expressions in C# and generics makes it succinct and expressive.

http://blog.jdconley.com/2009/01/functional-optimistic-concu...

Production Backend Question Let's say I have a very popular consumer facing service with 10 load balanced front end web servers running the latest asp.net mvc and averaging 100 simultaneous requests each, appropriately sized ms-sql servers, and a heavily used memcached cluster of 4. Everything is running great until we do some capacity planning and double the number of web servers to 20 and experience a 25% increase in simultaneous requests. Suddenly load shoots up on the ms-sql tier with far more transactions per web request than typical, overwhelming a ms-sql cluster that should have handled twice as much web traffic. Web server requests start timing out and throwing 500 errors to the clients, and the system practically comes to a halt. There were no code changes. Describe how you would troubleshoot this and what you think might be a few likely causes.

Failure Tell me about a project you have worked on that failed. What was your role? Why did it fail?

The Challenge This is meant to be a practical exercise, and is representative of the types of challenges we face. We want to see if you can make reasonable product choices under time pressure as well as write code. You get a lot of ownership here. Please use any frameworks/services/etc you want. We suggest using something you know very well. Feel free to search Google, go to the library, call a friend, or whatever you need for research. Please write all the code/copy/etc yourself. The output can run on whatever OS or PaaS/SaaS provider(s) you want, but it should be something we can also easily run. Please try to limit this to 4-8 hours of your time.

If you want to keep the repo private, please share it with me: https://github.com/jdconley

Create a web site with the following characteristics: Make the hackathon/minimal/proof-of-concept version of some popular consumer web app that you think could use some love. Craigslist, eBay, reddit, whatever...? Site must be responsive, gracefully scaling down to smartphone resolutions and up to full screen desktop displays. It does not need to be beautiful. Supports all the way down to IE8, with appropriate feature degradation as needed. Lean toward implementing things in-browser rather than in back end code. Bonus points if you do a Show HN and your implementation makes it to page 1 on hacker news.


tl;dr -- current programming interview format should be drastically changed.

I have interviewed 100+ candidates so far. I'm doing interview less and less recently simply because I found those coding/design questions less meaningful to judge how good a candidate is.

With websites like leetcode.com/lintcode.com that collect interview questions and provide online judge, all you need is to put enough time practicing. 10-years ago we use "reverse a linked-list" and nowadays we maybe use questions like "topo-sorting". The latter is significantly harder than the previous one -- but if candidate saw solution beforehand, it's actually easier to implement.


I look forward to seeing more articles that find ways to game the interviewing process. Perhaps showing interviewers how easily their hiring process could be gamed will 'inspire' improvements in interviewing.


Countless books have been written on this topic, so my money is on no.


Good article. Anyway, I am also disappointed with many interview processes. Sometimes I think there are courses or books about how to hire that spread a particular concept or practice that is common in some period.


"Line up offers" only works if you already have a job, I suppose. If you're unemployed, you generally have to take the first offer you get, or you lose your unemployment benefits.


"You need to be able to write a BFS cold, and you need to understand how a hash table is implemented."

Great advice! The list provided in this blog post is an excellent description of what you should know, cold, before you go into an interview. The reason you need to know them "cold" is that you (probably) won't be simply asked to code up mergesort. Instead, you'll be presented with a problem that can be reduced to mergesort. You need to know it cold so that you can reason more abstractly with it.

While this is great advice, it also demonstrates why people eventually develop interview fatigue over a career. I'm not talking about fatigue from your third interview this week, I mean, I mean fatigue that sets in over decades.

See, a year ago, just before I interviewed at google, I could have done all this "cold". I could code up a BFS, mergesort, find the shortest path between two nodes, print all permutations of a set, and so forth. Cold. And you know, I think in many knowledge-intensive fields, most practitioners are required to do stuff like this cold. But I probably wouldn't be able to do it all cold now. I could figure it out, but not in 45 minutes at a whiteboard, and certainly not in time to reason abstractly. I wouldn't be able to do this with partial differential equations or shakespeare's plays, two other subjects I was highly prepared for exams in a couple of decades ago.

See, people in other professions have to do this, but they do it once. Actuaries need to know vector calc and linear algebra, cold, to take their exams. But they don't have to remember how to integrate by parts when they are interviewing for a Sr Actuary position 15 year later. Physicians need to know Organic Chemistry, cold, at some point in their lives. But an experienced anesthesiologist isn't expected to answer whiteboard questions about undergraduate oChem.

I don't have an easy solution, since I actually do completely understand why tech employers rely on these exams. But I do think they take a serious toll on the field, and are a major contributing factor to attrition (as well as aversion among people who never go into the field at all). We, as developers, really do have to re-load complicated undergraduate coursework into exam ready memory over, and over, and over.

I'll finish the way I always do: if you interview like this, that is your choice, and you should feel free do do so - I really mean this. But why then do these employers act mystified that there is a "shortage" of developers? It seems to me that aversion and/or attrition is a very natural outcome for the way we do things in software. "No thanks, I'll do something else" seems like a very reasonable response to an industry that hires like this.


At the risk of repeating myself what I've said elsewhere on the page:

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

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


You've copy-pasted the exact same text several times in this thread already. Your worry about repeating yourself is justified. This seems like blatant advertising to me.


  This is a different skill [1].
The [1] is inside an <a> tag, but the tag doesn't contain an href attribute, so it doesn't link to anything.


Thanks. Fixing!


If you're given a take home project and you take a lot of time on it, it's usually a signal that we shouldn't hire you. We're not using you for free work, and if you think your take home project is assigned in that vain, then you're probably not qualified for the job. It's great personal work ethic when you tell us you worked super hard and spent a week on it, but we give you the expected time so you can filter yourself out. Also, shame on you because it makes us feel shitty to have to reject you after that.


How about technical interviews for non-technical roles. Any advice?


> To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly.

I certainly hope they aren't interviewing anybody under duress.


align your interview requirements with your actual desirability as employer and with realities of job at hand.


Recruitment in this industry is FUBAR.


> I fundamentally do not believe that good programmers should have to learn special interviewing skills to do well on interviews

> 2. Study common interview concepts

lol


You can simultaneously believe a process is bad and advise people to learn it in order to get ahead if you do not have control over said process.


Being evaluated is a skill.


The article starts pretty fine but then just explain how to be good at bullshit interviews?


interview != quiz


Well, technical interview questions are why I've given up on pursuing a programming career path and I was shocked that employers were still giving out technical interview questions for a product manager role, it didn't matter if I was a software dev years ago. Rote method still trumps real world experience building real commercial software that people will pay you for according to a lot of interviewers....and I've heard about few managers hiring neophiles based on their 'algorithmic' performance on a whiteboard build shit on Node.js, panic when it's far more work necessary and pull the plug on their CMS (reinventing wheels) because PHP is 'slow'...what in the fuck did I just hear you want to rebuild a static CMS website in Node.js because you think it's going to give you wings?

well at least that has been my experience so far trying to get a job and I'm coming up dry every time. I technically have no work experience because I've been holed up writing a big data mining SaaS tool for a few years and since I was self employed it seems to mean jack all for credentials.

I don't know I'm in a bit of a jam. Starting a complex SaaS product from scratch that thousands of people have used is simply useless against a fucking sorting algorithm that will be used heavily on the actual product.

Like I feel like I'm living in a bizarro world sometimes...I have all this experience and knowledge in this one area, building shit and getting people to pay for it, and it's going to waste as I'm half heartedly applying for jobs I know I will not be able to pass the second round of interviews when the technical algorithm questions begin....I'm sure if I wanted to learn more about the different variety of sorting algorithm I would've fucking consulted stackoverflow already....come on man I just wanna solve real world problems with real world product experience not write fucking code on a whiteboard. I'd be happy to architect out an entire stack powering your product in to the future on a white board but fuck man if you want help on your sorting algorithm just google stackoverflow.

my 2 cents.


You come off as a technophobe. As an employer, how am I supposed to quickly judge your independent work if you hate algorithms and new tech? I'm not going to pour through a repo; I don't get paid for that or care, to be honest.

If you're talking about PHP being better than JavaScript in a startup interview, you're not going to be hired most likely. Startups typically use new technology, and you clearly don't.


Is it weird that I find this entire blogpost eerily similar to PUA strategies?

I think it ultimately boils down to confidence. To use the dating analogy, nothing drops the proverbial panties (or boxers, if you're into that sort of thing) faster than having confidence. Being physically attractive (i.e. fit and in shape) doesn't hurt either.

Take my analysis with a grain of salt, though. I happen to be hilariously bad at interviewing, and don't get me started on dating.


I can't tell you how much dating advice I've read that advises you to be sure you remember breadth- and depth-first search algorithms.


And your advice is eerily similar to the non-advice people give guys who aren't naturally good with women. "Just be yourself" or "Just be confident."

Those statements aren't advice they are platitudes. And some people, despite people who are naturally good not understanding, need actionable advice about what to do exactly.


Ummm, this should be titled 'how to pass an interview', period. Most of this advice applies well outside of programming and reads like any of 1000 self-help books of the past many decades. Sure there are a few specifics to coding but all the themes are as old as the hills.


It you "mention C" in an effort to game the system, any competent interviewer will eat you alive.

I remember when "having a Github" was a signal, as soon as word got out everyone had one, but most were zero or near-zero original content.


"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.


We detached this subthread from https://news.ycombinator.com/item?id=11247773 and marked it off-topic.


Okay sure, though how is it off topic?


The subthread turned into a flamewar.

The root comment wasn't off-topic, but it wasn't helpful either, because of the snarky second sentence. It's typical for such a comment to nudge the thread in the wrong direction.


i often just refer to it as waterboarding.


whiterboarding?


I just call it "whiteboarding".

Seems to convey the subjective experience quite aptly.


I think they really downplay how much of a panic/anxiety these type of closed room with no ventiliation with solemn looking people judging your every move.

I could never calm down and think but the interviewers wanted to test how you would code on a whiteboard under duress


Have you ever been waterboarded? Putting waterboarding on the same level as whiteboard coding interviews is minimizing the horrific experience of those who have been waterboarded.


Not many people have been waterboarded, and most were terrorists, so it's not the same as a holocaust joke. In a world where we're not allowed to laugh at anything connected to some kind of injustice, then yes, that wasn't funny.

But I laughed.


>and most were terrorists

Do you have a source on this?


Putting waterboarding on the same level as whiteboard coding interviews is minimizing the horrific experience of those who have been waterboarded.

I guess it is, if you read it literally. But I don't think people mean it literally when they joke about it, nor are they making a serious comparison between the two experiences.


ok sure, but this conversation is figurative not literal. it would be horribly wrong to literally put whiteboarding on the same level as waterboarding. I don't see any problem with using figurative language and expressive metaphors to help convey a particular emotion felt about something that is common to the lives of those participating in the conversation.


Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".


Social performance stress is not technical performance stress. You can weed out a lot of undesirable work environments by seeing which potential employers confuse them.


Is this seriously what interviews are trying to discover? In what practical situation would this skill manifest - a meteor is about to hit the Earth, and you need to write some algorithm to stop it RIGHT NOW?

Or is it "we need to know how you handle the stress of critical bugs that are existential threats to our client relationships", which shouldn't exist in the first place if the company is run well? If yes then I guess you know what I'd say next...


Maybe - but I've also seen folks who ace that sort of thing be the worst engineers for getting real work done "under pressure", and fiddle around with reinventing the wheel and academic debates about trivial details too.


This is not how to find people you actually want to work with.


On the bright side, it's how you find people you want to work for.


you sound like a terrible boss


Thankfully I'm not a boss. But when I go to an interview and they put me under pressure, I dont automatically discount them because they put me in an uncomfortable situation. I assume they're gauging my mettle.


The point of most job interviews is to weed out people who need to read articles like this one.


So the purpose of job interviews is to find people who can pass job interviews? Seems like a tautology.


No it isn't. It's to weed out people who wouldn't think to or know where to find it.


Rote memorization of a guide or following a "script" is not the same as qualifying for a position.

A sufficiently experienced and knowledgeable person will be doing things similar to what's in the guide because they've learned to do so through experience, not because they read it in a silly guide.

People seeking out the guides are typically the same ones who don't have the experience to back up what the guide tells them to do.


I'd guess very few people use every one of these things on a day-to-day basis and in my experience the bigger companies actually encourage you to brush up on algorithms before interviews with links to resources you can use. If you're really hopeless it's not like two weeks of study are going to teach you everything you need to know.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: