11 ms·

I've been a software engineer for 10 years and I can't do interview questions

115 points by tempw 10y ago

NTDF9 10y ago
You know the process is fucked up when experienced professionals (with a track record of delivering projects) start complaining about how companies don't look for the ability of delivering projects.
- peter422 10y ago
  Every engineer says they delivered projects on time with great maintainable code. Unless the project is open source, they often have no way of giving any evidence. I'm not saying whiteboard interviews are the right way to interview, but in my experience you can't trust people's judgment about themselves and their skills. You need an interview that is equally fair to the person that will exaggerate their past successes to the people that are more reserved or the people that don't have much experience yet.
  - techterrier 10y ago
    In other engineering disciplines there's accreditation and references for this sort of thing. No CEng for software engineers sadly.
  - falcolas 10y ago
    Like a pair coding project on a computer with access to their internet resources? Can find out a lot about a person in a one/two hour pair coding interview.
  - brandon272 10y ago
    > Unless the project is open source, they often have no way of giving any evidence. Isn't this is the case for every job applicant in every industry? You look at the evidence available of someone's work history and make a judgment call.
  - enraged_camel 10y ago
    >>Every engineer says they delivered projects on time with great maintainable code. Unless the project is open source, they often have no way of giving any evidence. Okay, but having them solve coding problems on the whiteboard doesn't provide any evidence of that either. If they say they delivered projects on time with "great maintainable code," ask them what makes code maintainable, have them provide examples (using pseudocode) and talk through each one. Ask them about a time when they had to sacrifice maintainability for time, application performance or user experience. Ask them what they learned from the ordeal. In my opinion you're going to be much more likely to accurately judge their expertise level based on their answers to such questions. The reason is simple: one can memorize whiteboard questions prior to the interview. They can't, however, bullshit their way through questions that are experience-based - and if they do, well, you should hire them immediately because you just found yourself a great salesperson!
    - joshuamorton 10y ago
      I think its just as easy to memorize 'design' questions as 'whiteboard' questions. Not every whiteboard question is "implement a linked list", in fact I'd argue that's very rarely the case (or maybe I'm wrong and I've been insulated from these interviews). Most of my whiteboard interviews have involved a relatively small amount of actual coding (I think I had one question that was more than ~15 loc in python, and I've interviewed a few times). The rest was taking a relatively abstract problem presented in English and understanding it, removing ambiguities, and discussing tradeoffs with the interviewer. After that, a recursive function or a hash map or whatever is really easy.
      - NTDF9 10y ago
        As a person who successfully solved a problem but was rejected because of coding style (on a whiteboard, not on IDE), I am respectfully wary of the term "removal of ambiguity".
        joshuamorton 10y ago
        How do you mean? By "removal of ambiguity", I'm talking about when someone poses a problem like "Write a function to recognize an IP Address". My first thought is then "ipv4 or ipv6", because that problem is underspecified, and I don't want to inadvertently solve the incorrect problem (which is kind of a case of the xy problem)
  - mtberatwork 10y ago
    > you can't trust people's judgment about themselves and their skills. Unless the candidate is fresh out of uni, any qualified candidate with experience should be able to provide at least several solid contacts at previous employers from which to obtain this information.
    - dpark 10y ago
      References from co-workers aren't really that valuable. Many people have no qualms about giving glowing reviews for friends, even if those friends don't really deserve glowing reviews.
    - deleted 10y ago
      [deleted]
nix0n 10y ago
This is by design, they're looking for students.
- istorical 10y ago
  Students, super high achievers / superstars, and people who are willing to "play the game" and re-study everything for 2 weeks or a month.
  - justinzollars 10y ago
    this is a good point. Every successful interview I had was the result of about a month of study time. I think the only way I could make it through an interview is by quitting my job and studying for a month!
  - hackerblack1 10y ago
    LMAO.2 weeks? HA! Currently a graduating student that goes to one of those top schools. Do you really wanna know how long many of my peers are studying for these interviews? Months!!!!! I have a few friends that spent all of last summer after their daily internships doing interview prep for fall recruiting season. I also have a cousin that spent 5-6 months unemployed(given he did a masters/bs in ee and not in cs but wanted to move into the field) doing interview prep and just landed offers from Google and Dropbox. The competition is absolutely ruthless.
    - ad-hominem 10y ago
      Well, the people you interact with studying for interviews have never interviewed for a full-time position before in their field. They have no experience. They do not command a significant salary compared to the established professionals in their field. There are a lot of them, and they all want (the best job they can get || any decent job). They all just graduated and are unemployed (presumably). So yeah, of course they are all going to go crazy studying. A programmer with 5-10 years experience, who knows what they are doing professionally and has had a few jobs already (been through the process), and uses these skills on a daily basis is generally not going to spend months studying algorithmic questions. 2 weeks seems a lot more reasonable. Without studying, most worth their salt could probably still write a tree balancer or linked list from scratch even though it would be somewhat ugly. The studying is not to solidify and memorize all this stuff, it's just a refresher.
shadowcodex 10y ago
It's all become a game now. If you spend enough time on sites like codefights and hackerrank and know all the algorithms you can land a job. However, if you aren't prepared for these whiteboard interviews you are screwed.
mixmastamyk 10y ago
Same here, I've stopped doing tech interviews, they are a waste of time. Hopefully my freelancing network will continue to grow and I can avoid them forever.
- JCDenton2052 10y ago
  Freelancers do no tech interviews?
  - protomyth 10y ago
    When I did freelance work, it was all about connections and reputation. "Hey we got some problems with our overnight processing, you've done that before" type stuff.
  - mixmastamyk 10y ago
    They do some, but I find it more of a formality once you build a track record. The risk is lower than a full-time employee.
  - tonyedgecombe 10y ago
    Not often, I think I only had one in the time I was freelancing, networking is everything.
runT1ME 10y ago
But could all practicing lawyers pass the bar right now in their respective state? I'd guess no. The problem is not the questions necessarily, it's that you have to study a bit and do the same goddamn interview questions at multiple companies, sometimes with very different interviewers. Some are helpful, some make me nervous, some are asking the hardest possible questions without warmup easy questions, etc. Whiteboard or live coding is not the problem. Bad or untrained interviewers are, along with the fact we can't do one interview that proves to multiple companies what level we are at.
- shadowcodex 10y ago
  However, should a practicing lawyer have to re-pass the bar in order to land a new job?
  - snerbles 10y ago
    Are we going to make the PE exam a requirement for the title of "Software Engineer"?
    - eternalban 10y ago
      If "software engineers" want to be treated like "professional engineers". Licensing has been proven to work for other engineering fields.
    - prions 10y ago
      It really should be considered. I'm a registered (civil) EIT. IT would help towards the ambiguity in hiring and the ever increasing absurdity in interviewing. Especially since the conflicting statements of "software jobs need protection to ensure good salaries" and "everybody needs to code" are all to prevalent here. Being a PE means you have a certain level of experience and skill. It's a distinguishing feature and sets you apart as a "real" engineer. Additionally, it holds you to an ethical code. What continues to astound me is the lack of rigor and ethical backbone coming from engineers in important places. Yeah you're not building a bridge, but incidents like Volkswagen and Yahoo could have been prevented if people's jobs were bound by not being unethical.
jstewartmobile 10y ago
I'm kind-of on the fence about this topic. On the one hand, algorithms is a broad subject, so there's a large hole for false-positives and false-negatives to slip through. Sometimes it's like they'd pass on Gerry Spence as a trial attorney because he flubbed their question on tax law. On the other hand, can't totally drop the brain-teasers because you'll need all the IQ points you can get before the corporate retardation sets in.
- hughes 10y ago
  Does ability to solve brain-teasers correlate with a drop in "corporate retardation"?
  - jstewartmobile 10y ago
    Everyone gets hit by the CR, so it probably doesn't hurt to start with a higher baseline.
  - deleted 10y ago
    [deleted]
- abraves10001 10y ago
  Kind of off topic but I love relating programming to law. Both are enormous fields where no one has mastered all fields but the general populace (non-tech/legal) fails to grasp that. The interview process for engineers seems to have failed, to some extent, to understand this as well.
  - jstewartmobile 10y ago
    Definitely. I've had some algorithm-y interviews where I solved it in an original way, and they were ready to marry me off to their prettiest daughter. Then I've had others where I didn't even know what the hell they were asking, all requests for clarification were met with repetition of the original question, and both of us were probably wondering: "Is this guy stupid? an asshole? both?"
ep103 10y ago
I call bullshit on this train of thought. I've been reading about this on HN and reddit for years now. This last December, I was promoted high enough, that I could design the entire interview process (with executive help) for my teams. Which was important, I very much need to hire some people. So, keeping posts like this in mind, I designed as follows: Phone Interview - We talk about you, the company, etc. Then a few technical questions. Do you know certain things about js that make me think you are genuinely familiar with the language (as opposed to just jQuery)? Do you know certain things about sql that make me think you are genuinely familiar with the technology (as opposed to just using a table designer)? Assessment Test - Do a quick crud app, that will require some thought behind how to query the data. Make a point when talking to the prospective applicant that the code will be read by the team members they'll be working with, so while you can do the test quickly, please spend enough time on it that we can talk about the code, your choices, etc going into the technical interview. Ie) don't just link together 3rd party plugins. Actual Interview - Interview with leads, interview with actual team members. Offer both use of Visual Studio / SSMS / IDE of choice or whiteboard. Ask questions about technology in general. Ask the applicant to explain how he'd design out a new feature. Change the feature spec, so that there's a little bit of a hard problem. Have to populate a tree from flat sql data, or aggregate data from a service, or some other not-quite-an-algorithm question. The RESULTS? Recruiters figure out what questions you are most likely to ask during the phone interview, and school the candidates. The assessment test? No one bothers, everyone just hands in the simplest 3rd party libraries plumbed together with shitty code. Was the question select top per group? How about top 1 *? The really good devs shine through here, but a huge percentage don't even bother. Actual Interview? No one uses IDE / SSMS. All of them choose whiteboard. The ones who genuinely know how to code, have no problem answering, and would be fine answering algorithm questions straight out. The ones who can't, get confused somewhere or other. They try to implement hacks around the problem (I'd have the dba do it), then fail to actually solve the question. So In Short? I completely understand where this guy is coming from. But I also think, that at this point, I'm so tired of interviewing people who clearly don't care about their craft, that I want to start asking nothing other than algorithm questions... because the guy or gal that actually answers them will actually care about their craft. And at least with algo questions, I can change the question easily, and frequently. Coming up with real code problems, and good probing questions is much harder, particularly if they're going to have a short shelf-life before recruiters start training their candidates with answers.
pgtruesdell 10y ago
Form over substance, as usual with large bureaucracies. Unfortunately, tech seems to view the biggest and most "successful" company as the model way to move forward, instead of throwing up the middle finger like they used to. It's sad to see the transformation of Silicon Valley to a pseudo-government style group of mega-conglomerates. The next batch of real innovators will not be from the Valley or be from Valley culture.
- jstewartmobile 10y ago
  Yep. Used to be, the dream was to beat Bill Gates. Now the dream is to get bought by Facebook.
  - omouse 10y ago
    The dream was to make your own rules (which includes a ferrari, a private office and all sorts of perks). Getting bought by Google, Facebook, etc. is the new way of getting "fuck you" money.
