8 ms·

Programming interviews turn normal people into a-holes

100 points by whack 4y ago

vouaobrasil 4y ago
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.
- rco8786 4y ago
  To offer a counterpoint, you can also say it’s testing for people who are willing to do the work to get the task at hand done, and filter out people who say “well I could do that I just choose not to”.
- gopalv 4y ago
  > They are testing for the kind of person that is willing to jump through hoops. That's true, but it is meant as a different filter when applied to a large number of candidates. I went through a bunch of leetcode style interviews last year with some very odd interviewers - the oddest was a Sr Principal engineer asking me to manipulate linked lists with recursion. And the comment he made after I wrote the code was that "We don't care if you write code at work, but we want to know you like writing code enough to not see it as beneath you to do. To make sure you're not some whiteboard architect, because everyone you are supposed to lead will be writing code." I had been looking at the interview as a sort of idiot catcher before that point, but suddenly it seemed like a good filter for respecting the effort at the lowest level of the profession.
- hervature 4y ago
  I see this meme a lot and don't think it is a useful framing of what is going on. I'm sure there is one company out there, but I'm willing to bet that none of the companies that matter have actively sat down and a group of people decided to have programming questions explicitly to find people "willing to jump through hoops". Clearly, there are much better ways to test for that specific trait. Including actually asking them to jump through a hoop. I'm not debating that it is a welcomed side-effect that only fails in rare cases like the brew developer at Google. Mostly, I think this is just the result of companies looking to satisfy mainly three competing tasks. One, how do we assess someone can code. Two, making a standardized interviewing approach that many different people can perform. Three, doing it all in a time/resource efficient manner. Obviously code reviews satisfies the first but present very serious reproducibility and time requirement issues. I posit that programming leetcode style questions is the solution that most companies think balances the three. It feels bad as the interviewee because it is a fairly specific skill of programming that you need to practice and you cannot opt for another method to better illustrate your ability.
- seti0Cha 4y ago
  What makes you say that? I've been involved in a lot of hiring processes, and I would say that is nearly the opposite of their intent. Don't attribute to malice that which is adequately explained by incompetence.
  - vouaobrasil 4y ago
    I don't think it's malice. I think it's just an emergent property of the process. Large tech companies want people who will be a cog in their machine, it's as simple as that.
    - seti0Cha 4y ago
      Oh, I see, you're talking about the FAANG sort, where people do tons of prep before applying. I guess I could see that.
      - vouaobrasil 4y ago
        Yeah, for what it's worth, I went through some programming interviews at smaller places. And then it was much more normal, not leet-code.
- disambiguation 4y ago
  You're giving it too much credit. Google invented this interview style 2 decades ago basically as an intelligence test, and it's been the status quo ever since. That's all there is to it.
twblalock 4y ago
If someone acts like an asshole when they are given power over others, they were an asshole to begin with. You just didn't notice.
xyzelement 4y ago
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.
- ajmurmann 4y ago
  Interesting take. Somehow I feel confident and positive about all the things you call out, but struggle with the idea and situation of doing artificial coding puzzles while someone is watching, but judging instead of helping like a pair would. I enjoy doing coding puzzles for fun, but not while being watched and judged and a clock is ticking.
  - xyzelement 4y ago
    // doing artificial coding puzzles while someone is watching, but judging instead of helping Look it's definitely an interview and you're being evaluated but good interviewers help you a lot - eg hint when you're over or under thinking something, ask about edge cases you neglected, etc. If you think of the interview as adversarial you probably miss all of that. . // coding puzzles for fun, but not while being watched and judged and a clock is ticking. Have you ever troubleshooted a production issue with millions of dollars at stake every few minutes of down time? Lots of eyes on you and time pressure. Like I said, the interview gives signal. Remember, nobody is at their best in there situations. The interviewers aren't expecting perfection, they are expecting reasonable performance given the situation. They are usually calibrated on dozens or hundreds of other interviews.
    - sarchertech 4y ago
      There are very few systems that will actually lose a company millions of dollars every few minutes of downtime. I have done high stakes production troubleshooting many times. It’s not remotely the same as an interview—not even in the same ballpark. Everyone of those eyes wants you to succeed and will help you in any way they can. And if they aren’t being helpful, I politely tell them I’ll solve it faster if I can focus without people looking over my shoulder. The fake adversarial system created by coding interviews is why I prefer pair programming with a candidate on a novel problem.
