Tips for technical interviews?
March 9, 2022 1:58 PM
I'm pretty advanced in my career. I've written large, complex applications and compilers. I still fall flat on technical interviews mainly because they tend to ask niche questions. An example being "what's the difference between a clustered and non clustered index." Which as soon as I looked it up I knew but that is definitely not a day to day thing for me. Is there anyway to prepare for these interviews other than "any technical question that can be asked ever?"
I feel a bit embarrassed but at the same time a lot of interview questions are not what I deal with day to day. Usually I get called in a this point in my career if there's a bug in the framework itself or something really strange going on no one else can figure out. I'm sure at one point I could answer these with ease. I'm pretty up front about this and I GitHub page to show that I do know how to program. Should I avoid companies who get too technical like this? Or is there a good way to prepare for this I'm missing? When I interviewed people I usually had a "gut feeling" and never asked technical questions but just wanted to make sure they were someone I could work with.
I feel a bit embarrassed but at the same time a lot of interview questions are not what I deal with day to day. Usually I get called in a this point in my career if there's a bug in the framework itself or something really strange going on no one else can figure out. I'm sure at one point I could answer these with ease. I'm pretty up front about this and I GitHub page to show that I do know how to program. Should I avoid companies who get too technical like this? Or is there a good way to prepare for this I'm missing? When I interviewed people I usually had a "gut feeling" and never asked technical questions but just wanted to make sure they were someone I could work with.
They are not looking for the right answer they are looking for how you answer when you don’t know.
Fake it == don’t hire
Admit it, ask more questions, try to puzzle it out, speak intelligently about the topic == hire.
posted by St. Peepsburg at 2:28 PM on March 9, 2022
Fake it == don’t hire
Admit it, ask more questions, try to puzzle it out, speak intelligently about the topic == hire.
posted by St. Peepsburg at 2:28 PM on March 9, 2022
Source: was a engineering hiring manager and deliberately asked people questions on things I knew they didn’t know all the time just to see how they responded.
posted by St. Peepsburg at 2:30 PM on March 9, 2022
posted by St. Peepsburg at 2:30 PM on March 9, 2022
I agree with St. Peepsburg. My number one pet peeve when I used to conduct these interviews was when someone would answer a different question just so they would have something to say when they clearly didn't know the answer to the question I asked. Then you're left wondering, did they answer a different question to avoid saying "I don't know"? Or are they so out of their depth that they didn't even understand the question? A simple, "I would have to look that up," grounded with some of your relevant experience, like cmm described, should be satisfactory.
posted by telegraph at 3:19 PM on March 9, 2022
posted by telegraph at 3:19 PM on March 9, 2022
Generally what I would be looking for is the ability to think and reason abstractly about problems. The mechanics, someone at your level should be able to get up to speed on in a reasonable amount of time. But the level of abstract thought required to suck in a complex system and break it up into pieces small enough to execute on isn’t a given and that’s what I would primarily be looking for.
As for specifics… I expect you to be generally competent in the areas I’m looking for support in - it doesn’t have to be a perfect fit but, for instance, I’m usually looking for embedded engineers and if you know Web front ends you’re probably not going to be fit. (I wouldn’t be interviewing you, though.) I expect to be able to walk you through some design parameters in the space I’m working on, and get some reasonable starting points for an associated design. When I’m interviewing, “look it up on Google” is generally something I’d permit, and one of my jobs is to provide reasonable answers to reference questions if it’s needed to properly analyze the system I’m asking you to work with.
That said, if there’s overlap between specifics I know and specifics on your resume I’m definitely going to probe there to find out if you know what the resume says you do - if you don’t know something your resume says you should know, that’s a problem. In this case I probably won’t take “Google it” as an answer. This happens more than I like. I’ll also ask about things your resume covers that I don’t know really well, and I’ll ask you to walk me through it, whether or not it’s immediately relevant to what I’m doing, because a lot of the job is explaining to others the way things need to work. You’ll need to be able to walk me through projects you’ve written on your resume, in such a way that I understand how they work and could potentially provide direction for future development.
It’s rare that I will ask about something that I don’t know well and you don’t claim to know. Sometimes when I am working a bigger problem I will go off on a tangent that is more speculative - not particularly often, but occasionally for candidates that have done well so far - ask about something that’s not really related to the posting just to see how a candidates respond to things that are probably outside their wheelhouse. But having gotten there I am probably already inclined to hire you, and unless you say something completely crazy or start spouting bullshit you’ll probably be fine.
posted by doomsey at 3:51 PM on March 9, 2022
As for specifics… I expect you to be generally competent in the areas I’m looking for support in - it doesn’t have to be a perfect fit but, for instance, I’m usually looking for embedded engineers and if you know Web front ends you’re probably not going to be fit. (I wouldn’t be interviewing you, though.) I expect to be able to walk you through some design parameters in the space I’m working on, and get some reasonable starting points for an associated design. When I’m interviewing, “look it up on Google” is generally something I’d permit, and one of my jobs is to provide reasonable answers to reference questions if it’s needed to properly analyze the system I’m asking you to work with.
That said, if there’s overlap between specifics I know and specifics on your resume I’m definitely going to probe there to find out if you know what the resume says you do - if you don’t know something your resume says you should know, that’s a problem. In this case I probably won’t take “Google it” as an answer. This happens more than I like. I’ll also ask about things your resume covers that I don’t know really well, and I’ll ask you to walk me through it, whether or not it’s immediately relevant to what I’m doing, because a lot of the job is explaining to others the way things need to work. You’ll need to be able to walk me through projects you’ve written on your resume, in such a way that I understand how they work and could potentially provide direction for future development.
It’s rare that I will ask about something that I don’t know well and you don’t claim to know. Sometimes when I am working a bigger problem I will go off on a tangent that is more speculative - not particularly often, but occasionally for candidates that have done well so far - ask about something that’s not really related to the posting just to see how a candidates respond to things that are probably outside their wheelhouse. But having gotten there I am probably already inclined to hire you, and unless you say something completely crazy or start spouting bullshit you’ll probably be fine.
posted by doomsey at 3:51 PM on March 9, 2022
I don't know how representative this example is of the questions you're thinking about, but it strikes me as a question that would be pretty straightforward if you had experience performing tuning db queries, and quite difficult otherwise. So I don't think the theory that they're asking obscure questions to see how you deal with those is very applicable. I think it's more likely that they're asking questions to feel out how much knowledge you have in an area (where is the candidate on a scale of "can write a select statement" to "knows the optimal number of purge threads to set up in mysql for a given scenario").
Alternately, are you applying for the wrong kinds of jobs? You say that you've written complex applications and compilers, but not that you've written database-heavy applications. Are you also running into questions that seem overly-trivial or excessively technical but are in things you consider your area of specialization? Perhaps you should be just taking these questions as signs that they're looking for someone specializing in an area you don't focus on, and worry about trying to weed out that kind of company earlier in the process to avoid wasting everyone's time. (It is totally ok to ask the recruiter and/or hiring manager what kinds of areas the technical interview is going to focus on.)
posted by inkyz at 3:54 PM on March 9, 2022
Alternately, are you applying for the wrong kinds of jobs? You say that you've written complex applications and compilers, but not that you've written database-heavy applications. Are you also running into questions that seem overly-trivial or excessively technical but are in things you consider your area of specialization? Perhaps you should be just taking these questions as signs that they're looking for someone specializing in an area you don't focus on, and worry about trying to weed out that kind of company earlier in the process to avoid wasting everyone's time. (It is totally ok to ask the recruiter and/or hiring manager what kinds of areas the technical interview is going to focus on.)
posted by inkyz at 3:54 PM on March 9, 2022
A woman I know at a Big Tech firm you’d recognize, when asked to do a basic technical interview, simply said “No. I’m quite a bit past that. If you’d like to have a discussion about the technical aspects of my work and yours, I’d be more than happy to.”
In fairness, she’s got a particular niche, and she uses that response to weed out companies that don’t understand her niche so YMMV.
posted by aramaic at 4:37 PM on March 9, 2022
In fairness, she’s got a particular niche, and she uses that response to weed out companies that don’t understand her niche so YMMV.
posted by aramaic at 4:37 PM on March 9, 2022
Should I avoid companies who get too technical like this?
As an interviewer, I don't expect candidates to be able to answer every question I pose. I ask a ton of questions all over the place both to see what they know that's relevant and to see how they work (some) problems when they don't know the answer. In some cases I explicitly state they're allowed to Google the answer (but then need to be able to do more than just regurgitate the Wikipedia article).
And I try to always ask questions about concepts rather than some specific library or what flags you'd use to get such and such result. We hired a guy with no professional Python experience last year for a 100% Python role because we could tell his programming experience would let him pick it up and he had domain knowledge that would be useful that we hadn't found Python devs with. A bunch of his answers were honest, "I don't know."
Bad interviewers will use it as a gotcha or will have questions that are intentionally obscure as a way of making themselves feel smart. It's found everywhere but seems particularly common at the big name SV companies. The author of Homebrew famously couldn't get a job at Google where his software is widely used.
I try to avoid those companies of super smart kids with big egos and poor social skills. My company makes functional but unexciting software that gets the job done. We're not bleeding edge, we don't hire tons of MIT grads, it's mostly fairly basic CRUD stuff. There's something to be said for working for a company staffed by way above average people working on stuff that pushes the boundaries. But it can also lead to snobby stuff like the interview questions. And adjusted for cost of living, I make Bay Area Google/FB money, own a huge and nice house for a fraction of what renting a 1 BR is there, work 40 hours a week, get 4+ weeks of uninterrupted vacation a year plus a week or two of paid training. I burned very hard in my early development days and did some cool stuff but it mostly just left me burned out. And little of the pushing the envelope stuff mattered much at all five years down the line - it was all surpassed by better funded and staffed groups.
All of which is a long winded way to say that interviewers asking edge technical questions isn't necessarily a warning sign but how they react to you not knowing them is. Remember that you're interviewing them as much as vice versa. If the top tech companies are stressing you out with them and respond poorly when you don't know something, consider looking for less interesting companies that will still pay well and give you a better life/work balance.
posted by Candleman at 9:11 PM on March 9, 2022
As an interviewer, I don't expect candidates to be able to answer every question I pose. I ask a ton of questions all over the place both to see what they know that's relevant and to see how they work (some) problems when they don't know the answer. In some cases I explicitly state they're allowed to Google the answer (but then need to be able to do more than just regurgitate the Wikipedia article).
And I try to always ask questions about concepts rather than some specific library or what flags you'd use to get such and such result. We hired a guy with no professional Python experience last year for a 100% Python role because we could tell his programming experience would let him pick it up and he had domain knowledge that would be useful that we hadn't found Python devs with. A bunch of his answers were honest, "I don't know."
Bad interviewers will use it as a gotcha or will have questions that are intentionally obscure as a way of making themselves feel smart. It's found everywhere but seems particularly common at the big name SV companies. The author of Homebrew famously couldn't get a job at Google where his software is widely used.
I try to avoid those companies of super smart kids with big egos and poor social skills. My company makes functional but unexciting software that gets the job done. We're not bleeding edge, we don't hire tons of MIT grads, it's mostly fairly basic CRUD stuff. There's something to be said for working for a company staffed by way above average people working on stuff that pushes the boundaries. But it can also lead to snobby stuff like the interview questions. And adjusted for cost of living, I make Bay Area Google/FB money, own a huge and nice house for a fraction of what renting a 1 BR is there, work 40 hours a week, get 4+ weeks of uninterrupted vacation a year plus a week or two of paid training. I burned very hard in my early development days and did some cool stuff but it mostly just left me burned out. And little of the pushing the envelope stuff mattered much at all five years down the line - it was all surpassed by better funded and staffed groups.
All of which is a long winded way to say that interviewers asking edge technical questions isn't necessarily a warning sign but how they react to you not knowing them is. Remember that you're interviewing them as much as vice versa. If the top tech companies are stressing you out with them and respond poorly when you don't know something, consider looking for less interesting companies that will still pay well and give you a better life/work balance.
posted by Candleman at 9:11 PM on March 9, 2022
Is there anyway to prepare for these interviews other than "any technical question that can be asked ever?
Well, one way is to lean into a niche and specialize. You wont get all the niche Q's right, and sometimes your niche is not the niche an employer needs to hire. Read, take notes, and try to retain what you read. As an SRE we tend to ask many questions about the Linux API, and the question bank is a random sample of the much larger knowledge base. You need to be prepared to defend all questions but they only need a few 'gotchas', so some amount of luck is involved!
Should I avoid companies who get too technical like this?
That probably depends on employment status, and tolerance for failed interviews. In a way, the shitty hiring process at big, selective companies is also selecting for people willing to tolerate the BS of BigCorp life. Not that I think its intentional, it just works out that way.
As far as return on investment, it varies. With stock appreciation, my w2 last year was ~450k, and on track for over 500k this year. But the stock PE ratio is now double where it was when I started, and it takes time for refreshers to stack up.
Or is there a good way to prepare for this I'm missing?
O'Reilly books and Anki are my tools here. I target about 1 book a month plus some journal papers. It doesn't specifically mean I'll pass interviews, but there are books tailored to that, and a few of the megacorps offered suggested reading materials for my onsite interview.
posted by pwnguin at 11:56 PM on March 9, 2022
Well, one way is to lean into a niche and specialize. You wont get all the niche Q's right, and sometimes your niche is not the niche an employer needs to hire. Read, take notes, and try to retain what you read. As an SRE we tend to ask many questions about the Linux API, and the question bank is a random sample of the much larger knowledge base. You need to be prepared to defend all questions but they only need a few 'gotchas', so some amount of luck is involved!
Should I avoid companies who get too technical like this?
That probably depends on employment status, and tolerance for failed interviews. In a way, the shitty hiring process at big, selective companies is also selecting for people willing to tolerate the BS of BigCorp life. Not that I think its intentional, it just works out that way.
As far as return on investment, it varies. With stock appreciation, my w2 last year was ~450k, and on track for over 500k this year. But the stock PE ratio is now double where it was when I started, and it takes time for refreshers to stack up.
Or is there a good way to prepare for this I'm missing?
O'Reilly books and Anki are my tools here. I target about 1 book a month plus some journal papers. It doesn't specifically mean I'll pass interviews, but there are books tailored to that, and a few of the megacorps offered suggested reading materials for my onsite interview.
posted by pwnguin at 11:56 PM on March 9, 2022
I wouldn’t worry about trivia, but I do suggest practicing the types of situations which you can reasonably expect in SDE interviews.
Some examples of these would be a data structures and algorithms problem (leetcode-ish), a logical/maintainable code problem, an ambiguity handling problem, a system design problem, a bunch of behavioral questions (Tell Me About A Time When…”).
These are, for better or for worse, extremely common not just at large tech employers, but across the industry. Practicing answering them is helpful, because they aren’t completely natural otherwise, and a majority of interviewees invest substantial effort freshening their skills.
Source: I’m in engineering leadership at a FAANG company.
posted by whisk(e)y neat at 6:30 PM on March 10, 2022
Some examples of these would be a data structures and algorithms problem (leetcode-ish), a logical/maintainable code problem, an ambiguity handling problem, a system design problem, a bunch of behavioral questions (Tell Me About A Time When…”).
These are, for better or for worse, extremely common not just at large tech employers, but across the industry. Practicing answering them is helpful, because they aren’t completely natural otherwise, and a majority of interviewees invest substantial effort freshening their skills.
Source: I’m in engineering leadership at a FAANG company.
posted by whisk(e)y neat at 6:30 PM on March 10, 2022
I'm not sure that it's productive to study technical "trivia", just for the chance someone might ask about it. But as others have mentioned, there are topics you should be conversant on, because they're commonly-used screener questions.
A lot of technical interviews will include a question about big-O notation, just to make sure you've heard about it before. (Something like, "if you have two algorithms and one is On and one is O log(n), which one is faster?")
In my experience, some basic object-oriented questions tend to be common as well.
posted by Kadin2048 at 12:00 PM on March 11, 2022
A lot of technical interviews will include a question about big-O notation, just to make sure you've heard about it before. (Something like, "if you have two algorithms and one is On and one is O log(n), which one is faster?")
In my experience, some basic object-oriented questions tend to be common as well.
posted by Kadin2048 at 12:00 PM on March 11, 2022
As a technical interviewer I'm trying to apply a bullshit filter to your resume.
If your resume says you have 10+ years in embedded development I'm surely going to ask some questions to see if that's true. Start easy, then maybe get a little tougher and see where you hit the wall.
I guess what I'm trying to ask is : If you're stumped on a tricky database question, by your example, do you have that on your resume as one of your advanced skills?
I've been in a number of technical interviews that quickly flip into trivia contests and I understand your frustration. So maybe this isn't the case but I wanted to ask the question anyway.
posted by JoeZydeco at 2:30 PM on March 11, 2022
If your resume says you have 10+ years in embedded development I'm surely going to ask some questions to see if that's true. Start easy, then maybe get a little tougher and see where you hit the wall.
I guess what I'm trying to ask is : If you're stumped on a tricky database question, by your example, do you have that on your resume as one of your advanced skills?
I've been in a number of technical interviews that quickly flip into trivia contests and I understand your frustration. So maybe this isn't the case but I wanted to ask the question anyway.
posted by JoeZydeco at 2:30 PM on March 11, 2022
Just a follow up, I flubbed the first couple of interviews as I was asked about DRY/SOLID which I know but haven't had to define what they meant in a long, long time. Also I probably have been in upper management more than I realized as I don't talk code as much as sort of "what approach should we take to deliver on time and on budget."
I'm not worried about my technical abilities, I've written Typescript compilers or at least bad ones, but it took me a couple of interviews to get to speaking tech and not management again. Thanks for the advice! If anyone is interested I'd write off the first couple of interviews as getting used to interviews.
posted by geoff. at 9:27 PM on March 20, 2022
I'm not worried about my technical abilities, I've written Typescript compilers or at least bad ones, but it took me a couple of interviews to get to speaking tech and not management again. Thanks for the advice! If anyone is interested I'd write off the first couple of interviews as getting used to interviews.
posted by geoff. at 9:27 PM on March 20, 2022
This thread is closed to new comments.
"I'm not really sure what the difference between a clustered index and a non-clustered index is. I have a lot of database experience and could write a good index covering index for high use columns but I just don't know what the difference is between those two things. I would probably rely on a DBA or google it if it came up. I know in my experience there can be a lot of detrimental issues that can go wrong with intricate database setup. I'd be careful and I wouldn't just do things without understanding what I was doing. So I'm just not sure and I'd look that up probably."
If you know enough to talk tangentially about the topic, maybe do that ("Obviously indexes are important, but it is a trade off. In both relational DBs and non-relationshal DBs indexing is one of the best tools for performance and I would always index frequently used foreign keys or columns or fields that are very frequently used. I have experience using query plan analyzers on Mysql and Postgres and Oracle.", etc.) But never feel bad saying you don't know. They may be looking for someone who DOES know. But in that case, that isn't you anyways so you're doing both of you a favor.
As someone who conducts technical interviews, most of the time I'm just danging more rope to you to see where you go. I personally totally appreciate someone saying they don't know something. Maybe that one thing is really important; maybe it isn't. But I appreciate the honesty and the vulnerability when someone says they don't know. It's not as good as knowing and blowing me out of the water, but it is better than making things up or avoiding the question.
posted by cmm at 2:19 PM on March 9, 2022