- LordKano 10y ago
  I worked as a programmer for a promotional marketing company and their modus operandi was to copy everything they could from their biggest competitor. Eventually, it even got so bad that we were instructed to copy, word for word, certain disclosures from the competitor's web site. The big competitor is still the big competitor and my former employer is still doing OK but they'll never catch or pass anyone by copying what they're doing.
NikolaeVarius 10y ago
I don't quite understand this point of view and the whining. Why is it that Software Engineers feel the need to whine about these technical interview questions? I don't think many of these are THAT technical either, just requires some practice. I dislike brain teasers, but I don't think Algorithms questions are out of line, even if you might not use them. I graduated with an Aerospace Engineering degree. While I don't exactly remember how to derive the Normal Mode of a wing, I wouldn't have any issue relearning it for an interview. For my first job, I was asked questions that had very little to do with my day to day but I still answered them and didn't complain.
- falsedan 10y ago
  > Why is it that Software Engineers feel the need to whine about these technical interview questions? Because they're pointless for the vast majority of positions: why make me learn something for the interview that I'll never use again? This offends many engineers' sense of laziness. Because it's a pithy indication about what's wrong with tech interviews: we can't ask 'are you good at delivering with weird requirements' (because the candidate says 'sure I'm the best'), and we can't check their ability to do that in 45-60 minutes. Instead, we use these shibboleth questions to see if they are like other engineers (who can deliver etc.) Because it's gatekeeping: if you didn't study algorithms or have the time/energy to keep it fresh, you can't get past these interviews and get these jobs. It doesn't matter if you'd excel if you don't have the same opportunities as the normal privileged young white male engineer. Because it's inefficient: plenty of engineers could perform well in the position but get screened out by these imprecise questions. Sure, for a startup of 4 employees, you can't settle for great and have to keep rejecting until you get the best, but for a mature stable company, you want people with solid skills and abilities who can learn (how to do algorithms) on the job.
  - NikolaeVarius 10y ago
    None of that is specific to software engineers. My non software-engineering Interviews contained tons of questions that aren't completely relevant. For example, describe in detail how pressure and velocity are correlated in each turbofan stage and how they affect efficiency. Describe what isentropic flow is and how it relates to lift. I also hate getting random whiteboarding questions, but I'm not going to complain about it. If I really want a job I'm going to study for it.
dbg31415 10y ago
Hiring at most companies is fundamentally broken. We have no way of knowing if someone will work out, so finding ways to rule people out makes it seem like we did our job in the hiring process. Some Wonderlic-type questions, the person asking them gets to say, "Well, look we have some quantifiable way of measuring applicants." Total BS. No cure for it, other than to not turn around and be that asshole once you are hired. We should be more open about what the criteria is; hiring comes down to a few gut checks... do you like the person and think they will fit in, do you feel confident that they can do the work you will ask them to do, and are they in your budget? Unless you work with a person over time, there's not going to be any way of knowing how they are as an employee. If they are smart, if they keep up on current trends, if they are a good communicator (and any good at communicating inside of your organization), if they care, if they show up on time, if they are conscientious or just pass the buck, if they are a hard worker, if they are opportunistic / selfish with praise... Anyway HR needs to justify itself so we can't just throw darts at resumes... but essentially that's all hiring is. Trying to get a sense of someone quickly, cheaply, and correctly? Nah, just pick 2... at most.
JCDenton2052 10y ago
The prevalent thinking is that algorithmic skills transfer very well to other problem-solving skills. This is especially the case in Google, Microsoft, Facebook and Amazon who ask a lot of these questions. I do not necessarily agree with it, but it is the way things are. It's just another skill that can be acquired with proper effort and concentration. I can recommend "Cracking the Code Interview", it is chock full of these problems.
throwaway26960 10y ago
The interview process is great for employers... 1. Make qualified job interview candidate feel stupid by asking difficult questions unrelated to the job 2. Offer candidate low salary and argue that they barely passed the job interview 3. Profit Best solution I can offer is to not play their game. You'll lose no matter how hard you try. You're better off studying marketing and psychology for job interviews.
- falsedan 10y ago
  > You're better off studying marketing and psychology for job interviews Well, yeah. You should know how to sell yourself (to get past the resume screening process) and analyze the company's goals/culture/intent/desires (to avoid working at the next Uber).
- civilian 10y ago
  Studying an algorithms book (like Cracking the Coding Interview or Programming Interviews Exposed) is also an effective way to "hack" the interview. :-P
- Vekz 10y ago
  Great points about marketing and psychology. once you've won the lottery and got a whiteboard question, that you've prepared for. You additionally have to win unconscious biases of the interviewers and exhibit behavior that makes them judge you as a trusted "cultural fit" tribe member
  - deegles 10y ago
    Sigh. I completely crashed and burned at a phone screen once with a question that was easy but required knowing a bit shifting trick. I knew that the trick existed because I had glanced at it while studying and thought, "no way they'll ask that."
misja111 10y ago
I was in the same situation a couple of years ago. I had over 15 years of experience, was invited for a technical interview at Amazon, and failed. At first I was irritated, just like the author. But then I decided to turn this negative energy into something positive and followed a couple of courses on Algorithms on Coursera, also I discovered Hackerrank. And I found out that I actually loved solving algorithmic problems! Now it is a couple of years later and I actually was able to land a job thanks to my new skills (not at Amazon though). But what's much more important: I found a new hobby that will keep me entertained for many more years.
- mavelikara 10y ago
  My story is the same too. I was a promising junior developer when I went to an interview at Amazon. Got my back handed to me. I was upset, but decided to work on it. Read a few books on the topic, and I no longer find these interviews difficult.
  - nojvek 10y ago
    Before I interview I mention that I am uncomfortable with whiteboards. I prefer pen and paper. It's faster to write and feels a bit natural. Only one company denied me the request and I didn't go ahead for them. Their loss. I've also found having a github profile where you've files issues on projects and made a couple of commits really helps the chances. It gives more data than a resume. At one interview, the interviewer read some of my commits and he said "I don't have any doubts you can code, but I wanna ask you about design". He went on to ask why I did things in a certain way. But seriously. "Say no to coding on whiteboards".
    - wry_discontent 10y ago
      I'm the opposite way. I prefer the whiteboard to pen and paper.
- k__ 10y ago
  I was in the same situation, but I simply stopped doing these kind of interviews and started doing contract work. The pay is better with less strange questions asked upfront.
justinzollars 10y ago
I think tech interviews are broken. I've been on both ends of the equation and the process usually seems both unfair and random. I work hard, get good reviews, have nice looking work that doesn't crash and scales - and I can't interview either. I've also interviewed great candidates that get shot for no reason at all. That said, it is a numbers game, if you need a job keep at it - you have not other choice. But in the long term I think our community needs to chill out a little bit.
peterjones2 10y ago
I am just beginning my studies in computer science. I find discrete mathematics, data structures, theory of computation and algorithms to be the most interesting aspects of computer science. If I took an undergraduate algorithms course (Chapters 1-3, 7-9, 11-13, 15-16, 22-24 from CLRS) would I be prepared for most interviews? I noticed the graduate course overlaps with many of those chapters and also cover: chapters 18,21,25,26, 29-32, 35. Ideally, I would like to take both courses out of pure self-interest.
- GrumpyYoungMan 10y ago
  As others have suggested, get a copy of "Cracking the Coding Interview" and review the questions therein. If you can answer those questions easily, you'll have an easy time at the average interview. If you want to prepare to interview at one of the top companies, then afterwards procure a copy of my secret weapon: Aziz, Lee, & Prakash's "Elements of Programming Interviews". The questions there are an order of magnitude more difficult. If you are able to apply the CS concepts you are learning to questions of that difficulty, all doors will be open to you.
  - deleted 10y ago
    [deleted]
  - peterjones2 10y ago
    Thanks for taking the time to answer my question. This is my first time commenting on HN and am being downvoted for my legitimate question.
    - GrumpyYoungMan 10y ago
      Just a helpful tip: mentioning being downvoted is against the HN guidelines and usually attracts more downvotes. pkahler's sibling post also brings up an important side point: beyond the basic core, what you study really needs to be focused on what aspect of the software industry you want to be in or are likely to find yourself in. While I, too, encourage you to take C/asm courses or whatever your preferred focus is, the bulk of the jobs in the industry are in creating web sites and business systems (much of which are so-called CRUD apps; see https://en.wikipedia.org/wiki/Create,_read,_update_and_delete https://en.wikipedia.org/wiki/Create,_read,_update_and_delet...). Even if you plan to do something else, a course in databases and concurrent programming will stand you in good stead as a fallback if your career doesn't quite go as planned.
issa 10y ago
I worked at an unnamed big company where the interview process involved being interviewed by a PHP expert, a java expert, and a javascript expert. They were surprised when NO ONE ever passed the interviews. Most actual hiring at the company involved getting contractors from a recruiter and then hiring them if we liked them--no technical interviews, just how much we liked them personally and if they could perform at the most basic level. I would imagine this is pretty common.
- lj3 10y ago
  That's called 'contract to hire' and it was fairly common about 5-10 years ago. I don't see it as much these days. I'm not sure why, but it seems to have fallen out of fashion.
  - LordKano 10y ago
    I think that employers learned that they had difficulty keeping good people. If I'm working for you on a contract to hire basis but three-six months in, I get a better offer, I'm gone. I have no retirement vesting to keep me locked in for 3-5 years.
  - flukus 10y ago
    You don't see it because it gives the candidates a chance to see what a companies code base is like and look elsewhere when they discover how bad it is.
    - lj3 10y ago
      And that's exactly why I like work to hire. The biggest factors that contributes to whether you like your job or hate your life are your boss, the people you work with and the state of the code base. You don't get a good impression of any of them until after you've been hired.
brandon272 10y ago
I have never, and would never subject myself to the types of sadistic games masquerading as "hiring" that you see at a lot of software companies.
- lj3 10y ago
  How do you find work?
  - brandon272 10y ago
    Most jobs in this world do not require a laborious interview process with timed puzzles and riddles. Bear in mind that the companies that do put people through that kind of thing do it because they can. When you have people lined up down the street to work for you, you can be very selective in who you hire and put them through all kinds of skill tests before hiring, to triple check that they have the requisite skills. Many (most?) companies do not have that luxury.
    - lj3 10y ago
      > Most jobs in this world You're not US based then? Because I can say with some certainly that most advertised jobs in the US absolutely do. Granted, most open jobs in the US aren't advertised, but I haven't found a way to reliably find jobs that are both open and unadvertised.
      - brandon272 10y ago
        Sorry, I was referring to literally most jobs, not just the ones in our industry. Electricians, plumbers, writers, accountants, etc. are not typically solving timed riddles and jumping through silly hoops to get their jobs. There will be technical questions, yes, but for the most part their experience is presumed and the employer assumes some risk by hiring them and having them go through a probationary period.
pascalxus 10y ago
Well, you have to understand, the whole point of an interview to construct questions you or at least a subset of the candidates can NOT answer. When there's too many qualified candidates, you've got to weed them out somehow.
sna1l 10y ago
I think algo/ds interviews are created to test only one thing, and that is hard work. The idea that they test problem solving is mostly bullshit. Most people are good at algorithm interviews because they've practiced them a ton. They've seen basically all the different kinds of questions that get asked on an interview, and are able to use that mental database to answer any questions. Most of the time in interviews, interviewers will commend an applicant's "problem solving" skills if they did well on a difficult algo problem, when in all likelihood they've seen that exact problem, or an extremely similar problem before. If the applicant hasn't seen dijkstra's algorithm before and is able to derive it in a 45 minute interview, you would need to hire them on the spot, assuming that Dijkstra himself didn't develop this algorithm in 45 minutes. That is a contrived example, but you get my point. For better or for worse, algo interviews are for testing how much work you've put into studying (mostly worse).
- watwut 10y ago
  After working with a couple of people who did not liked to think, I see value in willingness to study and understand a bit more complicated things.
- praneshp 10y ago
  I've seen that many good interviewers have a problem that has a straightforward sub-optimal solution, which they expect you figure out ('problem solving') and code. If it can be solved better using Dijkstra, that comes as a follow-up.
- chrismcb 10y ago
  Most people are not good at doing these interviews. Which is one reason why they work better than a lot of people here think they do.
watwut 10y ago
I have read these threads for a while now and concluded that people are going to complain no matter what companies do. I think that while whiteboard nor algorithms nor random questions about technology are perfect, they are still better then vague talking about how passionate one is or variants of beer test. The issue with talking about good code is similar - it matters whether you know the principles, but it is too easy to fake by people who have more talking bluffing skills then anything else. Personally, I like the best when they tell me what they will ask for, so I can prepare myself - whatever that is. That seems the most fair to me - good programmer does not know everything fresh, but should be able to refresh or learn something new reasonably fast.
zwetan 10y ago
I reject all that too, the recruitment process is broken, it's not even the riddles it is the stupidity of some tests for the "less bright" companies. But every problem is an opportunity :), now most of my freelance work are companies who "had a problem and couldn't find anyone willing to solve it" and me who asked "can I give it a shot?" Showing you want to solve problem so far "works for me" much better than doing the guinea pig with riddles
baron816 10y ago
I've had a lot of trouble finding a job since shuttering my start up, which I constructed on my own. I open sourced my code, but no one seems to care. They still just look at me as if I have no experience and pass on me before a technical assessment. It's troubling to know that engineers with many years of experience still have difficulties. Every job listing I see asks for someone with 6+ years, and the only feedback I ever get is "we're looking for someone with more experience, try again in 4 years." Tech companies should really just hire for soft skills. Screw tech interviews completely. A lot of this stuff can be taught. Maybe just give people a contracted trial period. Companies are spending incredible sums of money just searching for candidates that meet their exact "needs." In reality, they're not going to know how well someone performs until they actually work with them. Stop wasting your employees' time by having them grade pointless coding quizzes. Use that time instead to train someone who's a good communicator, is passionate about the product, is creative and eager to learn, and wants build something your customers will love. Even if that doesn't work out, at least you didn't waste everyone's time.
- XaspR8d 10y ago
  Yeah I was in a similar position with a lot of code work from a startup that crashed (wasn't the founder, but 1st technical team member, and the founder ended up being useless as a reference) that people refused to look at. One thing I unfortunately take from that period is a bitterness toward people who complain about whiteboard interviews, because I was never even given a chance to do coding problems. I understand that many of the complaints are rational (especially when the interview skills are totally misaligned from the on-the-job skills), but since I was stuck before that phase, I'd emotionally rather have less early filtering and more code-based interviews. If I actually came into a position of hiring power, I'd take time to reevaluate and separate myself from the question, but that's the instinctual response my history has brought me to.
- kbanman 10y ago
  Having been in your position, I understand that having built a product from the ground up makes you feel like you are qualified to do anything. I was lucky enough to get hired at a late-stage startup after my endeavor failed, and am constantly reminded that time in the industry matters. Two years of intense coding is worth a lot, but you've only been exposed to a limited set of problems, both technical and business. 6+ years sounds reasonable to me if they are looking for someone with well-rounded experience. Mind you, as someone else mentioned, some folks spend 6 years in the industry and don't gain the knowledge and experience you already have, but that doesn't mean you've attained 6 years worth of knowledge and experience.
pklausler 10y ago
If you hate the idea of coding questions as part of interviews, please consider the other side for a moment. There are people out there (not you, obviously) who can talk their way into an interview for programming jobs that they simply can't perform. We're talking about no skills whatsoever, apart from the ability to sling buzzwords around enough to impress a recruiter. God only knows how they get their degrees, but they have them. Simple, straightforward programming questions that aren't already on the Web are like an immune system response to these non-programmers who interview for programming jobs. I'm truly sorry when a real programmer feels insulted when I ask them something like "given the starting and ending times of two calendar appointments, write an expression that's true if they conflict", because it's not their fault that there are people out there who will struggle for 20 minutes thinking about how to solve it before trying something like a doubly-nested loop over all the milliseconds in both intervals, testing for equality. I am not making this up. It's a real problem. if you can program a digital computer, you have nothing to fear from a good coding interview. And if you have a better way to reliably identify the non-programmers, I'd love to hear it.
- framebit 10y ago
  YES. This is why interviewers ask experienced devs to do FizzBuzz. It's not an insult, it's a safeguard.
  - watwut 10y ago
    I consider myself an experienced developer and have experienced collegues who likely could not do FizzBuzz or solve simple algorithms like finding duplicates. The worst was when they had high charisma and could talk well in generalites and bluff - took long for management to figure them out. Experience taught me not to be insulted about those questions. They guarantee all collegues will be able to pass them.
    - mixmastamyk 10y ago
      Fizzbuz is not what we're talking about here. It is "balance a tree" with me looking over your shoulder (and $100k in a suitcase) type of problems.
calvinbhai 10y ago
I have spoken about this to many SEs who are senior enough to conduct interviews in their companies. I ask them, what do you intend to get out of such interview process. Their response: 1) Evaluate how to think about a problem 2) Evaluate their approach to a problem 3) Evaluate how to solve by asking questions So, most of these interviews, an experienced Software Engineer dons the hat of a psychologist (without having any qualification/experience of a psychologist) and evaluates an interviewee. How sad is that? Whats worse? I know a few who prepare to interview a candidate by going through "how to crack the coding interview"! I'm only glad that there are quite a few in my circle who believe in giving a problem they have faced at work, to a candidate, and ask the candidate to solve, using the same tools they use, with the laptop hooked to a projector. Interviews where I have done this as a candidate, I feel are more respectful of the candidate. Many of those who love the "let me be an unqualified psychologist today" interviewing style disagree with my opinion. So do I, with their's.
framebit 10y ago
Application performance matters, that's why these data structures and algorithm questions still matter. The issue is dogma surrounding the technicalities of data structures and algorithms. We make sure in our group to focus on application of those concepts, not memorization or detailed knowledge of the concepts themselves. But yeah, fast algorithms matter. Memory usage matters. Proper data structures matter. I don't really care if you can spit out a syntactically correct implementation of a red-black tree on the spot, but you should know what a tree is and why you might pick or tree over a hash table. I'd rather hire a writer who can really get a concept across but relies on autocorrect for spelling than a writer who can spell the hell out of stuff but can't actually write. Dogmatic interviews weed out the software engineers with the big picture skills and performance thinking who might be fuzzy on the details, like experienced folks who are decades out from school.
- LordKano 10y ago
  Application performance matters, that's why these data structures and algorithm questions still matter. THIS! It's one of my go to stories but back when I was working as a co-op during my undergrad days, in my department there was a .NET programmer who was skilled but had no understanding of the underlying data structures. He would be mystified at how I could write Perl programs that would outperform his .NET programs, even on less robust hardware.
