28 ms·

Technical and non-technical tips for rocking your coding interview

259 points by duck 9y ago

Clubber 9y ago
So I wonder. If someone memorized all that trivia, do you think they can code?
- SmirkingRevenge 9y ago
  If its just memorized without understanding, probably not. But I've been doing a bit of the leetcode/hackerrank challenges lately, and believe it or not, I actually think it has made me a bit better, by refreshing bits of knowledge that were getting stale, and really forcing me to think about performance (many test cases in the challenges will fail without the fastest implementations). And they are kind of fun.
Waterluvian 9y ago
What I'd love tips for, is how to politely and professionally protest certain interview styles. I want to know how to say, "sure here's how to implement foo but I also want to express that a focus on this coding trivia is distracting from the skills I feel make me an asset..." Maybe what I'm asking is tips on how to steer an interview. One of the reasons I wouldn't even consider a tech giant interview is that I feel like I'm just one of many cattle being processed through a long gauntlet of nonsense that distils me down to quantifiable traits rather than who I am.
- SomeStupidPoint 9y ago
  An approach is to proactively bring up interesting aspects of the problem yourself -- eg, the last time I was writing example code on the board, I spent most of the time talking about where hooks to add more features would go or algorithmic complexity/edge cases I encounter as I try to implement a solution. If you're focusing on the trivia, you're probably too focused on the code and not on solving the problem -- my experience tends to be that there's at least one or two interesting edge cases you encounter if you try the naive approach, and those are generally what the interviewer wants to discuss. The reason is that discovering edge cases in requirements and solving them is what a lot of the job is, and so how you approach that matters (and to an extent, more than if your code on the board is "correct"). Another approach is to extend the problem by asking clarifying questions -- if there's something unspecified that might influence your design, ask about it and tell the interviewer why it matters. Again, this generally is more what they care about than the details of the coding. Finally, if those skills make you an asset -- why not apply them to the question? Even tangentially by talking about how you would (if you had more time/were doing a real assignment). Coding on the white board is more about the journey than the coding, assuming you can write vaguely correct code. (Though writing on a whiteboard is definitely a skill you have to practice.)
- ebiester 9y ago
  In our interview, we have people from 4 different departments who will talk with the candidate, as well as the team (who is there for the coding portion.) I honestly don't want to have to test if someone can handle a simple algorithm. (I'm not talking about anything crazy here, mind you.) Can they read code? Can they think about how to test? I've seen faked code samples, and our test has a half dozen answers on github. I want to just assume that anybody with five years of programming experience can code, but I've worked alongside enough counterexamples that I know I can't assume that. That said, I'd really rather not have to deal with it as a candidate or as an interviewer.
  - kuro68k 9y ago
    These tests favour people who are good at tests. I know people who test will, crank out code fast, but I'm the long run they suck because they didn't think about it enough. I'll point a company at my sample code. They can ask me about it too make sure it's really mine. When interviewing people I'd much rather have someone who knows how to find the best solution, not the person who has read a list of questions like this.
- misanthropic 9y ago
  Well you can always say that you're not comfortable coding during interview, and propose to look at your github instead...
- pklausler 9y ago
  When I ask a straightforward problem during a technical interview, I'm trying to ensure that the human before me is actually capable of solving the straightforward problem. You're free to respond any way that you like, but if your response doesn't actually include a solution that demonstrates the capability I'm testing for, I'm not sure that I'm going to be able to distinguish you from the ~50% of interview subjects that HR puts before me that have no idea whatsoever how to program a computer. I don't even ask softball questions. Mine are more like tee-ball questions. Too often, the tee pitches a perfect game.
  - rurounijones 9y ago
    Out of curiosity. Would you still ask these questions if the candidate has a github/gotlab/whatever profile with X repositories where they are the main / only contributor? Could you explain why yes / no and what the specifics would be? (Volume? Complexity? Commit history? )
    - pklausler 9y ago
      I absolutely do. I can't assume that the person before me is the person who actually wrote the code on github.
      - deleted 9y ago
        [deleted]
      - Vendan 9y ago
        I think you'd get more value out of talking with them about those repos, and the process of building them, design choices, then any silly question like "how would you design a database". Of course, that would also mean you'd have to actually put more then a few minutes into prep for the candidate's interview...
        rabidrat 9y ago
        While I agree with you for the most part, many companies want a "standardized" interview process, for both diversity and CYA reasons. Tailoring the interview to the candidate is actually illegal in certain organizations (like government), as it has large potential for abuse.
- tytytytytytytyt 9y ago
  Implementing things isn't trivia, it's an integral part of being a software engineer.
- sabman83 9y ago
  A somewhat related experience I had with a company that advertised proudly that they don't do live coding tests. They had a take-home exercise which I did very well and I was scheduled for a phone interview later. I was expecting it to be more around system design, behavioral questions but to my surprise it was a live coding test. After the interview was done I questioned the person why have another coding test. He said it was to test on different areas of programming. I later messaged the VP/CTO who wrote the blog post on not having live coding test. The person apologized for the experience and said that the team I interviewed for did not come under engineering org. It was a frustrating experience but at least the person responded positively.
