15 ms·

I once interviewed at a company that had you write a traveling salesman program where you were planning the shortest path of flights between cities. It was a ta

I once interviewed at a company that had you write a traveling salesman program where you were planning the shortest path of flights between cities. It was a take home test where you were given at least a week to complete it. I completed the test in record setting time (3 days earlier than most), mine was the only one that was fully documented with comments (no one else bothered to do this), they said I had the most visually stunning user interface (most were ugly or unusable; I even animated the plane flying between cities), the program came to the outcome in the shortest runnable time, out of all the submitters they said my program was the most optimized solution (not the best ever made, but the best submitted to this company so far), and mine was the only one that actually worked correctly and ran without flaws. They then proceeded to have me come in for the 6 hour interview in which they asked questions like, "Write a working hash table from scratch on the whiteboard." I got nervous and passed the question, they ended the interview early and rejected my application.

rcfox 7y ago
I once interviewed at a company that had me write a couple styles of matrix multiplication in C as a take home test, as well as give a one-page description of a project I had done. The project I described heavily involved graph searches. Then I had a phone interview where they started off by commenting that I was the only one to include tests and address undefined behaviour. Then I had to write a piece of code to traverse a tree and add numbers, I can't remember what it was exactly, but I got nervous and messed up somehow. Then I waited for 2 weeks just to hear back that they wanted someone more experienced with graph theory.
- mjevans 7y ago
  Expecting perfection on a white-board test is setting everyone up for failure. At best that's a large napkin exercise. Though having a failure, or a point where for whatever reason production is a bottleneck (if they happen to do it without obvious faults) is an opportunity to identify that either thing is the case in that section and move forward with how they'd react; what should be changed, etc. We're all still human; expect failure to happen. See what happens next.
  - rjbwork 7y ago
    100% agree. I interviewed at Microsoft nearly a decade ago now. I was told I'd be interviewing for the company, and then if I was hired, based on preference and ability and need I'd be placed with a team When I got there I was told I'd be interviewing for the SQL Server team, interesting work, but not something I'm interested in. I had never taken operating systems in university because it was always available at a time that another class I HAD to take occurred. So by some random chance, I'd never heard of a semaphore. Perhaps inexcusable at this point in my career, but I was ignorant of the topic at that time. My first interview question was to write a way to let many readers on a resource, and only 1 writer, with no readers reading at the time of the writer writing. I decided to use lists of something or another, ProcessId, or something similar. Every time I would go to write the code, i'd get a few characters in, and the interviewer would interrupt me and ask me questions to help me along. Since I had no idea what a semaphore was, much less that I was supposed to use it, we spent like 30 minutes of this back and forth, me trying to write, him interrupting me. By the end of the session I had a single line initializing a list written. Some of my other interviews during that battery of interviews went better than that one for sure but, needless to say, I didn't get the job.
azhenley 7y ago
I was not expecting your story to take that turn... that sounds like a bad experience! I hope something better came along.
- palisade 7y ago
  I've worked on pretty cool projects since then at other companies. And, it isn't the only interview I've ever had like that, it is more common than I would like. It is sometimes very hard for me to prove myself. Even though I've had plenty of jobs in the past with proof I can code and with good references. I sometimes feel like I'm an imposter, even while kicking ass on a project.
WalterBright 7y ago
The problem with take-home tests is you may have had help, or someone else did the test for you. If you didn't do well in the in-person test, they may have reasonably assumed that was the case. Especially if the home test was unusually good. I was aware candidates would do things like this when I applied for job long ago. I also was aware that employers were suspicious of these sorts of things. So I brought along listings of code I'd written, pulled them out, and walked the interviewer through how they worked to show I knew my stuff. Note that they didn't ask for this, I just did it proactively. I got an offer, too, and was told some time later by the interviewer that that was why.
- rcfox 7y ago
  Why bother giving a take-home test if you don't trust the results? Why compare the results to work done in a completely different medium with no opportunity to iterate on the output, take a break or work comfortably? If you assign a take-home test, make the interview focus on discussing the product.
  - shultays 7y ago
    Because you can eliminate most applicants that way by cutting no/poor submissions
    - chipperyman573 7y ago
      Yes but you also cut all the people who are good enough they know they can get a job somewhere that doesn't pull something like this.
  - lacker 7y ago
    Why bother giving a take-home test if you don't trust the results? You can have one-way trust in a take-home. If they don't meet your quality bar, you can discard the resume. And it takes near zero work on the company's part, that's why so many companies like it. However, some people will just get a lot of help on the take-home. So it isn't fair to the other applicants if you treat a take-home as anything other than a filter.