- flukus 10y ago
  > Application performance matters, that's why these data structures and algorithm questions still matter I'm yet to have a problem where the particular data structure makes a huge difference on performance, I'm sure the exist but I don't come across them much personally. Most of the time an inefficient list search would not be noticeably different from a dictionary lookup, sometimes faster. What I have come across quite often is people who quibble about data structures but have n+1 queries everywhere and don't know what a join is. Another thing that's critically missing in the field is experience with a profiler, someone that knows how to use a profiler will know more about performance than anyone thinking about algorithms. In fact, it's an approach I'd like to try in future for vetting candidates.
- 10y ago
segmondy 10y ago
I'm truly sick of this rubbish that has been brewing lately. If you can't do interview questions, your ability is questionable. The bar has been lowered enough with the push of "everyone can code and should code" mentality. If we want quality, we must raise the bar. Everyone can code, everyone should be able to code if they want to. But everyone can't qualify for as a professional software programmer. If the company has a standardized interview process and everyone else gets asked the same set of questions, then it's fair. If you can't answer or whiteboard it and other candidates could, Don't cry! Those candidates obviously know more than you in regards to what the company is looking for. Take the case of Google or Amazon, most of us can agree that they have very smart folks working for them. If the filter these smart folks had to go through was puzzles, math problems, algorithms, white boarding, then why should anyone get an exception to join them? Interviews are broken in most environment, and that doesn't mean we should do away with them or make them easier. Rather, we should fix them, make them better, and have them test what the candidate will be doing on the job. I see people say, "you don't need to understand algorithm complexity to build a website, or to know C or assembly" Sure! But you don't know what you don't know! If you know and understand algorithm complexity, you will use it even when building websites! You will think about scale. If you understand lower level languages and you are using PHP, you might understand how your code turns to C and how choices at a higher level turns to lower level. If you never studied computer architecture, you wouldn't understand the magnitude involved in fetching something from a register, processor cache, ram, drive, over the network. Yet such things do rear their ugly heads when developing these so called simple CRUD apps. So if you are interviewing for a PHP programming position, and you get asked about algorithm complexity or C or TCP/IP or other questions. Don't frown, those are important questions, if you don't know it, you don't know it. It doesn't mean you are a "bad programmer" but it does reveal that you are a programmer without a wide breadth of knowledge. A one trick pony for the most part. Get over it and widen your knowledge. The other day I was using an external API that was crapping out. After hitting a dead end, I informed the vendor and they said nothing was wrong. I did a system call trace and noticed a lot of error was being returned on poll(), I fired up tcpdump and noticed an abrupt and random FIN ending the connection. With this I was able to convince the vendor to test their API from outside their network, and once they did, they agreed that the issue was on their end and they fixed it. This was a basic PHP app. Without a wide breath of knowledge, I would have been stuck, no google or stackoverflow would have solved this. Great developers have knowledge that are wide and deep. If you fail an interview, Don't get mad, get glad that you found your weakness and brush up your skills.
segmondy 10y ago
For some folks 10 yrs experience is truly 10 yrs experience, for a lot of folks, 10 yrs experience is 1 yr experience repeated 10x. Or worse a few months experience repeated more. Unless you are truly learning each week and working with new tech often. Number of years doesn't tell me much. I've seen 2 yrs experience crush 20 yrs experience all around, in design, programming, OS knowledge, database, etc.
facepalm 10y ago
I must admit I can not really relate. What about somebody who can not FizzBuzz, but claims they can code? Most whiteboard interviews I had were not much harder than FizzBuzz. I was asked to implement Quicksort once, but they gave me the specification, some time and a sheet of paper. Why would somebody for whom it is easy consider to hire somebody who can not do a seemingly simple thing? I can understand if somebody has anxiety issues. Then maybe you can negotiate something else, homework project or coding on site for 30 minutes. But odds are you'll discuss stuff with your colleagues on a whiteboard, too.
User23 10y ago
"I oppose hiring practices that would exclude me." Really? How profound.
deleted 10y ago
[deleted]
sigsergv 10y ago
Modern interviews are metrics and every smart system (human/AI) will exploit them. Metrics are always exploited. Job Interview is just another profession that requires a lot of training and preparation.