RajT88 4y ago
Interviews in general turn people into assholes. Myself I am guilty of freaking out a candidate because I had just rolled off a huge escalation, heart racing and firing on all cylinders. Nervous, talking fast, etc. I will try some Gotcha type questions to use as shorthand for how deep they are in certain areas. Even if someone whiffs one of those I am still likely to recommend them if everything else was good. No biggie. If there is time I will explain the answer to see how they digest it. I am not trying to be an asshole. But in comparison I know a guy who won't hire someone if he doesn't like their shoes. He's an asshole outside of interviews though.
- ipaddr 4y ago
  Your not an asshole like your friend. But it sounds like you are not an A player hiring other A players. What you are doing is going to net you a C or worse. Put yourself in an A players shoes. Your trivia on the spot question shows you value unimportant things. A players can see talent in small signals and can map out a candidates profile you are trying to filter candidates by nonsense that doesn't map to the job. That leads to random results. Hiring is an important management responsibility that most developers should not be involved with unless they are part of the management track hopefully with some training
  - mjr00 4y ago
    > Hiring is an important management responsibility that most developers should not be involved with unless they are part of the management track Absolutely, this is what it boils down to. After a certain point (like 15-20 engineers or so) you need someone in management to actually come up with an interview plan. Letting developers just wing interviews and ask trivia questions is a sign of an immature organization and is a big red flag for anyone senior coming in.
  - RajT88 4y ago
    You'd be right if my role was a dev. (It isn't, and so you are not)
    - 4y ago
mjr00 4y ago
> The Idiotic "Most People Cannot Program" Myth 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 4y ago
  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.
- Alex3917 4y ago
  > "guess and check" programming 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.
janosdebugs 4y ago
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.
- hallway_monitor 4y ago
  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.
  - higeorge13 4y ago
    This. I ask people to explain in 5 min a technical achievement/contribution they are really proud of, and it’s been crazy to see people who mention all the buzzwords in their cv to not be able to explain anything or dive into the slightest details. People bs-ing in their cvs about their actual experience is one of the factors interview process has become like this.
  - janosdebugs 4y ago
    A not insignificant portion of people I meet in IT are freeriders. They just jump on any project that has a high visibility and do minimal, shoddy work on it just to be involved. Quite often these people then also hold fairly high titles in the corporate structure. Some people even manage to transscend companies with this by working on public-facing projects. However, a lot of them will have real problems when switching companies and being faced with a real technical interview as they are severely lacking in technical depth. Ask them about anything deeper than a manager's understanding of the topic and they will waffle on without answering the question. "What security measures did you take in your code?" - is a good question, followed up by a more specific "how did you prevent injection attacks when you did X?" (YMMV). Usually these candidates have no clue what that even is, compared to someone who actually had to deal with the nasty bits of the job the project hoppers can't be asked to deal with.
hprotagonist 4y ago
> The Idiotic "Most People Cannot Program" Myth 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.
- scruple 4y ago
  Yeah, I've seen it, too. It's terrifying. Some of the candidates I've rejected over the years have verifiable years of experience yet can't actually produce very, very basic working code.
  - giaour 4y ago
    What's more likely: that they managed to fool their boss and colleagues for years only to be found out by you, a complete stranger, in a 45 minute interview? Or that they were nervous, made a small mistake, and then panicked/ froze up?
    - icelancer 4y ago
      My first reaction despite how you worded it was that the former is far more believable in my experience, but I think it's pretty close either way.
    - andromeduck 4y ago
      I've seen some people who appear only capable of adding to or changeing existing logic - essentially relying on mimickry. They have a strong tendency to rely on hardcoding, sometimes pasting one loop 5x instead of just adding an outer loop. It's absolutely wild.
    - scruple 4y ago
      I've worked with these people "on the inside." My belief is that, yes, some of them do fake their way in and manage to hang on for a shockingly long time. I also agree that some of them panic from the induced stress of interviewing. I try to keep my interviews very cordial, I've been there before, too, so I'm sympathetic, and I also suffer from horrible imposter syndrome, because I am a CS college dropout, despite the fact that I've had a wonderful career with dozens of major victories over the last 16+ years. I really do get it. Despite that people who cannot program find their way in front of me, interviewing for Senior+ roles. A recent example is a Senior Software Engineer new hire (I did not interview this person) who was tasked with moving a git repository to a new upstream as part of a larger migration in the engineering org. This person proceeded to try write a sprawling bash script to handle the process in order to "preserve history." Clearly this individual doesn't understand git at all. The script wasn't even doing anything. Their other tasks, which were application development tasks, demonstrated code that was also somewhere around an intern/associate level. I left that role very shortly after because when I brought this to my management team it was made clear to me that what we needed was warm bodies. That person is still employed by my former employer, over 9 months later, making a 6-figure salary with an annual performance bonus and stock grants.