- thesmallestcat 9y ago
  A warning: If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem. Every off-by-one error you commit on the job will raise an eyebrow. People will wonder, does this guy want to be an engineer or something else? Why couldn't he rip through that problem and teach _us_ a thing or two on the way? Another thing is you're basically coming in and saying "your interview process is wrong". If you're being interviewed as a manager or a lead, you can afford that risk. If not, be careful, because many people, myself included, don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time.
  - programmarchy 9y ago
    > don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time This seems a little too general to me. Many things are not clearly thought out, and I'd rather work with people who can recognize when that is the case and communicate well enough to correct the course. A big part of successful development in my experience is knowing when not to implement things, or having foresight to implement things in a better way. Working with people who just do what they're told is often a huge waste of time.
  - majormajor 9y ago
    I think it's fair for non-simple coding problems. If someone asked me a problem that basically reduced to a textbook case of something in the middle, difficulty wise, like reservoir sampling, and I said "oh, nifty, resevoir sampling, what do you use that for in your stack?" and they said "nothing, I just want to make sure you can code," then depending on how my experience to that point in the process had been going I might challenge them on that to some extent, a la "do you find this more useful than questions that are more representative of the work you're expecting me to do?" If the loop had been going particularly robotically, this might find stronger forms - I've walked out on a mismanaged interview before, though it was way worse than this (and way worse in a very different way - they just weren't at all prepared and the tooling they wanted me to use wasn't actually functional). Or they might answer something more like "we use it to select test cases from our logs to ensure that we're adequately testing against real behavior with proper weights" (or whatever—it's been a while since I actually did this in a past job :) ) in which case I'd still try to have what I consider a more "real" conversation ("what primary problem are we trying to solve, and what else might be options to consider"), but in that case at least they had a good answer to the question and I'd be happy to write the code too. But lastly, frankly, as a hiring manager I absolutely want to hire people who are willing to "not focus on the task at hand" and question things. I don't want people who just blindly do what I tell them to, I want people I can trust to disagree with me and be able to make a case for why they disagree. Being a manager doesn't mean my instincts are 100% and theirs are 0%.
- watwut 9y ago
  It is only after you worked with someone lazy or barely capable of foo who charizma-around-company-pong-table his way to staying in company and being treated as genius by those who don't work directly with him that you appreciate those simple exercises.
- mylons 9y ago
  steering an interview is all about steering the human(s) giving the interview. real life example: an MIT PhD in distributed computing walks into the room, looking extremely tired from interviewing people like me. I can tell this is going to be rough unless I'm controlling the conversation and we have a good rapport. He's wearing a Fender shirt. I have played guitar a bit. After he introduces himself and I myself I open with, "Oh nice shirt. I assume you play some guitar?" and there goes 20 minutes of the interview talking about guitars. So long as I don't completely bomb the technical aspect I've left this person with a positive and relatable experience.
  - UncleMeat 9y ago
    This is the kind of thing that people want to avoid. Hiring a person because they share a hobby is ridiculous. If a candidate tried to steer the interview to non-technical questions I'd point that out to the relevant people and make sure it was highlighted in my feedback.
    - bsder 9y ago
      If you let the candidate steer the interview in the wrong direction, the fault is in the interviewer, not the candidate. I have been on both sides of the equation. My stories: 1) Brain teaser questions sometimes aren't as easy or as straightforward as everybody thinks--don't ask them as an interviewer unless you genuinely KNOW the question. Digital VLSI design loops almost always have a question that makes you use a state machine--this is actually a decent question for a whiteboard as long as you don't do something stupid like use J-K flip flops in CMOS. There are a host of basic questions you can use ... but beware of traps. I was once asked the following question: "You have a serial bitstream that represents a binary number. Keep track of the value of that number modulo 3." This is a decent question ... Or a really hard question ... depending upon whether the number is being clocked in MSB first or LSB first. Unfortunately, when I wrote the numbers down on the whiteboard, I chose the "hard" direction. And had to really think ... and the interviewer kept getting more and more agitated and finally complained "Look, this is easy, just do 3 states like this". To which my response was "But clock in any of the numbers in that I wrote on the board. Your machine fails at the second clock." His machine, of course, works just fine for one direction. But that wasn't the direction I picked and documented picking by writing it on the whiteboard. And his machine didn't work with the bitstreams I chose. And 20 minutes wasn't enough for me to see what he got wrong and demonstrate it back. And he didn't understand his question well enough to flag the reverse order. Exercise for the reader: There are two answers to the question depending upon MSB-first or LSB-first. One answer only requires 3 states. The other answer requires 6 states, but it is NOT clear that 6 states are enough without some serious thought (you can prove 6 are enough inductively if you are clever). 2) I used to always bring to electrical engineering interviews 2 printouts with the same program--one in Python and one in Perl. This meant that when I was asked "Do you know Perl?" I could force the interviewer into MY subset of Perl--and I could explain why I avoided Perl nowadays with a compare and contrast. This simply steamrolled all but one interviewer. 3) I was interviewing with an RF company who was needing VLSI digital designers. A poor slob of an analog engineer drew the short straw for handling the digital questions and was so completely out of his depth that I felt sorry for him. After about half the interview of glazing his eyes with advanced digital architecture, I threw him a bone. I made an off-handed comment about digital really not being digital and how the old audio guys used to use the 4000-series CMOS inverters as audio amplifiers. Baited and hooked. We spent the rest of the interview discussing that as an audio amp (of course, I knew the answers to that question cold--that's why I mentioned it). 4) As an interviewer, I used to run a really difficult section of the VLSI design loop which used to intimidate candidates horribly. I had very stern words with HR that my section was supposed to always be at the end (we almost lost a REALLY excellent candidate because he hit me first, did excellently but THOUGHT he bombed, and then flubbed everybody else afterward). I only had a couple of questions, but they were bottomless. If I had a PhD in front of me, I could make him explain complicated things. If I had a newbie in font of me, I would take him one step further than he was comfortable with and see how he reacted. The candidate steered the interview, but within the bounds I set. 5) My favorite interview was when an interviewer asked me my own difficult question back. It took a moment until I realized exactly what he did, and then I launched 30 minutes into the bottomless pit until I was sure that everybody had glazed eyes and then some. We all had a good laugh afterwards.