115 points by tempw 10y ago

NTDF9 10y ago

You know the process is fucked up when experienced professionals (with a track record of delivering projects) start complaining about how companies don't look for the ability of delivering projects.

peter422 10y ago
Every engineer says they delivered projects on time with great maintainable code. Unless the project is open source, they often have no way of giving any evidence. I'm not saying whiteboard interviews are the right way to interview, but in my experience you can't trust people's judgment about themselves and their skills. You need an interview that is equally fair to the person that will exaggerate their past successes to the people that are more reserved or the people that don't have much experience yet.
- techterrier 10y ago
  In other engineering disciplines there's accreditation and references for this sort of thing. No CEng for software engineers sadly.
- falcolas 10y ago
  Like a pair coding project on a computer with access to their internet resources? Can find out a lot about a person in a one/two hour pair coding interview.
- brandon272 10y ago
  > Unless the project is open source, they often have no way of giving any evidence. Isn't this is the case for every job applicant in every industry? You look at the evidence available of someone's work history and make a judgment call.
- enraged_camel 10y ago
  >>Every engineer says they delivered projects on time with great maintainable code. Unless the project is open source, they often have no way of giving any evidence. Okay, but having them solve coding problems on the whiteboard doesn't provide any evidence of that either. If they say they delivered projects on time with "great maintainable code," ask them what makes code maintainable, have them provide examples (using pseudocode) and talk through each one. Ask them about a time when they had to sacrifice maintainability for time, application performance or user experience. Ask them what they learned from the ordeal. In my opinion you're going to be much more likely to accurately judge their expertise level based on their answers to such questions. The reason is simple: one can memorize whiteboard questions prior to the interview. They can't, however, bullshit their way through questions that are experience-based - and if they do, well, you should hire them immediately because you just found yourself a great salesperson!
  - joshuamorton 10y ago
    I think its just as easy to memorize 'design' questions as 'whiteboard' questions. Not every whiteboard question is "implement a linked list", in fact I'd argue that's very rarely the case (or maybe I'm wrong and I've been insulated from these interviews). Most of my whiteboard interviews have involved a relatively small amount of actual coding (I think I had one question that was more than ~15 loc in python, and I've interviewed a few times). The rest was taking a relatively abstract problem presented in English and understanding it, removing ambiguities, and discussing tradeoffs with the interviewer. After that, a recursive function or a hash map or whatever is really easy.
    - NTDF9 10y ago
      As a person who successfully solved a problem but was rejected because of coding style (on a whiteboard, not on IDE), I am respectfully wary of the term "removal of ambiguity".
      - joshuamorton 10y ago
        How do you mean? By "removal of ambiguity", I'm talking about when someone poses a problem like "Write a function to recognize an IP Address". My first thought is then "ipv4 or ipv6", because that problem is underspecified, and I don't want to inadvertently solve the incorrect problem (which is kind of a case of the xy problem)
- mtberatwork 10y ago
  > you can't trust people's judgment about themselves and their skills. Unless the candidate is fresh out of uni, any qualified candidate with experience should be able to provide at least several solid contacts at previous employers from which to obtain this information.
  - dpark 10y ago
    References from co-workers aren't really that valuable. Many people have no qualms about giving glowing reviews for friends, even if those friends don't really deserve glowing reviews.
  - deleted 10y ago
    [deleted]

nix0n 10y ago

This is by design, they're looking for students.

istorical 10y ago
Students, super high achievers / superstars, and people who are willing to "play the game" and re-study everything for 2 weeks or a month.
- justinzollars 10y ago
  this is a good point. Every successful interview I had was the result of about a month of study time. I think the only way I could make it through an interview is by quitting my job and studying for a month!
- hackerblack1 10y ago
  LMAO.2 weeks? HA! Currently a graduating student that goes to one of those top schools. Do you really wanna know how long many of my peers are studying for these interviews? Months!!!!! I have a few friends that spent all of last summer after their daily internships doing interview prep for fall recruiting season. I also have a cousin that spent 5-6 months unemployed(given he did a masters/bs in ee and not in cs but wanted to move into the field) doing interview prep and just landed offers from Google and Dropbox. The competition is absolutely ruthless.
  - ad-hominem 10y ago
    Well, the people you interact with studying for interviews have never interviewed for a full-time position before in their field. They have no experience. They do not command a significant salary compared to the established professionals in their field. There are a lot of them, and they all want (the best job they can get || any decent job). They all just graduated and are unemployed (presumably). So yeah, of course they are all going to go crazy studying. A programmer with 5-10 years experience, who knows what they are doing professionally and has had a few jobs already (been through the process), and uses these skills on a daily basis is generally not going to spend months studying algorithmic questions. 2 weeks seems a lot more reasonable. Without studying, most worth their salt could probably still write a tree balancer or linked list from scratch even though it would be somewhat ugly. The studying is not to solidify and memorize all this stuff, it's just a refresher.

shadowcodex 10y ago

It's all become a game now. If you spend enough time on sites like codefights and hackerrank and know all the algorithms you can land a job. However, if you aren't prepared for these whiteboard interviews you are screwed.

mixmastamyk 10y ago

Same here, I've stopped doing tech interviews, they are a waste of time. Hopefully my freelancing network will continue to grow and I can avoid them forever.

JCDenton2052 10y ago
Freelancers do no tech interviews?
- protomyth 10y ago
  When I did freelance work, it was all about connections and reputation. "Hey we got some problems with our overnight processing, you've done that before" type stuff.
- mixmastamyk 10y ago
  They do some, but I find it more of a formality once you build a track record. The risk is lower than a full-time employee.
- tonyedgecombe 10y ago
  Not often, I think I only had one in the time I was freelancing, networking is everything.

runT1ME 10y ago

But could all practicing lawyers pass the bar right now in their respective state? I'd guess no. The problem is not the questions necessarily, it's that you have to study a bit and do the same goddamn interview questions at multiple companies, sometimes with very different interviewers. Some are helpful, some make me nervous, some are asking the hardest possible questions without warmup easy questions, etc. Whiteboard or live coding is not the problem. Bad or untrained interviewers are, along with the fact we can't do one interview that proves to multiple companies what level we are at.

shadowcodex 10y ago
However, should a practicing lawyer have to re-pass the bar in order to land a new job?
- snerbles 10y ago
  Are we going to make the PE exam a requirement for the title of "Software Engineer"?
  - eternalban 10y ago
    If "software engineers" want to be treated like "professional engineers". Licensing has been proven to work for other engineering fields.
  - prions 10y ago
    It really should be considered. I'm a registered (civil) EIT. IT would help towards the ambiguity in hiring and the ever increasing absurdity in interviewing. Especially since the conflicting statements of "software jobs need protection to ensure good salaries" and "everybody needs to code" are all to prevalent here. Being a PE means you have a certain level of experience and skill. It's a distinguishing feature and sets you apart as a "real" engineer. Additionally, it holds you to an ethical code. What continues to astound me is the lack of rigor and ethical backbone coming from engineers in important places. Yeah you're not building a bridge, but incidents like Volkswagen and Yahoo could have been prevented if people's jobs were bound by not being unethical.

jstewartmobile 10y ago

I'm kind-of on the fence about this topic. On the one hand, algorithms is a broad subject, so there's a large hole for false-positives and false-negatives to slip through. Sometimes it's like they'd pass on Gerry Spence as a trial attorney because he flubbed their question on tax law. On the other hand, can't totally drop the brain-teasers because you'll need all the IQ points you can get before the corporate retardation sets in.

hughes 10y ago
Does ability to solve brain-teasers correlate with a drop in "corporate retardation"?
- jstewartmobile 10y ago
  Everyone gets hit by the CR, so it probably doesn't hurt to start with a higher baseline.
- deleted 10y ago
  [deleted]
abraves10001 10y ago
Kind of off topic but I love relating programming to law. Both are enormous fields where no one has mastered all fields but the general populace (non-tech/legal) fails to grasp that. The interview process for engineers seems to have failed, to some extent, to understand this as well.
- jstewartmobile 10y ago
  Definitely. I've had some algorithm-y interviews where I solved it in an original way, and they were ready to marry me off to their prettiest daughter. Then I've had others where I didn't even know what the hell they were asking, all requests for clarification were met with repetition of the original question, and both of us were probably wondering: "Is this guy stupid? an asshole? both?"

ep103 10y ago

I call bullshit on this train of thought. I've been reading about this on HN and reddit for years now. This last December, I was promoted high enough, that I could design the entire interview process (with executive help) for my teams. Which was important, I very much need to hire some people. So, keeping posts like this in mind, I designed as follows: Phone Interview - We talk about you, the company, etc. Then a few technical questions. Do you know certain things about js that make me think you are genuinely familiar with the language (as opposed to just jQuery)? Do you know certain things about sql that make me think you are genuinely familiar with the technology (as opposed to just using a table designer)? Assessment Test - Do a quick crud app, that will require some thought behind how to query the data. Make a point when talking to the prospective applicant that the code will be read by the team members they'll be working with, so while you can do the test quickly, please spend enough time on it that we can talk about the code, your choices, etc going into the technical interview. Ie) don't just link together 3rd party plugins. Actual Interview - Interview with leads, interview with actual team members. Offer both use of Visual Studio / SSMS / IDE of choice or whiteboard. Ask questions about technology in general. Ask the applicant to explain how he'd design out a new feature. Change the feature spec, so that there's a little bit of a hard problem. Have to populate a tree from flat sql data, or aggregate data from a service, or some other not-quite-an-algorithm question. The RESULTS? Recruiters figure out what questions you are most likely to ask during the phone interview, and school the candidates. The assessment test? No one bothers, everyone just hands in the simplest 3rd party libraries plumbed together with shitty code. Was the question select top per group? How about top 1 *? The really good devs shine through here, but a huge percentage don't even bother. Actual Interview? No one uses IDE / SSMS. All of them choose whiteboard. The ones who genuinely know how to code, have no problem answering, and would be fine answering algorithm questions straight out. The ones who can't, get confused somewhere or other. They try to implement hacks around the problem (I'd have the dba do it), then fail to actually solve the question. So In Short? I completely understand where this guy is coming from. But I also think, that at this point, I'm so tired of interviewing people who clearly don't care about their craft, that I want to start asking nothing other than algorithm questions... because the guy or gal that actually answers them will actually care about their craft. And at least with algo questions, I can change the question easily, and frequently. Coming up with real code problems, and good probing questions is much harder, particularly if they're going to have a short shelf-life before recruiters start training their candidates with answers.

