6 ms·

I recently interviewed at Apple and one interviewer caused me to decide to never work there. I was put into a conference room and had 8 people over 6 hours come

I recently interviewed at Apple and one interviewer caused me to decide to never work there. I was put into a conference room and had 8 people over 6 hours come in and interview me one after another. Each person asked me about my background and then jumped into a whiteboard coding problem. Most of the interviewers were understanding of the fact that writing code on a whiteboard is nothing like writing code on a computer, and were helpful in pointing out simple mistakes that a compiler would have caught. While writing code for the last interviewer I had to do some simple division. I came up with the wrong answer and told the interviewer that I wasn't sure if that was correct, and to let me know if it was incorrect. He blankly stared at me and said he wouldn't help me. Usually I would be able to do the division in my head, but after 6 hours of constant interviewing my brain was starting to turn into mush. I went on and finished the solution and he said that there was an issue but wouldn't tell me where. I asked if it was an issue with the division and he said yes. He still wouldn't tell me the answer, so I floundered for a bit while trying to remember how to do long division. At one point I turned to him and said "I'm sorry this is taking me so long, it's been a very long day" and he replied "sometimes you will have to fix your code on the spot". It seemed like he was trying to see if I would crack under the pressure. Eventually I came up with the correct answer and was able to finish the problem, but it completely drained me. I decided then that I never wanted to work with that person, or with other people like them. Some jobs require performance under pressure, but programming is not one of them. The only thing that the interviewer was evaluating was my ability to do math problems in my head after being interviewed for 6 hours. Don't they have calculators at Apple? Or phones, perhaps?

corey_moncure 8y ago
So you met 8 people, and one of them was a jerk? I'd say that's a pretty acceptable jerk coefficient for a workplace. I've been in places north of 0.5.
- whichdan 8y ago
  If 12.5% of people in an office were jerks, I'd consider that a very toxic culture.
- 8_hours_ago 8y ago
  Your jerk tolerance is higher than mine. I really really don't like to work with people like that. There were other reasons why I decided that Apple was not for me, but the jerk interviewer definitely tilted the scale from "yes, I could see myself working there" to "no, I will never work there".
- geofft 8y ago
  The right number is zero and a UBI until they figure out how to stop being jerks. (My primary personal reason for supporting a UBI is I want to be able to say "No rational employer should employ you" without that implying "so you should be homeless and starve.") But short of that, the right number is zero on the interview circuit. You can employ jerks if you have to, but don't put them in more positions where they have to interact with others than necessary. Give them the legacy products where you can't staff a team of more than one qualified person anyway. Give them an office. And keep the door closed. Remember that a jerk is basically a 0.1x developer - an employee who causes other employees to lose productivity by spending time working around the jerkiness, taking a morale hit, etc. Even a remarkably productive jerk at best only compensates for their negative effect on people they work with, and most jerks are not consistently remarkably productive. https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde https://medium.freecodecamp.org/we-fired-our-top-talent-best... is a good example of a company learning that lesson a little too late. A company that signals that they trust their jerks enough to make hiring decisions and to represent the company's culture to potential new hires is a company that signals they're actively cool with jerks (or incapable of noticing, which has the same effect). If a jerk makes a good employee unhappy and they leave, the jerk is a net negative. And if you keep employing the jerks, you'll find yourself with a 0.5 jerk coefficient on your hands very quickly.
  - Bahamut 8y ago
    Just hiding how many jerks a company has until after the interview process is complete is not effectively any better - it could even be worse for people, as they could have had signal to avoid the jerk. The absence of evidence of some behavior or signal is not equivalent to it not being present at all. In my experience, most companies have jerks - I’m not convinced it’s even avoidable reliably, as people come from many walks of life, and sometimes the walks form people to be jerks. I work at Apple, where I’d say that jerks are a very low number of people I’ve interacted with (maybe a couple hundred employees so far) - I’ve seldom seen a company beforehand with less jerks percentage-wise, much less have processes that help with descalating arguments & deal with them quickly.
- Raphmedia 8y ago
  In my opinion the entire process was a jerk. An entire day of whiteboard problems? What a waste of time for everyone involved.
