3 ms·

In my experience, being "right" is no bar to getting the job. In one case where I was going for a C++ expert job, I got asked a question (that I can't remember

In my experience, being "right" is no bar to getting the job. In one case where I was going for a C++ expert job, I got asked a question (that I can't remember now), gave the correct answer, which the interviewer disputed. I asked if they had a copy of TC++PL on hand, which they did, and I pointed out the relevant section. I got the job. In another case, I was asked something complicated about "const" in C++ (which has a few gotchas), gave the right answer, but was still disputed. I got the job, and on my first day the guy that asked the question came up and apologised to me - he'd read up on it after. IMHO, telling the truth about technical matters is always best; I might fib a bit about other things.

bitwize 5y ago
Your experience is not universal. I've been passed over for a job because I did not recite the right buzzwords (framework names, etc.). Your job in an interview is to please the person across the table from you. Some interviewers are looking for a sharp technical mind unafraid to challenge them. Others view any challenge to what they think is right as a threat.
- zabzonk 5y ago
  > Some interviewers are looking for a sharp technical mind unafraid to challenge them. And people like that are those you want to work with. > Others view any challenge to what they think is right as a threat. And those you don't.
  - deleted 5y ago
    [deleted]
emeraldd 5y ago
It get's tricky with ambiguous subjects. If there is a concrete correct answer then yes, give that stick to your guns. If there isn't and the issue comes down to opinion and interpretation ... things get dicy ...
- zabzonk 5y ago
  Well, I disagree - people are presumably paying me for my experience and successes, which will affect my opinion and interpretation. If they don't like those, then presumably they don't value my experience, and we would probably not be happy working together.
  - emeraldd 5y ago
    I think there's a slight confusion here. An opinion should be stated as an opinion and not treated as or claimed to be a fact. If the point in question is stated as an opinion then fine and I'd agree with you. On the other hand, saying that an opinion is the factually one true way is a big red flag on either side. Otherwise, I'd agree with your stance completely.
dkarl 5y ago
This behavior selects for good, or at least compatible, coworkers. Of course if you are desperate for a job then you should read the room and say whatever they want to hear, but if the job market for your skill set is strong, you should show your personality and be open about how you approach technical problems (unless you're really an over-the-top asshole, and nobody thinks that about themselves, so it's pointless to give advice for that situation.) Once in a technical interview I was asked what data structure I would use for certain functionality "if performance was really critical." I said it would depend on the size and structure of the data that we needed to support, and when the interviewer said "unbounded," I said that the answer to that would go beyond an in-memory data structure, and if performance is critical you need to be able to project the sizes of data you need to support in the near future. I could tell the interviewer thought my answer was ignorant and sloppy. He started giving me a few "hints," which showed that what he wanted was the data structure had the best big-O performance. So I told what the best big-O performance was for the problem and what common data structure would provide it. Then he said, "So you would use that?" wanting to put the question to rest and move on the the next one, and I could have said yes. But instead I said "maybe," and I told him I remembered Bjarne Stroustrup talking about how algorithms classes in computer science education give students the wrong idea about how software engineers choose data structures and algorithms in practice. The university version, he said, is that if performance isn't critical, you just pick a container with the right functionality, and then if it turns out that performance matters, you pick something with the best possible big-O characteristics to get ideal performance. In reality (according to Stroustrup), when performance isn't critical, you should pick something with good big-O performance, and if it turns out that performance matters, you measure on realistic hardware with the data sizes and characteristics you need to support, and in many practical performance-critical cases you will end up choosing something with theoretically suboptimal big-O performance. I told the interviewer I liked Stroustrup's approach, and I always used data structures with known good performance by default, but I would measure if it mattered. I didn't get the job, and that was probably for the best at that stage in my career. I've nevertheless ended up working in situations like that, where people living by ideas I knew well thought I was an idiot for not understanding them, when I really just didn't completely agree with them, and those situations did not end well.

bitwize 5y ago

Your experience is not universal. I've been passed over for a job because I did not recite the right buzzwords (framework names, etc.). Your job in an interview is to please the person across the table from you. Some interviewers are looking for a sharp technical mind unafraid to challenge them. Others view any challenge to what they think is right as a threat.

zabzonk 5y ago
> Some interviewers are looking for a sharp technical mind unafraid to challenge them. And people like that are those you want to work with. > Others view any challenge to what they think is right as a threat. And those you don't.
- deleted 5y ago
  [deleted]

emeraldd 5y ago

It get's tricky with ambiguous subjects. If there is a concrete correct answer then yes, give that stick to your guns. If there isn't and the issue comes down to opinion and interpretation ... things get dicy ...

zabzonk 5y ago
Well, I disagree - people are presumably paying me for my experience and successes, which will affect my opinion and interpretation. If they don't like those, then presumably they don't value my experience, and we would probably not be happy working together.
- emeraldd 5y ago
  I think there's a slight confusion here. An opinion should be stated as an opinion and not treated as or claimed to be a fact. If the point in question is stated as an opinion then fine and I'd agree with you. On the other hand, saying that an opinion is the factually one true way is a big red flag on either side. Otherwise, I'd agree with your stance completely.

dkarl 5y ago

This behavior selects for good, or at least compatible, coworkers. Of course if you are desperate for a job then you should read the room and say whatever they want to hear, but if the job market for your skill set is strong, you should show your personality and be open about how you approach technical problems (unless you're really an over-the-top asshole, and nobody thinks that about themselves, so it's pointless to give advice for that situation.) Once in a technical interview I was asked what data structure I would use for certain functionality "if performance was really critical." I said it would depend on the size and structure of the data that we needed to support, and when the interviewer said "unbounded," I said that the answer to that would go beyond an in-memory data structure, and if performance is critical you need to be able to project the sizes of data you need to support in the near future. I could tell the interviewer thought my answer was ignorant and sloppy. He started giving me a few "hints," which showed that what he wanted was the data structure had the best big-O performance. So I told what the best big-O performance was for the problem and what common data structure would provide it. Then he said, "So you would use that?" wanting to put the question to rest and move on the the next one, and I could have said yes. But instead I said "maybe," and I told him I remembered Bjarne Stroustrup talking about how algorithms classes in computer science education give students the wrong idea about how software engineers choose data structures and algorithms in practice. The university version, he said, is that if performance isn't critical, you just pick a container with the right functionality, and then if it turns out that performance matters, you pick something with the best possible big-O characteristics to get ideal performance. In reality (according to Stroustrup), when performance isn't critical, you should pick something with good big-O performance, and if it turns out that performance matters, you measure on realistic hardware with the data sizes and characteristics you need to support, and in many practical performance-critical cases you will end up choosing something with theoretically suboptimal big-O performance. I told the interviewer I liked Stroustrup's approach, and I always used data structures with known good performance by default, but I would measure if it mattered. I didn't get the job, and that was probably for the best at that stage in my career. I've nevertheless ended up working in situations like that, where people living by ideas I knew well thought I was an idiot for not understanding them, when I really just didn't completely agree with them, and those situations did not end well.