Ask HN: How to handle interview when you do not think like other programmers?
18 comments
There exist many companies which quietly make an awful lot of money and which employ people much closer to you than to the stereotypical Silicon Valley Mobifotosocialgame Hipster Programmer. Get a job at one of them.
Absolutely. There is nothing wrong with the interview that you describe. You are learning exactly what you need to learn. Better to learn it today than six weeks into the job.
It is important to be polite, though, so to make it out of the room the usual talking points are:
1. "Our lousy platform was [mandated by management/chosen before I arrived], but I cheerfully got the job done with the inferior tools at hand."
2. "Our mission-critical legacy codebase made change difficult, but at least it was stable and made the company millions of dollars."
3. "I've heard of [interviewer's favorite magical tool] but I was so busy holding the widget factory together that I never had the time to research it and be sure it would solve my problem. Tell me more about [magic]! I've always wanted to work with the sort of brilliant yet sensitive person who uses [magic]."
Then shake hands, smile, leave the room, turn them down the next day, and get a job with a company that values you.
(You may find, however, that talking point #3, a tactic that comes straight from Dale Carnegie, makes your interviewers fall over themselves to hire you. Everyone loves to be invited to explain their favorite things.)
It is important to be polite, though, so to make it out of the room the usual talking points are:
1. "Our lousy platform was [mandated by management/chosen before I arrived], but I cheerfully got the job done with the inferior tools at hand."
2. "Our mission-critical legacy codebase made change difficult, but at least it was stable and made the company millions of dollars."
3. "I've heard of [interviewer's favorite magical tool] but I was so busy holding the widget factory together that I never had the time to research it and be sure it would solve my problem. Tell me more about [magic]! I've always wanted to work with the sort of brilliant yet sensitive person who uses [magic]."
Then shake hands, smile, leave the room, turn them down the next day, and get a job with a company that values you.
(You may find, however, that talking point #3, a tactic that comes straight from Dale Carnegie, makes your interviewers fall over themselves to hire you. Everyone loves to be invited to explain their favorite things.)
This is great.
A lot of people forget that interviews are two-way streets.
If the company culture indicates that you won't be valued, look somewhere else.
In this case specifically, I'd rather learn how to provide value than use some shiny new tool. It's much easier to learn the new tool.. that can be done when you need it.
A lot of people forget that interviews are two-way streets.
If the company culture indicates that you won't be valued, look somewhere else.
In this case specifically, I'd rather learn how to provide value than use some shiny new tool. It's much easier to learn the new tool.. that can be done when you need it.
Unfortunately, many of them are so quiet you can't tell they need people like you unless you really dig around, and sometimes not even then.
If the interviewer is truly confrontational (as in, you're being asked something like "why did you do stupid thing A when thing B is clearly better"), then you're better off not working there.
However, I'll often ask questions similar to those you posed (without thinking/telling the candidate he's useless, of course).
Let's take the "why not Java 1.8" example. If I asked you that, and you were prone to being defensive, you might think I'm attacking you. In reality, though, I'm just probing for more information. Are you familiar with Java 1.8? What would be the benefits/drawbacks of using it? If you can explain why Java 1.7 is fine for your project (I don't know Java, but I assume there are good reasons not to use the latest version), then I'm satisfied.
Basically, my goal is to learn as much as I can about you. This often involves direct questions. When I'm asking direct questions, I'm not attacking, and I suspect it's the same for many interviewers.
However, I'll often ask questions similar to those you posed (without thinking/telling the candidate he's useless, of course).
Let's take the "why not Java 1.8" example. If I asked you that, and you were prone to being defensive, you might think I'm attacking you. In reality, though, I'm just probing for more information. Are you familiar with Java 1.8? What would be the benefits/drawbacks of using it? If you can explain why Java 1.7 is fine for your project (I don't know Java, but I assume there are good reasons not to use the latest version), then I'm satisfied.
Basically, my goal is to learn as much as I can about you. This often involves direct questions. When I'm asking direct questions, I'm not attacking, and I suspect it's the same for many interviewers.
Wrong company / interviewer for you. Just move on.
That said, here's how I would answer: 1.7 because of legacy and potential stability reasons, and I will evaluate 1.8. I need to make a case for upper management and demonstrate there's a significant performance increase to justify the time required.
Ask the interviewer what he's refactored recently with lambda expressions.
For PHP/AngularJS, you can always joke about PHP and how much you want to switch to the next hip language. Unfortunately the mysterious previous developer picked it and you have to stabilize it. You will switch.. (eventually.)
For Angular, just say there's 30 other frameworks and you will get to it in due time. You can mess around and point the interviewer to that Todo list examples (http://todomvc.com/) and ask him why not the other 29?
You can always turn it around and ask them why they went with AngularJS instead of some other framework.
When I interview engineers, I do ask why AngularJS? I do this because I'm curious about their choices. Was it driven by hype or did they have a legitimate problem that was solved by the framework? I'm trying to have a technical discussion here and I'd rather do this than ask some random coding question. Given the limited context of your experience, I can't tell if the interviewer was being malicious or genuinely curious.
Hope this helps.
That said, here's how I would answer: 1.7 because of legacy and potential stability reasons, and I will evaluate 1.8. I need to make a case for upper management and demonstrate there's a significant performance increase to justify the time required.
Ask the interviewer what he's refactored recently with lambda expressions.
For PHP/AngularJS, you can always joke about PHP and how much you want to switch to the next hip language. Unfortunately the mysterious previous developer picked it and you have to stabilize it. You will switch.. (eventually.)
For Angular, just say there's 30 other frameworks and you will get to it in due time. You can mess around and point the interviewer to that Todo list examples (http://todomvc.com/) and ask him why not the other 29?
You can always turn it around and ask them why they went with AngularJS instead of some other framework.
When I interview engineers, I do ask why AngularJS? I do this because I'm curious about their choices. Was it driven by hype or did they have a legitimate problem that was solved by the framework? I'm trying to have a technical discussion here and I'd rather do this than ask some random coding question. Given the limited context of your experience, I can't tell if the interviewer was being malicious or genuinely curious.
Hope this helps.
They just want you to explain your reasonings. They aren't really interested in if you're "right" so much as how you got to your conclusion (e.g. "I decided to use Java 1.7 because of XYZ.").
Random aside: You should look into Aerospace Engineering/programming. You sound like you'd enjoy that type of development (functional programming, huge amount of docs, huge amount of testing, entirely fault tolerant end to end, etc).
Random aside: You should look into Aerospace Engineering/programming. You sound like you'd enjoy that type of development (functional programming, huge amount of docs, huge amount of testing, entirely fault tolerant end to end, etc).
Aerospace is definitely a field to look into. My only problem with it is that I found the working environment miserable. All my direct experience is with massive companies (Raytheon, Northrop, Boeing), though.
As an interviewer, if I heard
* someone picked java 1.7 because 1.8 is new and she or he wants to let some other suckers find all the crappy bugs in it (remember when 1.7 made lucene crap itself? I'm sure someone got to have some fun times with that, and I'm glad it wasn't me.)
* or she or he chose php because it was fast, easy, and had easy access to charting tools (I dunno if this is true or not) and for an internal dashboard what does it matter...
* I already know how to use it and can get the work done very quickly (always a great reason); there's no such thing as software finished too soon
* the company already has a large codebase in X and I wanted to say in the same language, libs, and deployment tools
I love people who say I like to lag versions a year, because it means they've been burned, learned the lesson, and want to let someone else do the debugging. You'll more likely than not get a strong hire vote from me. As parent said, it's about explaining why you picked something.
* someone picked java 1.7 because 1.8 is new and she or he wants to let some other suckers find all the crappy bugs in it (remember when 1.7 made lucene crap itself? I'm sure someone got to have some fun times with that, and I'm glad it wasn't me.)
* or she or he chose php because it was fast, easy, and had easy access to charting tools (I dunno if this is true or not) and for an internal dashboard what does it matter...
* I already know how to use it and can get the work done very quickly (always a great reason); there's no such thing as software finished too soon
* the company already has a large codebase in X and I wanted to say in the same language, libs, and deployment tools
I love people who say I like to lag versions a year, because it means they've been burned, learned the lesson, and want to let someone else do the debugging. You'll more likely than not get a strong hire vote from me. As parent said, it's about explaining why you picked something.
Don't bother. Target your applications toward the companies and roles that value the same things you do. If an interviewer harps on Java 1.8 vs. Java 1.7 while you want to talk about reliability, netstat, and performance problems, that's a sign that it's probably not a good fit for you.
"Not thinking like other programmers" is very often a good thing, but remember that the world is very broad, and there are probably programmers out there who think like you do. And even if you can't find them, there are also organizations out there that respect and need different talents, and you should find those.
"Not thinking like other programmers" is very often a good thing, but remember that the world is very broad, and there are probably programmers out there who think like you do. And even if you can't find them, there are also organizations out there that respect and need different talents, and you should find those.
Seems to me that you were being interviewed by a technocrat not a business person. My reading of the interview suggests to me that you are a person who can see an opportunity for business improvement and implement a valuable and reliable solution.
If this project is representative of how you look at the world, then maybe you should be focusing on how you can solve business problems. That is you are valuable for that level of insight and execution. Arguing over Java 1.7 vs 1.8 and PHP vs AngularJS doesn't increase business profits and doesn't recognise your true skills.
If this project is representative of how you look at the world, then maybe you should be focusing on how you can solve business problems. That is you are valuable for that level of insight and execution. Arguing over Java 1.7 vs 1.8 and PHP vs AngularJS doesn't increase business profits and doesn't recognise your true skills.
You should say "I used PHP because I wanted to use something I knew completely, rather than learning something new with unknown properties wrt fault tolerance." "I used Java 1.7 because Java 1.8 wasn't around at the time for the platform we're targetting."
If you can't come up with answers like that on the fly, you have bad "people skills" and are fucked. Interviewers doesn't care what technology choices you made, they just want to see that you'll fit into whatever little herd of programmers they are managing.
If you can't come up with answers like that on the fly, you have bad "people skills" and are fucked. Interviewers doesn't care what technology choices you made, they just want to see that you'll fit into whatever little herd of programmers they are managing.
Ask the interviewer if he wants you to use your employment at his company to learn the latest technology while working there so that you can leave for higher-paying work, or does the interviewer have actual business-related problems that need solving? Does the interviewer want to turn his company into "programmer university", or does he actually want to get shit done? Does the interviewer realize that the same problem can be solved in multiple other technologies and techniques? Is the interviewer using HIS time there to turn it into "personal programmer university" for himself so that he can bail soon, and is looking for a co-dependent rationalization? Does the interviewer have ACTUAL DATA showing that using the newer technology is: 1. faster to code, 2. less risky to code with, 3. less expensive to find developers who know it?
Does the interviewer want to make the answer to the question that nobody asked, or does he want to contribute to a company that has revenues?
Does the interviewer want to make the answer to the question that nobody asked, or does he want to contribute to a company that has revenues?
Actually, you sound very much like me, and I had a successful programming career before becoming disabled. As noted by others, you perhaps could improve your verbal interviewing skills, but interviews like this one are useful for filtering out companies you'd be unhappy at (and I'd add a good fraction of the technically doomed ones).
However I'll note that's one caveat to your "can do almost anything" concept: learning new paradigms, like functional programming if you only know imperative and OO (for me, learning OO when I only knew the other two), can take longer than most reasonable companies will be willing to give you.
Since you do know imperative and OO, if you don't know functional programming it could be worth your while to learn it on your own. Try something like SICP and you'll probably learn a few other worthwhile things.
However I'll note that's one caveat to your "can do almost anything" concept: learning new paradigms, like functional programming if you only know imperative and OO (for me, learning OO when I only knew the other two), can take longer than most reasonable companies will be willing to give you.
Since you do know imperative and OO, if you don't know functional programming it could be worth your while to learn it on your own. Try something like SICP and you'll probably learn a few other worthwhile things.
"1.7 met the needs of the project. We considered 1.8 but decided that it wasn't necessary and that taking on the training costs during development, and fracturing our platform, would not be a good trade-off to make."
> I don't know how to "defend" myself when the interview goes this way.
Don't.
In the example above, I would not want to work with coders who think like that, and it sounds like you would not want to either. So if you don't pass their interview process, consider it a win!
Keep looking, and if you are capable, you will eventually find an environment that fits.
Don't.
In the example above, I would not want to work with coders who think like that, and it sounds like you would not want to either. So if you don't pass their interview process, consider it a win!
Keep looking, and if you are capable, you will eventually find an environment that fits.
I would listen to my inside voice. The statements made by the interviewer were condescending and disrespectful. I would hold out for a company that respects and values; and realizes the great qualities I hold.
Redirect the conversation to what's important.
Like (a) asking what problems the company has that need to be solved, (b) how much more productive than the average software engineer you are, and (c) that you are determined: that you'll solve any problem, learning what you need as you go.
When someone asks a silly question, like why Java 1.8 instead of 1.7, your attitude shouldn't be to defend yourself as having made an Oscar-winning choice. Your answer should be the most comical, borderline embarrassing answer, because it will fulfill the possibly momentary psychological desire of the interviewer to feel they are right. But it should also be an answer that indirectly embarrasses the interviewer too for having asked it. You could say Java 1.7 would have caused the least trouble, and then point out that e.g. if you missed next week's release the company would have lost it's number one customer and shut down.
Plus, if what the interviewer wants is to show off superiority, let them. If you do that, you get the job. The interviewer isn't necessarily a bad person, and they might realize how stupidly they acted and shapen up. (Of course don't work there if they don't.) The more general advice is don't oppose forces, for the same reason trees let themselves bend when it's windy.
If you are unsure or feel cornered over silly stuff, say "I'm not sure that's the biggest problem to solve, or the one that will generate the most value for the company." If you have ideas of what that is, then go on to describe them.
In short, push back.
But don't push back the way a suit pushes back with some general, phony sounding, evasive statement like "well, I don't know how that affects some of the stakeholders." Be specific.
(Don't think of pushing back as doing something bad. Think of it as being more open-minded than the other person. You are considering data they are neglecting. It's part of being a good designer. Corollary: make an effort to consider other people's ideas, else you'll be the one who is narrow-minded.)
If I had only one piece of advice it would be: focus on the root of the problem. Hint: more often than not it's not what it appears to be, but it's some other problem hidden five layers deep.
For example, if an aggressive interviewer says "Clearly you don't know how to code and are useless", then clearly the problem is the interviewer, and the way you can pass the interview is to tell the truth. That he is the problem. But -- to do it indirectly, with humor as a lubricant. Start from the very first word: "clearly". Don't give them an inch.
You say something along the lines of: "Well, it's dangerous to make absolute statements, you know, to say "clearly", or "always" or "never". Not just because there's always a chance one could be wrong, but mostly because I noticed with myself that when I do that it's often to counteract something I subconsciously know is true. Else I wouldn't be finding the need to try hard to qualify what I say. I'd just say it. And you know what, I regret it eventually. It's strange how the subconscious works. I keep being surprised at how things aren't always as they seem. But I'm willing to learn."
In this way you address the root of the problem: the interviewer is aggressive without even realizing it. You identify how one can tell they are acting in ways they haven't realized: by making absolute statements. You show humility: you explain this is something that happened to you before. You allow for the interviewer to feel superior: because you just explained a mistake you made. You didn't budge; you stopped the conversation right on the first incorrect word: "clearly". And indirectly you push back: by making the interviewer look like a fool (because everything you just said about yourself could also be said about the interviewer). The problem isn't the Java version. Don't talk at all about any tech there.
Be humble. Be empathetic with people's faults. But the way out is following the truth, even if that means that you made a mistake or you need to learn something new. ALWAYS look for the root of the problem. If it feels hard to do, that's precisely your cue that you should do it.
And if the interviewer or company still don't get the hint, then forget about them. They can't tell what's important.
Like (a) asking what problems the company has that need to be solved, (b) how much more productive than the average software engineer you are, and (c) that you are determined: that you'll solve any problem, learning what you need as you go.
When someone asks a silly question, like why Java 1.8 instead of 1.7, your attitude shouldn't be to defend yourself as having made an Oscar-winning choice. Your answer should be the most comical, borderline embarrassing answer, because it will fulfill the possibly momentary psychological desire of the interviewer to feel they are right. But it should also be an answer that indirectly embarrasses the interviewer too for having asked it. You could say Java 1.7 would have caused the least trouble, and then point out that e.g. if you missed next week's release the company would have lost it's number one customer and shut down.
Plus, if what the interviewer wants is to show off superiority, let them. If you do that, you get the job. The interviewer isn't necessarily a bad person, and they might realize how stupidly they acted and shapen up. (Of course don't work there if they don't.) The more general advice is don't oppose forces, for the same reason trees let themselves bend when it's windy.
If you are unsure or feel cornered over silly stuff, say "I'm not sure that's the biggest problem to solve, or the one that will generate the most value for the company." If you have ideas of what that is, then go on to describe them.
In short, push back.
But don't push back the way a suit pushes back with some general, phony sounding, evasive statement like "well, I don't know how that affects some of the stakeholders." Be specific.
(Don't think of pushing back as doing something bad. Think of it as being more open-minded than the other person. You are considering data they are neglecting. It's part of being a good designer. Corollary: make an effort to consider other people's ideas, else you'll be the one who is narrow-minded.)
If I had only one piece of advice it would be: focus on the root of the problem. Hint: more often than not it's not what it appears to be, but it's some other problem hidden five layers deep.
For example, if an aggressive interviewer says "Clearly you don't know how to code and are useless", then clearly the problem is the interviewer, and the way you can pass the interview is to tell the truth. That he is the problem. But -- to do it indirectly, with humor as a lubricant. Start from the very first word: "clearly". Don't give them an inch.
You say something along the lines of: "Well, it's dangerous to make absolute statements, you know, to say "clearly", or "always" or "never". Not just because there's always a chance one could be wrong, but mostly because I noticed with myself that when I do that it's often to counteract something I subconsciously know is true. Else I wouldn't be finding the need to try hard to qualify what I say. I'd just say it. And you know what, I regret it eventually. It's strange how the subconscious works. I keep being surprised at how things aren't always as they seem. But I'm willing to learn."
In this way you address the root of the problem: the interviewer is aggressive without even realizing it. You identify how one can tell they are acting in ways they haven't realized: by making absolute statements. You show humility: you explain this is something that happened to you before. You allow for the interviewer to feel superior: because you just explained a mistake you made. You didn't budge; you stopped the conversation right on the first incorrect word: "clearly". And indirectly you push back: by making the interviewer look like a fool (because everything you just said about yourself could also be said about the interviewer). The problem isn't the Java version. Don't talk at all about any tech there.
Be humble. Be empathetic with people's faults. But the way out is following the truth, even if that means that you made a mistake or you need to learn something new. ALWAYS look for the root of the problem. If it feels hard to do, that's precisely your cue that you should do it.
And if the interviewer or company still don't get the hint, then forget about them. They can't tell what's important.
"I like to make stuff that solves a real, concrete problem."
How does the idea of spending 30% of time on refactoring sound to you?
How does the idea of spending 30% of time on refactoring sound to you?
Why are you trying to think like other programmers?
Why aren't you trying to find programmers that think like you?
FWIW every company I've worked at would be glad to hire someone that gave an answer like the one you gave.
Your answer sounds pretty good to me. The interviewer sounds a bit of an idiot.
I had interview similar to this last year. I was interviewing for back end engineer. I know SQL, Java, Python and Data warehouse fairly well. Guy interviewing was some Indian who always lives in his head. He started asking me deep Administration questions when role was clearly for engineering. I know some superficial DBA stuff but I am not DBA.
Than rude stupid asshole was clearly not paying attention when I was answering questions.
This is not something against Indian people but here is general piece of advice.
--> be polite
--> don't copy and ask questions posted on internet.
--> don't live in your head and assume you know everything.
--> don't copy and ask questions posted on internet.
--> don't live in your head and assume you know everything.
I've never felt that I had the same "goals" as other programmers. I like to make stuff that solves a real, concrete problem. I like it when my code runs for a long time and doesn't make any logic errors. I'm great at docs, debugging and code maintenance. I love to learn, but I love to make stuff work.
I'm really good at reverse-engineering. I'll use netstat to see who is talking to what, and on what ports, and at what times. I like to create documentation when it doesn't exist or it is wrong. I like to share what I've learned. I'll go to great lengths to get factual information.
I feel that I can do almost anything. If I don't know something, I'll go to great lengths to learn. If I need resources, I'll find them. But I struggle to get my knowledge, talents, and passion across to other programmers.
For example:
Interviewer: Tell me about a project you did.
Me: I saw a need in our business. There was valuable data in a system that no one could get to. The data was of great use to the business if the right people could see it. I wrote a Java program that connects to <foo> API and loads the data into <bar> database. I wrote some PHP pages to display charts and graphs based on my knowledge of the business problem domain. I profiled my code for memory leaks. I made it very fault-tolerant. The code I wrote stayed up for months at a time. I wrote several layers of monitors for the application. I get paged immediately on my phone if anything goes wrong. Everyone was thrilled.
Interviewer: What version of Java did you use?
Me: 1.7
Interviewer: Why didn't you use Java 1.8? It has lambda expressions. Why PHP? Why didn't you use AngularJS? Clearly you don't know how to code and are useless.
-----
I don't know how to "defend" myself when the interview goes this way. What should I do?