- mgkimsal 8y ago
  That they allowed that person to be a representative of the company when someone is interviewing the company to decide if they'd want to work there... that's a bad PR move. Yes, the company extends an offer on their end, but really, both parties are making decisions. If they can't put their best foot forward.... that's a problem. If they think this was their best foot forward, that's another problem.
  - ummonk 8y ago
    Apple interviews are team-specific, so I'm not sure that the existence of a single jerk on a single team's interview loop should reflect on a company with hundreds if not thousands of teams and tens of thousands of engineers.
- jogjayr 8y ago
  They were a jerk in a situation where both parties are supposed to be on their best behavior. Can you imagine how it must be dealing with them on a day-to-day basis?
commandlinefan 8y ago
> Some jobs require performance under pressure, but programming is not one of them. In fact, programming under pressure is the leading cause of programming disasters. It's the exact opposite of what a rational employer should want.
- guelo 8y ago
  Not to defend that interviewer, but sometimes it's inevitable that you do have to code under pressure. I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second, and I have to push a patch to production as quickly possible. Not that I would interview for such a situation.
  - jogjayr 8y ago
    You should probably roll back the commit that broke production though, instead of hastily pushing something out hoping you'll fix it. And ideally you should've been doing a gradual rollout, deploying on a few machines first then slowly ramping it up.
  - andrewprock 8y ago
    "I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second" That's the situation you get into when you code under pressure.
  - taurath 8y ago
    And if you are in that position, it is because you have the most (or enough) context to be able to solve the problem. In an interview situation, it is like being asked to fix a problem with skyscraper having never seen the interior before. Interviewing is low-context. You cannot test whether someone will fail under high-context pressure in an interview.
- twelvechairs 8y ago
  No jobs are performed best under pressure. Or at least past the body's ability for a brief surge (adreneline etc.). But it happens in every occupation because overall more will be produced by pushing people than letting them pace themselves...
ww520 8y ago
Division. Damn. That's what calculator is for. I would just whip out my phone to do it. Human has evolved to leverage tools to augment intelligence. If he can't understand the advantage of tool utilization, he's not a good engineer.
- jpttsn 8y ago
  Humans attach prestige to solving problems the old school way. We have ladders but watch pole vaulting at the Olympics.
bordercases 8y ago
> The only thing that the interviewer was evaluating was my ability to do math problems in my head after being interviewed for 6 hours. Although I agree with you about the (ir)relevance of the task, I disagree with this particular move you're making when other people do it. Typically when people want to trivialize test results they don't like, they say it's over-fitting to the immediate situation (like IQ tests "don't measure anything intrinsic, they just measure how well you do IQ tests"). Unfortunately this criticism can be logically generalized across any statistical or empirical measure whose job is not to let people into the job/tell the truth, but minimize the impact of something bad happening if the test returns a false positive, or the opportunity cost if it's a false negative. This means two things: (1) Because the chance of error always exists, there are always going to be people who feel gypped by the process; yet on the other hand, it is supremely difficult to come up with good measures of anything that is too costly to observe directly no matter what the domain. Thus sour grapes that want to claim over-fitting. (2) For software companies like Apple, they can probably afford to have bullshit tests to weed out applicants, because the alternative of having to place each applicant through a probationary period for three months is quite costly, if we're willing to refute all tests as being narrow or irrelevant indicators in the manner above. With Apple, it's still possible that they have an internal model for hiring that claims to have predictive power that relies on this particular task as a proxy in conjunction with all the other ways that they've tested you, before they move you over to a probationary period. But as the article pointed out this is also unlikely since the effectiveness of interview practices is understudied in a formal setting.
kitsune_ 8y ago
Long division under pressure? This sounds as dumb as Password Swordfish.
01100011 8y ago
I'm nitpicking, but yes sometimes you do have to code under pressure. Yes it can result in bad code but it can also save millions of dollars as production lines are allowed to run, ecommerce is allowed to happen, or important contractual obligations are met. That said, you generally do not write that code on a whiteboard with no access to the internet. It sounds like you just interviewed with a dick. That happens.
- pmiller2 8y ago
  I don't believe your nitpick is valid here. True, sometimes one has to code under pressure, in the sense that money is lost (or, at least not made) while things are down, but there's almost never a situation where you can't stop and take an extra 20 or 30 minutes to check to see that your code would do what you expect it to do. In fact, if the worst consequence of waiting 30 minutes to deploy a temporary fix is that some more money gets lost, I would argue you should almost always do that rather than deploying code that might have even worse consequences.
  - mgkimsal 8y ago
    > but there's almost never a situation where you can't stop and take an extra 20 or 30 minutes to check to see that your code would do what you expect it to do The implication in these examples is that you're doing it on your own, always, and... that's generally bad, especially with a known bug. Most of the bugs I have created have been ones where I've specifically not talked through the logic with someone else (usually a client/stakeholder, or domain expert, or whatever) to determine that my understanding is correct (might need more tests or to adjust existing tests to reflect a better understanding of the issue, etc). These 'emergency bug fixes that must be dealt with on the spot in minutes!' scenarios are more likely that cause of the issues in the first place.
  - 01100011 8y ago
    I suppose we've been exposed to different parts of the software elephant. When I say money is lost... it can potentially be a lot of money. Can you imagine what 10 minutes of downtime could cost Amazon, for instance? What about streaming the superbowl? Credit card payment processors? Even something simple like the test harness for a production line may mean that an entire shift of assembly workers now has to stand idle or sweep the floor. When your company is losing thousands of dollars per minute you will understand what I'm talking about.
