10 ms·

I just turned down an offer after a technical interview. Just after my tech call, I call the hiring manager and said I didn't want to move forward. Technical i

• ProAm 10y ago
  > but this 'My way or the highway' from pseudo engineers Aren't you saying the same thing to them when you decline to move forward? Looks like your both have the same message just relative to your position in the discussion.
  • blablablame 10y ago
    Not really. Im open to discuss any solution to a problem, from the most performant one to the most simple one (code wise) that does the job. When someone says: Maybe you could use a binary tree. and the reply is: No, that is wrong, what you need is X, is a different thing. Beste inverviews I had were always a give an take. I talked algorithms, data structures, etc but never with the interviewer having a one solution answer. Best interview questions are like: Ok, we have this domain problem, what can you do about it? and then spend a couple hours on a whiteboard on a back and forth discussion about it, maybe you get it right, maybe you dont but have another idea, etc.
• swillis16 10y ago
  You may have dodged a bullet because if someone has a "only one answer approach to interviewing" then the inability to see other possible solutions may carry over into their daily work as well.
• strictnein 10y ago
  Had a weird experience where the guy interviewing me would shake his head "no" when he didn't like the answer I was giving. Not that it was wrong, it just didn't conform to what he was expecting. It was really weird to describe a proper technical solution to someone who was doing that.
  • ktRolster 10y ago
    A lot of interviewers want to hire someone who mostly gets the question right, but needs help in a few details. When you know more than the interviewer, it's actually tough to handle that situation. I'm honestly not sure how to handle it.
    • cjcenizal 10y ago
      "Wow this is great. I think you may know more about this situation than I do! Could you tell me more about X?"
  • viewtransform 10y ago
    If the guy was from India(especially southern states and West Bengal) be aware that shaking the head side to side means that he was agreeing with you or indicating that he was following you.
• corysama 10y ago
  I've been giving a lot of interviews lately. It has been really difficult to come up with questions that don't end up turning into "guess my magic answer". As a result, I spend the majority of the time talking through work they did in the past with the primary goal being to determine "what did the applicant actually do on this project?" As opposed to simply hanging around the team or flipping switches to enable pre-packaged features.
  • ng12 10y ago
    Here's the problem I have -- how do you avoid hiring professional bullshitters? Wouldn't the guy who put together the PowerPoint for upper management sell himself better than the guy that actually wrote the machine learning system? I've just known too many people who are better talkers than coders. at least with CtCI-type questions you can't really lie or stumble your way through it. I'd rather take a few bad rejects than a few bad hires.
    • ktRolster 10y ago
      I've heard that at one company, the interviewer sits down with you and you program together for an hour. That is the extent of the interview.
    • serge2k 10y ago
      > I'd rather take a few bad rejects than a few bad hires. This is the root cause of interviewing being shitty.
      • ng12 10y ago
        And it's the totally right thing to do. Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming. Programming interviews aren't perfect, but the reality is there aren't better alternatives.
        • vonmoltke 10y ago
• beamatronic 10y ago
  Earlier in my career I would give white board coding questions. I would get excited when someone did come up with the same solution as me, but often get even more excited when they came up with a better solution, or made me think about changing how I posed the question. That's a good way to know if you want to work with someone - if you or they or both, get excited.
  • mlvljr 10y ago
    Let's plus one this fella, lads! (if you are even able to see my post, hehe)
• ktRolster 10y ago
  The worst is when the interviewer gets a question of stack-overflow, then modifies it slightly. The slight modifications mean that a completely different data structure should be used, but the interviewer doesn't realize that.