pgtruesdell 10y ago

Form over substance, as usual with large bureaucracies. Unfortunately, tech seems to view the biggest and most "successful" company as the model way to move forward, instead of throwing up the middle finger like they used to. It's sad to see the transformation of Silicon Valley to a pseudo-government style group of mega-conglomerates. The next batch of real innovators will not be from the Valley or be from Valley culture.

jstewartmobile 10y ago
Yep. Used to be, the dream was to beat Bill Gates. Now the dream is to get bought by Facebook.
- omouse 10y ago
  The dream was to make your own rules (which includes a ferrari, a private office and all sorts of perks). Getting bought by Google, Facebook, etc. is the new way of getting "fuck you" money.
LordKano 10y ago
I worked as a programmer for a promotional marketing company and their modus operandi was to copy everything they could from their biggest competitor. Eventually, it even got so bad that we were instructed to copy, word for word, certain disclosures from the competitor's web site. The big competitor is still the big competitor and my former employer is still doing OK but they'll never catch or pass anyone by copying what they're doing.

NikolaeVarius 10y ago

I don't quite understand this point of view and the whining. Why is it that Software Engineers feel the need to whine about these technical interview questions? I don't think many of these are THAT technical either, just requires some practice. I dislike brain teasers, but I don't think Algorithms questions are out of line, even if you might not use them. I graduated with an Aerospace Engineering degree. While I don't exactly remember how to derive the Normal Mode of a wing, I wouldn't have any issue relearning it for an interview. For my first job, I was asked questions that had very little to do with my day to day but I still answered them and didn't complain.