- IncRnd 9y ago
  How to steer the interview is to be honest and to talk. "That's a cool problem. I'm curious though - I didn't see that on the job description. I'm not expert on that, and I didn't bone up on that last night. (ha ha everyone laughs) I can step through it if you want, but it would help me if I knew why you asked about this. If you're looking to understand how I solve problems, that's okay, I'll muddle my way through it and ask if I need any clarifications." They'll tell you. Interviewers often hold similar views to the candidates, but may be asking for a different reason than you think.
10-6 9y ago
For those of you who like solving coding challenges online either for fun, practice, or to prepare for interviews, here's a list of popular sites: https://medium.freecodecamp.org/the-10-most-popular-coding-challenge-websites-of-2016-fb8a5672d22f https://medium.freecodecamp.org/the-10-most-popular-coding-c... I also recently put this list of resources together about Algorithms practice which I think can help out anyone who's preparing for an interview soon: https://medium.com/coderbyte/how-to-get-good-at-algorithms-data-structures-d33d5163353f https://medium.com/coderbyte/how-to-get-good-at-algorithms-d...
rickthegeek 9y ago
We wrote a post around this too if anyone is interested - https://geektastic.com/blog/five-killer-interview-questions-for-developers https://geektastic.com/blog/five-killer-interview-questions-...
kafkaesq 9y ago
2. What happens between you typing a URL into your browser address bar, hitting enter and seeing a web page? "What happens when I'm asked a question like X? I spout a mutated form of some canned response I cribbed from a list I found on HN a while back. Because I hear that's how you're supposed to 'rock your coding interview', these days." 3. What are the things you should consider if you were writing your own database server? "Look, you know as well as I that this job has nothing -- as in, nothing whatsoever -- to do with actually building production-grade database servers. Or anything even remotely analogous to it. Debugging that tangled mess of poorly conceived, never-reviewed JSON APIs left behind by the other developer (while you were pestering them about 'disruption' and 'just needing to get this thing to market') is more like it." "But hey, since you're playing that game, I can play too: here's a bunch of catchphrases like 'non-blocking I/O, sharding, blah blah.' Because I hear that's the killer answer to give to questions like these. And BTW, if you really think that people Michael Widenius or Salvatore Sanfilippo would be interviewing for this job, then your problems are way bigger than I could ever hope to help you with."
- _jordan 9y ago
  regarding the database question: I hear it as: "Tell me how detailed your understanding is of database internals in a conversational format; here is a talking prompt to help..." regarding typing in the url question: "Tell me the level in which you understand networking protocols" In the real world I would hope these questions would be more of a discussion; "ah, you mention ACID, what kind of pattern can you employ to help implement that", "MVCC" etc.. This format of interview is hard to pass on simply regurgitation alone and does a pretty decent job of vetting technical understanding in a natural, conversational way.
  - methodover 9y ago
    The URL question is a really good one though. You should absolutely understand every step of that process if you're working on web applications. The database one is weird. You don't need to know how to create a good database system yourself in order to effectively use one, I think. Neither do you need to know how to make a web browser to know how HTTP requests work.
partycoder 9y ago
I think that competitive programming, the kind of programming done at IEEE / ACM competitions as well as interviews, is very different from actual day to day programming. It tells you the person understands data structures and some aspects of programming, but translating that to productivity/success is questionable. In addition to competitive programming you've got "collaborative programming". Programming for maintainability, growth, construction for verification, good practices, etc. A good programmer has a balanced combination of both.
- MartinCron 9y ago
  I like to make the distinction between being a good "programmer" and being a good "professional software developer". Lots of good programmers aren't necessarily good professional software developers. I usually make it a policy not to bad-mouth my fellow coders, but I once worked with a BRILLIANT developer, knew all the trivia, rocked his interview, impressed the hell out of all of us. He then spent two solid weeks building an email address validation micro-service. It was perhaps the most exquisite and technically correct email address validation micro-service ever built, but was that really what the business needed?
  - partycoder 9y ago
    This happens when there's not a very clear expectation on what the deliverable is. Some people have a better intuition than others when it's moment to capture those requirements. Maybe it's better to spend a few more minutes doing the requirement analysis to set those expectations clear. Now, sometimes people tend to underestimate some things. URLs for instance, similar to e-mail addresses, can seem trivial to deal with at first but they're actually more complex than people intuitively think. Incorrect handling of URLs is a significant attack vector.
    - AlexCoventry 9y ago
      I think what the GP is implying is that even a 95%-accurate email address validator would suffice, because any email address you care about is going to get further validation when you validate the address as functional. So it's wasted effort, and suggests poor business sense and a need for close supervision.
aith 9y ago
This has a bit of a web front end slant. Check out https://www.acefrontend.com https://www.acefrontend.com for another good source of practical front end challenges
westurner 9y ago
This is also a great resource, if you're into studying yourself: "Coding Interview University" https://github.com/jwasham/coding-interview-university https://github.com/jwasham/coding-interview-university
gameguy43 9y ago
A piece focused on non-technical tips: https://www.interviewcake.com/coding-interview-tips https://www.interviewcake.com/coding-interview-tips (Full disclosure: I wrote it)
- irl_zebra 9y ago
  I'm not related to this in any way. I'll just say I paid the money recently and went through interview cake and it was really helpful. Learned a bunch and added a bunch of tools to my toolbox. Really liked the walkthroughs of problems bringing it from a brute force answer to optimal. I ended up making it to onsite final interviews with five companies in SF, which I will be going to in the coming weeks. Totally worth it. Only gripe, the online ide you use sucks balls. Half the time I'm debugging whether I used tabs or spaces, and dealing with errors. No matter how careful I tried to be, it seemed to default to whatever I wasn't using and threw errors. Please get a new ide and add in some test cases that maybe tell me how I'm doing in those tests. Otherwise seriously awesome site.
  - gameguy43 9y ago
    Thanks! New IDE is coming! And test cases after that, hopefully.