JMTQp8lwXL 7y ago
You are not alone in such experiences. After going through something like that, I no longer do take-homes.
ourlordcaffeine 7y ago
If I were ever to give a coding interview, I wouldn't be asking the candidate to implement a certain data structure, but rather explain the pros and cons of using say, an array vs a linked list and when you would use one over another. Because at the end of the day, you will not be implementing them but using them.
- mattdeboard 7y ago
  At a previous education startup I did a lot of interviewing of candidates. The question I feel gave me the most insight into candidates was very, very broad. After explaining (generally) how the company’s product worked, I’d ask them something like, “Let’s have a conversation about how you would design a system to distribute e-textbooks to students.” I would reassure them there is not a right answer, that the exercise was just asking them to engage with the question. It was so effective as an indicator of future performance, and, according to those who eventually were hired, felt fair to them. Of course this implies all my biases to people who can have a 1:1 convo about a very vaguely specified problem and so on. No idea if it’d be positive for everyone, but I wish someone would interview me like that.
- xtracto 7y ago
  Exactly, after years and years of interviewing and building teams I learned that the best way to interview about data structures is to do Q&A related to them. Even if you are going to work in a project that requires building such structures, I demand that you don't do it from memory, but make sure to get help from resources to ensure that your structures are sound.
fatnoah 7y ago
Or put more succinctly: https://twitter.com/mxcl/status/608682016205344768?lang=en https://twitter.com/mxcl/status/608682016205344768?lang=en "Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so f* off."
- alexmlamb 7y ago
  Is it just me or does this reasoning not make any sense? "NASA: 90% of our rocket scientists use the A/C you just fixed, but you can't explain how a rocket works so f* off" Presumably what matters is whether homebrew is technically significant or relevant, not just that they use it?
  - musicale 7y ago
    I think it's just you. 0. The actual job of a software developer is usually to develop software with some real-world use and benefit, not to write cs101 code on a whiteboard while someone watches you and grades you for speed and accuracy. 1. Software is what Google does, and Google does tons of software from tools to infrastructure to services to games. If you created a key software tool that tons of people use at Google to do their jobs, it's pretty relevant. 2. Software isn't like doing routine maintenance on an existing A/C system - it's usually somewhere between inventing A/C and creating a new design for data center A/C systems then building, deploying, and operating it.
    - NeverFade 7y ago
      Without making any judgement about this particular situation, this logic isn't sound: 1. I develop tool X, which is a simple popular solution. 2. Some company Y is hiring engineers to develop solutions that are far more complex and demanding than what my tool does, for instance because they have to support billions of concurrent users. 3. I deserve the job because most of Y's engineers use the simple tool X that I developed, even though the job requires far more advanced skills than I have demonstrated writing X, and I actually don't have these skills and will totally fail at the job if hired.
bitL 7y ago
If they were willing to give you a top compensation, then OK, writing hash table from the scratch is a pretty common question at Google/FB. If it was for some generic job with generic pay, they did you a great service by rejecting you.
- otabdeveloper4 7y ago
  "Writing a hash table from scratch" is a programming 101 problem just slightly harder than FizzBuzz, but not by much. Though I guess these days I guess 'software development' means downloading Javascript crap from github and copy-pasting CSS.
  - bsder 7y ago
    > "Writing a hash table from scratch" is a programming 101 problem just slightly harder than FizzBuzz, but not by much. No, it's bloody not. What's your hash function? Why? What do you do on hash collisions. How many buckets and how big? Does your hash function map to identity or not? Do you exclude certain fields from hashing? How do you handle contention from multiple threads? I can go on and on. The fact that you think writing a hash is easy betrays a stunning amount of ignorance.
    - detaro 7y ago
      That's the difference between a hashtable you might want to use in practice and a toy example to have someone write some code while quizzing some CS theory.
    - antisemiotic 7y ago
      To be fair, the interview question a few posts up mentioned a working hash table, saying nothing about efficiency or thread safety. (though such a question could be gamed with a linked list as a "well akshuolly" a single-bucket hash table...)
misiti3780 7y ago
what was the company? - companies like this should be called out
- palisade 7y ago
  I wouldn't do that to them. They have a right to interview how they want. I just wasn't good enough. They were looking for someone who could think on their feet under pressure in the moment and I'm not that guy. I need a quiet place to sit and think something through and plan it out. It is why I did well on the test portion but not on site surrounded by interrogators. In those kind of situations I kind of feel like I'm the in the movie Swordfish where they're like, "Hack that server you have sixty seconds! (gun to head)" The difference is, I would have been dead.
  - mixmastamyk 7y ago
    > I need a quiet place to sit and think something through and plan it out That’s the only way hard, unique problems are solved. If it can be done quickly, it’s routine.