falsedan 10y ago
> Why is it that Software Engineers feel the need to whine about these technical interview questions? Because they're pointless for the vast majority of positions: why make me learn something for the interview that I'll never use again? This offends many engineers' sense of laziness. Because it's a pithy indication about what's wrong with tech interviews: we can't ask 'are you good at delivering with weird requirements' (because the candidate says 'sure I'm the best'), and we can't check their ability to do that in 45-60 minutes. Instead, we use these shibboleth questions to see if they are like other engineers (who can deliver etc.) Because it's gatekeeping: if you didn't study algorithms or have the time/energy to keep it fresh, you can't get past these interviews and get these jobs. It doesn't matter if you'd excel if you don't have the same opportunities as the normal privileged young white male engineer. Because it's inefficient: plenty of engineers could perform well in the position but get screened out by these imprecise questions. Sure, for a startup of 4 employees, you can't settle for great and have to keep rejecting until you get the best, but for a mature stable company, you want people with solid skills and abilities who can learn (how to do algorithms) on the job.
- NikolaeVarius 10y ago
  None of that is specific to software engineers. My non software-engineering Interviews contained tons of questions that aren't completely relevant. For example, describe in detail how pressure and velocity are correlated in each turbofan stage and how they affect efficiency. Describe what isentropic flow is and how it relates to lift. I also hate getting random whiteboarding questions, but I'm not going to complain about it. If I really want a job I'm going to study for it.

dbg31415 10y ago

Hiring at most companies is fundamentally broken. We have no way of knowing if someone will work out, so finding ways to rule people out makes it seem like we did our job in the hiring process. Some Wonderlic-type questions, the person asking them gets to say, "Well, look we have some quantifiable way of measuring applicants." Total BS. No cure for it, other than to not turn around and be that asshole once you are hired. We should be more open about what the criteria is; hiring comes down to a few gut checks... do you like the person and think they will fit in, do you feel confident that they can do the work you will ask them to do, and are they in your budget? Unless you work with a person over time, there's not going to be any way of knowing how they are as an employee. If they are smart, if they keep up on current trends, if they are a good communicator (and any good at communicating inside of your organization), if they care, if they show up on time, if they are conscientious or just pass the buck, if they are a hard worker, if they are opportunistic / selfish with praise... Anyway HR needs to justify itself so we can't just throw darts at resumes... but essentially that's all hiring is. Trying to get a sense of someone quickly, cheaply, and correctly? Nah, just pick 2... at most.

JCDenton2052 10y ago

The prevalent thinking is that algorithmic skills transfer very well to other problem-solving skills. This is especially the case in Google, Microsoft, Facebook and Amazon who ask a lot of these questions. I do not necessarily agree with it, but it is the way things are. It's just another skill that can be acquired with proper effort and concentration. I can recommend "Cracking the Code Interview", it is chock full of these problems.

throwaway26960 10y ago

The interview process is great for employers... 1. Make qualified job interview candidate feel stupid by asking difficult questions unrelated to the job 2. Offer candidate low salary and argue that they barely passed the job interview 3. Profit Best solution I can offer is to not play their game. You'll lose no matter how hard you try. You're better off studying marketing and psychology for job interviews.

falsedan 10y ago
> You're better off studying marketing and psychology for job interviews Well, yeah. You should know how to sell yourself (to get past the resume screening process) and analyze the company's goals/culture/intent/desires (to avoid working at the next Uber).
civilian 10y ago
Studying an algorithms book (like Cracking the Coding Interview or Programming Interviews Exposed) is also an effective way to "hack" the interview. :-P
Vekz 10y ago
Great points about marketing and psychology. once you've won the lottery and got a whiteboard question, that you've prepared for. You additionally have to win unconscious biases of the interviewers and exhibit behavior that makes them judge you as a trusted "cultural fit" tribe member
- deegles 10y ago
  Sigh. I completely crashed and burned at a phone screen once with a question that was easy but required knowing a bit shifting trick. I knew that the trick existed because I had glanced at it while studying and thought, "no way they'll ask that."

misja111 10y ago

I was in the same situation a couple of years ago. I had over 15 years of experience, was invited for a technical interview at Amazon, and failed. At first I was irritated, just like the author. But then I decided to turn this negative energy into something positive and followed a couple of courses on Algorithms on Coursera, also I discovered Hackerrank. And I found out that I actually loved solving algorithmic problems! Now it is a couple of years later and I actually was able to land a job thanks to my new skills (not at Amazon though). But what's much more important: I found a new hobby that will keep me entertained for many more years.

mavelikara 10y ago
My story is the same too. I was a promising junior developer when I went to an interview at Amazon. Got my back handed to me. I was upset, but decided to work on it. Read a few books on the topic, and I no longer find these interviews difficult.
- nojvek 10y ago
  Before I interview I mention that I am uncomfortable with whiteboards. I prefer pen and paper. It's faster to write and feels a bit natural. Only one company denied me the request and I didn't go ahead for them. Their loss. I've also found having a github profile where you've files issues on projects and made a couple of commits really helps the chances. It gives more data than a resume. At one interview, the interviewer read some of my commits and he said "I don't have any doubts you can code, but I wanna ask you about design". He went on to ask why I did things in a certain way. But seriously. "Say no to coding on whiteboards".
  - wry_discontent 10y ago
    I'm the opposite way. I prefer the whiteboard to pen and paper.
k__ 10y ago
I was in the same situation, but I simply stopped doing these kind of interviews and started doing contract work. The pay is better with less strange questions asked upfront.

justinzollars 10y ago

I think tech interviews are broken. I've been on both ends of the equation and the process usually seems both unfair and random. I work hard, get good reviews, have nice looking work that doesn't crash and scales - and I can't interview either. I've also interviewed great candidates that get shot for no reason at all. That said, it is a numbers game, if you need a job keep at it - you have not other choice. But in the long term I think our community needs to chill out a little bit.

peterjones2 10y ago

I am just beginning my studies in computer science. I find discrete mathematics, data structures, theory of computation and algorithms to be the most interesting aspects of computer science. If I took an undergraduate algorithms course (Chapters 1-3, 7-9, 11-13, 15-16, 22-24 from CLRS) would I be prepared for most interviews? I noticed the graduate course overlaps with many of those chapters and also cover: chapters 18,21,25,26, 29-32, 35. Ideally, I would like to take both courses out of pure self-interest.

GrumpyYoungMan 10y ago
As others have suggested, get a copy of "Cracking the Coding Interview" and review the questions therein. If you can answer those questions easily, you'll have an easy time at the average interview. If you want to prepare to interview at one of the top companies, then afterwards procure a copy of my secret weapon: Aziz, Lee, & Prakash's "Elements of Programming Interviews". The questions there are an order of magnitude more difficult. If you are able to apply the CS concepts you are learning to questions of that difficulty, all doors will be open to you.
- deleted 10y ago
  [deleted]
- peterjones2 10y ago
  Thanks for taking the time to answer my question. This is my first time commenting on HN and am being downvoted for my legitimate question.
  - GrumpyYoungMan 10y ago
    Just a helpful tip: mentioning being downvoted is against the HN guidelines and usually attracts more downvotes. pkahler's sibling post also brings up an important side point: beyond the basic core, what you study really needs to be focused on what aspect of the software industry you want to be in or are likely to find yourself in. While I, too, encourage you to take C/asm courses or whatever your preferred focus is, the bulk of the jobs in the industry are in creating web sites and business systems (much of which are so-called CRUD apps; see https://en.wikipedia.org/wiki/Create,_read,_update_and_delete https://en.wikipedia.org/wiki/Create,_read,_update_and_delet...). Even if you plan to do something else, a course in databases and concurrent programming will stand you in good stead as a fallback if your career doesn't quite go as planned.

issa 10y ago

I worked at an unnamed big company where the interview process involved being interviewed by a PHP expert, a java expert, and a javascript expert. They were surprised when NO ONE ever passed the interviews. Most actual hiring at the company involved getting contractors from a recruiter and then hiring them if we liked them--no technical interviews, just how much we liked them personally and if they could perform at the most basic level. I would imagine this is pretty common.

lj3 10y ago
That's called 'contract to hire' and it was fairly common about 5-10 years ago. I don't see it as much these days. I'm not sure why, but it seems to have fallen out of fashion.
- LordKano 10y ago
  I think that employers learned that they had difficulty keeping good people. If I'm working for you on a contract to hire basis but three-six months in, I get a better offer, I'm gone. I have no retirement vesting to keep me locked in for 3-5 years.
- flukus 10y ago
  You don't see it because it gives the candidates a chance to see what a companies code base is like and look elsewhere when they discover how bad it is.
  - lj3 10y ago
    And that's exactly why I like work to hire. The biggest factors that contributes to whether you like your job or hate your life are your boss, the people you work with and the state of the code base. You don't get a good impression of any of them until after you've been hired.

brandon272 10y ago

I have never, and would never subject myself to the types of sadistic games masquerading as "hiring" that you see at a lot of software companies.

lj3 10y ago
How do you find work?
- brandon272 10y ago
  Most jobs in this world do not require a laborious interview process with timed puzzles and riddles. Bear in mind that the companies that do put people through that kind of thing do it because they can. When you have people lined up down the street to work for you, you can be very selective in who you hire and put them through all kinds of skill tests before hiring, to triple check that they have the requisite skills. Many (most?) companies do not have that luxury.
  - lj3 10y ago
    > Most jobs in this world You're not US based then? Because I can say with some certainly that most advertised jobs in the US absolutely do. Granted, most open jobs in the US aren't advertised, but I haven't found a way to reliably find jobs that are both open and unadvertised.
    - brandon272 10y ago
      Sorry, I was referring to literally most jobs, not just the ones in our industry. Electricians, plumbers, writers, accountants, etc. are not typically solving timed riddles and jumping through silly hoops to get their jobs. There will be technical questions, yes, but for the most part their experience is presumed and the employer assumes some risk by hiring them and having them go through a probationary period.

pascalxus 10y ago

Well, you have to understand, the whole point of an interview to construct questions you or at least a subset of the candidates can NOT answer. When there's too many qualified candidates, you've got to weed them out somehow.

sna1l 10y ago

I think algo/ds interviews are created to test only one thing, and that is hard work. The idea that they test problem solving is mostly bullshit. Most people are good at algorithm interviews because they've practiced them a ton. They've seen basically all the different kinds of questions that get asked on an interview, and are able to use that mental database to answer any questions. Most of the time in interviews, interviewers will commend an applicant's "problem solving" skills if they did well on a difficult algo problem, when in all likelihood they've seen that exact problem, or an extremely similar problem before. If the applicant hasn't seen dijkstra's algorithm before and is able to derive it in a 45 minute interview, you would need to hire them on the spot, assuming that Dijkstra himself didn't develop this algorithm in 45 minutes. That is a contrived example, but you get my point. For better or for worse, algo interviews are for testing how much work you've put into studying (mostly worse).

watwut 10y ago
After working with a couple of people who did not liked to think, I see value in willingness to study and understand a bit more complicated things.
praneshp 10y ago
I've seen that many good interviewers have a problem that has a straightforward sub-optimal solution, which they expect you figure out ('problem solving') and code. If it can be solved better using Dijkstra, that comes as a follow-up.
chrismcb 10y ago
Most people are not good at doing these interviews. Which is one reason why they work better than a lot of people here think they do.

watwut 10y ago

I have read these threads for a while now and concluded that people are going to complain no matter what companies do. I think that while whiteboard nor algorithms nor random questions about technology are perfect, they are still better then vague talking about how passionate one is or variants of beer test. The issue with talking about good code is similar - it matters whether you know the principles, but it is too easy to fake by people who have more talking bluffing skills then anything else. Personally, I like the best when they tell me what they will ask for, so I can prepare myself - whatever that is. That seems the most fair to me - good programmer does not know everything fresh, but should be able to refresh or learn something new reasonably fast.

zwetan 10y ago

I reject all that too, the recruitment process is broken, it's not even the riddles it is the stupidity of some tests for the "less bright" companies. But every problem is an opportunity :), now most of my freelance work are companies who "had a problem and couldn't find anyone willing to solve it" and me who asked "can I give it a shot?" Showing you want to solve problem so far "works for me" much better than doing the guinea pig with riddles

baron816 10y ago

I've had a lot of trouble finding a job since shuttering my start up, which I constructed on my own. I open sourced my code, but no one seems to care. They still just look at me as if I have no experience and pass on me before a technical assessment. It's troubling to know that engineers with many years of experience still have difficulties. Every job listing I see asks for someone with 6+ years, and the only feedback I ever get is "we're looking for someone with more experience, try again in 4 years." Tech companies should really just hire for soft skills. Screw tech interviews completely. A lot of this stuff can be taught. Maybe just give people a contracted trial period. Companies are spending incredible sums of money just searching for candidates that meet their exact "needs." In reality, they're not going to know how well someone performs until they actually work with them. Stop wasting your employees' time by having them grade pointless coding quizzes. Use that time instead to train someone who's a good communicator, is passionate about the product, is creative and eager to learn, and wants build something your customers will love. Even if that doesn't work out, at least you didn't waste everyone's time.

XaspR8d 10y ago
Yeah I was in a similar position with a lot of code work from a startup that crashed (wasn't the founder, but 1st technical team member, and the founder ended up being useless as a reference) that people refused to look at. One thing I unfortunately take from that period is a bitterness toward people who complain about whiteboard interviews, because I was never even given a chance to do coding problems. I understand that many of the complaints are rational (especially when the interview skills are totally misaligned from the on-the-job skills), but since I was stuck before that phase, I'd emotionally rather have less early filtering and more code-based interviews. If I actually came into a position of hiring power, I'd take time to reevaluate and separate myself from the question, but that's the instinctual response my history has brought me to.
kbanman 10y ago
Having been in your position, I understand that having built a product from the ground up makes you feel like you are qualified to do anything. I was lucky enough to get hired at a late-stage startup after my endeavor failed, and am constantly reminded that time in the industry matters. Two years of intense coding is worth a lot, but you've only been exposed to a limited set of problems, both technical and business. 6+ years sounds reasonable to me if they are looking for someone with well-rounded experience. Mind you, as someone else mentioned, some folks spend 6 years in the industry and don't gain the knowledge and experience you already have, but that doesn't mean you've attained 6 years worth of knowledge and experience.

pklausler 10y ago

If you hate the idea of coding questions as part of interviews, please consider the other side for a moment. There are people out there (not you, obviously) who can talk their way into an interview for programming jobs that they simply can't perform. We're talking about no skills whatsoever, apart from the ability to sling buzzwords around enough to impress a recruiter. God only knows how they get their degrees, but they have them. Simple, straightforward programming questions that aren't already on the Web are like an immune system response to these non-programmers who interview for programming jobs. I'm truly sorry when a real programmer feels insulted when I ask them something like "given the starting and ending times of two calendar appointments, write an expression that's true if they conflict", because it's not their fault that there are people out there who will struggle for 20 minutes thinking about how to solve it before trying something like a doubly-nested loop over all the milliseconds in both intervals, testing for equality. I am not making this up. It's a real problem. if you can program a digital computer, you have nothing to fear from a good coding interview. And if you have a better way to reliably identify the non-programmers, I'd love to hear it.

framebit 10y ago
YES. This is why interviewers ask experienced devs to do FizzBuzz. It's not an insult, it's a safeguard.
- watwut 10y ago
  I consider myself an experienced developer and have experienced collegues who likely could not do FizzBuzz or solve simple algorithms like finding duplicates. The worst was when they had high charisma and could talk well in generalites and bluff - took long for management to figure them out. Experience taught me not to be insulted about those questions. They guarantee all collegues will be able to pass them.
  - mixmastamyk 10y ago
    Fizzbuz is not what we're talking about here. It is "balance a tree" with me looking over your shoulder (and $100k in a suitcase) type of problems.

calvinbhai 10y ago

I have spoken about this to many SEs who are senior enough to conduct interviews in their companies. I ask them, what do you intend to get out of such interview process. Their response: 1) Evaluate how to think about a problem 2) Evaluate their approach to a problem 3) Evaluate how to solve by asking questions So, most of these interviews, an experienced Software Engineer dons the hat of a psychologist (without having any qualification/experience of a psychologist) and evaluates an interviewee. How sad is that? Whats worse? I know a few who prepare to interview a candidate by going through "how to crack the coding interview"! I'm only glad that there are quite a few in my circle who believe in giving a problem they have faced at work, to a candidate, and ask the candidate to solve, using the same tools they use, with the laptop hooked to a projector. Interviews where I have done this as a candidate, I feel are more respectful of the candidate. Many of those who love the "let me be an unqualified psychologist today" interviewing style disagree with my opinion. So do I, with their's.