jv22222 9y ago
I had an idea for a startup that I think could be a much better solution than code interviews. It hinges on the fact you can get a much better sense of a developer after you've worked with her for a few weeks. So, here's the startup idea: Hire a group of developers to to work with you on a small project for a few weeks. They come in as a (virtual or real world) team and build something you've been meaning to do, but it's on your low priority stack. All of the developers in that group are actually looking for a full time job. As you work with them during those 2 weeks you can see which dev you gel with best and offer them a job. In the mean time, all the devs get paid for doing useful work for you for a short period of time, even if they don't get hired. So... the startup is a central agency that engages developers looking for a full time job and then hires them out as a group to help clients do a small project, with a view to picking one or more of the developers for full time work. This is a win for the agency because they have to do less work to convince a client about a candidate. It's a win for developers because they get paid to be on job interviews. And it's a win for the client because they get to try before they buy and as a result will make much higher quality hires. Possible brand name: TeamHire Edit: If you like this please feel free to take it and run with it :)
- ramphastidae 9y ago
  Is your idea limited to developers who do not already have a job? How would someone with a job use this?
  - jv22222 9y ago
    I think you could do something like night or weekend teams. They could work in a virtual capacity in a hangout, or they could come in if they were close by.
    - Epenthesis 9y ago
      But why would I as a person looking for a job want to commit a week or more of my free time to do something like this? Especially since the current job market gives me plenty of much lower time investment options?
pfarnsworth 9y ago
The only answer is: memorize all the leetcode answers perfectly, and pretend you don't know the answer but that you're "working through it". At places like Facebook, I heard that you're given several interviews with 2 coding questions to answer perfectly in 45 mins. It's basically luck of the draw whether or not you know the answer, and the best way to game it is by memorizing as many answers as possible. I know this is possible because I have friends that have gotten offers from Facebook and Google by doing exactly this. All this does, of course, is create an arms race where interviewers ask harder and harder questions. It's frankly ridiculous unless we start taking the algorithmic portion away from the interview.
- ubernostrum 9y ago
  The arms race doesn't proceed all that quickly. Memorize a couple implementations of breadth-first and depth-first search, an implementation of longest common subsequence, and big O of some data structures, and you'll get surprisingly far in most big-tech-co interviews.
smnscu 9y ago
While this is imho in a much nicer format, I also maintain a somewhat opinionated list of technical interview resources: https://github.com/andreis/interview https://github.com/andreis/interview
macjohnmcc 9y ago
I have a request. When someone takes the time to travel to come interview with you at least do them the courtesy of providing useful feedback if you decide not to hire them.
- autarch 9y ago
  Sadly, most companies will not let interviewers do this for fear of lawsuits.
  - bk8335 9y ago
    I have an idea to run mock interviews online with real HR people moonlighting, so that you can receive their honest feedback, and as a result, be better for the real thing.
    - billhathaway 9y ago
      Have you looked at interviewing.io