mLuby 7y ago
That sucks, I'm sorry. How do you know the quality of others' submissions? >I got nervous and passed the question I didn't know that was allowed. Has that worked for people in the past?
- palisade 7y ago
  The employer informed me how my results fared. I went back and looked at the emails. I can't edit my original comment so I'll jot the corrections here. They gave 3 days not a week. I completed the submission in 7 hours, they required you track how many hours you spent and when. I used a genetic algorithm to solve the problem. And, I took advantage of multiple cores if they were available to divide the work load. Looking at the email there were signs even in their review of my submission that their outlook wasn't completely rosy. They mentioned things like how I failed to correct for differential conversion factors based on global location and stuff like that. Skipping the question obviously didn't work out for me as I didn't get the position. It was a weird experience to be put on the spot with such great skepticism with all my past accomplishments and knowing how much they respected my test submission. In a way it was humiliating. I didn't leave that interview feeling very good about myself. I still regret it to this day. In some ways I wish I could go back in time and pass on the interview, I think I would be more confident today.
  - mLuby 7y ago
    Thanks for the update; it makes more sense now. I bombed an interview where I couldn't understand the prompt, literally. Like the interviewer spoke it to me, and I restated the problem, and he said "no it's…" and drew something on the white board, and I listened and restated it, and we went back and forth like that for about 15 minutes. To this day I don't understand what he was asking for, only that involved a rate of bank customers and a Greek lambda. Getting good jobs means pushing your limits and it's therefore a numbers game. Feeling shame from rejection is natural, but also generally unhelpful these days, so it's worth unlearning.
- stevenwoo 7y ago
  I remember doing a take home and adding it to github as requested by the company. Then I realized every one else who applied did the same thing and left up their solution and found all the other candidate answers using a simple search. This was prior to github making private repos free.
mawburn 7y ago
My favorite interview experience was when I passed a live coding exercise on Monday and had time to optimize, then completely failed the exact same problem on Friday with a different company because my nerves hit me.
- kbrisso 7y ago
  I feel for you man, I drove 4 hours from Sacramento to Palo Alto for a great start up job. I nailed the phone interview and thought all was going to go well. The first onsite interview went pretty well. The second part went south and my nerves got me. I really wanted the job but I blew it. I got good feedback and I'm working on interview problems. It was my first interview in 20 years but again I really wanted the job.
  - deleted 7y ago
    [deleted]