ctrwu2843 4y ago
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.
seti0Cha 4y ago
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.
- zitterbewegung 4y ago
  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.
Psychlist 4y ago
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.
kitanata 4y ago
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.
- Ancalagon 4y ago
  I like questions 2 and 3 but question 1 seems like a subtle dig at the candidate to see if they spend most of their time outside of work coding.
  - dqh 4y ago
    For the same level of commercial experience, someone who spends most of their time outside work coding has more experience coding than someone who doesn't, and they probably love it. I think these things are worth knowing about a candidate when hiring?
pokstad 4y ago
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.
- Garlef 4y ago
  When was the last time you professionally coded on a whiteboard with no google or compiler feedback?
  - pokstad 4y ago
    In the old days (before covid) that was the norm. You’d write real or pseudo code on a whiteboard.
- kitsunesoba 4y ago
  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.
- mtizim 4y ago
  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
  - XorNot 4y ago
    Also a decently designed API should work with autocomplete to help you use it.
  - 4y ago
rednerrus 4y ago
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. That's it.
throwaway675309 4y ago
I'm not sure what it was but I really disliked the style of this article. I felt like it was very light on actual examples. It would've been much more engaging if they had provided specific details on each of the mistakes that they, as an interviewer, had made. As an interviewer, I prefer to give potential applicants a softball, like writing a function that computes the nth digit of PI in O(1).
- 4RealFreedom 4y ago
  import math print( math.pi )
deleted 4y ago
[deleted]
patmcc 4y ago
>>>Decide beforehand what questions you will ask 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.
- Psychlist 4y ago
  We used to call it the elevator test: can a candidate navigate the elevator and make it to the interview. Partly because we got ghosted a few times, but mostly for the number of interviews where we'd sit candidates in front of a PC, show them some code in the language we were advertising for, and say "add a trivial function". Make a button show some text level. The failure rate was a bit terrifying for "2-5 years experience with X" programmers. I stopped bothering with questions before that point, I'd read their application, look at their resume, then get them in to play with a computer. The good news is that it actually found the people we needed, the bad news is we never found an effective way to pre-filter the ones who couldn't (and even a couple who said "I've never seen this before" when looking at the code!!)
keeptrying 4y ago
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.
- drewcoo 4y ago
  I love the open-ended hypothetical questions that have to reframe into behavioral questions so that I can show what similar things I've actually accomplished in the past.
andsoitis 4y ago
I don’t know. If you’re a jerk, you’re a jerk.
lp4vn 4y ago
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.
AlbertCory 4y ago
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.
- janosdebugs 4y ago
  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.
  - AlbertCory 4y ago
    The best thing was, I had a specific job: "find out if an engineer can get along with this person?" Whether they were good lawyers or not was someone else's question to answer.