framebit 10y ago

Application performance matters, that's why these data structures and algorithm questions still matter. The issue is dogma surrounding the technicalities of data structures and algorithms. We make sure in our group to focus on application of those concepts, not memorization or detailed knowledge of the concepts themselves. But yeah, fast algorithms matter. Memory usage matters. Proper data structures matter. I don't really care if you can spit out a syntactically correct implementation of a red-black tree on the spot, but you should know what a tree is and why you might pick or tree over a hash table. I'd rather hire a writer who can really get a concept across but relies on autocorrect for spelling than a writer who can spell the hell out of stuff but can't actually write. Dogmatic interviews weed out the software engineers with the big picture skills and performance thinking who might be fuzzy on the details, like experienced folks who are decades out from school.

LordKano 10y ago
Application performance matters, that's why these data structures and algorithm questions still matter. THIS! It's one of my go to stories but back when I was working as a co-op during my undergrad days, in my department there was a .NET programmer who was skilled but had no understanding of the underlying data structures. He would be mystified at how I could write Perl programs that would outperform his .NET programs, even on less robust hardware.
flukus 10y ago
> Application performance matters, that's why these data structures and algorithm questions still matter I'm yet to have a problem where the particular data structure makes a huge difference on performance, I'm sure the exist but I don't come across them much personally. Most of the time an inefficient list search would not be noticeably different from a dictionary lookup, sometimes faster. What I have come across quite often is people who quibble about data structures but have n+1 queries everywhere and don't know what a join is. Another thing that's critically missing in the field is experience with a profiler, someone that knows how to use a profiler will know more about performance than anyone thinking about algorithms. In fact, it's an approach I'd like to try in future for vetting candidates.
10y ago