rsyring 7y ago
There is a lot of discussion in the comments on this thread about take home tests not being useful. I believe we've have a pretty good hiring process that makes significant use of take home tests (16-18 hours of them in fact). At the same time, I assure you that we care deeply about making the best use of our and the applicants time. This is what we do to make that happen: - We make a commitment to reply to every candidate who applies as instructed. Not every reply can be detailed, but candidates are never applying to a black hole. - We have a very detailed job description that answers a lot of the questions many developers have about a company up front. There is always a chance that we are lying or don't live up to what we say, but the info is at least there so the applicants can make an informed decision about whether they are really interested in working for us. The details about our application process are also stated clearly up front so that candidates know what they are getting into. - We ask pretty in-depth follow questions about technical experience to make sure it aligns with what we are looking for. This filters out a decent amount of candidates who would be unlikely to pass the rest of our process saving them and us time. Other than roughly validating that the candidates work experience falls within the range we are looking for, we find resumes to be mostly useless. - The initial "take home" exercise we ask applicants to complete takes 60-90 minutes. It's not a coding exercise and they are given a document that helps them prep for the work they are going to be asked to do. We have found over time that this is more predictive of success in our organization that doing an initial phone screen. Candidates are given relatively detailed feedback on this exercise, usually within 3 business days of submitting their work. - The next step is a Zoom interview. We have a few very basic coding tasks that we ask them to do as part of this interview. These tasks are representative of real world skills a developer would need and not in any way convoluted or academic. The environment could be challenging for some due to the fact that we are watching over their shoulder, but again the tasks are very basic and the goal is simply to see that the tasks are able to be finished in a reasonable time. This isn't to tell us if the candidate can do the job, it just helps us filter out candidates who are likely to fail badly on the next part of our interview process. It saves them time and us time and money. We have occasionally passed candidates on this step who seemed like their bad performance might have been from nervousness and, to date, those candidates have never performed well on the rest of our skills tests. The candidate has an opportunity to ask any questions they would like during this interview. We also talk about money at this stage. Our salary range and benefits are published on the job description so we ask the candidate what their expectations are from a compensation perspective. If they are reluctant to share details, that's fine, but we at least confirm that they understand that our published compensation is what we are actually planning on paying and ask that if that is not suitable to them, that they let us know that now before moving along in the process. Only if everything is aligning at this stage, do we then ask them to commit to a significant more time working through our skills tests process. Our increasing "ask" of the candidate's time is deliberately progressive. We are trying to only ask more of them when we have had the chance to vet them for obvious mismatches and vice versa. - We then move into a two part skills test process (16-18 hours). All candidates who move on to these tests are compensated at around $50 per hour. All tests are timed and represent real world tasks our developers do on a daily basis. The first three have to be scheduled and proctored but the fourth is really "take home" and can be done at the developers leisure. If they pass all of those tests, the work on the fourth test goes through a code review process and is then reviewed with the candidate as part of their second video interview, in a very similar way to how we would do a code review for one of our projects. - Finally, if all that goes well, we do an on-site interview which is mostly a work day (or two) with the project they are working on, again, very representative of the work our developers do on a daily basis. The costs of travel and lodging are compensated at this stage, but we are not paying them hourly. The work they do for us is not customer based work and does not generate revenue for us. I can't say this is a perfect process and it is a lot to ask of an applicant. But, we also put a lot of time and money into this process for those who get to the later stages. So it's a "give, give" if you will. I'm sure some will take issue with this process and some don't apply because they don't like the intensity or commitment involved. But I honestly can't fathom trying to decide on someone's technical ability by spending less time seeing how they handle actual programming tasks. So, we do ask a lot from applicants, but our skills tests work out ok specifically because: - As much as possible, our process is designed to be "evidence based." We rely heavily on skills tests and evaluations that look at how the candidate does work that is very similar to the work we actually need them to do in the job. - We work hard to provide the candidate with all the info they need from us to determine if we'd be a good fit for them before we ask for more than a few hours of their time - All programming tasks are done on their own machine with the editor/tools of their choice (we do choose the language the skills tests are in which align with the technologies which are posted as required in the job descriptions) - All programming tasks are highly representative of actual work a candidate would do if they were hired. The fact that they are timed is probably the one thing that is most "contrived" about the tests. - The skills tests are paid at ~$50 per hour - The grading of the candidates work is pretty straight forward. We have a rubric of sorts for what we are looking for and, to the best of our ability, that rubric aligns with the same things we'd be looking for during a code review of one of our employees that was working on a customer project. There are no trick questions and there are no academic or algorithmic oriented questions (because our day to day tasks don't usually involve those skills) - While it's possible someone could get another developer to take the skills tests for them, the on-site work day(s) would likely reveal their deceit rather quickly. And, if not, we are a small organization and would figure it out pretty quickly if they made it all the way through and actually started working with us. I'd love to have a simpler and less time consuming process for everyone's sake (it takes a lot of our time to administer this process too). But without the validation that comes with the candidate participating in these exercises for us, hiring becomes more of a guess than an evaluation. At least, I haven't figured out how to do it differently yet and the advice I read hear on HN and elsewhere about dev hiring hasn't convinced me of a better way to do it. We do offer some candidates the option of skipping the on-site interview and instead work with us in a 30-90 day contract to hire situation. This is actually, probably, the best scenario for us but it obviously doesn't work for all candidates to leave a stable employment situation for such an offer.
shivawu 7y ago
What they do doesn't make sense at all! The company chose to spend a lot of time evaluating all these take home projects, in the first step, and then reject people for silly reason afterwards? It's a lose-lose situation. Sounds like their hiring procedure is deeply broken.
- csa 7y ago
  Let me give a charitable and slightly less negative interpretation: It may have looked like the applicant had someone else do the take-home assignment for him. That said, I imagine that they could have interviewed in a more constructive way that may have been less stressful (e.g., walk us through your thought processes as you completed this take home assignment — most frauds can’t do this convincingly). The company definitely could have done better. If you have someone hitting a home run on a take home assignment, at that point a no-hire decision better have some very strong justification behind it.
  - palisade 7y ago
    I went back and looked through my emails with them. When I asked why they rejected not only did the cite the interview questions as a problem they didn't like that I was vague in response to "What is your GPA?" I had responded "Average"
    - csa 7y ago
      Wow! Sounds like there are better places to work. I hope you landed in a good place.
    - newen 7y ago
      They asked for a very specific question with your GPA and you didn't answer it. I don't know what you'd expect.
otabdeveloper4 7y ago
> I got nervous and passed the question, they ended the interview early and rejected my application. When interviewing, we test for presentation, self-control and anxiety as well. For me it's not a big deal, but for the guys that were interviewing you it seems it was. Software development is a very stressful job, if you can't even handle the interview, how would you handle real life (c) at this corporation?
- ldng 7y ago
  It's just the sign it's a terrible place to work at.