jlarocco 8y ago
I had a similar experience with a Google phone interview once. The interviewer asked me about a technology I knew almost nothing about, and I told him right off the bat that I didn't know much about it but I would explain what little I did know. But then he spent the next 20 minutes asking me more questions about it, how I'd use it, how it could be implemented, etc.. It was so frustrating I should have just ended the call early.
vivekseth 8y ago
So you will never work at Apple because you had 1 bad interviewer out of a sample size of 8? That seems foolish.
- 8_hours_ago 8y ago
  As a programmer I have the ability to be selective with the jobs that I take. The first 7 interviewers did not convince me that Apple was a good place to work. The last interviewer convinced me that I didn't want to work with them or people like them. Of course, things change. It would be difficult for Apple to change my mind about working there, but it is not impossible. Ask me again in 10 years :)
- mv4 8y ago
  Stay hungry, stay foolish. Someone said that.
- deleted 8y ago
  [deleted]
- vivekseth 8y ago
  My point was that Apple is a large company with many teams. I didn’t understand why OP would write off an an entire company because they didn’t like 1 team.
adrianmonk 8y ago
I will defend about 20% of the interviewer's behavior here. I've had candidates try to negotiate away requirements or get me to give them part of the answer. They'll say something equivalent to, "Hey, could this method I'm supposed to implement have an extra parameter that makes everything easy?" Sure, any problem can be made easy by taking away the hard part, but we're not doing that. Or they'll say, "So what data structure would you use?" That's for you to solve. From time to time, I ran into candidates with a crazy attitude like this, so I learned to stand my ground. It was an unfortunate and surprising necessity. The interviewer might have been doing this but going overboard with it. (Or maybe they were just a jerk.) Now the 80% of the behavior I won't defend: 1. An interviewer should have the soft skills to stand their ground without being harsh and implying that you suck. 2. An interviewer should know the difference between minutiae and important stuff. Partly for time management reasons during limited interview time. 3. Even if an interviewer is rough around the edges sometimes, they should understand that in this context, they are the face of the company. And it is stressful and tiring. So they should reign it in and be understanding and nice. 4. The company should be in control of their own interviewing process, at least enough that failures like this aren't common. Maybe an interviewer needs some guidance to improve, or maybe some people aren't cut out to do interviews, but they shouldn't be just left to their own devices.
nitwit005 8y ago
I just become unable to do math during interviews. You know how people hate public speaking, because they feel super nervous, sweat a lot, and have trouble saying what they want? That but with calculous you haven't touched in 12 years. If they gave me a piece of paper and let me do it without interruption, I could do it, but generally interviewers will sit there and demand you explain what you're doing.
PinkMilkshake 8y ago
> Don't they have calculators at Apple? Or phones, perhaps? He must have been from the iPad dev team.
jarsin 8y ago
Next time just tell him you are a Millennial and you never heard of long division before.
jiveturkey 8y ago
> I decided then that I never wanted to work with that person, or with other people like them. sounds like the interview was a complete success. As a candidate, keep in mind the most important thing you are going to get out of an interview is to assess the job and the company. They need to make a quick decision (employ you for years based on a few hours interview), and so do you.
anonytrary 8y ago
> and he replied "sometimes you will have to fix your code on the spot" You should have told him that "every time, you get to use a calculator". If I managed interviews, I'd have 1 person interview 1 person in a full-technical interview, without the personal questions, with 3 additional interviewers watching behind a one-way mirror. When the interview was over, I'd go in myself, and ask the candidate how well they thought they did, and how well they thought the interviewer did, with the 3 other interviewers still watching.
kanelbullar 8y ago
I came up with the wrong answer and told the interviewer that I wasn't sure if that was correct, and to let me know if it was incorrect. He blankly stared at me and said he wouldn't help me. Meaning: presumably he's trying to be helpful, and give you a perfectly accurate representation of how people at his company interact when trying to solve problems together.