_8j50 4y ago
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.
Roark66 4y ago
I never had the misfortune to encounter such interviewing techniques nor had to use them on others. This is in two Fortune 500 companies and few smaller businesses. Perhaps because I always interviewed for "full stack" jobs where the knowledge of tiny details this very moment is a lot less important than the ability to understand systems as a whole and how those little things fit together. On the hiring end before it came to me being directly involved the candidate would already have gone through the basic "test" I and my colleagues prepared. It was a series of "question" "answer" sets starting with really simple and increasing in difficulty we gave to our manager. He would do the first part of the interview with a candidate and to fail, one would have to really have no clue. It was really surprising that 90% of candidates, with really good resumes we got sent by recruitment agencies failed that. It is important to stress those were not questions of the sort "implement some algorithm in pseudo language", but more like, "explain what is a microservice", "what is redis and when you would use it(assuming they have it in their cv)" etc. They were simple questions. I had similar questions on every single interview asked of me when I was a candidate (except the very first one when I was asked to fix an actual issue, but by then I was almost hired). Then once they passed this initial step they would sit down with us(hopefully their future coworkers) and we would talk to them about their resume, ask what they worked at in previous jobs, what problems they resolved and how etc. This allowed me and my coworkers doing that part of the interview to very quickly get an idea if the person we're interviewing is on "our level" or not. Perhaps it was helpful that we interviewed people for both senior and junior positions so someone with less experience, but demonstrating ability/willingness to learn could still be a good match. At the end, if our manager was happy with what he heard he would ask us for our opinion. And I have to say, despite this easy-going interview method it took us over a year to find a good candidate for one senior role we were hiring for. During this year we had only 5 or 6 people progress to the second stage and we had a new stack of CVs to go through every 2 weeks or so. We did get 3 people for junior roles at the same time. So is it true "most people interviewing have no clue"? I'll respond to this by saying it depends which recruiter has sent them. I have had recruiters admit to me they "tweak" CVs on more than one occasion. Also, yes, there are lots of people applying for jobs way above their skill level. Hiring is not easy. That's why good recruiters make more money than developers they recruit (I know a recruiter making £50k monthly in commission).
MilStdJunkie 4y ago
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.
- CnRiAggZeYr 4y ago
  [dead]
disambiguation 4y ago
Any system run by humans is by definition flawed. But the tech industry interview process is such low hanging fruit for mocking, I don't think this article is anything more than meme-ing a trendy topic for clicks. If we really want to evolve into something better, then here's what I propose: All employers must release their laptop surveillance data to the public domain for all the see. That way we can objectively compare who writes the most LoC and logs the most onscreen hours.
brg 4y ago
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.
readonthegoapp 4y ago
Good take I'd talk a bit more about power, generally, and what it does to people but this is good
marstall 4y ago
my technique: me: [scans resume] ... "tell me about project y here" interviewee: [tells me a bit] me: [ask questions, listen, drill down, listen, get gently more and more technical, back off if I hit a soft spot and find another place to drill down] repeat, repeat. I find its a good way to determine the candidate's strengths - versus freaking them out with a gotcha that's irrelevant to their skillset.
ern0 4y ago
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.

100 points by whack 4y ago

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.

rco8786 4y ago
To offer a counterpoint, you can also say it’s testing for people who are willing to do the work to get the task at hand done, and filter out people who say “well I could do that I just choose not to”.
gopalv 4y ago
> They are testing for the kind of person that is willing to jump through hoops. That's true, but it is meant as a different filter when applied to a large number of candidates. I went through a bunch of leetcode style interviews last year with some very odd interviewers - the oddest was a Sr Principal engineer asking me to manipulate linked lists with recursion. And the comment he made after I wrote the code was that "We don't care if you write code at work, but we want to know you like writing code enough to not see it as beneath you to do. To make sure you're not some whiteboard architect, because everyone you are supposed to lead will be writing code." I had been looking at the interview as a sort of idiot catcher before that point, but suddenly it seemed like a good filter for respecting the effort at the lowest level of the profession.
hervature 4y ago
I see this meme a lot and don't think it is a useful framing of what is going on. I'm sure there is one company out there, but I'm willing to bet that none of the companies that matter have actively sat down and a group of people decided to have programming questions explicitly to find people "willing to jump through hoops". Clearly, there are much better ways to test for that specific trait. Including actually asking them to jump through a hoop. I'm not debating that it is a welcomed side-effect that only fails in rare cases like the brew developer at Google. Mostly, I think this is just the result of companies looking to satisfy mainly three competing tasks. One, how do we assess someone can code. Two, making a standardized interviewing approach that many different people can perform. Three, doing it all in a time/resource efficient manner. Obviously code reviews satisfies the first but present very serious reproducibility and time requirement issues. I posit that programming leetcode style questions is the solution that most companies think balances the three. It feels bad as the interviewee because it is a fairly specific skill of programming that you need to practice and you cannot opt for another method to better illustrate your ability.
seti0Cha 4y ago
What makes you say that? I've been involved in a lot of hiring processes, and I would say that is nearly the opposite of their intent. Don't attribute to malice that which is adequately explained by incompetence.
- vouaobrasil 4y ago
  I don't think it's malice. I think it's just an emergent property of the process. Large tech companies want people who will be a cog in their machine, it's as simple as that.
  - seti0Cha 4y ago
    Oh, I see, you're talking about the FAANG sort, where people do tons of prep before applying. I guess I could see that.
    - vouaobrasil 4y ago
      Yeah, for what it's worth, I went through some programming interviews at smaller places. And then it was much more normal, not leet-code.