- iherbig 7y ago
  Software development does not have to be a stressful experience. I'm sorry that you believe it does as that implies that your experience has largely been stressful. In my mind, that perspective is a huge red flag for me when I'm on the job hunt. If you are trying to stress me out in an interview rather than make me comfortable then I have to thank you for letting me know before I started working there that you would be exhausting both physically and emotionally.

rcfox 7y ago

I once interviewed at a company that had me write a couple styles of matrix multiplication in C as a take home test, as well as give a one-page description of a project I had done. The project I described heavily involved graph searches. Then I had a phone interview where they started off by commenting that I was the only one to include tests and address undefined behaviour. Then I had to write a piece of code to traverse a tree and add numbers, I can't remember what it was exactly, but I got nervous and messed up somehow. Then I waited for 2 weeks just to hear back that they wanted someone more experienced with graph theory.

mjevans 7y ago
Expecting perfection on a white-board test is setting everyone up for failure. At best that's a large napkin exercise. Though having a failure, or a point where for whatever reason production is a bottleneck (if they happen to do it without obvious faults) is an opportunity to identify that either thing is the case in that section and move forward with how they'd react; what should be changed, etc. We're all still human; expect failure to happen. See what happens next.
- rjbwork 7y ago
  100% agree. I interviewed at Microsoft nearly a decade ago now. I was told I'd be interviewing for the company, and then if I was hired, based on preference and ability and need I'd be placed with a team When I got there I was told I'd be interviewing for the SQL Server team, interesting work, but not something I'm interested in. I had never taken operating systems in university because it was always available at a time that another class I HAD to take occurred. So by some random chance, I'd never heard of a semaphore. Perhaps inexcusable at this point in my career, but I was ignorant of the topic at that time. My first interview question was to write a way to let many readers on a resource, and only 1 writer, with no readers reading at the time of the writer writing. I decided to use lists of something or another, ProcessId, or something similar. Every time I would go to write the code, i'd get a few characters in, and the interviewer would interrupt me and ask me questions to help me along. Since I had no idea what a semaphore was, much less that I was supposed to use it, we spent like 30 minutes of this back and forth, me trying to write, him interrupting me. By the end of the session I had a single line initializing a list written. Some of my other interviews during that battery of interviews went better than that one for sure but, needless to say, I didn't get the job.

azhenley 7y ago

I was not expecting your story to take that turn... that sounds like a bad experience! I hope something better came along.

palisade 7y ago
I've worked on pretty cool projects since then at other companies. And, it isn't the only interview I've ever had like that, it is more common than I would like. It is sometimes very hard for me to prove myself. Even though I've had plenty of jobs in the past with proof I can code and with good references. I sometimes feel like I'm an imposter, even while kicking ass on a project.

WalterBright 7y ago

The problem with take-home tests is you may have had help, or someone else did the test for you. If you didn't do well in the in-person test, they may have reasonably assumed that was the case. Especially if the home test was unusually good. I was aware candidates would do things like this when I applied for job long ago. I also was aware that employers were suspicious of these sorts of things. So I brought along listings of code I'd written, pulled them out, and walked the interviewer through how they worked to show I knew my stuff. Note that they didn't ask for this, I just did it proactively. I got an offer, too, and was told some time later by the interviewer that that was why.

rcfox 7y ago
Why bother giving a take-home test if you don't trust the results? Why compare the results to work done in a completely different medium with no opportunity to iterate on the output, take a break or work comfortably? If you assign a take-home test, make the interview focus on discussing the product.
- shultays 7y ago
  Because you can eliminate most applicants that way by cutting no/poor submissions
  - chipperyman573 7y ago
    Yes but you also cut all the people who are good enough they know they can get a job somewhere that doesn't pull something like this.
- lacker 7y ago
  Why bother giving a take-home test if you don't trust the results? You can have one-way trust in a take-home. If they don't meet your quality bar, you can discard the resume. And it takes near zero work on the company's part, that's why so many companies like it. However, some people will just get a lot of help on the take-home. So it isn't fair to the other applicants if you treat a take-home as anything other than a filter.

JMTQp8lwXL 7y ago

You are not alone in such experiences. After going through something like that, I no longer do take-homes.

ourlordcaffeine 7y ago

If I were ever to give a coding interview, I wouldn't be asking the candidate to implement a certain data structure, but rather explain the pros and cons of using say, an array vs a linked list and when you would use one over another. Because at the end of the day, you will not be implementing them but using them.