corey_moncure 8y ago

So you met 8 people, and one of them was a jerk? I'd say that's a pretty acceptable jerk coefficient for a workplace. I've been in places north of 0.5.

whichdan 8y ago
If 12.5% of people in an office were jerks, I'd consider that a very toxic culture.
8_hours_ago 8y ago
Your jerk tolerance is higher than mine. I really really don't like to work with people like that. There were other reasons why I decided that Apple was not for me, but the jerk interviewer definitely tilted the scale from "yes, I could see myself working there" to "no, I will never work there".
geofft 8y ago
The right number is zero and a UBI until they figure out how to stop being jerks. (My primary personal reason for supporting a UBI is I want to be able to say "No rational employer should employ you" without that implying "so you should be homeless and starve.") But short of that, the right number is zero on the interview circuit. You can employ jerks if you have to, but don't put them in more positions where they have to interact with others than necessary. Give them the legacy products where you can't staff a team of more than one qualified person anyway. Give them an office. And keep the door closed. Remember that a jerk is basically a 0.1x developer - an employee who causes other employees to lose productivity by spending time working around the jerkiness, taking a morale hit, etc. Even a remarkably productive jerk at best only compensates for their negative effect on people they work with, and most jerks are not consistently remarkably productive. https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde https://medium.freecodecamp.org/we-fired-our-top-talent-best... is a good example of a company learning that lesson a little too late. A company that signals that they trust their jerks enough to make hiring decisions and to represent the company's culture to potential new hires is a company that signals they're actively cool with jerks (or incapable of noticing, which has the same effect). If a jerk makes a good employee unhappy and they leave, the jerk is a net negative. And if you keep employing the jerks, you'll find yourself with a 0.5 jerk coefficient on your hands very quickly.
- Bahamut 8y ago
  Just hiding how many jerks a company has until after the interview process is complete is not effectively any better - it could even be worse for people, as they could have had signal to avoid the jerk. The absence of evidence of some behavior or signal is not equivalent to it not being present at all. In my experience, most companies have jerks - I’m not convinced it’s even avoidable reliably, as people come from many walks of life, and sometimes the walks form people to be jerks. I work at Apple, where I’d say that jerks are a very low number of people I’ve interacted with (maybe a couple hundred employees so far) - I’ve seldom seen a company beforehand with less jerks percentage-wise, much less have processes that help with descalating arguments & deal with them quickly.
Raphmedia 8y ago
In my opinion the entire process was a jerk. An entire day of whiteboard problems? What a waste of time for everyone involved.
mgkimsal 8y ago
That they allowed that person to be a representative of the company when someone is interviewing the company to decide if they'd want to work there... that's a bad PR move. Yes, the company extends an offer on their end, but really, both parties are making decisions. If they can't put their best foot forward.... that's a problem. If they think this was their best foot forward, that's another problem.
- ummonk 8y ago
  Apple interviews are team-specific, so I'm not sure that the existence of a single jerk on a single team's interview loop should reflect on a company with hundreds if not thousands of teams and tens of thousands of engineers.
jogjayr 8y ago
They were a jerk in a situation where both parties are supposed to be on their best behavior. Can you imagine how it must be dealing with them on a day-to-day basis?

commandlinefan 8y ago

> Some jobs require performance under pressure, but programming is not one of them. In fact, programming under pressure is the leading cause of programming disasters. It's the exact opposite of what a rational employer should want.

