Hacker News new | past | comments | ask | show | jobs | submit login
How to pass a programming interview (2016) (triplebyte.com)
282 points by davidjnelson 11 days ago | hide | past | web | favorite | 150 comments

Funny, I just went through a pre-screen assessment for one of the big ones and it was not one but _two_ DP problems. I could have probably come up with a slow solution using recursion and a bit more of time, but was given only 90 minutes. And I thought to myself, what exactly did they learn about _me_ after this exercise? Absolutely nothing, except that I can't solve DP problems on the spot. What a waste of time.

And the funny thing is, I work as an embedded developer and actually have to look up a topic or two from CLR at least once a year for work stuff (which is not very common). But DP? I've never needed it or used it. Why the emphasis in it then?

It feels a lot like software interviewing is just a bunch of rain dances and cargo culting and those that know the dance get through the hoop. I guess I'll have to order Elements of Rain Dancing from Amazon and get to practicing.

I have yet to find an interview process that works better than RPI (Rob's Pairing Interview)[1] plus a day-in-the-life[2].

It gives both the employer and the candidate a chance to evaluate each other in context.

As an employer, you get to see how the candidate performs on two different real-world tasks, as well as how they interact with existing employees.

As an employee, you get to see what the company is really like to work with. No amount of whiteboarding can deliver that.

And at the end of the day, if that relationship feels good, both parties can choose to continue onwards towards full employment.

On the other hand, computer science trivia, by which I mean "implement Dijkstra or quicksort on a whiteboard", is a very poor means indeed by which to test for the ability to do real-world work in a real-world context.

Sure, it's valuable to have a broad understanding of algorithms and data structures. But whiteboard interviews on those types of problems only tests how well you would do competing in an ACM (Association for Computing Machinery) challenge, not how well you can deal with "here is a totally new-to-you problem that lacks a precise solution, now work productively with a team to solve it under the constraints of an operating business"

[1] https://builttoadapt.io/the-developer-hiring-process-is-brok...

[2] https://blog.jonrshar.pe/2016/Dec/05/pivotal-interviews.html

These were my personal favourite as well. After both interviews I left feeling very enthusiastic about working at Pivotal. Both interviews felt extremely collaborative, and in both cases I actually _enjoyed_ my time, rather than feeling stressed as had happened in more "typical" interview processes.

For the day-in-the-life, I got to work on real problems that I would be solving, in the manner of working that Pivotal espouses, with the colleagues I would be working with, in the environment that I would be working in.

I think that these interviews are particularly suited to Pivotal's model of working (in particular the pair-programming) and are probably less suitable elsewhere.

Unrelated: I absolutely heart your username.

This is absolutely horrible.

"We believe coding is a social activity. In fact, we’re testing you to see how social you can be around coding."

It's worth understanding that Pivotal are hiring for a work environment that is almost entirely pair-programming, with teams of 2 to 8 engineers that rotate pairs almost every day. With that in mind, it's absolutely critical that Pivotal consider the social side of candidates while pairing.

That makes the process less suitable for other types of working environments.

It seems to me that "programming" there means glorified devops and the primary goal is a headcount of young compliant workers to show off to investors.

Probably activity is valued higher than progress.

They are certainly not looking for Knuth, who would likely fail the interview.

Unless your business goal is to advance computer science research, why would you want to hire Knuth and why would he want to work for you?

Yes, I think Pivotal are not looking for Knuth. Most companies don't need Knuth to be successful. That said, individual brilliance is not at odds with the other skills Pivotal are looking for.

The other statements don't ring true for me, but I understand it's just your viewpoint.

Why should he fail the interview? He's exceptional at talking through complex algorithms, and I've never heard of him being particularly anti-social.

Yeah, it would be okay if they were talking about coding at that specific organisation.

But the generalisation is just stupid.

How is it horrible?

I'd be absolutely drained and miserable after pair programming for an entire day. It's not an environment I would consider when looking for a job.

The best interview I ever had was similar, the largest chunk of it was me and my boss whiteboarding out a problem together, he had the marker. We were solving a problem that I'd be solving on the product, and that he had implemented on a previous project at a different employer. It just felt great.

Stripe is similar, I found it so refreshing when I learned this: https://www.quora.com/What-is-the-engineering-interview-proc...

I feel your pain. I did exactly one dynamic programming algorithm (in the string matcher for Hyperscan) and was pretty inordinately pleased with myself for doing it, but we built dozens of algorithms in that project and that was the only case of DP that I recall.

But I expect to go into interviews and have people demand a different rain dance, now that everyone is talking about DP. They like mugging people with 'so big it has to be out of core' stuff, which is a good way of finding out who went to the right grad school algorithms course. :-)

I think I only saw DP-based algorithms 3 times in 12 years of working and reading open source code. Two of them were boring textbook-based implementations. One algorithm was original, and came from 80s - it's from Emacs source code, with comments like "do not touch", "here be dragons", etc.

Yes, the code involving the DP algorithm I put in had a bug in it - not from the DP algorithm itself but the assumptions that fed into it - which went undetected for some time because of how complex the DP algorithm was and how hard it was to evaluate. It only caused a minor performance quirk (not a actual semantic error) so was hard to find.

A cautionary tale about being overly clever-clever I suppose.

I don't do well on on the spot programming interviews. studying doesn't help. I can identify what needs to be done almost always, but implementing it in front of someone in only 40 mins? I need to practice that I guess. In the end as you said, I am constantly wondering what being able to regurgitate a memorized problem tells them about me (nothing) and why they don't care about my past experience, projects, successes and ratings. However, this is what every software interview is now

> I need to practice that I guess.

You are right about that, at least according to that article here:https://news.ycombinator.com/item?id=18942572