mattdeboard 7y ago
At a previous education startup I did a lot of interviewing of candidates. The question I feel gave me the most insight into candidates was very, very broad. After explaining (generally) how the company’s product worked, I’d ask them something like, “Let’s have a conversation about how you would design a system to distribute e-textbooks to students.” I would reassure them there is not a right answer, that the exercise was just asking them to engage with the question. It was so effective as an indicator of future performance, and, according to those who eventually were hired, felt fair to them. Of course this implies all my biases to people who can have a 1:1 convo about a very vaguely specified problem and so on. No idea if it’d be positive for everyone, but I wish someone would interview me like that.
xtracto 7y ago
Exactly, after years and years of interviewing and building teams I learned that the best way to interview about data structures is to do Q&A related to them. Even if you are going to work in a project that requires building such structures, I demand that you don't do it from memory, but make sure to get help from resources to ensure that your structures are sound.

fatnoah 7y ago

Or put more succinctly: https://twitter.com/mxcl/status/608682016205344768?lang=en https://twitter.com/mxcl/status/608682016205344768?lang=en "Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so f* off."

alexmlamb 7y ago
Is it just me or does this reasoning not make any sense? "NASA: 90% of our rocket scientists use the A/C you just fixed, but you can't explain how a rocket works so f* off" Presumably what matters is whether homebrew is technically significant or relevant, not just that they use it?
- musicale 7y ago
  I think it's just you. 0. The actual job of a software developer is usually to develop software with some real-world use and benefit, not to write cs101 code on a whiteboard while someone watches you and grades you for speed and accuracy. 1. Software is what Google does, and Google does tons of software from tools to infrastructure to services to games. If you created a key software tool that tons of people use at Google to do their jobs, it's pretty relevant. 2. Software isn't like doing routine maintenance on an existing A/C system - it's usually somewhere between inventing A/C and creating a new design for data center A/C systems then building, deploying, and operating it.
  - NeverFade 7y ago
    Without making any judgement about this particular situation, this logic isn't sound: 1. I develop tool X, which is a simple popular solution. 2. Some company Y is hiring engineers to develop solutions that are far more complex and demanding than what my tool does, for instance because they have to support billions of concurrent users. 3. I deserve the job because most of Y's engineers use the simple tool X that I developed, even though the job requires far more advanced skills than I have demonstrated writing X, and I actually don't have these skills and will totally fail at the job if hired.

bitL 7y ago

If they were willing to give you a top compensation, then OK, writing hash table from the scratch is a pretty common question at Google/FB. If it was for some generic job with generic pay, they did you a great service by rejecting you.

otabdeveloper4 7y ago
"Writing a hash table from scratch" is a programming 101 problem just slightly harder than FizzBuzz, but not by much. Though I guess these days I guess 'software development' means downloading Javascript crap from github and copy-pasting CSS.
- bsder 7y ago
  > "Writing a hash table from scratch" is a programming 101 problem just slightly harder than FizzBuzz, but not by much. No, it's bloody not. What's your hash function? Why? What do you do on hash collisions. How many buckets and how big? Does your hash function map to identity or not? Do you exclude certain fields from hashing? How do you handle contention from multiple threads? I can go on and on. The fact that you think writing a hash is easy betrays a stunning amount of ignorance.
  - detaro 7y ago
    That's the difference between a hashtable you might want to use in practice and a toy example to have someone write some code while quizzing some CS theory.
  - antisemiotic 7y ago
    To be fair, the interview question a few posts up mentioned a working hash table, saying nothing about efficiency or thread safety. (though such a question could be gamed with a linked list as a "well akshuolly" a single-bucket hash table...)

misiti3780 7y ago

what was the company? - companies like this should be called out

palisade 7y ago
I wouldn't do that to them. They have a right to interview how they want. I just wasn't good enough. They were looking for someone who could think on their feet under pressure in the moment and I'm not that guy. I need a quiet place to sit and think something through and plan it out. It is why I did well on the test portion but not on site surrounded by interrogators. In those kind of situations I kind of feel like I'm the in the movie Swordfish where they're like, "Hack that server you have sixty seconds! (gun to head)" The difference is, I would have been dead.
- mixmastamyk 7y ago
  > I need a quiet place to sit and think something through and plan it out That’s the only way hard, unique problems are solved. If it can be done quickly, it’s routine.

mLuby 7y ago

That sucks, I'm sorry. How do you know the quality of others' submissions? >I got nervous and passed the question I didn't know that was allowed. Has that worked for people in the past?