deathanatos 9y ago
> Tailor your answers to the interviewer’s age. > Generation Y interviewers (between 20 and 30): Bring along visual samples of your work and highlight your ability to multitask. > Generation X interviewers (between 30 and 50): Emphasize your creativity and mention how work/life balance contributes to your success. > Baby Boomer interviewers (between 50 and 70): Show that you work hard and demonstrate respect for what they've achieved. This strikes me as an incredibly ageist thing to do. Even looking at the "suggestion" for my supposed group — what? No; answer the question as correctly as you can; if you can't, try to reason though it as much as you can, and try to convince me that you know something. Some of this is good, but that part in particular … just no.
neilwilson 9y ago
In a world where there is a massive shortage of developers you are the talent and the firms come to you to negotiate. Particularly in a world where anybody can look at your GitHub feed and see what you can do. So these increasingly ridiculous interview techniques have a more sinister purpose. They are an extension of the frat tests to become part of an 'exclusive club'. It's just another brand trick to try and get you to invest so much time and energy into an application that if you actually get picked you will work for less money and worse conditions. You might be the only applicant, but by suckering you in and getting you to jump through hoops you are less likely to walk away when you finally find out they want God on a stick for two pennies for 70 hours a week. Look up psychological loss aversion and sunk cost. Humans hate to write things off and walk away. If I'm hiring a developer I can look at their Github resume and see what style they are and how they work. Then really I need a chat with them to see if their personality fits with the existing team personality (ideally you interview them with the team. The team need to work out if the new prospect fits with their group personality, e.g do they think chickens with lips are funny). You pick one based upon that process and set them on a side job to see how they perform in practice. If they don't perform during probation you let them go and try again. That is a far less costly process to go through than rigging up seven round interviews with everybody. In some respect if you do set up a seven round interview process and invite applications you actually want to talk to those who declined the process. Particularly if they told the selector that it makes no business sense to have such an expensive and time consuming process and therefore there must be another reason for it. Because those are then the ones who can look at the system from the perspective of the other guy, work out what is actually happening rather than what people think is happening and then determine it isn't efficient and can be improved. Which is usually what you are after.
danblick 9y ago
"Doing what you do to seek for what you desire is like climbing a tree to seek for fish." - Mencius Coding interviews test for skills that aren't really the same skills you need to do well as a software engineer. I'm surprised the industry hasn't found any better way to evaluate job candidates yet, given how much is at stake.
BeetleB 9y ago
What I would really like is the ability to ask my interviewers (or better, the team I'd work with) a lot of questions - both technical and otherwise. After all, the interview is supposed to be a two-way process. But they usually give the candidate a lot less time to ask questions. They want to ask me all the difficult questions to see if I'm good enough for them. And I likewise want to ask questions (fairly basic ones) to see if they're good enough for me. Few things suck more than the company demanding a lot from their candidates, and then sticking you in a team with people who don't seem to know the basics.
_pmf_ 9y ago
So this is what we're going to do today.

259 points by duck 9y ago

Clubber 9y ago

So I wonder. If someone memorized all that trivia, do you think they can code?

SmirkingRevenge 9y ago
If its just memorized without understanding, probably not. But I've been doing a bit of the leetcode/hackerrank challenges lately, and believe it or not, I actually think it has made me a bit better, by refreshing bits of knowledge that were getting stale, and really forcing me to think about performance (many test cases in the challenges will fail without the fastest implementations). And they are kind of fun.

Waterluvian 9y ago

What I'd love tips for, is how to politely and professionally protest certain interview styles. I want to know how to say, "sure here's how to implement foo but I also want to express that a focus on this coding trivia is distracting from the skills I feel make me an asset..." Maybe what I'm asking is tips on how to steer an interview. One of the reasons I wouldn't even consider a tech giant interview is that I feel like I'm just one of many cattle being processed through a long gauntlet of nonsense that distils me down to quantifiable traits rather than who I am.

SomeStupidPoint 9y ago
An approach is to proactively bring up interesting aspects of the problem yourself -- eg, the last time I was writing example code on the board, I spent most of the time talking about where hooks to add more features would go or algorithmic complexity/edge cases I encounter as I try to implement a solution. If you're focusing on the trivia, you're probably too focused on the code and not on solving the problem -- my experience tends to be that there's at least one or two interesting edge cases you encounter if you try the naive approach, and those are generally what the interviewer wants to discuss. The reason is that discovering edge cases in requirements and solving them is what a lot of the job is, and so how you approach that matters (and to an extent, more than if your code on the board is "correct"). Another approach is to extend the problem by asking clarifying questions -- if there's something unspecified that might influence your design, ask about it and tell the interviewer why it matters. Again, this generally is more what they care about than the details of the coding. Finally, if those skills make you an asset -- why not apply them to the question? Even tangentially by talking about how you would (if you had more time/were doing a real assignment). Coding on the white board is more about the journey than the coding, assuming you can write vaguely correct code. (Though writing on a whiteboard is definitely a skill you have to practice.)
ebiester 9y ago
In our interview, we have people from 4 different departments who will talk with the candidate, as well as the team (who is there for the coding portion.) I honestly don't want to have to test if someone can handle a simple algorithm. (I'm not talking about anything crazy here, mind you.) Can they read code? Can they think about how to test? I've seen faked code samples, and our test has a half dozen answers on github. I want to just assume that anybody with five years of programming experience can code, but I've worked alongside enough counterexamples that I know I can't assume that. That said, I'd really rather not have to deal with it as a candidate or as an interviewer.
- kuro68k 9y ago
  These tests favour people who are good at tests. I know people who test will, crank out code fast, but I'm the long run they suck because they didn't think about it enough. I'll point a company at my sample code. They can ask me about it too make sure it's really mine. When interviewing people I'd much rather have someone who knows how to find the best solution, not the person who has read a list of questions like this.
misanthropic 9y ago
Well you can always say that you're not comfortable coding during interview, and propose to look at your github instead...
pklausler 9y ago
When I ask a straightforward problem during a technical interview, I'm trying to ensure that the human before me is actually capable of solving the straightforward problem. You're free to respond any way that you like, but if your response doesn't actually include a solution that demonstrates the capability I'm testing for, I'm not sure that I'm going to be able to distinguish you from the ~50% of interview subjects that HR puts before me that have no idea whatsoever how to program a computer. I don't even ask softball questions. Mine are more like tee-ball questions. Too often, the tee pitches a perfect game.
- rurounijones 9y ago
  Out of curiosity. Would you still ask these questions if the candidate has a github/gotlab/whatever profile with X repositories where they are the main / only contributor? Could you explain why yes / no and what the specifics would be? (Volume? Complexity? Commit history? )
  - pklausler 9y ago
    I absolutely do. I can't assume that the person before me is the person who actually wrote the code on github.
    - deleted 9y ago
      [deleted]
    - Vendan 9y ago
      I think you'd get more value out of talking with them about those repos, and the process of building them, design choices, then any silly question like "how would you design a database". Of course, that would also mean you'd have to actually put more then a few minutes into prep for the candidate's interview...
      - rabidrat 9y ago
        While I agree with you for the most part, many companies want a "standardized" interview process, for both diversity and CYA reasons. Tailoring the interview to the candidate is actually illegal in certain organizations (like government), as it has large potential for abuse.
tytytytytytytyt 9y ago
Implementing things isn't trivia, it's an integral part of being a software engineer.
sabman83 9y ago
A somewhat related experience I had with a company that advertised proudly that they don't do live coding tests. They had a take-home exercise which I did very well and I was scheduled for a phone interview later. I was expecting it to be more around system design, behavioral questions but to my surprise it was a live coding test. After the interview was done I questioned the person why have another coding test. He said it was to test on different areas of programming. I later messaged the VP/CTO who wrote the blog post on not having live coding test. The person apologized for the experience and said that the team I interviewed for did not come under engineering org. It was a frustrating experience but at least the person responded positively.
thesmallestcat 9y ago
A warning: If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem. Every off-by-one error you commit on the job will raise an eyebrow. People will wonder, does this guy want to be an engineer or something else? Why couldn't he rip through that problem and teach _us_ a thing or two on the way? Another thing is you're basically coming in and saying "your interview process is wrong". If you're being interviewed as a manager or a lead, you can afford that risk. If not, be careful, because many people, myself included, don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time.
- programmarchy 9y ago
  > don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time This seems a little too general to me. Many things are not clearly thought out, and I'd rather work with people who can recognize when that is the case and communicate well enough to correct the course. A big part of successful development in my experience is knowing when not to implement things, or having foresight to implement things in a better way. Working with people who just do what they're told is often a huge waste of time.
