Want to know the secret to interview developers? Here are the only 3 questions you have to ask:
1. What do you do for fun when not at work? … dig into to questions from here.
2. What is the coolest thing you ever built? How did it work? How long did it take to build? What language? What architecture / framework? What was hard about it? … you get the idea.
3. What are your biggest pet peeves when it comes to reading other peoples code?
Question #1 breaks the ice and gives permission to the candidate to be themselves. Look for common ground. Connect with them. Learn who they are as a person.
Question #2 gets you to see their passion. Talk to them on their ground. Give them the benefit of the doubt. Ask them hard questions, but don’t intimidate. Just go deep. The candidate cannot fake this. It’s not possible. People without the experience they claim are painfully obvious here.
Question #3 gives you two things. 1. Is this person openly critical of things looking to improve them? And Is this person a jerk? I call this the Jerk Trap. Jerks jump right in to being Jerks. After all you just kind of game them permission here! — I would ask though you be careful about excluding neurodiverse people who may not be able to control tone or navigate social situations well. These people will tend to be direct. Don’t confuse directness with being a Jerk. They are not the same thing.
I’ve interviewed a lot of engineers in my career, and tried a lot of things. This methodology has yet to fail me.
EDIT: It’s sad I even have to point this out, but in #1 you are looking to connect with the person on a human level. It’s not bait them into talking about coding outside of work. If you do that or think that way you are being discriminatory towards people who can’t code outside of work… you know like single mothers. And people wonder why we don’t have more women in tech. Stop equating passion with > 40 hours a week. It’s bullshit. Stop.
> 1. What do you do for fun when not at work? … dig into to questions from here.
Sorry but I think it's a bad question. What if the answer is "Oh I don't have much spare time these days, I make dinner for our toddler son and put him to bed. My lesbian partner can't help much because she's expecting in a month." It's a trap leading to unwanted information - many of which would be downright illegal if factored into hiring decisions.
There's a reason why all the big companies emphasize never to ask anything about nationality, ethnicity, marital status, religion, blah blah. You don't need to know, you don't want to know.
I love this style of interviewing, but I have been discouraged by HR/management from asking questions like these because they were deemed too subjective. Personally I believe this was directly related to their D&I pipeline efforts and the "subconscious bias" we were told we all had.
This sounds like a recipe for an incredibly inconsistent interview process.
I know engineers love open, discussion-y interviews and senior interviewers like giving them, but the evidence just doesn't bare it out. "Work sample tests" and "Structured Interviews" are the most predictive of on-the-job success from the published research I've seen. No matter how much I'd prefer to have a freewheeling conversation as you describe, I have to bow to the evidence.
I ask a question kinda similar to 1 sometimes when I interview people. Even when their answer isn't software related (for me it's more fun when that's the case but I try not to be biased), there's a lot of room to dig in deeper.
Like if someone says their goal in life is to make the best tasting sourdough, ask them how they go about doing that. Researching new recipes? Starting with a base recipe they like and making small tweaks? Optimizing for their own taste preferences vs the tastes of the people they share it with? Etc.
Even if their hobby isn't collecting Github stars, you can still learn a bit about their mindset. Plus I've found that getting someone to talk about something they're passionate about for 5 minutes is a good icebreaker to start an interview.
#3 is one I've had to think on a lot recently and I think it comes down to two things:
1) When the person who wrote the code is no longer available to talk to. Having even a 5-10 minute chat can massively speed up my comprehension of someone else's code and save a lot of time.
2) Unused code that hasn't been deleted. I think everyone should strive to clean up their codebases. I'm not exactly blame-free here either so it's something I try to apply more and more as the codebases I work on start staying around for longer.
This. All the best places I have worked at in my career have basically followed this formula. And in fact these questions are fairly similar to the original YC application, with the exception that the question about your favorite tech stack was separate from the question about the coolest thing you've built.
In contrast, the places that have done tech interviews have generally been awful to work at. Less intelligent people, less interesting work, worse management, etc.
Many below gave various reasons about it being less than ideal to ask "personal" questions about hobbies etc, but I think I have had such question asked of me during every interview. It never was at the beginning, usually after we've done talking about technical stuff and before the money conversation.
Personally I never had a problem with it and from the interviewer point of view it helps lighten the atmosphere a bit talking about out of work stuff.
> It’s not bait them into talking about coding outside of work.
I've been to work for companies that say anything you build while employed at company belongs to them unless you go through the proper channels and layers of red tape to discuss the projects with them to ensure that anything you are working on does not involve any company IP. This could sound like baiting for a different direction than the other comments are alluding.
I hated interviewing SWEs at Google, and the way I got out with it while still doing my duty was to interview the patent lawyers! They always had one engineer interviewer and I was it. My stock answer for why I did it was, "Hey, who wouldn't enjoy torturing lawyers?"
Actually, I loved it. You might not be able to imagine this, but I actually like lawyers, as a rule.
Since Google insists on giving candidates a problem, I took a patent from a previous job that I was familiar with, and said, "OK, we're going to pretend I'm the inventor, and I'm going to describe this invention to you. Your job will be to write the first claim."
This is pretty similar to their actual job, at least on the patent prosecution side. They have to come up to speed on an unfamiliar technology quickly? Well, that's what patent lawyers do. Most of them did pretty well on the test, too. It was way fun.
Unlike in a SWE interview, I never heard anything after I gave my feedback (with a SWE, you would see what the other interviewers said). The only way I even heard if they were hired was to check a few months later. I didn't know if Legal even paid attention to me.
Years later, I joined Legal and found out they'd been hanging on my every word.
Oddly enough, this sounds like a lot of fun. For the most part, I got to know lawyers as incredibly hard-working people and if you show them a little bit of respect and understanding towards their profession they are an absolute joy to work with.
Didn't like this article at all. The writer's style is dismissive and combative in a way that's at odds with the message it's trying to convey. It's not an idiotic myth that most people aren't good programmers and it's not arrogance that makes people think that it's very important to make sure the wrong person isn't hired. I don't think this because I've spent too much time on Hacker News, I think it because I've worked with a lot of people over the years and I know how a team can be dragged down by a bad hire.
Of course you shouldn't humiliate the candidate, that's never the right thing to do. But there's a huge gap between maintaining a high hiring standard and believing that "everyone else looking for a job is an idiot, and our job is to expose them, to teach them a lesson, to humiliate them till they quit." The bulk of the advice in this article is fine, but the hyperbole is just plain annoying.
Also, seeing people site the no asshole rule is a warning sign for me. I worked at a place that constantly mentioned that, and let's just say it was clearly ineffective. Assholes rarely think that they are the asshole and are perfectly comfortable citing that principle.
I feel like in the third situation it means that the team is way too picky and that’s why you should try to avoid job postings that have been open for a few months or more.
Once you do enough interviews, you realize this isn't a myth. Okay, maybe most is too strong of a qualifier. But the reality is that a title of Senior Software Engineer doesn't imply the ability to translate human problems into machine-executable code in a structured way. It's very possible that a "Senior Software Engineer" has been working at a small consultancy on the same project for 5+ years, has few if any technical teammates, and spends most of their time copy and pasting StackOverflow answers and doing "guess and check" programming to do bug fixes for a legacy VB6 or FoxPro app. I'd know, as I've worked with those people.
That being said...
> The interviewer asked me a very basic question– something small like how to create a table(or something silly like that).
If you're asking syntax questions in an interview, you've already lost. For technical interviews, the thought process is far more important than the end result. Again, programming is the act of turning human problems into machine code in a structured, repeatable way. Pseudocode is sufficient for this. Forget whether you should be using `sort` or `sorted` in python? Me too, so just tell me what you expect the sort method to do and move on.
So yes, asking for the SQL create table syntax in an interview is absurd and the author is right to complain here.
> Actually talk about their fucking resume... You can easily filter out people who just coasted along vs those who accomplished something.
Sorry, but you cannot. Some people are excellent at bullshitting and making themselves sound like incredible workers, especially if they've had time to prepare. You'll hear amazing stories of late nights and heroic effort, but they were often done by other people and merely observed by the interviewee, or just fabrications.
This. I’ve interviewed some amazing talkers with epic resumes. I’ve had people try to hog the mic to charm me but then when it came down to coding they couldn’t produce any working code in the language of their choice.
All the most advanced computer science research areas right now basically come down to guess and check. E.g. AI, ML, NLP, etc. The folks behind spaCy have a good talk somewhere explaining that this is the reason why there isn't more academic funding things like NER, despite the fact that it's an insanely valuable problem.
But regardless, the best programmers you know probably spend most of their week doing guess and check.
despite the fact that the specific problem has been memed to death, i can still reliably wash out 70% or so of the interview cohort i’ve interviewed by fizzbuzzing.
I think this depends heavily on your candidate source. A few bits of anecdata:
1. A couple years out of college, I went back to my alma matter to recruit interns. I stood at a booth at a job fair and chatted with people. Anyone who seemed interesting I invited for a 30-minute interview the next day (9 people). The next day I had all 9 people do fizzbuzz on paper (I know, I know, I was young!) - every single one passed easily and it filtered out no one.
2. More recently, I was recruiting off of workatastartup.com for senior devs. I went through a few dozen first-round interviews and didn't once come across someone who couldn't code.
3. More recently still, I was working with some recruiters who would send resumes my way. I was looking for a specific combo of two common techs and I started out giving a first-round interview to anyone who listed any experience with both. I found that something like 60-80% of these candidates would *not* have, (in my opinion), been able to code fizzbuzz.
It was interesting because, until #3, I'd never really believed the "most people cannot program" thing - at least not after my experience with #1. The lesson I took was that it totally depends on your pipeline. If you put a job listing on Indeed.com or whatever, you'll get a lot of people who cannot program. If you use other channels or do any other form of screening (implicit or not), you may get almost none.
It’s incredibly uncomfortable when a candidate can’t fizzbuzz. I used to use it as a warm up before hiring in big tech, where the process is very defined.
I had one candidate take the entire first half of the interview to solve it, and I guided him very strongly the entire time. By the time he was half way through, he had so much sweat pouring from his face he looked like he was running a marathon. It was very awkward and uncomfortable for me.
Like fishtoaster’s #3 above, these candidates came through recruiters where we specified the technologies we wanted.
The number of people who find fizzbuzz hard makes me wonder if there's something that I find straightforward to understand in it that's actually harder than it appears, which makes me avoid it as an interview question. I want to find good devs, not good Fizzbuzz authors.
yeah I really don't understand this "catch them out" mentality.
My approach is to try and make the candidate feel relaxed, as I want them to show their best self in an already stressful situation. Following this it's about giving them the opportunity to demonstrate their skills.
If you go into an interview with a combative mindset of "filtering out the lemons" and then complain how hard it is to hire good people, you really ought to take a long hard look in the mirror.
I have the following framework when interviewing (either side of the table)
1. Both parties hope it's a match but of course worry about making the wrong choice. Think: the interview wants me to do well, I need to help them say yes to me.
2. Programming ability is a necessary but not sufficient skill for a real programming job. How you are on call, how you are with brainstorming, how you are hashing through requirements, how you are when you make a mistake, how you are when you are being coached - all matter and the programming interview is generally structured to get signal on those things.
I think most people who make themselves crazy / hate interviews / are befuddled - it's because they don't see this.
This seems to be a human trait; where authority mixed with lack of responsibility leads to terrible outcomes. Not only in programming interviews, but across the spectrum. My first awareness of this is in teacher-student relationships, where faculty deem themselves in high regard because they are continually interacting with people who are ignorant of the facts they have been teaching for the entirety of their careers.
Been in the technical interviewer role once. I did feel like an asshole for asking what seemed like a trivia question but they were all very basic things meant to be a starting point to pull on the thread and use that to have a conversation. I asked multiple questions like that because they keep saying they didn't know what I was talking about. This was a non-entry level security job and the questions were simple things like "do you know what a sql injection is?" Or "do you know what a dns record is? Is so, what is the purpose of the SOA record?" It was fine if they didn't know really, "I know what sql is but I don't know what a sql injection is" is a good enough answer.
It was horrible. Never want to be the reason someone didn't get a job again lol.
I agree with the article - some common styles of interview are designed to produce arseholes. Which, fine, if you want to employ only arseholes and people who like working with arseholes that's what you should be doing. Likewise if your workflow is 90% programming trivia questions and 10% meetings. It's useful for me as a candidate, the sooner you show that the sooner I can get out of there.
The bit at the end about trying to discover what candidates are good at and see them actually working... I'm shocked that so few interviews actually do that. I get that it's hard in tiny companies where you have one vaguely technical person who realises they're out of their depth and is hiring to fill that gap. Everyone else has no excuse for lousy evaluation of technical skills.
Other than the assholes, there is also the "I just found out about this 10 mins ago" guy. This guy doesn't have any questions and hasn't prepared.
This means when they ask him for feedback he'll say "Oh he was okay. Not very technical"
To solve for this guy, you need to have some very good questions about technical problems the company may be facing and then you need to be able to have insights on how they might solve this.
You essentially have to structure the interview for them. Give them the questions and then you answer and then you have to impress.
The aim should always be to impress and be liked unless you have someone who is out to prove you wrong. With those types you need to show technical superiority in addition. These types are usually small in number though.
This is really big; we've been using the same basic "is this person a big phony" set of questions for a long time, and it immediately filters out people who just have no knowledge. Stuff like what is a Boolean variable, what is ssh, what is asymmetric encryption, name 3 hardware components of a server, what is a primary key, etc. I've seen people with resumes full of tech jobs that fail at all of these. And I don't mean slightly off, I mean no clue at all. We don't require a perfect score or anything, and recognize language barriers, but it becomes super clear super quickly when someone is just bullshitting.
In my opinion the reason why programming interviews are the way they are is that they are primarily testing for a kind of person rather than programming ability. They are testing for the kind of person that is willing to jump through hoops.
Triangulating skill level of prospects can be challenging the further down the Niche Hole you go. At the very edge of the problem space the prospect is going to fall off a cliff; it can't be avoided, there's just too much specialization.
However . .
When prospective associates are responding to these sorts of questions, it's possibly more informative to see how they handle questions that they don't know the answer to.
Native intelligence and initiative outweigh a set quantity of specialized knowledge; far more important to find out how a prospect thinks about the problem and how they respond to these situations under pressure.
Problem here is that the interviewers need to know their stuff, and, regretfully, that's not been the case for virtually any interview board I've assisted. All the participants were far, far too high above the levels where work happened, well into the vertiginous expanse of Aero/Def Management Brain Rot. Best I could do was wave my hands vigorously while silently mouthing the words HE DOESN'T KNOW WHAT WHITESPACE MEANS . . to no avail.
Thing is, I know it's not just my industry. It happens in the "normal" world too. Some guy makes a thingy with Framework X, leaves, and then it's practically impossible for management to find another random guy who knows Framework X in just the same way, because damned if management knows what the heck Framework X is.
Something I have rarely seen mentioned: ask the interviewee about the things they claim in their CV. Sure, it takes some prep time, but it makes them feel more comfortable, and it also weeds out the bullshitters because even without the deep technical knowledge in that area you can just ask them to talk specifics. If they know their stuff, they will dive into something super detailed. If others did the work and they were just along for the ride, they will gloss over all the details.
Yeah, I think there's a surprising amount that can be learned just by having a technical conversation, and it's the interview format that is least likely to cause performance anxiety. That said, I've been snowballed a couple of times by people who could somehow talk exactly like a productive person, yet not produce anything. The huge variety of people is what makes interviewing so hard.
I was so confused the first time this happened. I kept asking about these things they said they'd worked on and could not get any details. Now I understand how many people are able to coast and never contribute meaningfully. These people need to be coached out of the profession.
I imagined how should I act when I forgetting the SQL table create command in an interview.
1. I admit I am nervous so much that I just couldn't tell my own name.
2. It's just strange for first look that I don't remember, but we create tables so rarely, that it's not a surprise.
3. Okay, let's try to figure out the command, my first hint is that it should be "new", "create" or something. Let's recall, how to deal other way, say, delete or modify tables: "drop table", "alter table" - so my best hint is "create table" or "new table". (Offensive notice: if you learnt SQL one day before the interview, this gonna not work.)
Great, go on, it's pretty sure it should contain the list of fields, define them: names, types, and some constraints, whether it can be empty etc. Maybe this command defines the indexes as well, then every index should declare one or more fields, ascending/descending marks per field. Oh, a table unique key is also can be specified, at the field specification. Finally I notice, that different SQL servers may have different syntax and even features, like choosing storage system for the table (MySQL: InnoDB etc.).
That's the _content_ of the SQL's create table command, withot any syntax. I think, it's clear, that I would have no problem with writing a table creating SQL statement.
If you can not solve the "I-forget-the-syntax" problem, probably (another offensive statement, sorry) you're not for this job. In real life, you will have even more stressful situations, and you have to solve them, or at least DO SOMETHING. What you've done was NOTHING.
The solution for this, along with most interviewing problems, is to get your team together and come up with a very clear picture of what it is that you're looking for in a candidate. Hash it out and write it down. Now take that list and write out a group of questions that help to suss out whether or not the candidate has those things. Use the same group of questions for everyone that you interview for that position. Nothing good comes from asking gotcha questions. It's more likely to happen if you don't have a clear, documented process.
Depending on what your needs are, you may need to do a technical interview. Do the same thing with the technical interview, figure out your needs then write your questions. Have a similar group of people doing the situational interviews do the technical interview, preferably the people the candidate is going to work with. Find a way to make it collaborative if you can. Seeing how a candidate works with other people is nearly as valuable as seeing how technically proficient a candidate is.
Interviewing is a multifaceted process that depends on many variables. Unfortunately google and other similar companies influenced/contaminated so much the general idea of what an interview should look like that many, many people believe that a person writing in 15 minutes a sloppy solution for what's essentially an academic exercise is the gold standard for measuring someone's skills.
I have no problem solving exercises in interviews as long as we're talking about one session of at most one hour. I was contacted by recruiters of companies that expected me to go through many rounds of interviews that would span many weeks. lol
I always reply that I'm already employed, that for me their company is just like any other company and that working for them is not a privilege, it's just a job.
Anyone else surprised how many candidates can’t code without autocomplete? I let candidates google answers and some still gripe about not having autocomplete. We code in a web app, so it makes me wonder how they would perform on a whiteboard with no google or compiler feedback.
I can write code without autocomplete, but given that most of what I write is Swift for iOS/macOS where verbose naming is the rule (and thus, is probably what I'm interviewing to do) it can be painful because often I don't have method signatures, etc memorized because heavy autocomplete usage is a must to not drag down speed. When faced with writing in a plain editor or whiteboard I'll usually ask if I can write non-compiling pseudocode because I'm likely to have name errors all over the place.
Why is it surprising that people are less productive without their tools of choice? Why does it matter how they perform on a whiteboard without Google or compiler feedback? Is this how you work on a daily basis?
We set up all these artificial handicaps and are then surprised people do badly in interviews. Just let them code using their own machine and IDE, and any other tool they need.
I wonder if you'll also scoff when people start asking for Copilot or GPT.
No autocomplete is a major pain in the ass when you use different languages and forget if it's "#list", "len(list)","list.len()", "list.length()", "list.size()" or "list.length".
Also, grug hit dot on keyboard and list of things grug can do pop up magic
[+] [-] kitanata|3 years ago|reply
1. What do you do for fun when not at work? … dig into to questions from here. 2. What is the coolest thing you ever built? How did it work? How long did it take to build? What language? What architecture / framework? What was hard about it? … you get the idea. 3. What are your biggest pet peeves when it comes to reading other peoples code?
Question #1 breaks the ice and gives permission to the candidate to be themselves. Look for common ground. Connect with them. Learn who they are as a person.
Question #2 gets you to see their passion. Talk to them on their ground. Give them the benefit of the doubt. Ask them hard questions, but don’t intimidate. Just go deep. The candidate cannot fake this. It’s not possible. People without the experience they claim are painfully obvious here.
Question #3 gives you two things. 1. Is this person openly critical of things looking to improve them? And Is this person a jerk? I call this the Jerk Trap. Jerks jump right in to being Jerks. After all you just kind of game them permission here! — I would ask though you be careful about excluding neurodiverse people who may not be able to control tone or navigate social situations well. These people will tend to be direct. Don’t confuse directness with being a Jerk. They are not the same thing.
I’ve interviewed a lot of engineers in my career, and tried a lot of things. This methodology has yet to fail me.
EDIT: It’s sad I even have to point this out, but in #1 you are looking to connect with the person on a human level. It’s not bait them into talking about coding outside of work. If you do that or think that way you are being discriminatory towards people who can’t code outside of work… you know like single mothers. And people wonder why we don’t have more women in tech. Stop equating passion with > 40 hours a week. It’s bullshit. Stop.
[+] [-] yongjik|3 years ago|reply
Sorry but I think it's a bad question. What if the answer is "Oh I don't have much spare time these days, I make dinner for our toddler son and put him to bed. My lesbian partner can't help much because she's expecting in a month." It's a trap leading to unwanted information - many of which would be downright illegal if factored into hiring decisions.
There's a reason why all the big companies emphasize never to ask anything about nationality, ethnicity, marital status, religion, blah blah. You don't need to know, you don't want to know.
[+] [-] mshake2|3 years ago|reply
[+] [-] Ancalagon|3 years ago|reply
[+] [-] fishtoaster|3 years ago|reply
I know engineers love open, discussion-y interviews and senior interviewers like giving them, but the evidence just doesn't bare it out. "Work sample tests" and "Structured Interviews" are the most predictive of on-the-job success from the published research I've seen. No matter how much I'd prefer to have a freewheeling conversation as you describe, I have to bow to the evidence.
[+] [-] bawolff|3 years ago|reply
[+] [-] giantg2|3 years ago|reply
[+] [-] Rebelgecko|3 years ago|reply
Like if someone says their goal in life is to make the best tasting sourdough, ask them how they go about doing that. Researching new recipes? Starting with a base recipe they like and making small tweaks? Optimizing for their own taste preferences vs the tastes of the people they share it with? Etc.
Even if their hobby isn't collecting Github stars, you can still learn a bit about their mindset. Plus I've found that getting someone to talk about something they're passionate about for 5 minutes is a good icebreaker to start an interview.
[+] [-] Longlius|3 years ago|reply
1) When the person who wrote the code is no longer available to talk to. Having even a 5-10 minute chat can massively speed up my comprehension of someone else's code and save a lot of time.
2) Unused code that hasn't been deleted. I think everyone should strive to clean up their codebases. I'm not exactly blame-free here either so it's something I try to apply more and more as the codebases I work on start staying around for longer.
[+] [-] Alex3917|3 years ago|reply
In contrast, the places that have done tech interviews have generally been awful to work at. Less intelligent people, less interesting work, worse management, etc.
[+] [-] Roark66|3 years ago|reply
Personally I never had a problem with it and from the interviewer point of view it helps lighten the atmosphere a bit talking about out of work stuff.
[+] [-] dylan604|3 years ago|reply
I've been to work for companies that say anything you build while employed at company belongs to them unless you go through the proper channels and layers of red tape to discuss the projects with them to ensure that anything you are working on does not involve any company IP. This could sound like baiting for a different direction than the other comments are alluding.
[+] [-] catiopatio|3 years ago|reply
My time outside of work and what I do for fun isn’t your concern, and I don’t want to share those details with you.
[+] [-] tmaly|3 years ago|reply
Maybe your first question might work to get more at that idea.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] AlbertCory|3 years ago|reply
Actually, I loved it. You might not be able to imagine this, but I actually like lawyers, as a rule.
Since Google insists on giving candidates a problem, I took a patent from a previous job that I was familiar with, and said, "OK, we're going to pretend I'm the inventor, and I'm going to describe this invention to you. Your job will be to write the first claim."
This is pretty similar to their actual job, at least on the patent prosecution side. They have to come up to speed on an unfamiliar technology quickly? Well, that's what patent lawyers do. Most of them did pretty well on the test, too. It was way fun.
Unlike in a SWE interview, I never heard anything after I gave my feedback (with a SWE, you would see what the other interviewers said). The only way I even heard if they were hired was to check a few months later. I didn't know if Legal even paid attention to me.
Years later, I joined Legal and found out they'd been hanging on my every word.
[+] [-] janosdebugs|3 years ago|reply
[+] [-] seti0Cha|3 years ago|reply
Of course you shouldn't humiliate the candidate, that's never the right thing to do. But there's a huge gap between maintaining a high hiring standard and believing that "everyone else looking for a job is an idiot, and our job is to expose them, to teach them a lesson, to humiliate them till they quit." The bulk of the advice in this article is fine, but the hyperbole is just plain annoying.
Also, seeing people site the no asshole rule is a warning sign for me. I worked at a place that constantly mentioned that, and let's just say it was clearly ineffective. Assholes rarely think that they are the asshole and are perfectly comfortable citing that principle.
[+] [-] zitterbewegung|3 years ago|reply
[+] [-] mjr00|3 years ago|reply
Once you do enough interviews, you realize this isn't a myth. Okay, maybe most is too strong of a qualifier. But the reality is that a title of Senior Software Engineer doesn't imply the ability to translate human problems into machine-executable code in a structured way. It's very possible that a "Senior Software Engineer" has been working at a small consultancy on the same project for 5+ years, has few if any technical teammates, and spends most of their time copy and pasting StackOverflow answers and doing "guess and check" programming to do bug fixes for a legacy VB6 or FoxPro app. I'd know, as I've worked with those people.
That being said...
> The interviewer asked me a very basic question– something small like how to create a table(or something silly like that).
If you're asking syntax questions in an interview, you've already lost. For technical interviews, the thought process is far more important than the end result. Again, programming is the act of turning human problems into machine code in a structured, repeatable way. Pseudocode is sufficient for this. Forget whether you should be using `sort` or `sorted` in python? Me too, so just tell me what you expect the sort method to do and move on.
So yes, asking for the SQL create table syntax in an interview is absurd and the author is right to complain here.
> Actually talk about their fucking resume... You can easily filter out people who just coasted along vs those who accomplished something.
Sorry, but you cannot. Some people are excellent at bullshitting and making themselves sound like incredible workers, especially if they've had time to prepare. You'll hear amazing stories of late nights and heroic effort, but they were often done by other people and merely observed by the interviewee, or just fabrications.
[+] [-] pokstad|3 years ago|reply
[+] [-] Alex3917|3 years ago|reply
All the most advanced computer science research areas right now basically come down to guess and check. E.g. AI, ML, NLP, etc. The folks behind spaCy have a good talk somewhere explaining that this is the reason why there isn't more academic funding things like NER, despite the fact that it's an insanely valuable problem.
But regardless, the best programmers you know probably spend most of their week doing guess and check.
[+] [-] hprotagonist|3 years ago|reply
despite the fact that the specific problem has been memed to death, i can still reliably wash out 70% or so of the interview cohort i’ve interviewed by fizzbuzzing.
it’s shocking every time.
[+] [-] fishtoaster|3 years ago|reply
1. A couple years out of college, I went back to my alma matter to recruit interns. I stood at a booth at a job fair and chatted with people. Anyone who seemed interesting I invited for a 30-minute interview the next day (9 people). The next day I had all 9 people do fizzbuzz on paper (I know, I know, I was young!) - every single one passed easily and it filtered out no one.
2. More recently, I was recruiting off of workatastartup.com for senior devs. I went through a few dozen first-round interviews and didn't once come across someone who couldn't code.
3. More recently still, I was working with some recruiters who would send resumes my way. I was looking for a specific combo of two common techs and I started out giving a first-round interview to anyone who listed any experience with both. I found that something like 60-80% of these candidates would *not* have, (in my opinion), been able to code fizzbuzz.
It was interesting because, until #3, I'd never really believed the "most people cannot program" thing - at least not after my experience with #1. The lesson I took was that it totally depends on your pipeline. If you put a job listing on Indeed.com or whatever, you'll get a lot of people who cannot program. If you use other channels or do any other form of screening (implicit or not), you may get almost none.
[+] [-] lampshades|3 years ago|reply
I had one candidate take the entire first half of the interview to solve it, and I guided him very strongly the entire time. By the time he was half way through, he had so much sweat pouring from his face he looked like he was running a marathon. It was very awkward and uncomfortable for me.
Like fishtoaster’s #3 above, these candidates came through recruiters where we specified the technologies we wanted.
[+] [-] GloriousKoji|3 years ago|reply
And I would roughly say 70% are stunned because they don't know what to do. The remaining 30% are shocked by how ridiculously trivial the question is.
[+] [-] onion2k|3 years ago|reply
[+] [-] twblalock|3 years ago|reply
[+] [-] ctrwu2843|3 years ago|reply
My approach is to try and make the candidate feel relaxed, as I want them to show their best self in an already stressful situation. Following this it's about giving them the opportunity to demonstrate their skills.
If you go into an interview with a combative mindset of "filtering out the lemons" and then complain how hard it is to hire good people, you really ought to take a long hard look in the mirror.
[+] [-] xyzelement|3 years ago|reply
1. Both parties hope it's a match but of course worry about making the wrong choice. Think: the interview wants me to do well, I need to help them say yes to me.
2. Programming ability is a necessary but not sufficient skill for a real programming job. How you are on call, how you are with brainstorming, how you are hashing through requirements, how you are when you make a mistake, how you are when you are being coached - all matter and the programming interview is generally structured to get signal on those things.
I think most people who make themselves crazy / hate interviews / are befuddled - it's because they don't see this.
[+] [-] brg|3 years ago|reply
[+] [-] badrabbit|3 years ago|reply
It was horrible. Never want to be the reason someone didn't get a job again lol.
[+] [-] Psychlist|3 years ago|reply
The bit at the end about trying to discover what candidates are good at and see them actually working... I'm shocked that so few interviews actually do that. I get that it's hard in tiny companies where you have one vaguely technical person who realises they're out of their depth and is hiring to fill that gap. Everyone else has no excuse for lousy evaluation of technical skills.
[+] [-] keeptrying|3 years ago|reply
This means when they ask him for feedback he'll say "Oh he was okay. Not very technical"
To solve for this guy, you need to have some very good questions about technical problems the company may be facing and then you need to be able to have insights on how they might solve this.
You essentially have to structure the interview for them. Give them the questions and then you answer and then you have to impress.
The aim should always be to impress and be liked unless you have someone who is out to prove you wrong. With those types you need to show technical superiority in addition. These types are usually small in number though.
[+] [-] patmcc|3 years ago|reply
This is really big; we've been using the same basic "is this person a big phony" set of questions for a long time, and it immediately filters out people who just have no knowledge. Stuff like what is a Boolean variable, what is ssh, what is asymmetric encryption, name 3 hardware components of a server, what is a primary key, etc. I've seen people with resumes full of tech jobs that fail at all of these. And I don't mean slightly off, I mean no clue at all. We don't require a perfect score or anything, and recognize language barriers, but it becomes super clear super quickly when someone is just bullshitting.
[+] [-] vouaobrasil|3 years ago|reply
[+] [-] MilStdJunkie|3 years ago|reply
However . .
When prospective associates are responding to these sorts of questions, it's possibly more informative to see how they handle questions that they don't know the answer to.
Native intelligence and initiative outweigh a set quantity of specialized knowledge; far more important to find out how a prospect thinks about the problem and how they respond to these situations under pressure.
Problem here is that the interviewers need to know their stuff, and, regretfully, that's not been the case for virtually any interview board I've assisted. All the participants were far, far too high above the levels where work happened, well into the vertiginous expanse of Aero/Def Management Brain Rot. Best I could do was wave my hands vigorously while silently mouthing the words HE DOESN'T KNOW WHAT WHITESPACE MEANS . . to no avail.
Thing is, I know it's not just my industry. It happens in the "normal" world too. Some guy makes a thingy with Framework X, leaves, and then it's practically impossible for management to find another random guy who knows Framework X in just the same way, because damned if management knows what the heck Framework X is.
[+] [-] CnRiAggZeYr|3 years ago|reply
[deleted]
[+] [-] janosdebugs|3 years ago|reply
[+] [-] seti0Cha|3 years ago|reply
[+] [-] hallway_monitor|3 years ago|reply
[+] [-] ern0|3 years ago|reply
1. I admit I am nervous so much that I just couldn't tell my own name.
2. It's just strange for first look that I don't remember, but we create tables so rarely, that it's not a surprise.
3. Okay, let's try to figure out the command, my first hint is that it should be "new", "create" or something. Let's recall, how to deal other way, say, delete or modify tables: "drop table", "alter table" - so my best hint is "create table" or "new table". (Offensive notice: if you learnt SQL one day before the interview, this gonna not work.)
Great, go on, it's pretty sure it should contain the list of fields, define them: names, types, and some constraints, whether it can be empty etc. Maybe this command defines the indexes as well, then every index should declare one or more fields, ascending/descending marks per field. Oh, a table unique key is also can be specified, at the field specification. Finally I notice, that different SQL servers may have different syntax and even features, like choosing storage system for the table (MySQL: InnoDB etc.).
That's the _content_ of the SQL's create table command, withot any syntax. I think, it's clear, that I would have no problem with writing a table creating SQL statement.
If you can not solve the "I-forget-the-syntax" problem, probably (another offensive statement, sorry) you're not for this job. In real life, you will have even more stressful situations, and you have to solve them, or at least DO SOMETHING. What you've done was NOTHING.
[+] [-] rednerrus|3 years ago|reply
Depending on what your needs are, you may need to do a technical interview. Do the same thing with the technical interview, figure out your needs then write your questions. Have a similar group of people doing the situational interviews do the technical interview, preferably the people the candidate is going to work with. Find a way to make it collaborative if you can. Seeing how a candidate works with other people is nearly as valuable as seeing how technically proficient a candidate is.
That's it.
[+] [-] lp4vn|3 years ago|reply
I have no problem solving exercises in interviews as long as we're talking about one session of at most one hour. I was contacted by recruiters of companies that expected me to go through many rounds of interviews that would span many weeks. lol
I always reply that I'm already employed, that for me their company is just like any other company and that working for them is not a privilege, it's just a job.
[+] [-] pokstad|3 years ago|reply
[+] [-] kitsunesoba|3 years ago|reply
[+] [-] imiric|3 years ago|reply
We set up all these artificial handicaps and are then surprised people do badly in interviews. Just let them code using their own machine and IDE, and any other tool they need.
I wonder if you'll also scoff when people start asking for Copilot or GPT.
[+] [-] mtizim|3 years ago|reply
Also, grug hit dot on keyboard and list of things grug can do pop up magic
[+] [-] icedchai|3 years ago|reply
[+] [-] Garlef|3 years ago|reply