• zippergz 10y ago
  Dismissing a company because one engineer there is bad at interviewing seems potentially short-sighted. First, you're getting a single data point. And second, how the person operates in interviews quite likely has nothing to do with how he or she is to work with on projects. Obviously it's your prerogative to decide where to work. But walking away because you didn't like a single interview is a little bit petty.
  • dblohm7 10y ago
    Dismissing a company because one engineer there is bad at interviewing seems potentially short-sighted. One could swap "a company" and "one engineer there" and still have a perfectly valid argument.
  • blablablame 10y ago
    If the only look into a company is that tech interview, and he or she will be someone you will have to work with on a day to day basis, and s/he is someone that just flat out refuses to accept that maybe his answer isn't the right one, would you want to work with someone like this 8 hours a day? To be fair, I might have been that guy 10 years ago, and I was probably quite an annoying know it all co-worker then, but now, after close to 20 years in the industry, having worked in software that is used by millions, being a referenced author, honestly, no, I refuse outright to deal with bullshit like this. I don't expect everyone to think what I say is right (because it isn't) but to just dismiss it since it isn't THEIR answer, is a RED flag for me and I would prefer not to work there, no matter the offer.
  • Scarblac 10y ago
    On the other hand, that's what the interview process is for, right? What other information do you have except what you see in the interview?
  • dragonwriter 10y ago
    > Dismissing a company because one engineer there is bad at interviewing seems potentially short-sighted. I keep hearing about a shortage of quality talent in the industry. Given that, I would expect employers to pay particular attention to putting their best foot forward in interviews -- since interviews work in both directions. One that fails to do so -- or whose best foot is off-putting -- is revealing that their attitude toward potential hires and/or their ability to offer a good working environment is poor. People talk about how a bad hire is a significant cost for employers, but taking a bad job can be a much bigger cost for the employee than a single bad hire is for an employer, and quite worth avoiding.
• dmansen 10y ago
  Are you sure this is what happened? I ask because we interview lots of candidates who always jump straight to their favorite data structure. Given any algorithmic question, they'll immediately create an instance of their pet data structure (usually it's a HashMap), without specifying the types of keys or values. They can't explain why they're choosing this, and continually try to shoehorn the problem into it even when it makes no sense. This interview doesn't sound nearly that bad to me. It sounds like you were discussing the advantages / tradeoffs for your choices, given various performance considerations. How do you know they considered you "wrong"? Maybe they were seeing how you reacted to being pushed.
  • azraomega 10y ago
    I'm curious. What would be a good reaction? Not reacting and accepting that's only truth from now on? Reacting respectfully saying why you think there are more than one answer, then continue getting pushed? When I test people's reaction, it's generally not because I want to hire them. I just want to learn about people. If the purpose is hiring, overreacting but good coder will not take the job, under-reacting but good coder will not stay long because he/she will get angry eventually, over-reacting and taking the job seems desperate... I just don't see what can possibly get out this kind of test from a hiring perspective.
    • dmansen 10y ago
      [edit: Both the reactions you listed seem fine, depending on what you're looking for. But I wouldn't do this myself, anyway.] I don't know the correct reaction, and don't do this when I'm interviewing. My point was that I could easily see a different side of this story, from the interviewer's perspective. Maybe the interviewer understood the OP's solution, and wanted them to explore a different angle. We're lacking so much context here - what did the interviewer actually say? Was their tone gentle or aggressive? Were they flat-out ignoring the OP's answer, or acknowledging it while taking it through different use cases? We can't know, we weren't there. I understand there are many places with poor interview practices, but I've seen enough devs come out of these types of interviews with wildly incorrect self-assessments that I no longer blindly trust these anecdotes. Unless they told you the exact reason you failed, you're speculating. And if you're an engineer that repeatedly gets turned down after these interviews at many different shops, you may not know what you don't know. Complaining about the interview process isn't a productive way to improve in those situations. [note that my critique goes both ways: I have no way of knowing OP's skill, and their story could be completely accurate. however, I see this attitude a lot from overconfident junior devs, and that's to whom this rant applies.]
• collyw 10y ago
  For me its the fact they expect you to take the time out to do this crap before even getting to speak to anyone technical about the job.
• FLUX-YOU 10y ago
  >Y is valid, and when Y is a problem Here is my issue with this reasoning: Y could turn into a problem in production and cause real impact of the business before you know it's a problem. You're writing hundreds of Y's over the course of months as the project goes on so some amount of first-guessing is good to have. You don't want to play wait-and-see with all of them. If it is a product where demand can spike very rapidly then it is more important to take the time to find a best solution first. One day, you thought Y would never reach this magnitude but it just did because something went viral and the internet is essentially DDOSing you (happens all the time with sites posted here going down). And some companies may take to this approach on the first step and don't want to wait until things fail to realize they used the wrong data structure for this demand. Because often, it only takes a single thing to break a product or produce the wrong output or fail gracefully. Now naturally if your interviewer wraps this problem up in vagueness, confusion, and gotchas then you aren't going to do well. A sane interview should be more than willing to answer questions about magnitude and that tells you that Y is now a problem and you need to think of a better solution than your first one even though it is fine for most use cases. If it seems like they were trying to confuse you or just throw their ego around, just write this business off. They are only interested in playing slots. They pull the lever until eventually someone walks in and just happens to know the answer and also wants to work there.
  • rawnlq 10y ago
    I think might have been Google who said this, but you should design for 100x of your expected load and when you get within 10x you redesign and rewrite it. It will make sure you don't try to design for a billion users when you have a thousand but still gives you decent room to handle spikes and more time to write a more lasting architecture.
  • deleted 10y ago
    [deleted]
• deleted 10y ago
  [deleted]
• ChrisAntaki 10y ago
  Let's say your approach was ideal. Is it possible the interviewer wanted to see how you'd solve the problem, if your first solution was off the table?
• sngz 10y ago
  I had an interview with amazon before that went exactly like that. The question was asking for a search algorithm the answer I gave was O(n log n) if you ran it the first time and O(1) every time after that. But the answer he wanted was O(n) every single time, wouldn't accept my explanation / answer.