- majormajor 9y ago
  I think it's fair for non-simple coding problems. If someone asked me a problem that basically reduced to a textbook case of something in the middle, difficulty wise, like reservoir sampling, and I said "oh, nifty, resevoir sampling, what do you use that for in your stack?" and they said "nothing, I just want to make sure you can code," then depending on how my experience to that point in the process had been going I might challenge them on that to some extent, a la "do you find this more useful than questions that are more representative of the work you're expecting me to do?" If the loop had been going particularly robotically, this might find stronger forms - I've walked out on a mismanaged interview before, though it was way worse than this (and way worse in a very different way - they just weren't at all prepared and the tooling they wanted me to use wasn't actually functional). Or they might answer something more like "we use it to select test cases from our logs to ensure that we're adequately testing against real behavior with proper weights" (or whatever—it's been a while since I actually did this in a past job :) ) in which case I'd still try to have what I consider a more "real" conversation ("what primary problem are we trying to solve, and what else might be options to consider"), but in that case at least they had a good answer to the question and I'd be happy to write the code too. But lastly, frankly, as a hiring manager I absolutely want to hire people who are willing to "not focus on the task at hand" and question things. I don't want people who just blindly do what I tell them to, I want people I can trust to disagree with me and be able to make a case for why they disagree. Being a manager doesn't mean my instincts are 100% and theirs are 0%.
watwut 9y ago
It is only after you worked with someone lazy or barely capable of foo who charizma-around-company-pong-table his way to staying in company and being treated as genius by those who don't work directly with him that you appreciate those simple exercises.
mylons 9y ago
steering an interview is all about steering the human(s) giving the interview. real life example: an MIT PhD in distributed computing walks into the room, looking extremely tired from interviewing people like me. I can tell this is going to be rough unless I'm controlling the conversation and we have a good rapport. He's wearing a Fender shirt. I have played guitar a bit. After he introduces himself and I myself I open with, "Oh nice shirt. I assume you play some guitar?" and there goes 20 minutes of the interview talking about guitars. So long as I don't completely bomb the technical aspect I've left this person with a positive and relatable experience.
- UncleMeat 9y ago
  This is the kind of thing that people want to avoid. Hiring a person because they share a hobby is ridiculous. If a candidate tried to steer the interview to non-technical questions I'd point that out to the relevant people and make sure it was highlighted in my feedback.
  - bsder 9y ago
    If you let the candidate steer the interview in the wrong direction, the fault is in the interviewer, not the candidate. I have been on both sides of the equation. My stories: 1) Brain teaser questions sometimes aren't as easy or as straightforward as everybody thinks--don't ask them as an interviewer unless you genuinely KNOW the question. Digital VLSI design loops almost always have a question that makes you use a state machine--this is actually a decent question for a whiteboard as long as you don't do something stupid like use J-K flip flops in CMOS. There are a host of basic questions you can use ... but beware of traps. I was once asked the following question: "You have a serial bitstream that represents a binary number. Keep track of the value of that number modulo 3." This is a decent question ... Or a really hard question ... depending upon whether the number is being clocked in MSB first or LSB first. Unfortunately, when I wrote the numbers down on the whiteboard, I chose the "hard" direction. And had to really think ... and the interviewer kept getting more and more agitated and finally complained "Look, this is easy, just do 3 states like this". To which my response was "But clock in any of the numbers in that I wrote on the board. Your machine fails at the second clock." His machine, of course, works just fine for one direction. But that wasn't the direction I picked and documented picking by writing it on the whiteboard. And his machine didn't work with the bitstreams I chose. And 20 minutes wasn't enough for me to see what he got wrong and demonstrate it back. And he didn't understand his question well enough to flag the reverse order. Exercise for the reader: There are two answers to the question depending upon MSB-first or LSB-first. One answer only requires 3 states. The other answer requires 6 states, but it is NOT clear that 6 states are enough without some serious thought (you can prove 6 are enough inductively if you are clever). 2) I used to always bring to electrical engineering interviews 2 printouts with the same program--one in Python and one in Perl. This meant that when I was asked "Do you know Perl?" I could force the interviewer into MY subset of Perl--and I could explain why I avoided Perl nowadays with a compare and contrast. This simply steamrolled all but one interviewer. 3) I was interviewing with an RF company who was needing VLSI digital designers. A poor slob of an analog engineer drew the short straw for handling the digital questions and was so completely out of his depth that I felt sorry for him. After about half the interview of glazing his eyes with advanced digital architecture, I threw him a bone. I made an off-handed comment about digital really not being digital and how the old audio guys used to use the 4000-series CMOS inverters as audio amplifiers. Baited and hooked. We spent the rest of the interview discussing that as an audio amp (of course, I knew the answers to that question cold--that's why I mentioned it). 4) As an interviewer, I used to run a really difficult section of the VLSI design loop which used to intimidate candidates horribly. I had very stern words with HR that my section was supposed to always be at the end (we almost lost a REALLY excellent candidate because he hit me first, did excellently but THOUGHT he bombed, and then flubbed everybody else afterward). I only had a couple of questions, but they were bottomless. If I had a PhD in front of me, I could make him explain complicated things. If I had a newbie in font of me, I would take him one step further than he was comfortable with and see how he reacted. The candidate steered the interview, but within the bounds I set. 5) My favorite interview was when an interviewer asked me my own difficult question back. It took a moment until I realized exactly what he did, and then I launched 30 minutes into the bottomless pit until I was sure that everybody had glazed eyes and then some. We all had a good laugh afterwards.