guelo 8y ago
Not to defend that interviewer, but sometimes it's inevitable that you do have to code under pressure. I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second, and I have to push a patch to production as quickly possible. Not that I would interview for such a situation.
- jogjayr 8y ago
  You should probably roll back the commit that broke production though, instead of hastily pushing something out hoping you'll fix it. And ideally you should've been doing a gradual rollout, deploying on a few machines first then slowly ramping it up.
- andrewprock 8y ago
  "I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second" That's the situation you get into when you code under pressure.
- taurath 8y ago
  And if you are in that position, it is because you have the most (or enough) context to be able to solve the problem. In an interview situation, it is like being asked to fix a problem with skyscraper having never seen the interior before. Interviewing is low-context. You cannot test whether someone will fail under high-context pressure in an interview.
twelvechairs 8y ago
No jobs are performed best under pressure. Or at least past the body's ability for a brief surge (adreneline etc.). But it happens in every occupation because overall more will be produced by pushing people than letting them pace themselves...

ww520 8y ago

Division. Damn. That's what calculator is for. I would just whip out my phone to do it. Human has evolved to leverage tools to augment intelligence. If he can't understand the advantage of tool utilization, he's not a good engineer.

jpttsn 8y ago
Humans attach prestige to solving problems the old school way. We have ladders but watch pole vaulting at the Olympics.

bordercases 8y ago

> The only thing that the interviewer was evaluating was my ability to do math problems in my head after being interviewed for 6 hours. Although I agree with you about the (ir)relevance of the task, I disagree with this particular move you're making when other people do it. Typically when people want to trivialize test results they don't like, they say it's over-fitting to the immediate situation (like IQ tests "don't measure anything intrinsic, they just measure how well you do IQ tests"). Unfortunately this criticism can be logically generalized across any statistical or empirical measure whose job is not to let people into the job/tell the truth, but minimize the impact of something bad happening if the test returns a false positive, or the opportunity cost if it's a false negative. This means two things: (1) Because the chance of error always exists, there are always going to be people who feel gypped by the process; yet on the other hand, it is supremely difficult to come up with good measures of anything that is too costly to observe directly no matter what the domain. Thus sour grapes that want to claim over-fitting. (2) For software companies like Apple, they can probably afford to have bullshit tests to weed out applicants, because the alternative of having to place each applicant through a probationary period for three months is quite costly, if we're willing to refute all tests as being narrow or irrelevant indicators in the manner above. With Apple, it's still possible that they have an internal model for hiring that claims to have predictive power that relies on this particular task as a proxy in conjunction with all the other ways that they've tested you, before they move you over to a probationary period. But as the article pointed out this is also unlikely since the effectiveness of interview practices is understudied in a formal setting.

kitsune_ 8y ago

Long division under pressure? This sounds as dumb as Password Swordfish.

01100011 8y ago

I'm nitpicking, but yes sometimes you do have to code under pressure. Yes it can result in bad code but it can also save millions of dollars as production lines are allowed to run, ecommerce is allowed to happen, or important contractual obligations are met. That said, you generally do not write that code on a whiteboard with no access to the internet. It sounds like you just interviewed with a dick. That happens.

pmiller2 8y ago
I don't believe your nitpick is valid here. True, sometimes one has to code under pressure, in the sense that money is lost (or, at least not made) while things are down, but there's almost never a situation where you can't stop and take an extra 20 or 30 minutes to check to see that your code would do what you expect it to do. In fact, if the worst consequence of waiting 30 minutes to deploy a temporary fix is that some more money gets lost, I would argue you should almost always do that rather than deploying code that might have even worse consequences.
- mgkimsal 8y ago
  > but there's almost never a situation where you can't stop and take an extra 20 or 30 minutes to check to see that your code would do what you expect it to do The implication in these examples is that you're doing it on your own, always, and... that's generally bad, especially with a known bug. Most of the bugs I have created have been ones where I've specifically not talked through the logic with someone else (usually a client/stakeholder, or domain expert, or whatever) to determine that my understanding is correct (might need more tests or to adjust existing tests to reflect a better understanding of the issue, etc). These 'emergency bug fixes that must be dealt with on the spot in minutes!' scenarios are more likely that cause of the issues in the first place.