palisade 7y ago
The employer informed me how my results fared. I went back and looked at the emails. I can't edit my original comment so I'll jot the corrections here. They gave 3 days not a week. I completed the submission in 7 hours, they required you track how many hours you spent and when. I used a genetic algorithm to solve the problem. And, I took advantage of multiple cores if they were available to divide the work load. Looking at the email there were signs even in their review of my submission that their outlook wasn't completely rosy. They mentioned things like how I failed to correct for differential conversion factors based on global location and stuff like that. Skipping the question obviously didn't work out for me as I didn't get the position. It was a weird experience to be put on the spot with such great skepticism with all my past accomplishments and knowing how much they respected my test submission. In a way it was humiliating. I didn't leave that interview feeling very good about myself. I still regret it to this day. In some ways I wish I could go back in time and pass on the interview, I think I would be more confident today.
- mLuby 7y ago
  Thanks for the update; it makes more sense now. I bombed an interview where I couldn't understand the prompt, literally. Like the interviewer spoke it to me, and I restated the problem, and he said "no it's…" and drew something on the white board, and I listened and restated it, and we went back and forth like that for about 15 minutes. To this day I don't understand what he was asking for, only that involved a rate of bank customers and a Greek lambda. Getting good jobs means pushing your limits and it's therefore a numbers game. Feeling shame from rejection is natural, but also generally unhelpful these days, so it's worth unlearning.
stevenwoo 7y ago
I remember doing a take home and adding it to github as requested by the company. Then I realized every one else who applied did the same thing and left up their solution and found all the other candidate answers using a simple search. This was prior to github making private repos free.

mawburn 7y ago

My favorite interview experience was when I passed a live coding exercise on Monday and had time to optimize, then completely failed the exact same problem on Friday with a different company because my nerves hit me.

kbrisso 7y ago
I feel for you man, I drove 4 hours from Sacramento to Palo Alto for a great start up job. I nailed the phone interview and thought all was going to go well. The first onsite interview went pretty well. The second part went south and my nerves got me. I really wanted the job but I blew it. I got good feedback and I'm working on interview problems. It was my first interview in 20 years but again I really wanted the job.
- deleted 7y ago
  [deleted]

rsyring 7y ago