disambiguation 4y ago
You're giving it too much credit. Google invented this interview style 2 decades ago basically as an intelligence test, and it's been the status quo ever since. That's all there is to it.

twblalock 4y ago

If someone acts like an asshole when they are given power over others, they were an asshole to begin with. You just didn't notice.

xyzelement 4y ago

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.

ajmurmann 4y ago
Interesting take. Somehow I feel confident and positive about all the things you call out, but struggle with the idea and situation of doing artificial coding puzzles while someone is watching, but judging instead of helping like a pair would. I enjoy doing coding puzzles for fun, but not while being watched and judged and a clock is ticking.
- xyzelement 4y ago
  // doing artificial coding puzzles while someone is watching, but judging instead of helping Look it's definitely an interview and you're being evaluated but good interviewers help you a lot - eg hint when you're over or under thinking something, ask about edge cases you neglected, etc. If you think of the interview as adversarial you probably miss all of that. . // coding puzzles for fun, but not while being watched and judged and a clock is ticking. Have you ever troubleshooted a production issue with millions of dollars at stake every few minutes of down time? Lots of eyes on you and time pressure. Like I said, the interview gives signal. Remember, nobody is at their best in there situations. The interviewers aren't expecting perfection, they are expecting reasonable performance given the situation. They are usually calibrated on dozens or hundreds of other interviews.
  - sarchertech 4y ago
    There are very few systems that will actually lose a company millions of dollars every few minutes of downtime. I have done high stakes production troubleshooting many times. It’s not remotely the same as an interview—not even in the same ballpark. Everyone of those eyes wants you to succeed and will help you in any way they can. And if they aren’t being helpful, I politely tell them I’ll solve it faster if I can focus without people looking over my shoulder. The fake adversarial system created by coding interviews is why I prefer pair programming with a candidate on a novel problem.

RajT88 4y ago

Interviews in general turn people into assholes. Myself I am guilty of freaking out a candidate because I had just rolled off a huge escalation, heart racing and firing on all cylinders. Nervous, talking fast, etc. I will try some Gotcha type questions to use as shorthand for how deep they are in certain areas. Even if someone whiffs one of those I am still likely to recommend them if everything else was good. No biggie. If there is time I will explain the answer to see how they digest it. I am not trying to be an asshole. But in comparison I know a guy who won't hire someone if he doesn't like their shoes. He's an asshole outside of interviews though.

ipaddr 4y ago
Your not an asshole like your friend. But it sounds like you are not an A player hiring other A players. What you are doing is going to net you a C or worse. Put yourself in an A players shoes. Your trivia on the spot question shows you value unimportant things. A players can see talent in small signals and can map out a candidates profile you are trying to filter candidates by nonsense that doesn't map to the job. That leads to random results. Hiring is an important management responsibility that most developers should not be involved with unless they are part of the management track hopefully with some training
- mjr00 4y ago
  > Hiring is an important management responsibility that most developers should not be involved with unless they are part of the management track Absolutely, this is what it boils down to. After a certain point (like 15-20 engineers or so) you need someone in management to actually come up with an interview plan. Letting developers just wing interviews and ask trivia questions is a sign of an immature organization and is a big red flag for anyone senior coming in.
- RajT88 4y ago
  You'd be right if my role was a dev. (It isn't, and so you are not)
  - 4y ago

mjr00 4y ago

> The Idiotic "Most People Cannot Program" Myth 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 4y ago
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.
Alex3917 4y ago
> "guess and check" programming 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.

janosdebugs 4y ago

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.

hallway_monitor 4y ago
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.
- higeorge13 4y ago
  This. I ask people to explain in 5 min a technical achievement/contribution they are really proud of, and it’s been crazy to see people who mention all the buzzwords in their cv to not be able to explain anything or dive into the slightest details. People bs-ing in their cvs about their actual experience is one of the factors interview process has become like this.