- 01100011 8y ago
  I suppose we've been exposed to different parts of the software elephant. When I say money is lost... it can potentially be a lot of money. Can you imagine what 10 minutes of downtime could cost Amazon, for instance? What about streaming the superbowl? Credit card payment processors? Even something simple like the test harness for a production line may mean that an entire shift of assembly workers now has to stand idle or sweep the floor. When your company is losing thousands of dollars per minute you will understand what I'm talking about.

jlarocco 8y ago

I had a similar experience with a Google phone interview once. The interviewer asked me about a technology I knew almost nothing about, and I told him right off the bat that I didn't know much about it but I would explain what little I did know. But then he spent the next 20 minutes asking me more questions about it, how I'd use it, how it could be implemented, etc.. It was so frustrating I should have just ended the call early.

vivekseth 8y ago

So you will never work at Apple because you had 1 bad interviewer out of a sample size of 8? That seems foolish.

8_hours_ago 8y ago
As a programmer I have the ability to be selective with the jobs that I take. The first 7 interviewers did not convince me that Apple was a good place to work. The last interviewer convinced me that I didn't want to work with them or people like them. Of course, things change. It would be difficult for Apple to change my mind about working there, but it is not impossible. Ask me again in 10 years :)
mv4 8y ago
Stay hungry, stay foolish. Someone said that.
deleted 8y ago
[deleted]
vivekseth 8y ago
My point was that Apple is a large company with many teams. I didn’t understand why OP would write off an an entire company because they didn’t like 1 team.

adrianmonk 8y ago

I will defend about 20% of the interviewer's behavior here. I've had candidates try to negotiate away requirements or get me to give them part of the answer. They'll say something equivalent to, "Hey, could this method I'm supposed to implement have an extra parameter that makes everything easy?" Sure, any problem can be made easy by taking away the hard part, but we're not doing that. Or they'll say, "So what data structure would you use?" That's for you to solve. From time to time, I ran into candidates with a crazy attitude like this, so I learned to stand my ground. It was an unfortunate and surprising necessity. The interviewer might have been doing this but going overboard with it. (Or maybe they were just a jerk.) Now the 80% of the behavior I won't defend: 1. An interviewer should have the soft skills to stand their ground without being harsh and implying that you suck. 2. An interviewer should know the difference between minutiae and important stuff. Partly for time management reasons during limited interview time. 3. Even if an interviewer is rough around the edges sometimes, they should understand that in this context, they are the face of the company. And it is stressful and tiring. So they should reign it in and be understanding and nice. 4. The company should be in control of their own interviewing process, at least enough that failures like this aren't common. Maybe an interviewer needs some guidance to improve, or maybe some people aren't cut out to do interviews, but they shouldn't be just left to their own devices.

nitwit005 8y ago

I just become unable to do math during interviews. You know how people hate public speaking, because they feel super nervous, sweat a lot, and have trouble saying what they want? That but with calculous you haven't touched in 12 years. If they gave me a piece of paper and let me do it without interruption, I could do it, but generally interviewers will sit there and demand you explain what you're doing.

PinkMilkshake 8y ago

> Don't they have calculators at Apple? Or phones, perhaps? He must have been from the iPad dev team.

jarsin 8y ago

Next time just tell him you are a Millennial and you never heard of long division before.

jiveturkey 8y ago

> I decided then that I never wanted to work with that person, or with other people like them. sounds like the interview was a complete success. As a candidate, keep in mind the most important thing you are going to get out of an interview is to assess the job and the company. They need to make a quick decision (employ you for years based on a few hours interview), and so do you.

anonytrary 8y ago

> and he replied "sometimes you will have to fix your code on the spot" You should have told him that "every time, you get to use a calculator". If I managed interviews, I'd have 1 person interview 1 person in a full-technical interview, without the personal questions, with 3 additional interviewers watching behind a one-way mirror. When the interview was over, I'd go in myself, and ask the candidate how well they thought they did, and how well they thought the interviewer did, with the 3 other interviewers still watching.

kanelbullar 8y ago

I came up with the wrong answer and told the interviewer that I wasn't sure if that was correct, and to let me know if it was incorrect. He blankly stared at me and said he wouldn't help me. Meaning: presumably he's trying to be helpful, and give you a perfectly accurate representation of how people at his company interact when trying to solve problems together.