There is a lot of discussion in the comments on this thread about take home tests not being useful. I believe we've have a pretty good hiring process that makes significant use of take home tests (16-18 hours of them in fact). At the same time, I assure you that we care deeply about making the best use of our and the applicants time. This is what we do to make that happen: - We make a commitment to reply to every candidate who applies as instructed. Not every reply can be detailed, but candidates are never applying to a black hole. - We have a very detailed job description that answers a lot of the questions many developers have about a company up front. There is always a chance that we are lying or don't live up to what we say, but the info is at least there so the applicants can make an informed decision about whether they are really interested in working for us. The details about our application process are also stated clearly up front so that candidates know what they are getting into. - We ask pretty in-depth follow questions about technical experience to make sure it aligns with what we are looking for. This filters out a decent amount of candidates who would be unlikely to pass the rest of our process saving them and us time. Other than roughly validating that the candidates work experience falls within the range we are looking for, we find resumes to be mostly useless. - The initial "take home" exercise we ask applicants to complete takes 60-90 minutes. It's not a coding exercise and they are given a document that helps them prep for the work they are going to be asked to do. We have found over time that this is more predictive of success in our organization that doing an initial phone screen. Candidates are given relatively detailed feedback on this exercise, usually within 3 business days of submitting their work. - The next step is a Zoom interview. We have a few very basic coding tasks that we ask them to do as part of this interview. These tasks are representative of real world skills a developer would need and not in any way convoluted or academic. The environment could be challenging for some due to the fact that we are watching over their shoulder, but again the tasks are very basic and the goal is simply to see that the tasks are able to be finished in a reasonable time. This isn't to tell us if the candidate can do the job, it just helps us filter out candidates who are likely to fail badly on the next part of our interview process. It saves them time and us time and money. We have occasionally passed candidates on this step who seemed like their bad performance might have been from nervousness and, to date, those candidates have never performed well on the rest of our skills tests. The candidate has an opportunity to ask any questions they would like during this interview. We also talk about money at this stage. Our salary range and benefits are published on the job description so we ask the candidate what their expectations are from a compensation perspective. If they are reluctant to share details, that's fine, but we at least confirm that they understand that our published compensation is what we are actually planning on paying and ask that if that is not suitable to them, that they let us know that now before moving along in the process. Only if everything is aligning at this stage, do we then ask them to commit to a significant more time working through our skills tests process. Our increasing "ask" of the candidate's time is deliberately progressive. We are trying to only ask more of them when we have had the chance to vet them for obvious mismatches and vice versa. - We then move into a two part skills test process (16-18 hours). All candidates who move on to these tests are compensated at around $50 per hour. All tests are timed and represent real world tasks our developers do on a daily basis. The first three have to be scheduled and proctored but the fourth is really "take home" and can be done at the developers leisure. If they pass all of those tests, the work on the fourth test goes through a code review process and is then reviewed with the candidate as part of their second video interview, in a very similar way to how we would do a code review for one of our projects. - Finally, if all that goes well, we do an on-site interview which is mostly a work day (or two) with the project they are working on, again, very representative of the work our developers do on a daily basis. The costs of travel and lodging are compensated at this stage, but we are not paying them hourly. The work they do for us is not customer based work and does not generate revenue for us. I can't say this is a perfect process and it is a lot to ask of an applicant. But, we also put a lot of time and money into this process for those who get to the later stages. So it's a "give, give" if you will. I'm sure some will take issue with this process and some don't apply because they don't like the intensity or commitment involved. But I honestly can't fathom trying to decide on someone's technical ability by spending less time seeing how they handle actual programming tasks. So, we do ask a lot from applicants, but our skills tests work out ok specifically because: - As much as possible, our process is designed to be "evidence based." We rely heavily on skills tests and evaluations that look at how the candidate does work that is very similar to the work we actually need them to do in the job. - We work hard to provide the candidate with all the info they need from us to determine if we'd be a good fit for them before we ask for more than a few hours of their time - All programming tasks are done on their own machine with the editor/tools of their choice (we do choose the language the skills tests are in which align with the technologies which are posted as required in the job descriptions) - All programming tasks are highly representative of actual work a candidate would do if they were hired. The fact that they are timed is probably the one thing that is most "contrived" about the tests. - The skills tests are paid at ~$50 per hour - The grading of the candidates work is pretty straight forward. We have a rubric of sorts for what we are looking for and, to the best of our ability, that rubric aligns with the same things we'd be looking for during a code review of one of our employees that was working on a customer project. There are no trick questions and there are no academic or algorithmic oriented questions (because our day to day tasks don't usually involve those skills) - While it's possible someone could get another developer to take the skills tests for them, the on-site work day(s) would likely reveal their deceit rather quickly. And, if not, we are a small organization and would figure it out pretty quickly if they made it all the way through and actually started working with us. I'd love to have a simpler and less time consuming process for everyone's sake (it takes a lot of our time to administer this process too). But without the validation that comes with the candidate participating in these exercises for us, hiring becomes more of a guess than an evaluation. At least, I haven't figured out how to do it differently yet and the advice I read hear on HN and elsewhere about dev hiring hasn't convinced me of a better way to do it. We do offer some candidates the option of skipping the on-site interview and instead work with us in a 30-90 day contract to hire situation. This is actually, probably, the best scenario for us but it obviously doesn't work for all candidates to leave a stable employment situation for such an offer.

shivawu 7y ago

What they do doesn't make sense at all! The company chose to spend a lot of time evaluating all these take home projects, in the first step, and then reject people for silly reason afterwards? It's a lose-lose situation. Sounds like their hiring procedure is deeply broken.

csa 7y ago
Let me give a charitable and slightly less negative interpretation: It may have looked like the applicant had someone else do the take-home assignment for him. That said, I imagine that they could have interviewed in a more constructive way that may have been less stressful (e.g., walk us through your thought processes as you completed this take home assignment — most frauds can’t do this convincingly). The company definitely could have done better. If you have someone hitting a home run on a take home assignment, at that point a no-hire decision better have some very strong justification behind it.
- palisade 7y ago
  I went back and looked through my emails with them. When I asked why they rejected not only did the cite the interview questions as a problem they didn't like that I was vague in response to "What is your GPA?" I had responded "Average"
  - csa 7y ago
    Wow! Sounds like there are better places to work. I hope you landed in a good place.
  - newen 7y ago
    They asked for a very specific question with your GPA and you didn't answer it. I don't know what you'd expect.

otabdeveloper4 7y ago

> I got nervous and passed the question, they ended the interview early and rejected my application. When interviewing, we test for presentation, self-control and anxiety as well. For me it's not a big deal, but for the guys that were interviewing you it seems it was. Software development is a very stressful job, if you can't even handle the interview, how would you handle real life (c) at this corporation?

ldng 7y ago
It's just the sign it's a terrible place to work at.
iherbig 7y ago
Software development does not have to be a stressful experience. I'm sorry that you believe it does as that implies that your experience has largely been stressful. In my mind, that perspective is a huge red flag for me when I'm on the job hunt. If you are trying to stress me out in an interview rather than make me comfortable then I have to thank you for letting me know before I started working there that you would be exhausting both physically and emotionally.