That guy trained on a well known website to solving minor coding issues and then (that's the important part) practised solving them in mock interviews to real persons.

Maybe that could help you.

Neither does this famous guy [1]. All these interviews do is waste a lot of time and generate a lot of false negatives.

You can practice all you want to get better, but no one in the corporate world is saying "I need you to code bubble sort, and I need in the next 45 minutes" and then proceeds to stand over your shoulder the entire time.

[1] https://twitter.com/dhh/status/834146806594433025

For big companies that have a ton of applicants, the false-negative rate probably doesn't matter all that much. They need a quick way to narrow the field.

As for wasting a lot of time, what more reliable method is there that takes less time than a leetcode-style problem? Surely there are more reliable methods, they probably don't take 30 minutes or less though.

I see a disturbing trend every time one of these articles comes up. It seems all these companies are doubling down on these absurd interviews. Making them harder and harder to get in.

DP is the epitome of how absurd these interviews have become and now people are getting asked 2 of these questions in pre-assestment stage.

I view it as industry moving the marker higher and higher for cult and loyalty marks and seeing if they get a steady manpower influx inline with their needs.

Jokes on them when they stop getting good devs and start getting good shortterm greedy puzzle solvers.

Hyuck hyuck hyuck

I have a theory that dynamic programming problems have become more popular in part because the lower hanging fruit — reverse a linked list, is this a palindrome? — have become widely known and practiced via books and sites like hackerrank.

DP problems represent the next rung of the ladder, are somewhat less familiar. And most importantly, satisfy an interviewer’s possibly sadistic impulses by presenting a problem that has an easy 2^n solution. ;)

Sarcasm aside, I think this is just the inevitable result of the systemisation and gaming of the whiteboard interview.

Both of those have pretty easy recursive solutions. I don't think you are required to pass all the unit tests in order to move forward and doubt the most optimal DP solution was really required. I got similar (as in recursive with DP optimization possible) questions in my real interviews.

It's especially horrifying when you see all the people who devote their time to learning the rain dance instead of actually useful skills. People on /r/csMajors or /r/cscareerquestions who will say with a straight face, (well, as much as one can virtually) "you only need a data structures and algorithms class" or the generic "just grind leetcode" as a response for any perceived inadequacy. I wonder how many of these people make their job only to realize they have no experience and no interest in the actual content of their job.

I completely agree with you that solving a DP problem for a job interview shows next to nothing about the candidate, that asking a DP problem as an interview problem is cargo culting/rain dancing/etc. On the other hand, I believe DP is fundamental algorithm that comes up again and again and is the equivalent in importance to the simplex method but for millennials and gen-[xyz]'ers.

Among the problems it solves are:

* Shortest path in a graph (aka Bellman-Ford's method) [1], A* path finding [2]

* Approximate string matching [3]

* Viterbi algorithm for hidden Markov models [4]

* Earley parser [5] for context free grammar parsing

* Dynamic time warping [6]

* Finding the base of a strong generating set for permutation groups [7]

I'm consistently surprised that DP crops up in so many places. While most people won't be required to implement the above list in their day-to-day programming life, it's quietly in the background as a fundamental algorithm.

Dynamic programming is one of the few algorithms that, in a "natural" way, reduces a problem that is naively exponential to one that is polynomial. For example, try counting where 2^T random walkers lands in an array starting from the middle after T time steps. Naively, this would require 'simulation' of 2^T but with DP you can do this in O(T^2) (assuming addition of atomic integer types is "free" and there's no overflow on count) using DP (by summing a 'count' of random walkers at each time step, at each bucket in the array).

[1] https://en.wikipedia.org/wiki/Bellman%E2%80%93Ford_algorithm

[2] https://en.wikipedia.org/wiki/A*_search_algorithm

[3] https://en.wikipedia.org/wiki/Approximate_string_matching

[4] https://en.wikipedia.org/wiki/Viterbi_algorithm

[5] https://en.wikipedia.org/wiki/Earley_parser

[6] https://en.wikipedia.org/wiki/Dynamic_time_warping

[7] https://en.wikipedia.org/wiki/Schreier%E2%80%93Sims_algorith...

When I went to graduate school, I took two algorithms classes. The first was general, and the second more targeted. For both classes, dynamic programming regularly was needed.

I think they ask about it on interviews because it’s basucally a proxy for “did you get good grades in graduate level courses”. At a top school, undergrad courses should be close enough. Of course, they could just look at your transcript, but maybe you cheated.

Which is sort of silly if you didn't PhD in CS, but rather say, mathematics, where your courses hit you with numerical methods for PDEs, linear algebra, optimization, etc.

But then they use the same interview questions for somebody who finished school 10 years ago and hasn't touched DP since then.

This also makes them convenient tools for age discrimination

> But DP? I've never needed it or used it. Why the emphasis in it then

There are people who did only the multiple choice questions and moved on to the video conf interview. At least they can skip DP question for some people, so probably not an emphasis.

> Absolutely nothing, except that I can't solve DP problems on the spot

It's an IQ test.

It measures cognitive intelligence. Does it predict overall success? No.

IQ tests themselves are a bad predictor for performance, and skewed by access to resources. So maybe it is similar? That's not a good thing though.

For the dp problem, you need to have experience with dp problems, experience with general algorithm problems (from the acm-like programming challenge side specifically), and generally be good at applying those in new situations. Unless that's your actual previous work, it doesn't measure intelligence in any way.

IQ tests are one of the best-known predictors of performance in any occupation.

> The validity of IQ as a predictor of job performance is above zero for all work studied to date, but varies with the type of job and across different studies, ranging from 0.2 to 0.6

Best know doesn't mean good. Any occupation also fails:

> for minimally-skilled activities, athletic strength (manual strength, speed, stamina, and coordination) are more likely to influence performance.


Also, that's a predictor for "any" job. You can do better if you know exactly what job you're interested in. Do a sample of work that's very close to the real one and you'll have a better prediction.

Regardless of whether or not it’s a good measuring stick to see who to hire (it’s probably not), I feel like DP is something that ought to be in a professional programmer’s toolbox.

I’m an embedded developer too, and I end up reaching for DP every year or two. I think I probably use it _more_ because I’m in embedded: if I was willing to accept harder to analyze memory requirements and runtime performance, which I almost always am outside of embedded, most things I’ve solved with DP I could have more swiftly solved by composing algorithms and data structures from the standard library.

I agree, it is a tool box thing. I either did not know of or forgot the term "dynamic programming," but I use memoization regularly, and have used it as short cuts on recursive calls. Accidental dynamic programming. Heck, the first time I heard of the collatz conjecture, my toy playing around with it memoized the results.

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

If a candidate can solve large, complex problems but bombs your interview, the problem is your interview. TripleByte should focus on this problem and educate these companies on effective interviewing techniques. For example, if your interview overemphasizes coding challenges, puzzles, quizzes, or otherwise feels more like being on Jeopardy than real-world applicable, you're doing it wrong.

Candidates should be focused on their skill set and filling in gaps (i.e. I've toyed with Python but I see it being in demand so let me get better at syntax, packages, thinking in pythonic way).

Okay, but the problem is, 45-60 minutes is usually all hiring managers have to assess a candidate. What can you do in that amount of time to assess someone‘s real world performance? Having a high level conversation about technology and problem solving approach helps but often doesn’t translate into writing code. Tech-stack specific challenges are no good because general programming ability is more important, you can learn a new language on the job. Algorithm puzzle problems aren’t great because then we’re selecting for people who spend a lot of time on hackerrank or whatever.

Maybe effective programmer hiring is just an unsolved problem.

What's so friggin' different about hiring software developers that we've gotta get all weird about it and come up with some brand new thing? What's the hiring process like for other office workers? How about for other technical or specialist roles that are somewhat similar to software developer? Engineers of various sorts, maybe? Accountants? Hell, lawyers even? There's got to be some set of existing practices that'll fit this just fine. It's simply not. That. Special.

My brother is a mechanical engineer, and his org hires by bringing in graduates on a low salary, moving the competent ones to roles that make use of their competencies, and moving the incompetent ones to roles that are pretty much the same as unskilled technicians. Sometimes the boss meets a candidate at a conference or over beers and fast-tracks them. They have literally no women in the entire engineering department.

I'm not defending whiteboarding the knapsack problem so much as I'm defending the difficulty of hiring skilled workers from different walks of life. Tech isn't special, hiring is just hard, and a lot of other industries are actually worse.

The software engineer analogue of this would be consulting. You hire everyone out of college. Start them off at a salary such that they are still net positive even if they only ever stay at the lowest possible billable rate. If you get good enough to command higher rates (or the effective rate through increasing the success rate of projects), you'll keep on getting commensurate raises.

Many things happen:

* You hire people who end up not being able to do the work (I hear my wife complain about this problem in accounting just about every three days)

* You end up needing more stringent certifications than exist in comp sci land (you mentioned lawyers, so that's one with bar exams, but also accounts with CPA exams, professional engineers, doctors, etc)

* You get proof of prior work

* You rely heavily on recommendations, with all the pros and cons there

> You hire people who end up not being able to do the work

Funnily enough, I've heard the same thing from some friends who worked at companies with algorithmic interviews.

> You end up needing more stringent certifications than exist in comp sci land

That sounds great. You just have to study up and take a very hard exam at the beginning of your career instead of having to study up and take a hard exam every few years.

> You get proof of prior work

And what about Github? Most employers want to see proof of prior work unless you've got a very good excuse.

> You rely heavily on recommendations, with all the pros and cons there

This may be the only decent argument against the accounting/engineering/medicine interview. Even with good performance, recommendations are a crap shoot (did you get along well w/your boss, are they pissed you're leaving, do they refuse to give out references to anyone like one contract employer I worked for for a year a long time ago).

But then again, puzzle interviews are also a crap shoot.

GitHub can't be used in Graduate interview efficiently, and those one could be probably the most problematic. If a candidate has work experience, you can at least assess that he can do something

To be clear I wasn't arguing anything, just stating what happens. Things are different in some ways, but not all (recommendations and proof of work are common in programming too)

In my experience, recommendations aren't very common in programming, unless you're talking about referrals by former supervisors/colleagues to some job opening.

Have others had a different experience?

Recommendations really only come into play when you're talking about the best engineers. In which case, you're effectively no longer interviewing, just getting people in your network who say they must hire you or tell other people in their networks they must hire you.

Related, in blog form: https://www.joelonsoftware.com/2006/09/06/finding-great-deve...

I would consider those as more referrals, not recommendations (which implies the traditional job recommendation process).

> Hell, lawyers even?

It's pretty terrible. There's no other profession that's quite as snobby as the legal profession. If you want to go work for a top firm you need to have gone to one of a handful of law schools. While there you need to have gotten good grades in your first years' classes so that when on campus recruiting happens at the start of the second year you get an interview. These OCI interviews are almost entirely what the tech industry would call culture fit, with all the implications of bias that implies. One a summer position is obtained, the job is yours to lose. Do reasonable work, don't get drunk and vomit on a partner's spouse or blow off your third year classes and you will probably get a job offer with the firm you summered for.

I don't think this is a process any other field should try to emulate. Whiteboard interviews may have their flaw but it's a lot better than:

  Did you go to Harvard Law &&
  Did you get top 1/3 grades as a 1L &&
  Do you remind the partner you are interviewing with of himself and/or his kid

I think other professions emphasise past experience and referrals more. That and official credentials, especially in certified professions (I.e. Medicine).

That said, I think all interviews have an element of silliness to them. I know a financial consultant who was quizzed over articles published in the days financial times newspaper. Also know one of our analysts makes candidates do long division on paper! Don't forget the infamous how many golf balls can you fit in a jumbo jet kind of thing.

It kind of is tho. Also you should research what kind of shit accountants have to go through to get hired at big 4 for instance. And lawyers have to pass bar.

Lawyers pass the bar once.

They pass it once, at most. Many take it many times.

True, cle is mostly a joke lol

A lot of fields are similar in pretty lame ways like consultants from MBAs, accountants, lawyers. For all of them. Getting into the tier 1, tier 2/good boutique place is a rigid crappy system. I can’t remember exactly how investment banking and other main MBA sort of jobs work but I think they are similar too.

Friends in more general office jobs like HR, managers, etc, it doesn’t seem much better. It’s different than how to get a software dev job, but to say it’s been better would be a bit much.

I used to be a lead software engineer and conducted dozens of interviews and phone screens. I would simply look at existing problems I had solved recently and ask the candidate how they would solve them. If they came up with something on par with my solution or better I would recommend them for a second interview. If they talked around the problem and just dropped buzzwords I knew right away they weren't a good match and/or didn't know their stuff.

This approach is straightforward, real-world, and you can find out about a person this way in as little as 15 minutes.

Shhhh stop giving away my trade secrets for hiring better than everyone else!

I have had a strong hand in the technical interview design at my company. Push back on 45 minutes. I've put a line in the sand that we at least an hour for code and an hour for design, and we schedule those next to each other if we need to give more time to code.

For code, the key is to find a recent problem your team's have recently had to actually solve. Distill it down. As a interview question designer, give yourself 1/4 to 1/3 the coding interview time and see how far you get implementing the solution. That is the bar: don't expect a candidate to be able to get further than that in the whole time block. You also want to budget time to talk about productionizing the code (metrics, logging, monitoring, etc).

I had a question that I wanted to give and required a couple passing unit tests. After applying the 1/3 time rule, I realized that my question was unfair and I had to alter what I started with.

I've agree with the difficulty you describe - even with 4 hours of interviews.

I've come to the conclusion that one (or both) of the following might be best:

- a small take home project with a reasonable due date (say 5-8 days) that is representative of the kinds of work that is expected on the job. Then, a 1-2 hour code walk through and presentation. Candidate should expect to build, run, debug and describe the code and architecture, tools choices, show source control use etc.

- a 3 month probationary period with a fairly narrow starting role that all new hires expected to be able to code are required to go through; ex: fixing bugs on project X; ramp-up and demonstrate _______ and _______ on project Y.

Doing the take-home project is certainly difficult for some candidates who may have a hard time carving out time to do it - but the hiring manager can offer some flexibility here - and this seems like a much better approach than taking online code quizzes.

The 3 month probationary period seems like a way to detect other on the job performance or interpersonal skills issues that may be a cause for disqualification.

>a small take home project with a reasonable due date (say 5-8 days) that is representative of the kinds of work that is expected on the job. Then, a 1-2 hour code walk through and presentation. Candidate should expect to build, run, debug and describe the code and architecture, tools choices, show source control use etc.

The problem with this is that talented developers generally do not want to work for free on someone else's proprietary software and there is a very real risk of companies trying to abuse this practice to extract free labour from candidates the closer you get to "work that is representative of the kinds of work that is expected."

I do not want to spend hours of my life on unpaid labour for a company that may or may not hire me. Give me the 45-minute algorithmic challenge that puts me on the spot every time.

I also strongly suspect your 3 month probationary period would be an effective anti-signal as well, useful for attracting desperate candidates rather than the ones you really want. You can't reasonably expect a senior engineer to jump at leaving a secure position for a 50/50 shot they might be unemployed in 3 months because they're "not a good cultural fit."

To your second point, I'm a fairly young engineer with 1.5 years experience, and I'm not leaving my secure job for a shot at being a good 'cultural fit' for some other company.

Financial security is important, and I would put up with a lot of shit from my company before I'd consider taking a chance on another one like that.

Although I know some companies (my current one included) have a 3 month "probationary period" where they've only ever let 1 person go at the end out of approximately 150 since I've been there. It's just to make sure you're not a complete goon.

Problem is, it could be really hard to tell apart a company that has a "probationary period" like mine, or a real time that they judge you at the end.

> work for free on someone else's proprietary software and there is a very real risk of companies trying to abuse this practice to extract free labour from candidates

This may happen in some places, but in practice I've never seen a task which actually could be applied anywhere. Most of the time these were toy projects, or simple exercises.

I think you'd easily notice if giving you the test was worth more to the company than all the recruitment time spent on taking to you. It's not free labour if you end up spending hours with each candidate, splitting up real work into "exercise chunks", integrating wildly different styles, validating results, etc.

I've seen this when the company switched the "exercise" as a no-wait-solve-this-one-instead which was fairly obvious it was a work-related task that was being farmed out to candidates.

The problem with all "contract to hire" schemes is you essentially set yourself up for failure on the labor marketplace. Unless you're offering some other compensation, why would any talented candidate take your contract to offer job over the firm next door that's hiring them flat out (assuming both of you pay market rates). Not to mention you shut yourself out of any nonlocal market.

Especially in the US, asking an employee to give up even more rights is a hard bargain. You run the risk of naturally selecting for employees that can't get hired anywhere else (which tend to either worse, or at the very least require more investment; something you're not willing to do or why have you made them use their time to do a take home and start this contract to hire business)

In my appraisal, more firms just need to recognize that they don't need half the technical skill they think they do. Building a CRUD back end or a mobile app doesn't take deep algorithmic horse power and the engineers you've managed to retain to administer the interview probably aren't qualified to do so anyway.

These are interesting ideas. It seems like a hurdle would be getting candidates to agree to the conditions. What incentive do I have to pick a company that requires a 3 month probationary period when I can just get very good at dynamic programming and topological sorting and ace a one day interview at another company?

Also, I find that take home projects in particular are biased against people without free time, eg, parents.

> when I can just get very good at dynamic programming and topological sorting

might work at one place, but the next will ask completely different questions. You can’t know everything.

The pool of problems asked at these places is pretty limited, which is why websites like leetcode are a thing. It's a shitty situation, but that's the reality.

I haven’t found that, one place will ask about CS, the next DBs, the next tools, and stacks have exploded.

You can read my resume and call a few of my references. You can ask me to explain my previous work. You can ask me how I'd approach a problem you've worked on. It's not very complicated, and for some reason software hiring worked just fine with this approach up until 10 or so years ago. If you have a bad hire, you make them do shit work until they quit, or you fire them. I've worked with a few bad hires over the years and the team adapted around them just fine and work still got done.

I think you’ve mentioned a HUGE part of the interview process that interviewers forget: you only have 60 mins. 45 mins if you leave time for questions (which you always should). It’s an incredibly difficult task, and deserves significant effort, as opposed to just thinking “oh interviewing is easy”

A recent experience I've had with programming screens, not whiteboard interviews specifically, is the lack of feedback. I'm given a programming problem (or a set of problem), given about 2 hours to do it, I do it in the allotted time, check my code, verify to the best of my ability that what I've come up with in the limited time is correct, I verify I'm passing the provided test cases and some test cases I come up with. Then it's basically a coin flip whether anyone follows up. No feedback, no reason why they're not moving forward besides maybe some generic HR response about my qualifications or 'decided to go in another direction'. Quite annoying and a waste of time on my end. Is this it? Is this really the best way to filter down the pool of resumes? Feels like it's a very high false positive rate and one that pushes all the time costs onto the applicant (multiply ~2hr by say 5 companies that want you to do a coding challenge).

I've gotten feedback, and even more frustrating than no feedback is demonstrably false feedback.

Google said I should try contributing to an open source project to improve my resume... when I had literally a million lines of code in a major open source project, and that was written on my resume.

Was it a mistake? Was there a mixup and had they interviewed me thinking I was someone else? Did they have a corrupt copy of my resume? More likely was it a throwaway comment from someone just saying something to be polite? No idea, but it's more frustrating than just 'no thanks' because it didn't even make any sense.

Imagine if you tried to improve yourself based on that feedback, applied again, and then they overlooked it again and gave you the same feedback!

That's some bullshit. Sorry that happened to you. You would think a company as well-endowed as Google would take the utmost care when selecting their employees. But based on this comment and others I have seen, it's clearly not the case.

This interview system is frustrating. I had 4 calls where I talked to the same recruiter thrice for this company I'm applying to. It doesn't sound like much but when you're in my situation wasting a few minutes is precious time. I'm driving 3 hours down and back to a full-day interview at said company. I had to take PTO. What do you tell your boss? I told em I had a drs appointment, luckily they bought it. I don't want to get harassed for looking for another job, it happens here.

Does it really take a full day to find out whether someone is a good programmer? I'd argue it takes longer. We just hired someone who washed out after 2 weeks without finishing a (significant) ticket.

Maybe instead of these nutty run-the-gauntlet interviews we should focus more on work-to-hire month long programs, with some guaranteed compensation if you fail(so that you are compensated for the risk of switching). I don't know. The current system is stupid.

I have gotten offers from a few major companies. But cramming this stupid Interview shit (What's the difference between an abstract class and an interface in Java?) when I've been running Golang, Python and Ruby for the past 3 years isn't fun. I should stop writing this comment and get back to studying.

> Maybe instead of these nutty run-the-gauntlet interviews we should focus more on work-to-hire month long programs, with some guaranteed compensation if you fail(so that you are compensated for the risk of switching). I don't know. The current system is stupid.

If you think you got shitty candidates with your old system, this would only get you desperate ones.

How do you get to a million lines of code on an open source project? At my full time job, 5k lines in a week would be a lot, and even at that fast pace it would take four years of full time work to get to a million.

A million lines diff yeah, not standing code, over a few years of basically full time as my PhD on a fast moving greenfield project. A lot of refactoring causes churn.

I could see how this might be an issue with someone early in their career who has a low-profile project or two, but your resume would stand out very quickly among the rest so for this to happen is alarming.

Feels like a very similar occurrence to what happened to the homebrew dev who got reject by google (albeit different circumstance to your false feedback)

The homebrew guy was subsequently hired by Apple, but later left, saying in a (now deleted) tweet that big company life wasn't his bag. Link from around that time: https://news.ycombinator.com/item?id=12276219

There's a non-zero chance that the Google interviewers were able to pick up on this. Those of us not directly involved only ever got one side of this particular story.

Wasnt it the case that he got offended over the fact that he had to go through the same process as other people? Hope I am not mixing him with someone else.

I happened to speak to a recruiter this week about Google. In-house recruiters are an eternally revolving door. They come and go, they aren't incentivized like the externals, and they often aren't well trained. So I can imagine them glossing over your CV and missing the important points.

Is it becoming an unspoken requirement to have a GitHub resume? I don't have any serious code on GitHub -- how screwed am I?

You can upload the code you already have in less than a minute so it’s easy to set one up if you want to.

I have a github account, with not much in it. And not much to add to it. I've written tons of code, but it was all under various NDAs and uploading it wouldn't be a good idea.

As an interviewer I've never looked at a candidates github. As an interviewee I've gotten a number of first interviews without having a github. It might help, and my friend at M$ says they look at it, but I don't think it is required.

Projects from when you were a student? I have my undergraduate project on there for example, from well over a decade ago, but it still gets a lot of interest.

Community service projects? I maintain a bibliography I have on there, and I write a local history book on my GitHub. I made a website for a conference on there recently.

Slides, notes and code from conference talks you've given?

Hobbies? I used to have some repositories with things related to the sport I play.

Open source projects you contribute to in the course of your work?

Notes and experiments you make while learning about technology like new languages and libraries?

You must have done at least something like those ideas at some point in your life?

I mean you obviously don't have to if you don't want to and I don't know anything about your personal situation, but if you do want to have a GitHub profile I'm sure there's tons of things you're involved in in your life that you could upload even if you work at the NSA or something.

yeah sure, i have some stuff i did for coursera data science courses up there. and a neat graph algorithm project i did for a take-home interview. i think they’re ok, but i was really asking if google et al want an impressive github resume. based on the comment i replied to, they might.

>Feels like it's a very high false positive rate and one that pushes all the time costs onto the applicant (multiply ~2hr by say 5 companies that want you to do a coding challenge).

It is, I wouldn't entertain companies that do this unless you really need a position.

This is the trifecta of bad interviewing tests:

- No compensation

- Stupidly restrictive time limit

- High chance of not getting feedback

Personally I would turn them down and then explain these three things. There are plenty of companies with less annoying hoops.

> - Stupidly restrictive time limit

This one kills the chance of my applying by itself. Turns what could be a interesting coding challenge into an exam, ruining the fun of it. I could see junior devs going through this to get some experience but why would anyone past that point in their career bother when there are so many options?

Because the companies that do the coding exams pay well, have high prestige, use tech that he likes, etc. It's not always so simple to just refuse to go through an annoying interview process, even if it sucks.

Of course there will be exceptions to any rule. But in general it is still a good rule.

> - No compensation

Curious if anybody has ever billed the interviewing company for their time if they didn't get the job.

Not the same thing but I’ve read that Square pays people for coming to their on site interview because it’s a full day. Unsure if that is still the case.

There's not much you can do about the fact that most prospective employers won't have a particularly good idea how to optimize the hiring process and even if they did, their incentives wouldn't always be aligned with applicants when it comes to questions of investing time.

But in a market like the current one, many developers can do some filtering of their own. When I'm asked to complete a test or exercise, over time I've made it a habit to ask questions like these:

- Do you have reference solutions that someone at the company completed on company time?

- Exactly how long did it take them?

- Do you have a rubric for evaluating submitted solutions?

- Will you share the reference solutions and/or rubric once I've submitted mine?

I don't need 100% positive/detailed answers to each one of these -- I know from the other side why they're not always there -- but how people respond seems to improve my early feel for (a) how the organization approaches process and problem-solving and (b) whether my solutions are likely to get a serious examination and useful feedback, which I can then use to inform my choice about whether putting in the time is worth it.

I recently went through interviewing at a number of companies. One had a hackerrank problem to solve. I was fine with it, took me a couple of hours to complete.

What frustrated me is that my solution passed all of the disclosed scenarios, but failed about half of the non disclosed. Neither the input nor output was disclosed. How do you expect someone to solve a problem when you dont disclose either the inputs or the expected output?

As a rule, do not expect feedback from companies. On the company's end, it's just not worth the risk of opening themselves up to potential legal liability to provide detailed feedback to any candidate. The new standard for responding to a rejected candidate is ghosting. The company has extended you a profound courtesy by bothering to respond at all.

Everything about this response is a poisonous and stupid lie. Detailed feedback is fine. There is no legal liability if you’re not discriminating against a protected class. Companies and individuals that behave this way are poisonous and stupid and best avoided.

Maybe you wish this was so, but it does not appear to be in practice.


Sure, and since companies aren't paranoid about discrimination lawsuits... oh wait.

The best part about these types of interviews is how they don't even treat you like a human being. There's absolutely zero interest in you whatsoever, and moreso every single word that comes out of your mouth is by default treated as a lie until they've had you submit to their Leetcode questions and determined you to be worthy of even speaking to. It's why I've become so incredulous at even being asked anything in the first round; anything I have to say here is completely meaningless and has no bearing whatsoever on any kind of hiring decision until that test has been passed. The utterly degrading inhumanity of this process had driven me to an emotional breaking point until I started interviewing outside the bay area. And what do you know? It's a completely different world. To anyone else stuck in this nightmare, just leave. Another 20% take home pay is simply not worth your sanity.

When you say outside the bay area, do you also mean companies are not 'tech-first' type companies? (companies that hire devs, but their primary domain is not just some app/website/saas) I've applied to many jobs in Canada, but I've still noticed a large tendency for companies to put you through a screen even before they speak to you.

Does interviewing outside the Bay Area mean interviewing in places still around north Cali? Or going away from that region entirely? I know SF, Bay Area, and SV are different, but i have them all sort of confused and lumped together.

I like to imagine the movie trailer voice over guy

“Do you have what it takes?”

“Do think you’re tough enough!?”

“You call yourself a....”


“Then... SORT... MY... LIST... WHILE... TALKING... OUT... LOUD”

But really, I feel like the whole process is uniquely American, kind of like crossfit. Very intense very trying. Like Nike; “JUST DO IT!”

The problem about this very intense “game” of interviewing is it’s for a job, for you to eat, to afford healthcare, to survive. To afford basic necessities and save for retirement. To buy a house. To start a family. To afford a car. Or even simply to not be just another body stepped over on Market street.

You've probably enjoyed 7 some years as a web developer, as a productive team member or consulting for happy clients. Now some stranger is dangling a carrot in front of your face telling you to implement an LRU cache under bright fluorescent lights while badgering you with “what are you thinking, I need to know what you’re thinking” ... after you’ve just spent the last 5 hours talking about your work history etc

#1 on that list is enthusiasm for the company. Really...? So, you gotta be a good bullsh!tter? I can see this for small startups, because passion will take you to places. But for large companies, their software products are so diverse.

I work for a manufacturing company and my application space has nothing to do with manufacturing. Every space has their challenges and pitfalls. As long as you have good tech, good people, and aren't doing anything unethical, I'll want to work for you.

Also, I've thought about the interviewing problem a bit. I don't do the interview for my team...but if I have the opportunity to interview and was given free range, I think I would create a small application using our tech stack. Put some bugs in there, put some bad practices, and let the interviewee fix it. Talk about the tech stack, how to scale it, design trade offs, etc. IMHO reading code and maintaining code is more important than knowing bfs and dfs by heart.

This is a decent start, but then again remember you only have 60 minutes. And what might seem relatively easy to you, might not be so easy to someone with a time limit (60 mins), and pressure (trying to get a job you want).

I'd say rather than practicing interview questions, work on a side project that really stretches your technical ability. And a hard project, something that you don't even know where to start, not just "I'm going to rewrite this todo app in vue.js". I think that gives your brain more of a workout than droning through interview questions day after day. Even though you could say "you don't run marathons to practice for a sprint", just in my experience it works better. The interview practice websites are too easy to get distracted from, or look up the answer, or whatever, and your brain really doesn't get the workout that a solid long-term low level project gives it.

Plus, at the end, at least you have a project you've done.

Sadly there tends not to be much correlation between real life programming and interview programming. Most of the software engineers at my company feel that we couldn't pass our company's interviews because we're out of practice.

Real life programming for work isn't really the "hard" programming I'm talking about. Create a language runtime, a distributed database, a video player, a network stack. I think if you can focus on something like this in whatever free time you have available, you're exercising your brain a lot more than the little leet speed drills.

Unfortunately, this doesn't translate to interviewing in silicon valley. It's a completely separate skill unless your job is explaining out loud various algorithms and data structures to other people to solve a variety of contrived problems. I'll admit I've done things that are close to this for real world situations but it's maybe once every month or 3.

Not a situation for /most/ of us on a regular basis.

No, not a work project. Agree most of our jobs are pretty banal, figure out how to get this css to center correctly in IE6. Rather, selectively choose a side project to do that likely will involve some interesting data structures and algorithms. That will give your brain a really deep workout and it'll be more prepared to go through silly interview questions.

I think that something that should be mentioned that these coding challenges are the norm for hiring out of college. It doesn't matter (at 90% of companies, from personal applications) that you have a resume/portfolio of cool and interesting project/experience. All companies count on this coding interview to screen you. Some companies give you rather outlandish questions to screen you on the first try. My cool personal projects have never been mentioned by a interviewer.

I wasn't suggesting doing projects in order to talk about them at an interview (though if you can, then great!), but more about selecting challenging projects that give you more of a brain workout. I have found this more effective preparation for interview questions than just running through practice questions.

I started on a side project after getting rejected from one job and the interviewer on the next job said they read the code on my project and said it looked great. This was a fairly difficult project that I'm still working on today. 8 months later and its almost ready to use :p

I'd recommend actually doing both.

Find a good project and make it work well. By this process you will hopefully uncover and learn practical details, skills, programming language, how to write high quality code...

And learn Computer Science (algorithms, structures) to show that you are smart and can learn stuff and when given a problem you can solve it efficiently.

When hiring, - we definitely check if you have something interesting on github - we ask both computer Science questions and then some more practical questions (e.g. if you are Web FE, then rendering some interesting situation, maybe optimizing page speed...)

Yeah that occurred to me just after I submitted the post. I'll still stand by my own experience though. I felt so much more prepared on this latest round of interviews after having worked on a type inference engine side project for the previous couple months, than I ever did after spending a couple months stressing over leet. Just, brain felt stronger for whatever reason.

And I think it makes sense too. When I conduct interviews, I look more for how is this person thinking about the problem, than can they solve the question in isolation in the allotted time. Because unlike leet, it's not in isolation. There's always some back and forth, and that's where I think leet's shallowness shows.

Homebrew isn't particularly technically complex and in the follow max even says as much.

It probably isn't brain stretching.

I'd agree that doing projects is a better way to learn in general, but some level of practicing interview questions is needed when applying to companies that do whiteboard interviews. Projects can boost your resume and get you in the door, but they're not a huge help in passing some algorithm question.

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

The under duress part is the dumbest part of coding interviews.

I understand the approximation of small coding challenges, why explaining your thoughts is beneficial, as is understanding how a candidate approachs problem solving.

Causing duress to a candidate purposefully has no value what-so-ever in the workplace.

I think the interview process itself causes duress to candidates intrinsically. There is probably no way to eliminate it completely.

That said, there probably is a reason for testing candidates under duress. Some companies may want to push people hard, and knowing they can deal with stress is valuable.

I don't agree that programming interviews are conducted to see how well candidates will fare in a dysfunctional workplace.

Anecdotally, programmers thrive in quiet environments where they can have focused uninterrupted time. As open-offices have become the norm, most programmers have headphones they use to isolate background sounds.

Constantly peppering candidates with questions while they are trying to do a task that is mentally intensive is not close to the type of stress candidates face on the job.

Even the most work-life balanced places do these same types of interviews.

PSA: if you take TripleByte's online quiz, they don't have the capability of giving you the results of the quiz. At least, that's what I was told when I took the online quiz -- they couldn't share the results with me because the quiz is "adaptive" and scores and questions vary each time the quiz is taken. (I have no idea how they're able to do anything useful with the quiz results if they don't record them and the scores vary so greatly.)

I have no faith in TripleByte or their process at this point, especially since I feel I was somewhat taken advantage of (I did the online quiz expecting to get some feedback -- isn't that the point?). I'm certain they will use the collected data from my quiz to build their product, though.

I did it within the last week and got scored in 6 areas. It's just a whole number out of 5 points in each area, no further info.

I did the 2hr phone interview later and received my interviewer's notes on my performance, which were more detailed and helpful.

> These are concepts that are far more common in interviews than they are in production web programming

So of course let's talk about a dozen different types of them!

Welcome to Ford! To be considered for this position, please list every GM Model from 1983 to 1987.

The last good paying work I had I somehow passed the coding interview, but I bombed out of the last few I had and went back to basics. I signed up to Project Euler and Hacker Rank and have been doing problems from them.

What I do is start the Linux program "recordmydesktop", and then go about solving the problem as if I am interviewing, i.e. on the clock.

One thing I noticed is these programs use maps, characters, use 64 bit long numbers, do string manipulation, do certain type conversions and so on more than I usually do programming. Some of these things I would usually look up, such as how to type convert a character '7' to an integer, or create and populate a multi-array and things like that. So I made sure how to memorize how to do these test-tending things.

Then I watched over my recordmydesktop sessions to see where I ran into trouble. I noticed array one-offs were a problem - getting an index out of bound error, using < instead of <= etc. Or I would declare a variable before a loop and use it initially, but forget to assign or reset it at the end of the loop when it needed that. Sometimes I would declare a variable like k and then re-use it in the same method. Also, if I ever have to switch to a web browser to look up what call does a string reversal, I note that as well, and if it is common enough, I memorize how it is done so I don't have to look it up again.

Memorizing the string manipulation, map etc. functions is already working for me. I am getting better at some of the other problems, like not assigning/resetting variables at the end of loops (I put a comment next to them that they will need to be assigned/reset, and then do it later, and then erase the comment). Some I still have to work on, like reasoning about exactly where the array boundary is. These aren't things I mess up necessarily, but things that slow me down, and cause bad compiles or runtime errors.

I can already see the improvement in the problems I am doing. I had been letting myself naturally memorize some of these things, I guess it's not so bad that I am memorizing more of them that I may need.

For anyone interested, I took notes on The Algorithm Design Manual for JavaScript if you are studying chapters 3 through 5 like the blog post suggested:


Thank you!

Is it just me, or does this read like a massive farce? That everything that Triplebyte is trying to solve they just... can't?

I just went through a small exercise with a company ... we did an hour screensharing on coderpad.

basic exercise was in php (mix of systems, but there's existing php to touch). financial service industry, and they'd mocked up a rough idea of a typical problem. The example code clearly wasn't production, and was generic, but also illustrated the problem domain well enough for them to get an idea of how well I could adapt.

I got through the 'nut' of the problem in about 10-15 minutes, talking through some issues. One thing I'd ignored (and said I'd be ignoring) was date handling - they wanted some date sorting thing, but since this was just 'raw' code without any good helper libraries, I suggested we punt on that (and I named the libraries I'd typically use for date handling).

There was one spot where the interviewer suggested the ?? 'newer' null coalescing, where I'd been looking at doing some 'array_key_exists' checking. he'd suggested that the ?? syntax was easier and more compact, and I'd countered with I'd prefer to be more explicit about the specific keys I wanted to check for, and that ideally I'd be using a class or some other more defined structure to ensure some degree of valid data shape as a first level of sanity checking. I'd felt I may have pushed back a bit hard on that point, but, we moved on.

After the first 15 min or so, we'd spent another 15-20 talking about different ways to do other types of error handling, some potential performance issues, etc. High level stuff, mainly, which... there's only so much you can do with coderpad (my jetbrains and vim muscle memory did me no good in the browser!)

All in all, though, I'd felt it was a decent exchange. They were able to show a 'real' problem without relying on any proprietary stuff, it was difficult enough that someone junior probably would have struggled a bit more, the guy on the other end was pleasant, and engaged appropriately (responded to questions and casual banter, and interjected now and then to ask questions and give feedback in real time). It was probably one of the better 'tech interviews' I've had (although I haven't had many in recent years, so, hard to compare). It did seem better than many I read about, and certainly better than some from 10-15 years ago.

I'm the CoderPad guy dropping in to mention you can switch to vi keybindings in CoderPad settings!

Thanks. I didn't see that up front, and was more concerned about the timed aspect of our meeting/review, but I'll keep it in mind. Thanks for the tool!

(I think I made a similar comment to a similar submission a while back)

I suggest this type of interview:

Both the interviewer and interviewee get a problem to solve and they work together to solve it. It should be new to both of them, so the interviewer can better assess its level of difficulty without the bias of knowing the solution beforehand. This will enable natural empathy for the candidate.

It also shows how interaction would look like in every day kind of work. You can learn a lot about another person's skill by doing pair programming.

Logistically speaking, you can whiteboard the design/code, or sit around a big screen for the coding part, with whatever tools/IDE the candidate likes to use (s/he should be writing most of the code, even if the solution/design was a common process).

It's a programming "test" right? Sometimes I wonder if it's better to solve the problem in isolation, to show that I can sit on a problem and go at it, or to solve it in a collaborative manner with the interviewer, to show I'd play well in a team.

Sometimes when I read people saying the end goal is not to solve the problem weird. Does that mean those who solved the problem alone by losing a few hairs actually scored worse than an outspoken candidate who solved it with help from the interviewer?

You can ask them what they prefer. Also, communication is an important element - in real work you may be spending time on something that's already obvious to someone else, or getting stuck on an approach which is known to not work.

I think actually solving those problems or failing in the end is random (unless you know the answer already). But if you get a good chat out of it, it may be in your favour.


I came up with my own set of questions that hopefully show how a person can deal with human complexity at work (the bulk of our issues), rather than memorizing algorithms. Some people don't like it - but it works for me: https://www.5whys.com/articles/a-realistic-hackerrank-develo...

I recently came across some videos from Interview.io, which seems to be in the same business as triplebyte, the company behind TFA.

I thought the interview seemed quite nice. Is this the type of coding interviews, HN is always complaining about, or is it some rosy best-case exhibition?

Example interview: https://youtu.be/tj_sBZw9nS0

> Mentioning other offers in an interview heavily biases the interviewer in your favor.

Is this really true? Also, how do you just mention offers? And will the programmer interviewing me really care? Should this only be done at the HR stage?

Like, what's a good way to let the other person know that they're not the only one.

Is there any evidence that coding interviews aren’t just tests for 1) general fluid intelligence or 2) memorization?

Triplebyte/HackerRank etc is a great filter for companies that view their developers so low they would subject them to such pre-employment screens that no other employees in the organization must jump through.

I dislike most competitive programming sites as a hiring method, but Triplebyte works more like a recruiting firm. They do their own phone interviews that cover a large breadth of programming topics including a number of things that are often missing from whiteboard interviews, such as parallel programming. Out of the many times I've been interviewed my Triplebyte interview is in the top 3 that best represented my skills.

I really enjoyed triplebyte's online software engineering challenge. One of their ads caught my eye about nine months ago, so I gave it a shot. I thought the challenges covered topics concerning software maintainability, implementation time trade-offs, investment value judgement calls, interface design, separation of concerns, etc. very nicely.

I'd never thought to interview on some of the topics presented until I took the quiz. Worthwhile Saturday evening accompanied by a beer or two.

I took their test once for fun once a few years ago. A few months ago they suddenly added me to their "newsletter". Every week I would unsubscribe and the next week I would receive their spam like clockwork. I complained that they need to fix the unsubscribe link. Two months later some hapless customer support person gave me a very informative email about clicking the unsubscribe link at the bottom of their emails.

Not a company that has things together to say the least.

Same experience here, did their challenge once, only feedback they will give you about your performance is something like "exceptional" and then they keep spamming you every day even if you said in the questionnaire you aren't interested in a new job.

<irrelevant comment deleted>

you probably wanted to comment on https://news.ycombinator.com/item?id=19344146

The key to success in any interview, but especially in a programming interview, is practicing as much as possible. It's not enough to start just a few days before the real thing. The best method of preparing is incorporating your interview prep into your everyday coding practice, so that you'll never fall behind, even if you aren't currently searching for a job. But the plan "to practice" is too vague and leaves a lot of programmers unsure of how to get started in the process, which can be overwhelming. If you're frustrated and aren't sure how to get going on your coding interview practice, follow these steps to get started.

1. Review the basics. Even experienced programmers and engineers can get tripped up when questions about algorithms and data structure come up. If you haven't yet mastered the basics, focus on this for a few weeks or months to get yourself ready to tackle the bigger problems. It's crucial, not only for a coding interview, but for the entirety of your professional career, that you understand the basics. They are your foundational skills upon which you will build and master your expertise.

2. Solve coding problems and work on projects. Online coding practice problems are a great place to start. Apply your knowledge and work on projects you enjoy. Write code. Build things. Put your skills to use. This should be the fun part - if you aren't enjoying the journey and the process of building your coding skills, you'll have a difficult career as a programmer. Sure, there will be moments of frustration where you'll want to smash your computer screen and throw your mouse at the wall. But forge on. Keep trying. Find those bugs and destroy them. Build great things, and immerse yourself in online forums and other communities where you can turn to for help when you really get stuck.

3. Use online coding interview platforms for practice. This is a great way to get exposure to how the real coding interview will feel. Smash your nerves and anxiety by conducting a full coding interview with a partner. On platforms like Pramp and Leetcode, you'll get paired with another programmer of a similar skill level, so it will scale to your ability. Together you'll experience the coding interview from both perspectives. Performing the role of the interviewer and the interviewee will teach you a lot. After the mock run, you'll both leave each other feedback, and this is a great thing to have to tailor your practice schedule and for identifying what you need to work on the most.

Applications are open for YC Summer 2019

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