- janosdebugs 4y ago
  A not insignificant portion of people I meet in IT are freeriders. They just jump on any project that has a high visibility and do minimal, shoddy work on it just to be involved. Quite often these people then also hold fairly high titles in the corporate structure. Some people even manage to transscend companies with this by working on public-facing projects. However, a lot of them will have real problems when switching companies and being faced with a real technical interview as they are severely lacking in technical depth. Ask them about anything deeper than a manager's understanding of the topic and they will waffle on without answering the question. "What security measures did you take in your code?" - is a good question, followed up by a more specific "how did you prevent injection attacks when you did X?" (YMMV). Usually these candidates have no clue what that even is, compared to someone who actually had to deal with the nasty bits of the job the project hoppers can't be asked to deal with.

hprotagonist 4y ago

> The Idiotic "Most People Cannot Program" Myth 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.

scruple 4y ago
Yeah, I've seen it, too. It's terrifying. Some of the candidates I've rejected over the years have verifiable years of experience yet can't actually produce very, very basic working code.
- giaour 4y ago
  What's more likely: that they managed to fool their boss and colleagues for years only to be found out by you, a complete stranger, in a 45 minute interview? Or that they were nervous, made a small mistake, and then panicked/ froze up?
  - icelancer 4y ago
    My first reaction despite how you worded it was that the former is far more believable in my experience, but I think it's pretty close either way.
  - andromeduck 4y ago
    I've seen some people who appear only capable of adding to or changeing existing logic - essentially relying on mimickry. They have a strong tendency to rely on hardcoding, sometimes pasting one loop 5x instead of just adding an outer loop. It's absolutely wild.
  - scruple 4y ago
    I've worked with these people "on the inside." My belief is that, yes, some of them do fake their way in and manage to hang on for a shockingly long time. I also agree that some of them panic from the induced stress of interviewing. I try to keep my interviews very cordial, I've been there before, too, so I'm sympathetic, and I also suffer from horrible imposter syndrome, because I am a CS college dropout, despite the fact that I've had a wonderful career with dozens of major victories over the last 16+ years. I really do get it. Despite that people who cannot program find their way in front of me, interviewing for Senior+ roles. A recent example is a Senior Software Engineer new hire (I did not interview this person) who was tasked with moving a git repository to a new upstream as part of a larger migration in the engineering org. This person proceeded to try write a sprawling bash script to handle the process in order to "preserve history." Clearly this individual doesn't understand git at all. The script wasn't even doing anything. Their other tasks, which were application development tasks, demonstrated code that was also somewhere around an intern/associate level. I left that role very shortly after because when I brought this to my management team it was made clear to me that what we needed was warm bodies. That person is still employed by my former employer, over 9 months later, making a 6-figure salary with an annual performance bonus and stock grants.

ctrwu2843 4y ago

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.

seti0Cha 4y ago

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.

zitterbewegung 4y ago
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.

Psychlist 4y ago

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.

kitanata 4y ago

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.

Ancalagon 4y ago
I like questions 2 and 3 but question 1 seems like a subtle dig at the candidate to see if they spend most of their time outside of work coding.
- dqh 4y ago
  For the same level of commercial experience, someone who spends most of their time outside work coding has more experience coding than someone who doesn't, and they probably love it. I think these things are worth knowing about a candidate when hiring?

pokstad 4y ago

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.

Garlef 4y ago
When was the last time you professionally coded on a whiteboard with no google or compiler feedback?
- pokstad 4y ago
  In the old days (before covid) that was the norm. You’d write real or pseudo code on a whiteboard.
kitsunesoba 4y ago
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.
mtizim 4y ago
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
- XorNot 4y ago
  Also a decently designed API should work with autocomplete to help you use it.
- 4y ago

rednerrus 4y ago

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. That's it.

throwaway675309 4y ago

I'm not sure what it was but I really disliked the style of this article. I felt like it was very light on actual examples. It would've been much more engaging if they had provided specific details on each of the mistakes that they, as an interviewer, had made. As an interviewer, I prefer to give potential applicants a softball, like writing a function that computes the nth digit of PI in O(1).

4RealFreedom 4y ago
import math print( math.pi )

deleted 4y ago

[deleted]

patmcc 4y ago

>>>Decide beforehand what questions you will ask 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.