segmondy 10y ago

I'm truly sick of this rubbish that has been brewing lately. If you can't do interview questions, your ability is questionable. The bar has been lowered enough with the push of "everyone can code and should code" mentality. If we want quality, we must raise the bar. Everyone can code, everyone should be able to code if they want to. But everyone can't qualify for as a professional software programmer. If the company has a standardized interview process and everyone else gets asked the same set of questions, then it's fair. If you can't answer or whiteboard it and other candidates could, Don't cry! Those candidates obviously know more than you in regards to what the company is looking for. Take the case of Google or Amazon, most of us can agree that they have very smart folks working for them. If the filter these smart folks had to go through was puzzles, math problems, algorithms, white boarding, then why should anyone get an exception to join them? Interviews are broken in most environment, and that doesn't mean we should do away with them or make them easier. Rather, we should fix them, make them better, and have them test what the candidate will be doing on the job. I see people say, "you don't need to understand algorithm complexity to build a website, or to know C or assembly" Sure! But you don't know what you don't know! If you know and understand algorithm complexity, you will use it even when building websites! You will think about scale. If you understand lower level languages and you are using PHP, you might understand how your code turns to C and how choices at a higher level turns to lower level. If you never studied computer architecture, you wouldn't understand the magnitude involved in fetching something from a register, processor cache, ram, drive, over the network. Yet such things do rear their ugly heads when developing these so called simple CRUD apps. So if you are interviewing for a PHP programming position, and you get asked about algorithm complexity or C or TCP/IP or other questions. Don't frown, those are important questions, if you don't know it, you don't know it. It doesn't mean you are a "bad programmer" but it does reveal that you are a programmer without a wide breadth of knowledge. A one trick pony for the most part. Get over it and widen your knowledge. The other day I was using an external API that was crapping out. After hitting a dead end, I informed the vendor and they said nothing was wrong. I did a system call trace and noticed a lot of error was being returned on poll(), I fired up tcpdump and noticed an abrupt and random FIN ending the connection. With this I was able to convince the vendor to test their API from outside their network, and once they did, they agreed that the issue was on their end and they fixed it. This was a basic PHP app. Without a wide breath of knowledge, I would have been stuck, no google or stackoverflow would have solved this. Great developers have knowledge that are wide and deep. If you fail an interview, Don't get mad, get glad that you found your weakness and brush up your skills.

segmondy 10y ago

For some folks 10 yrs experience is truly 10 yrs experience, for a lot of folks, 10 yrs experience is 1 yr experience repeated 10x. Or worse a few months experience repeated more. Unless you are truly learning each week and working with new tech often. Number of years doesn't tell me much. I've seen 2 yrs experience crush 20 yrs experience all around, in design, programming, OS knowledge, database, etc.

facepalm 10y ago

I must admit I can not really relate. What about somebody who can not FizzBuzz, but claims they can code? Most whiteboard interviews I had were not much harder than FizzBuzz. I was asked to implement Quicksort once, but they gave me the specification, some time and a sheet of paper. Why would somebody for whom it is easy consider to hire somebody who can not do a seemingly simple thing? I can understand if somebody has anxiety issues. Then maybe you can negotiate something else, homework project or coding on site for 30 minutes. But odds are you'll discuss stuff with your colleagues on a whiteboard, too.

User23 10y ago

"I oppose hiring practices that would exclude me." Really? How profound.

deleted 10y ago

[deleted]

sigsergv 10y ago

Modern interviews are metrics and every smart system (human/AI) will exploit them. Metrics are always exploited. Job Interview is just another profession that requires a lot of training and preparation.