IncRnd 9y ago
How to steer the interview is to be honest and to talk. "That's a cool problem. I'm curious though - I didn't see that on the job description. I'm not expert on that, and I didn't bone up on that last night. (ha ha everyone laughs) I can step through it if you want, but it would help me if I knew why you asked about this. If you're looking to understand how I solve problems, that's okay, I'll muddle my way through it and ask if I need any clarifications." They'll tell you. Interviewers often hold similar views to the candidates, but may be asking for a different reason than you think.

10-6 9y ago

For those of you who like solving coding challenges online either for fun, practice, or to prepare for interviews, here's a list of popular sites: https://medium.freecodecamp.org/the-10-most-popular-coding-challenge-websites-of-2016-fb8a5672d22f https://medium.freecodecamp.org/the-10-most-popular-coding-c... I also recently put this list of resources together about Algorithms practice which I think can help out anyone who's preparing for an interview soon: https://medium.com/coderbyte/how-to-get-good-at-algorithms-data-structures-d33d5163353f https://medium.com/coderbyte/how-to-get-good-at-algorithms-d...

rickthegeek 9y ago

We wrote a post around this too if anyone is interested - https://geektastic.com/blog/five-killer-interview-questions-for-developers https://geektastic.com/blog/five-killer-interview-questions-...

kafkaesq 9y ago

2. What happens between you typing a URL into your browser address bar, hitting enter and seeing a web page? "What happens when I'm asked a question like X? I spout a mutated form of some canned response I cribbed from a list I found on HN a while back. Because I hear that's how you're supposed to 'rock your coding interview', these days." 3. What are the things you should consider if you were writing your own database server? "Look, you know as well as I that this job has nothing -- as in, nothing whatsoever -- to do with actually building production-grade database servers. Or anything even remotely analogous to it. Debugging that tangled mess of poorly conceived, never-reviewed JSON APIs left behind by the other developer (while you were pestering them about 'disruption' and 'just needing to get this thing to market') is more like it." "But hey, since you're playing that game, I can play too: here's a bunch of catchphrases like 'non-blocking I/O, sharding, blah blah.' Because I hear that's the killer answer to give to questions like these. And BTW, if you really think that people Michael Widenius or Salvatore Sanfilippo would be interviewing for this job, then your problems are way bigger than I could ever hope to help you with."

_jordan 9y ago
regarding the database question: I hear it as: "Tell me how detailed your understanding is of database internals in a conversational format; here is a talking prompt to help..." regarding typing in the url question: "Tell me the level in which you understand networking protocols" In the real world I would hope these questions would be more of a discussion; "ah, you mention ACID, what kind of pattern can you employ to help implement that", "MVCC" etc.. This format of interview is hard to pass on simply regurgitation alone and does a pretty decent job of vetting technical understanding in a natural, conversational way.
- methodover 9y ago
  The URL question is a really good one though. You should absolutely understand every step of that process if you're working on web applications. The database one is weird. You don't need to know how to create a good database system yourself in order to effectively use one, I think. Neither do you need to know how to make a web browser to know how HTTP requests work.

partycoder 9y ago

I think that competitive programming, the kind of programming done at IEEE / ACM competitions as well as interviews, is very different from actual day to day programming. It tells you the person understands data structures and some aspects of programming, but translating that to productivity/success is questionable. In addition to competitive programming you've got "collaborative programming". Programming for maintainability, growth, construction for verification, good practices, etc. A good programmer has a balanced combination of both.

MartinCron 9y ago
I like to make the distinction between being a good "programmer" and being a good "professional software developer". Lots of good programmers aren't necessarily good professional software developers. I usually make it a policy not to bad-mouth my fellow coders, but I once worked with a BRILLIANT developer, knew all the trivia, rocked his interview, impressed the hell out of all of us. He then spent two solid weeks building an email address validation micro-service. It was perhaps the most exquisite and technically correct email address validation micro-service ever built, but was that really what the business needed?
- partycoder 9y ago
  This happens when there's not a very clear expectation on what the deliverable is. Some people have a better intuition than others when it's moment to capture those requirements. Maybe it's better to spend a few more minutes doing the requirement analysis to set those expectations clear. Now, sometimes people tend to underestimate some things. URLs for instance, similar to e-mail addresses, can seem trivial to deal with at first but they're actually more complex than people intuitively think. Incorrect handling of URLs is a significant attack vector.
  - AlexCoventry 9y ago
    I think what the GP is implying is that even a 95%-accurate email address validator would suffice, because any email address you care about is going to get further validation when you validate the address as functional. So it's wasted effort, and suggests poor business sense and a need for close supervision.

aith 9y ago

This has a bit of a web front end slant. Check out https://www.acefrontend.com https://www.acefrontend.com for another good source of practical front end challenges

westurner 9y ago

This is also a great resource, if you're into studying yourself: "Coding Interview University" https://github.com/jwasham/coding-interview-university https://github.com/jwasham/coding-interview-university

gameguy43 9y ago

A piece focused on non-technical tips: https://www.interviewcake.com/coding-interview-tips https://www.interviewcake.com/coding-interview-tips (Full disclosure: I wrote it)

irl_zebra 9y ago
I'm not related to this in any way. I'll just say I paid the money recently and went through interview cake and it was really helpful. Learned a bunch and added a bunch of tools to my toolbox. Really liked the walkthroughs of problems bringing it from a brute force answer to optimal. I ended up making it to onsite final interviews with five companies in SF, which I will be going to in the coming weeks. Totally worth it. Only gripe, the online ide you use sucks balls. Half the time I'm debugging whether I used tabs or spaces, and dealing with errors. No matter how careful I tried to be, it seemed to default to whatever I wasn't using and threw errors. Please get a new ide and add in some test cases that maybe tell me how I'm doing in those tests. Otherwise seriously awesome site.
- gameguy43 9y ago
  Thanks! New IDE is coming! And test cases after that, hopefully.

jv22222 9y ago