Psychlist 4y ago
We used to call it the elevator test: can a candidate navigate the elevator and make it to the interview. Partly because we got ghosted a few times, but mostly for the number of interviews where we'd sit candidates in front of a PC, show them some code in the language we were advertising for, and say "add a trivial function". Make a button show some text level. The failure rate was a bit terrifying for "2-5 years experience with X" programmers. I stopped bothering with questions before that point, I'd read their application, look at their resume, then get them in to play with a computer. The good news is that it actually found the people we needed, the bad news is we never found an effective way to pre-filter the ones who couldn't (and even a couple who said "I've never seen this before" when looking at the code!!)

keeptrying 4y ago

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.

drewcoo 4y ago
I love the open-ended hypothetical questions that have to reframe into behavioral questions so that I can show what similar things I've actually accomplished in the past.

andsoitis 4y ago

I don’t know. If you’re a jerk, you’re a jerk.

lp4vn 4y ago

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.

AlbertCory 4y ago

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.

janosdebugs 4y ago
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.
- AlbertCory 4y ago
  The best thing was, I had a specific job: "find out if an engineer can get along with this person?" Whether they were good lawyers or not was someone else's question to answer.

_8j50 4y ago

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.

Roark66 4y ago

I never had the misfortune to encounter such interviewing techniques nor had to use them on others. This is in two Fortune 500 companies and few smaller businesses. Perhaps because I always interviewed for "full stack" jobs where the knowledge of tiny details this very moment is a lot less important than the ability to understand systems as a whole and how those little things fit together. On the hiring end before it came to me being directly involved the candidate would already have gone through the basic "test" I and my colleagues prepared. It was a series of "question" "answer" sets starting with really simple and increasing in difficulty we gave to our manager. He would do the first part of the interview with a candidate and to fail, one would have to really have no clue. It was really surprising that 90% of candidates, with really good resumes we got sent by recruitment agencies failed that. It is important to stress those were not questions of the sort "implement some algorithm in pseudo language", but more like, "explain what is a microservice", "what is redis and when you would use it(assuming they have it in their cv)" etc. They were simple questions. I had similar questions on every single interview asked of me when I was a candidate (except the very first one when I was asked to fix an actual issue, but by then I was almost hired). Then once they passed this initial step they would sit down with us(hopefully their future coworkers) and we would talk to them about their resume, ask what they worked at in previous jobs, what problems they resolved and how etc. This allowed me and my coworkers doing that part of the interview to very quickly get an idea if the person we're interviewing is on "our level" or not. Perhaps it was helpful that we interviewed people for both senior and junior positions so someone with less experience, but demonstrating ability/willingness to learn could still be a good match. At the end, if our manager was happy with what he heard he would ask us for our opinion. And I have to say, despite this easy-going interview method it took us over a year to find a good candidate for one senior role we were hiring for. During this year we had only 5 or 6 people progress to the second stage and we had a new stack of CVs to go through every 2 weeks or so. We did get 3 people for junior roles at the same time. So is it true "most people interviewing have no clue"? I'll respond to this by saying it depends which recruiter has sent them. I have had recruiters admit to me they "tweak" CVs on more than one occasion. Also, yes, there are lots of people applying for jobs way above their skill level. Hiring is not easy. That's why good recruiters make more money than developers they recruit (I know a recruiter making £50k monthly in commission).

MilStdJunkie 4y ago

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.

CnRiAggZeYr 4y ago
[dead]

disambiguation 4y ago

Any system run by humans is by definition flawed. But the tech industry interview process is such low hanging fruit for mocking, I don't think this article is anything more than meme-ing a trendy topic for clicks. If we really want to evolve into something better, then here's what I propose: All employers must release their laptop surveillance data to the public domain for all the see. That way we can objectively compare who writes the most LoC and logs the most onscreen hours.

brg 4y ago

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.

readonthegoapp 4y ago

Good take I'd talk a bit more about power, generally, and what it does to people but this is good

marstall 4y ago

my technique: me: [scans resume] ... "tell me about project y here" interviewee: [tells me a bit] me: [ask questions, listen, drill down, listen, get gently more and more technical, back off if I hit a soft spot and find another place to drill down] repeat, repeat. I find its a good way to determine the candidate's strengths - versus freaking them out with a gotcha that's irrelevant to their skillset.

ern0 4y ago

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.