I had an idea for a startup that I think could be a much better solution than code interviews. It hinges on the fact you can get a much better sense of a developer after you've worked with her for a few weeks. So, here's the startup idea: Hire a group of developers to to work with you on a small project for a few weeks. They come in as a (virtual or real world) team and build something you've been meaning to do, but it's on your low priority stack. All of the developers in that group are actually looking for a full time job. As you work with them during those 2 weeks you can see which dev you gel with best and offer them a job. In the mean time, all the devs get paid for doing useful work for you for a short period of time, even if they don't get hired. So... the startup is a central agency that engages developers looking for a full time job and then hires them out as a group to help clients do a small project, with a view to picking one or more of the developers for full time work. This is a win for the agency because they have to do less work to convince a client about a candidate. It's a win for developers because they get paid to be on job interviews. And it's a win for the client because they get to try before they buy and as a result will make much higher quality hires. Possible brand name: TeamHire Edit: If you like this please feel free to take it and run with it :)

ramphastidae 9y ago
Is your idea limited to developers who do not already have a job? How would someone with a job use this?
- jv22222 9y ago
  I think you could do something like night or weekend teams. They could work in a virtual capacity in a hangout, or they could come in if they were close by.
  - Epenthesis 9y ago
    But why would I as a person looking for a job want to commit a week or more of my free time to do something like this? Especially since the current job market gives me plenty of much lower time investment options?

pfarnsworth 9y ago

The only answer is: memorize all the leetcode answers perfectly, and pretend you don't know the answer but that you're "working through it". At places like Facebook, I heard that you're given several interviews with 2 coding questions to answer perfectly in 45 mins. It's basically luck of the draw whether or not you know the answer, and the best way to game it is by memorizing as many answers as possible. I know this is possible because I have friends that have gotten offers from Facebook and Google by doing exactly this. All this does, of course, is create an arms race where interviewers ask harder and harder questions. It's frankly ridiculous unless we start taking the algorithmic portion away from the interview.

ubernostrum 9y ago
The arms race doesn't proceed all that quickly. Memorize a couple implementations of breadth-first and depth-first search, an implementation of longest common subsequence, and big O of some data structures, and you'll get surprisingly far in most big-tech-co interviews.

smnscu 9y ago

While this is imho in a much nicer format, I also maintain a somewhat opinionated list of technical interview resources: https://github.com/andreis/interview https://github.com/andreis/interview

macjohnmcc 9y ago

I have a request. When someone takes the time to travel to come interview with you at least do them the courtesy of providing useful feedback if you decide not to hire them.

autarch 9y ago
Sadly, most companies will not let interviewers do this for fear of lawsuits.
- bk8335 9y ago
  I have an idea to run mock interviews online with real HR people moonlighting, so that you can receive their honest feedback, and as a result, be better for the real thing.
  - billhathaway 9y ago
    Have you looked at interviewing.io

deathanatos 9y ago

> Tailor your answers to the interviewer’s age. > Generation Y interviewers (between 20 and 30): Bring along visual samples of your work and highlight your ability to multitask. > Generation X interviewers (between 30 and 50): Emphasize your creativity and mention how work/life balance contributes to your success. > Baby Boomer interviewers (between 50 and 70): Show that you work hard and demonstrate respect for what they've achieved. This strikes me as an incredibly ageist thing to do. Even looking at the "suggestion" for my supposed group — what? No; answer the question as correctly as you can; if you can't, try to reason though it as much as you can, and try to convince me that you know something. Some of this is good, but that part in particular … just no.

neilwilson 9y ago

In a world where there is a massive shortage of developers you are the talent and the firms come to you to negotiate. Particularly in a world where anybody can look at your GitHub feed and see what you can do. So these increasingly ridiculous interview techniques have a more sinister purpose. They are an extension of the frat tests to become part of an 'exclusive club'. It's just another brand trick to try and get you to invest so much time and energy into an application that if you actually get picked you will work for less money and worse conditions. You might be the only applicant, but by suckering you in and getting you to jump through hoops you are less likely to walk away when you finally find out they want God on a stick for two pennies for 70 hours a week. Look up psychological loss aversion and sunk cost. Humans hate to write things off and walk away. If I'm hiring a developer I can look at their Github resume and see what style they are and how they work. Then really I need a chat with them to see if their personality fits with the existing team personality (ideally you interview them with the team. The team need to work out if the new prospect fits with their group personality, e.g do they think chickens with lips are funny). You pick one based upon that process and set them on a side job to see how they perform in practice. If they don't perform during probation you let them go and try again. That is a far less costly process to go through than rigging up seven round interviews with everybody. In some respect if you do set up a seven round interview process and invite applications you actually want to talk to those who declined the process. Particularly if they told the selector that it makes no business sense to have such an expensive and time consuming process and therefore there must be another reason for it. Because those are then the ones who can look at the system from the perspective of the other guy, work out what is actually happening rather than what people think is happening and then determine it isn't efficient and can be improved. Which is usually what you are after.

danblick 9y ago

"Doing what you do to seek for what you desire is like climbing a tree to seek for fish." - Mencius Coding interviews test for skills that aren't really the same skills you need to do well as a software engineer. I'm surprised the industry hasn't found any better way to evaluate job candidates yet, given how much is at stake.

BeetleB 9y ago

What I would really like is the ability to ask my interviewers (or better, the team I'd work with) a lot of questions - both technical and otherwise. After all, the interview is supposed to be a two-way process. But they usually give the candidate a lot less time to ask questions. They want to ask me all the difficult questions to see if I'm good enough for them. And I likewise want to ask questions (fairly basic ones) to see if they're good enough for me. Few things suck more than the company demanding a lot from their candidates, and then sticking you in a team with people who don't seem to know the basics.

_pmf_ 9y ago

So this is what we're going to do today.