14 ms·

The technical interview is an ego trip

171 points by kowsheek 6y ago

WrtCdEvrydy 6y ago
Of course it is, it's a way to gauge whether "someone is dedicated to the job by cramming the algorithms section they haven't touched in years" I've done dozens of interviews and after all of it, I realized there are only four qualities we quantify as useful: caring, ability to listen, ability to learn.
- jonfw 6y ago
  That's only 3
  - WrtCdEvrydy 6y ago
    There are only two types of people: those who can derive a set from missing data.
- daggerdrone 6y ago
  Fourth quality: ability to count
  - asddubs 6y ago
    there are four kinds of people: people who can count, people who can't, and pedants
- jaxx75 6y ago
  Also the ability to identify off-by-one errors
- shreyansj 6y ago
  And debugging off-by-one errors.
- kowsheek 6y ago
  I think "caring" is probably the only one that separates the best from the rest. Reminds me of this: https://youtu.be/7EmboKQH8lM?t=2165 https://youtu.be/7EmboKQH8lM?t=2165 If we care as a developer, we write better code, learn things and listen to our team, customers.
- jhayward 6y ago
  I love this comment, not least because the enumeration leaves one to imagine what level of multi-dimensional punning and irony are being invoked.
  - WrtCdEvrydy 6y ago
    To be completely honest, it was a mistake... I forgot to add 'curiosity' after 'caring' but... I will now use this to figure out who is curious about the fourth one :D
pictur 6y ago
Sad but true
sushshshsh 6y ago
idk i do well in them
paxys 6y ago
Is it already that time of the week again?
- aphextron 6y ago
  We should just have a template to fill out for these posts
  - jameshush 6y ago
    I'm smelling a great "Show HN: Using GPT-2 to create comments for a post about tech interviews" submission :)
    - stygiansonic 6y ago
      The kicker is that such a submission should be generated by GPT-3 itself
    - mhh__ 6y ago
      Wouldn't really surprise me at all. 90% of everything is crap, HN submissions are no different - the comments are the site.
  - jakear 6y ago
    I want a GPT-3 trained on HN - if it can look at your title and generate basically your content/comment, don’t post it. Similarly, if it can look at the comment you’re replying to and generate essentially your reply (let’s say in top-5 most probable), don’t post it. Edit, love the irony that both responses are about GPT. Point proven?
  - minimaxir 6y ago
    Following the other comments, I gave GPT-3 the prompt: A post titled "The Technical Interview Is an Ego Trip" was submitted to tech forum Hacker News. Here are the comments on that submission: Here are the unedited/uncurated results: --- "The interview process is really more of an ego trip for the interviewer, and the interviewee is just the means of satisfying that need." "The most common reason I see people getting technical interviews is to satisfy the ego of the interviewer." "I have been on both sides of the table and I can honestly say that the interview process is mostly about the ego of the interviewer. And that is a shame." "I have done many interviews, and can say that, with a few exceptions, the vast majority of them are ego trips." "The technical interview is a big ego trip for the interviewer." "I am not sure how many times I have heard a manager say that he likes the technical interview process because it gives him a chance to meet technical people." "While the 'ego trip' comment might be a bit of an overstatement, interviewing is a skill and a process that, like any other, should be improved over time." "I have never really gotten the feeling that a technical interview is done for the benefit of the candidate." "Once you realize that you're not actually interviewing for a job, you'll find the process a lot less stressful." "I don't think the 'ego trip' term is a fair description. First of all, I am not interviewing for my ego." ---
darth_avocado 6y ago
Can we also add to the list of things that we don't need 8 interviews AND a tech screen to figure out whether a person can code?
- pmiller2 6y ago
  I don't think I've ever done more than 5 interviews plus a phone screen in a single loop. Who tried to put you through 8 hours of on-site interviews?
  - sushshshsh 6y ago
    Not them but for my last job at a mid tier company i did 6 hours of onsite total, and amazon/fb both were 4 hours each not including the screen(s)
TheCapn 6y ago
This was my take on interviewing with Amazon at one point a long while ago. The initial interview itself was pretty straight forward, but it seemed like every answer I gave was "wrong" because the interviewer was looking for key phrases instead of understanding of the concepts. We talked about hashing, and when he asked if I knew what hashing was I said sure, its a one-way function to create a unique identifier. He asked me to elaborate, so I sorta... talked more? I remember feeling confused because I'm not sure what else he wanted me to say. Eventually he ended the question, said he was looking for me to say hashing is for "fingerprinting" We moved on, he asked me for an example of a hash function. I said md5 or sha. He pressed further, asked about collisions and eventually cut off the line of questioning telling me he was looking for an example like the modulus function. Questioning lead further to reaching into linked-lists and the like. Having never sat through this kind of interview I was left with a really salty taste for the process. If any they were looking for was me to rattle off some pre-determined key words then what good is the interview for? I incorrectly assumed he was gauging my familiarity with the subject rather than repeating my 2nd year university coarse which introduced shit like data structures and algorithms. His smugness in the way he concluded each topic was just a giant turn off of ever seeking further work with companies like Amazon (giant & highly competitive software conglomerates). I feel like everyone is trying to one up or appear to be king shit in some way, it left a bad taste. (For the record, I did a couple interviews of this style before totally writing the experience off. Others were better, but this experience always stuck with me)
- kowsheek 6y ago
  I'm sorry you had to experience that, I know how you might feel :( That data structures and algorithm book and course is the root of so much distasteful smugness in the tech world, it's really bizarre. [Edit]: It's almost like it was the first course we found very difficult so we should that imprint of challenge on everyone else.
  - zamfi 6y ago
    The word I think you’re looking for is “hazing”
- 6y ago
LordHumungous 6y ago
Oh I see it's time for this blog post again.
bosswipe 6y ago
I'm coming to the realization that there's almost no point in spending time on a lot of the things that I love about being a developer: learning new languages, studying best practices for your tech stack, reading software engineering books, becoming involved in tech communities, keeping up with the latest trends. Interviewers don't value any of that beyond lip service. The only thing worth spending time on is leetcode grinding, it can be worth 10s of thousands of dollars. The attitude of the algorithm geniuses is that software engineering is easy and anyone can learn it, which might be true, but my point is that I already did learn it and I spent five years becoming an expert in it. That should be valuable to your business whether you look down upon it or not.
- jakearmitage 6y ago
  Nail tests, get offer, ask for signup bonus, drop out 3 months later. Repeat.
  - chrstphrknwtn 6y ago
    Two or three cycles in, people hiring will see serial 3 month stints as a red flag.
ng12 6y ago
Articles like this always underestimate how many bullshit artists there are out there. The technical interview is not perfect but it is still far more meritocratic than many fields.
- syspec 6y ago
  This, so much this! If it sounds crazy, it is because you're not a BS artist yourself, so it is hard to put yourself in that mindset. I have friends who fall into this category, and they would be the first to admit they bullshited their way into FANG
  - 2bitencryption 6y ago
    that just sounds like imposter syndrome with a different face on it.
    - syspec 6y ago
      That's fair, it very well could be that.
- mwfunk 6y ago
  It is utterly shocking how many bullshitters show up for interviews. I'm sure it varies by company and industry, but a fair chunk of interviewing is weeding out bullshitters.
- commandlinefan 6y ago
  Not only that, but the only concrete example the author gives is that they asked him about red-black trees. Probing knowledge of data structures is very relevant to day-to-day software development work: even if you don't actually implement them (or haven't since college), having a good knowledge of how they work is the only way to make intelligent decisions about tradeoffs involving them.
  - nogabebop23 6y ago
    NOT knowing the internal implementation details of everthing is what has gotten us this far in the first place. You just don't evaluate candidate data structures that often in the vast majority of programming work.
x87678r 6y ago
One issue is very few people get interview training. I have interviewed maybe 100 people but had to figure it out for myself what works. I wish I could apologize to the first few dozen.
- leafboi 6y ago
  Another thing to consider is even if you interviewed that many people there's really know way to evaluate your interview accuracy and performance unless you work with all 100 people.
catchmeifyoucan 6y ago
This is super true. I was interviewing with a Startup once, and we had an initial screening, and they had a lot of work to be done with AWS, some APIs and data pipelines. My area of work. When we had a "technical" interview, it was completely algorithms focused. And the interviewer dropped a few anchors, which restricted my thinking, and caught me cycling. It was super obvious the call wasn't going great. Odd enough, they acknowledged, that I was one of their best candidates, and were surprised. I didn't get the offer. It was a job I knew I could've aced, but the questions they asked didn't match up to what they actually needed done :/
- mixmastamyk 6y ago
  Reminds me of an interview a friend got me at a Spring Boot shop. Make sure you know SB, he said. I normally do Python, so I brushed up on Java and Spring for a month beforehand and was impressed with my progress. Well, final technical interview wasn't done by him and was instead 100% SQL and database theory instead. I did decently, I got about 85% of the questions right off the top of my head. Pretty decent result for zero preparation. Well, guess what another SQL-head did better. Was a total disaster because I was unemployed at the time and staring down financial ruin.
rehman 6y ago
Problem solving skill is a must. Not saying to cram the algorithms. But using those in your approach shows the ability of the candidate's efficiency and quickness in solving them.
pmiller2 6y ago
> My golden rule for technical interviews is that, "Every step, conversation and question must be pertinent to the day-to-day of the role." While this may be obvious, I am sure that many hiring managers are still expecting candidates to arrive at technical interviews with Computer Science books memorized. This form of technical interviews should be made obsolete. Here's the core of the article right here. The "regurgitate LeetCode-style problems" interview fails to be relevant to the day to day of pretty much any SWE job (unless, maybe, you're applying to work for LeetCode, and one of the duties is to create solutions to problems in under 40 minutes, without outside resources). Take the author's golden rule and layer on a structured interview process, and now you've got an interview process that will be more predictive of whether a candidate is a good hire than any "throw a random engineer in a room with the candidate and have them answer random algorithm problems" type interview. Even better, since you have an actual process, you can tweak it to be even more predictive of a good hire. Why don't companies understand this?
dmurray 6y ago
There's so much hate for "whiteboard interviews" and "interviewers focusing on themselves rather than the candidate" and all that on HN, but what if...this is actually what works for some companies? Some people want to work on super challenging problems with technically brilliant coworkers. Some people treat a poor performance not as a humiliation, but as an opportunity to understand how much they do not yet know. What if you want to attract candidates like that? Ask them tough questions, don't tailor the questions to their strengths, and have the interviewers show off how smart they are (even if they're not, it's easy to appear smart when you have all the answers). Pay good money and have high prestige so that you get plenty of quality applicants for every role, because you're going to miss out on many of the good ones, but you will attract some of the brightest and most driven people.
jaaron 6y ago
I agree. We recently got rid of our more traditional "tech screen" and replaced it with a 90 minute realistic programming interview. We have 3 tests we give depending on the role (game dev, backend, or SRE). The tests replicate typical work the engineer would be doing, such as adding functionality to a 2D game, developing out a web service for a given API, or debugging and optimizing a linux server. We provide a development environment remotely, or the engineer can use their own. They code/work on their own, without needing to share their screen, though we're on the line if they have questions or just want to chat. The interview itself takes about an hour and we schedule in buffer time before/after to setup and to debrief. We've designed the problems to be (a) relative, (b) scalable and (c) fun. By scalable, I mean that the problem should have a simple, naive solution that most engineers who work in that space should be able to solve quickly and easily, while also having enough space for more advanced engineers to extend the problem and show off a bit. So far we've gotten good feedback from this approach, even for candidates who haven't passed. I know 90 minutes is a long time, we but feel that with this test, we get a good, realistic work sample, and we can forgo a lot of the other less effective interviews. (plug: we're still hiring [1]) [1] https://www.singularity6.com/careers https://www.singularity6.com/careers
- throwaway815190 6y ago
  Is the 90 minutes a time limit? And are you required to do it all in one sitting?
- lazyant 6y ago
  "scalable" (not sure about that name) questions or scenarios are the best to gauge competency. I do them although it's pretty hard to come up with good ones. A fallback for shorter question is to ask for a something with many possible answers, as typically somebody more experienced will have many answers besides the most popular ones. (server A can't ping server B, what can be the reasons?)
  - jaaron 6y ago
    Yes, scalable problems are the best, but can be difficult to devise. A lot of folks tend to go the "optimization" route, by having a problem with multiple ways of extracting more performance, typically by better algorithms or data structures. These are ok, but not great. Most candidates will reasonably start with a simple naive solution that works and then try to optimize, but time may not allow for that and the optimization may require significant rewriting of the solution. So unless you either start out with the optimized solution or you have a lot of time, you're unlikely to ever see those solutions. I tend to prefer scaling via scope. For example, for our game engineering test, we start with a half-finished 2D "game" (think something like pacman). We then have a list of functionality that can be added with increasing difficulty. This allows us to measure "seniority" by both (a) how far down the list they get and (b) the quality of the individual solutions. Another example is starting with a single threaded solution and then extending into a multi-threaded or multi-process solution.
globular-toast 6y ago
I had the strangest technical interview recently. I didn't get an offer, but in every case where that's happened before it's been obvious to me where my deficiencies lie (which I then use to improve in that area). This time I learnt nothing. It was six individual one-to-one interviews, back to back. The first five were an ego trip for me. I was able to do everything perfectly it seems: read code, write code, talk about code. Then the sixth was this synthetic problem involving nested boxes. I figured out it was a tree problem and started writing code to build the tree. I had an approach in mind and asked the interviewer if he thought that was a good approach (given that there was only enough time for one attempt). He said no, he didn't think it would work. That completely threw me off. Later I realised me approach would have worked anyway. I didn't get an offer, but what in the ever-loving fuck was the point of putting me through 5 technical interviews only to fail the sixth? It really felt like they were looking for that ego boost but didn't get it from me. It's hard not to sound arrogant in this situation, but I've been humbled in the past. This time I was just confused.
- phnofive 6y ago
  If the whole thing was coordinated, that’s messed up; I wonder if it was a coincidence and #6 was testing your mettle, or even just genuinely disagreed. What did you do when he said no?
- sushisource 6y ago
  I'd say this happens semi consistently to me when I get rejected. I did a tech screen (of which this is the first I've ever failed). I chose to do it in Rust as that's my main language these days. I probably should've reconsidered that decision as Rust is notoriously difficult when it comes to dealing with trees and I spend most of my time managing pointers. I described a solution to the tree problem quickly, implemented it, and then dealt with the compiler for about 15 minutes. As a result I never fully finished the task, but it was pretty darn clear I knew what I was doing. Same thing, they came back and said no and I really have a hard time imagining why other than the interviewer not being familiar with Rust - but - hey, don't tell me it's fine to use then! That to say, rejection feedback is almost always useless.
hanoz 6y ago
So I've always wondered about these leetcode interviews, having never suffered one myself, if you're given one you've seen before, are you still supposed to pretend you're working it out from first principles?
- pmiller2 6y ago
  I don't know what the interviewers expect, but, generally, your "reward" for admitting you've seen the problem before is a harder question to answer. It seems more in the candidate's interest to pretend to work out the solution than to be honest.
  - smabie 6y ago
    Yeah, I've been asked a lot of leetcode questions and always pause for a couple minutes before the answer hits me in a "brilliant" stroke of insight. This con works really well.
    - deleted 6y ago
      [deleted]
    - bradlys 6y ago
      You need to get advanced level tactics like one of my past coworkers. He told me he would purposefully go down the wrong path with a problem - to only later have "divine inspiration" just before the interviewer would interrupt him and try to give him a hint... He would raise his hand and exclaim, "But, maybe!" And then promptly explain and solve the problem. It was at this point that I realized I have no chance of getting into FAANG when I'm playing low-level tactics like just trying to just solve two medium problems in <40 minutes with the most optimal answer. :( (Or 1 hard problem in 30-35 minutes)
    - wolco 6y ago
      It would be more impressive if you solved it right away.
      - 6y ago
davidhyde 6y ago
> “Often, I will give them a scenario where the processes are failing the team to find what they would do to tackle inefficiencies and if they would be willing to speak up.“ While the intention here is good you are unlikely to get an accurate answer from the candidate using this method because the candidate “should” tell you what you want to hear rather than what they would do in reality. You basically want to find out how the developer delivers criticism. Do they bruise egos or are they tactful or do they simply stay silent. A better approach is allowing a candidate to demonstrate how they offer criticism. Give them a codebase to read and make sense of and ask them to explain it to you. Ask them to to point out parts that could be better designed. You can gather a lot of information this way. 1. Can the candidate read a foreign codebase and make sense of it. 2. Can the candidate pick up business logic from the code. 3. Does the candidate offer criticism that is likely to make another developer defensive or are they more guarded with their communication and offer higher level design alternatives.
glangdale 6y ago
Ego Trip is the right phrase. A lot of the traditional algorithms puzzler interviews amount to the material being covered in an adversarial, closed-book fashion for the interviewee, after the interviewer has themselves gotten to master the material in a "at your leisure" fashion with an open book. I wouldn't mind getting asked nasty questions about red-black trees or Krushkal vs Prim or something if I knew the person sitting across from me had taken a "pass this test under these same conditions or you're fired" type scenario. It wouldn't make these interviews a good idea, but it's the reek of hypocrisy about them that puts it over the top for me. I still contend these interviews - in any form - are a hazing exercise designed to convince you that your own expertise doesn't really matter. You may think of yourself as a accomplished professional developer but to BigCo you are a Smart Person (?) Grade N to be slotted into an arbitrary role. What better way to convey this message than put you through an interview that you would have been best equipped to pass straight out of university or grad school? I suspect my peak "pass the tech interview" would have been straight out of the core courses mid-PhD and my ability to do this has since gone down every year.
- pmiller2 6y ago
  > I wouldn't mind getting asked nasty questions about red-black trees or Krushkal vs Prim or something if I knew the person sitting across from me had taken a "pass this test under these same conditions or you're fired" type scenario. It wouldn't make these interviews a good idea, but it's the reek of hypocrisy about them that puts it over the top for me. The only equivalent I know of this is a PhD oral comprehensive exam. I get your point regarding the hypocrisy of it all, but I don't think I would be into it, even if my interviewer had a PhD and had done something similar.
- commandlinefan 6y ago
  > Ego Trip is the right phrase Well, here's the thing about that, though... somebody does eventually pass these interviews. It may be a tough blow to your own ego to realize that you actually weren't the best candidate out there, or that somebody more qualified than you would be willing to accept a position that you yourself are just qualified enough for, but probing the competence of the candidate is entirely the point of a job interview. This is doubly important for a technical position where a false positive is orders of magnitude more damaging than a false negative.
allenu 6y ago
I really like the interview process the author lays out here. As someone who has been working for about 20 years in the industry, this feels like a better, more direct gauge of how well someone will fit in the role than of seeing if they know how to invert a binary tree. I do think it's still worth doing some sort of coding question, but it doesn't have to be some intricate algorithmic puzzle. It can be as simple as, "How would you design X?" for design and some data structure algorithm question, but something that does not take up the bulk of the interview. (Perhaps one interview in the loop could be devoted to hands-on coding.) One of the best interviews I had, and I'm biased here since i hit out of the park, was one where the interviewer literally gave me a laptop and told me to code a simple iOS app. I was applying as a senior iOS developer with many years experience, so it was totally fair to ask it. Having written several apps on the side, I got straight to work and knew exactly how to set up data structures, algorithms, and trade-offs. Even with my experience, I was not able to finish the complete app in the time allotted, but I was able to breeze through all the elements of of what go into designing an app from scratch. I had a few more interviews and later they offered me a job, but I ended up working elsewhere. Interestingly, the place I did take a job at had more traditional tech interviews, which I actually found too easy compared to larger tech companies, however there was more long-term growth available there and the pay was much better.
roflc0ptic 6y ago
Man. I interviewed somewhere last week for a Scala position, advertising myself as a functional programmer. In the interview, they asked me, "What's the difference between fold left and fold right?" I said "Um, one of them starts on the left side of the data structure, one of them starts on the right. I never remember which is which." They said essentially: "okay. The answer I was looking for was that fold right is not stack safe." I protested weakly, and they dug in, so I graciously let it go. But it's patently not true. A naive implementation of fold right in Scala isn't stack safe, but the actual implementation is stack safe. It's been stack safe since like 2010. So rather than interrogating my knowledge of functional programming, they're just asking me bullshit language trivia, and dinging me when I don't come up with their arbitrary wrong answer. I wanted to work there before that, but the interview made me a little ambivalent, and then they just ghosted me. So I guess I dodged a bullet. But man, that was frustrating.
- pmiller2 6y ago
  Huh. Other than taking the opportunity to talk about tail call elimination, I'm not sure what you could have done to salvage that interview. Bullet dodged, indeed.
- x87678r 6y ago
  I hate that post interview ghosting too. Is super inconsiderate.
  - roflc0ptic 6y ago
    I’ve never experienced it before now - how common is this? Is it a west coast thing? This was my first interview with a west coast shop. I don’t need an essay on why they thought it wasn’t a good fit, but radio silence seems eminently unprofessional.
    - nefitty 6y ago
      Not sure how common but this has happened to me as well. Coding challenge complete, follow-up interview scheduled... then cancelled. Rescheduled... then ghosted. It was a cheap way of figuring out I shouldn’t even consider working there.
uxenthusiast 6y ago
I'm doing a lot of interview as an interviewer these days mostly with junior candidate. The guy in charge of those before me was the kind that use aha question with no relevance whatsoever. Pure ego trip. If that guy had interviewe me I would have said "I don't know" a few times and eventually get up and leave. For my candidates, I tried a few things. Now I've got it down to explain to me your last project. I ask questions until I've understood every little detail of the project. Then we code a few simple "exercises" with increasing "difficulty". The candidate is allowed google, documentation, questions, anything. Then we read code. A piece of code with a "bug" or a feature to add. The key is to make them talk about concept from impérative, fonctionnal and object paradigm and interact like a junior and senior dev would in a dev team. I found that junior candidates react pretty well to these. Some of them thank me for having had the opportunity to learn about new things like functionnal programming. It's pretty cool and I feel that make them want to join us most of the time.
TheOtherHobbes 6y ago
YC2025 - "home.ly" - we aim to disrupt the remote technical interview process by replacing capricious human interviewers with the latest conversational AI leet-bots...
ricardobeat 6y ago
Sadly there is another side to this - by not doing any kind of technical assessment you expose yourself to fraud. I would have never expected that in the past, but after nearing a hundred interviews I saw a few cases of a candidate's skills as judged by code samples looking completely different once they were writing code on the spot. The exercises were all related to real tasks. I don't think we'd have caught on through product or problem-solving questions.
- leafboi 6y ago
  There's a real performance downgrade when performing in front of people. To add more accuracy to your assessment I would give these people the opportunity to perform in a room without someone watching.
deleted 6y ago
[deleted]
wwarner 6y ago
Look, you have to do technical interviews. You don't have to be a bully, but you have to find a way to probe the candidate's ability to solve technical problems and code. Pick a question that tests the skills you're looking for, but not too closely related to the problems you encounter every day, as that will introduce really strong bias. Pick a question that can be answered in 10 or 20 minutes on a white board. The question should seem really easy, so prepare a follow up question (or two) that adds difficulty for the candidate that needs the challenge. But here's the most important part: use the same question in at least 10 interviews. Test your questions by using them on many candidates. Don't introduce uncertainty by playing a different role in every interview. You'll get much better results.
- sg47 6y ago
  45 minutes - write a simple API matching the spec in one of the 3 languages on your/our laptop. Use Google if you have to. Someone will be in the room to help answer questions. API should be functional. Returning fake data is fine (or provide data in a sqlite db) 45 minutes - do code review of this extremely buggy code like you'd review a coworker's code 45 minutes - presentation on a technical topic to one or more members 45 minutes - behavioral. Let's talk about failures, conflicts in your career. Who are your role models? What do they do well? Leadership abilities, career progression 45 minutes - troubleshooting. Here's a docker container. Make this thing work. Rate all these on a scale of 1 to 10. Sum up the scores. Keep calibrating across all your candidates.
Google234 6y ago
I want to work with engineers that know their basic algorithms. Sorry, but complicated projects require smart solutions. If you don’t know the basics, you won’t be able to solve difficult problems efficiently.
hashkb 6y ago
If we aren't complaining about interviews where we got the offer and turned it down, there's a serious risk we're experiencing "sour grapes". Every interview I failed was an opportunity to get better. If it feels arbitrary and you don't get the job... you may just be below the bar. No shame in that... buy there's definitely shame in this sadly common framing attack on the concept of the tech screen.
px1999 6y ago
As an interviewer and decision maker around hiring engineers, there is zero legitimate reason to make the candidate feel like an idiot for not knowing something. It's easy enough to clarify what they're saying, and if there's a miss to just say "ok cool" and to ask the next question.
pstrateman 6y ago
Sometimes your job is just to make the button bigger. That job is not called software engineer, that job is called junior code monkey and pays $25k/yr.
deleted 6y ago
[deleted]
vasu_man 6y ago
"Every step, conversation and question must be pertinent to the day-to-day of the role" While I agree with the author's 'golden rule', I believe the complex data structure questions are just a way to filter interviewing candidates in a highly competitive job market. It's akin to the highly competitive Indian Joint Entrance Examination (JEE) where hundreds of thousands of students solve complex problems in Math, Physics, and Chemistry to get into premiere institutions with few thousand seats, most of whom do not pursue a career in sciences.
- ozim 6y ago
  I think that biggest issue for me is when some small startup acts like "premier institution". If you need to sling out cookie cutter code to deliver stuff to your customers don't pretend you are going to change the world. I just rejected one company because they had 4 pages of NDA and were small company.
fatjokes 6y ago
Unpopular opinion: I like technical interviews. They at least enforce some form of a standard hiring bar. I feel this way because I've seen hiring for non-technical roles, e.g., project management, etc. They basically end up being friends hiring friends, with minimal domain expertise.
- mixmastamyk 6y ago
  A bad hiring bar can be worse than random for hiring good candidates.
nojvek 6y ago
Ha! Zoox (the self driving car company) out of the 5 hours, 2 hours were math problems. Couldn’t google. Couldn’t use a calculator. No notepad. Had to use a zoom virtual whiteboard. What’s the area of an equilateral triangle ? Volume of a sphere? Sorry. Haven’t needed to use that in eons. I usually just google it.
- oblio 6y ago
  I'm guessing they were looking for game engine developers or 3D modelling engine developers, which probably know those by heart.
sleepysysadmin 6y ago
Most technical interviews aren't technical. You are expected to know irrelevant trivia like which port does ICMP use? There's literally no job on earth where that matters. So when I did technical interviews; I had a demo domain controller vm. I printed out 5 steps they need to do. dcpromo, slave domain.local to the dc, install wsus. pretty boring stuff that much candidates know how to do. My trick, there's lots of tiny details like did you get the server's name instead of SERVER-1897237534 Oh and I'll be talking about video games, tv and movies distracting you as much as possible during the testing. I just sit there asking them question after question about hobbies. Really really distracting.

171 points by kowsheek 6y ago

Of course it is, it's a way to gauge whether "someone is dedicated to the job by cramming the algorithms section they haven't touched in years" I've done dozens of interviews and after all of it, I realized there are only four qualities we quantify as useful: caring, ability to listen, ability to learn.

jonfw 6y ago
That's only 3
- WrtCdEvrydy 6y ago
  There are only two types of people: those who can derive a set from missing data.
daggerdrone 6y ago
Fourth quality: ability to count
- asddubs 6y ago
  there are four kinds of people: people who can count, people who can't, and pedants
jaxx75 6y ago
Also the ability to identify off-by-one errors
shreyansj 6y ago
And debugging off-by-one errors.
kowsheek 6y ago
I think "caring" is probably the only one that separates the best from the rest. Reminds me of this: https://youtu.be/7EmboKQH8lM?t=2165 https://youtu.be/7EmboKQH8lM?t=2165 If we care as a developer, we write better code, learn things and listen to our team, customers.
jhayward 6y ago
I love this comment, not least because the enumeration leaves one to imagine what level of multi-dimensional punning and irony are being invoked.
- WrtCdEvrydy 6y ago
  To be completely honest, it was a mistake... I forgot to add 'curiosity' after 'caring' but... I will now use this to figure out who is curious about the fourth one :D

pictur 6y ago

Sad but true

sushshshsh 6y ago

idk i do well in them

paxys 6y ago

Is it already that time of the week again?

aphextron 6y ago
We should just have a template to fill out for these posts
- jameshush 6y ago
  I'm smelling a great "Show HN: Using GPT-2 to create comments for a post about tech interviews" submission :)
  - stygiansonic 6y ago
    The kicker is that such a submission should be generated by GPT-3 itself
  - mhh__ 6y ago
    Wouldn't really surprise me at all. 90% of everything is crap, HN submissions are no different - the comments are the site.
- jakear 6y ago
  I want a GPT-3 trained on HN - if it can look at your title and generate basically your content/comment, don’t post it. Similarly, if it can look at the comment you’re replying to and generate essentially your reply (let’s say in top-5 most probable), don’t post it. Edit, love the irony that both responses are about GPT. Point proven?
- minimaxir 6y ago
  Following the other comments, I gave GPT-3 the prompt: A post titled "The Technical Interview Is an Ego Trip" was submitted to tech forum Hacker News. Here are the comments on that submission: Here are the unedited/uncurated results: --- "The interview process is really more of an ego trip for the interviewer, and the interviewee is just the means of satisfying that need." "The most common reason I see people getting technical interviews is to satisfy the ego of the interviewer." "I have been on both sides of the table and I can honestly say that the interview process is mostly about the ego of the interviewer. And that is a shame." "I have done many interviews, and can say that, with a few exceptions, the vast majority of them are ego trips." "The technical interview is a big ego trip for the interviewer." "I am not sure how many times I have heard a manager say that he likes the technical interview process because it gives him a chance to meet technical people." "While the 'ego trip' comment might be a bit of an overstatement, interviewing is a skill and a process that, like any other, should be improved over time." "I have never really gotten the feeling that a technical interview is done for the benefit of the candidate." "Once you realize that you're not actually interviewing for a job, you'll find the process a lot less stressful." "I don't think the 'ego trip' term is a fair description. First of all, I am not interviewing for my ego." ---

darth_avocado 6y ago

Can we also add to the list of things that we don't need 8 interviews AND a tech screen to figure out whether a person can code?

pmiller2 6y ago
I don't think I've ever done more than 5 interviews plus a phone screen in a single loop. Who tried to put you through 8 hours of on-site interviews?
- sushshshsh 6y ago
  Not them but for my last job at a mid tier company i did 6 hours of onsite total, and amazon/fb both were 4 hours each not including the screen(s)

TheCapn 6y ago

This was my take on interviewing with Amazon at one point a long while ago. The initial interview itself was pretty straight forward, but it seemed like every answer I gave was "wrong" because the interviewer was looking for key phrases instead of understanding of the concepts. We talked about hashing, and when he asked if I knew what hashing was I said sure, its a one-way function to create a unique identifier. He asked me to elaborate, so I sorta... talked more? I remember feeling confused because I'm not sure what else he wanted me to say. Eventually he ended the question, said he was looking for me to say hashing is for "fingerprinting" We moved on, he asked me for an example of a hash function. I said md5 or sha. He pressed further, asked about collisions and eventually cut off the line of questioning telling me he was looking for an example like the modulus function. Questioning lead further to reaching into linked-lists and the like. Having never sat through this kind of interview I was left with a really salty taste for the process. If any they were looking for was me to rattle off some pre-determined key words then what good is the interview for? I incorrectly assumed he was gauging my familiarity with the subject rather than repeating my 2nd year university coarse which introduced shit like data structures and algorithms. His smugness in the way he concluded each topic was just a giant turn off of ever seeking further work with companies like Amazon (giant & highly competitive software conglomerates). I feel like everyone is trying to one up or appear to be king shit in some way, it left a bad taste. (For the record, I did a couple interviews of this style before totally writing the experience off. Others were better, but this experience always stuck with me)

kowsheek 6y ago
I'm sorry you had to experience that, I know how you might feel :( That data structures and algorithm book and course is the root of so much distasteful smugness in the tech world, it's really bizarre. [Edit]: It's almost like it was the first course we found very difficult so we should that imprint of challenge on everyone else.
- zamfi 6y ago
  The word I think you’re looking for is “hazing”
6y ago

LordHumungous 6y ago

Oh I see it's time for this blog post again.

bosswipe 6y ago

I'm coming to the realization that there's almost no point in spending time on a lot of the things that I love about being a developer: learning new languages, studying best practices for your tech stack, reading software engineering books, becoming involved in tech communities, keeping up with the latest trends. Interviewers don't value any of that beyond lip service. The only thing worth spending time on is leetcode grinding, it can be worth 10s of thousands of dollars. The attitude of the algorithm geniuses is that software engineering is easy and anyone can learn it, which might be true, but my point is that I already did learn it and I spent five years becoming an expert in it. That should be valuable to your business whether you look down upon it or not.

jakearmitage 6y ago
Nail tests, get offer, ask for signup bonus, drop out 3 months later. Repeat.
- chrstphrknwtn 6y ago
  Two or three cycles in, people hiring will see serial 3 month stints as a red flag.

ng12 6y ago

Articles like this always underestimate how many bullshit artists there are out there. The technical interview is not perfect but it is still far more meritocratic than many fields.

syspec 6y ago
This, so much this! If it sounds crazy, it is because you're not a BS artist yourself, so it is hard to put yourself in that mindset. I have friends who fall into this category, and they would be the first to admit they bullshited their way into FANG
- 2bitencryption 6y ago
  that just sounds like imposter syndrome with a different face on it.
  - syspec 6y ago
    That's fair, it very well could be that.
mwfunk 6y ago
It is utterly shocking how many bullshitters show up for interviews. I'm sure it varies by company and industry, but a fair chunk of interviewing is weeding out bullshitters.
commandlinefan 6y ago
Not only that, but the only concrete example the author gives is that they asked him about red-black trees. Probing knowledge of data structures is very relevant to day-to-day software development work: even if you don't actually implement them (or haven't since college), having a good knowledge of how they work is the only way to make intelligent decisions about tradeoffs involving them.
- nogabebop23 6y ago
  NOT knowing the internal implementation details of everthing is what has gotten us this far in the first place. You just don't evaluate candidate data structures that often in the vast majority of programming work.

x87678r 6y ago

One issue is very few people get interview training. I have interviewed maybe 100 people but had to figure it out for myself what works. I wish I could apologize to the first few dozen.

leafboi 6y ago
Another thing to consider is even if you interviewed that many people there's really know way to evaluate your interview accuracy and performance unless you work with all 100 people.

catchmeifyoucan 6y ago

This is super true. I was interviewing with a Startup once, and we had an initial screening, and they had a lot of work to be done with AWS, some APIs and data pipelines. My area of work. When we had a "technical" interview, it was completely algorithms focused. And the interviewer dropped a few anchors, which restricted my thinking, and caught me cycling. It was super obvious the call wasn't going great. Odd enough, they acknowledged, that I was one of their best candidates, and were surprised. I didn't get the offer. It was a job I knew I could've aced, but the questions they asked didn't match up to what they actually needed done :/

mixmastamyk 6y ago
Reminds me of an interview a friend got me at a Spring Boot shop. Make sure you know SB, he said. I normally do Python, so I brushed up on Java and Spring for a month beforehand and was impressed with my progress. Well, final technical interview wasn't done by him and was instead 100% SQL and database theory instead. I did decently, I got about 85% of the questions right off the top of my head. Pretty decent result for zero preparation. Well, guess what another SQL-head did better. Was a total disaster because I was unemployed at the time and staring down financial ruin.

rehman 6y ago

Problem solving skill is a must. Not saying to cram the algorithms. But using those in your approach shows the ability of the candidate's efficiency and quickness in solving them.

pmiller2 6y ago

> My golden rule for technical interviews is that, "Every step, conversation and question must be pertinent to the day-to-day of the role." While this may be obvious, I am sure that many hiring managers are still expecting candidates to arrive at technical interviews with Computer Science books memorized. This form of technical interviews should be made obsolete. Here's the core of the article right here. The "regurgitate LeetCode-style problems" interview fails to be relevant to the day to day of pretty much any SWE job (unless, maybe, you're applying to work for LeetCode, and one of the duties is to create solutions to problems in under 40 minutes, without outside resources). Take the author's golden rule and layer on a structured interview process, and now you've got an interview process that will be more predictive of whether a candidate is a good hire than any "throw a random engineer in a room with the candidate and have them answer random algorithm problems" type interview. Even better, since you have an actual process, you can tweak it to be even more predictive of a good hire. Why don't companies understand this?

dmurray 6y ago

There's so much hate for "whiteboard interviews" and "interviewers focusing on themselves rather than the candidate" and all that on HN, but what if...this is actually what works for some companies? Some people want to work on super challenging problems with technically brilliant coworkers. Some people treat a poor performance not as a humiliation, but as an opportunity to understand how much they do not yet know. What if you want to attract candidates like that? Ask them tough questions, don't tailor the questions to their strengths, and have the interviewers show off how smart they are (even if they're not, it's easy to appear smart when you have all the answers). Pay good money and have high prestige so that you get plenty of quality applicants for every role, because you're going to miss out on many of the good ones, but you will attract some of the brightest and most driven people.

jaaron 6y ago

I agree. We recently got rid of our more traditional "tech screen" and replaced it with a 90 minute realistic programming interview. We have 3 tests we give depending on the role (game dev, backend, or SRE). The tests replicate typical work the engineer would be doing, such as adding functionality to a 2D game, developing out a web service for a given API, or debugging and optimizing a linux server. We provide a development environment remotely, or the engineer can use their own. They code/work on their own, without needing to share their screen, though we're on the line if they have questions or just want to chat. The interview itself takes about an hour and we schedule in buffer time before/after to setup and to debrief. We've designed the problems to be (a) relative, (b) scalable and (c) fun. By scalable, I mean that the problem should have a simple, naive solution that most engineers who work in that space should be able to solve quickly and easily, while also having enough space for more advanced engineers to extend the problem and show off a bit. So far we've gotten good feedback from this approach, even for candidates who haven't passed. I know 90 minutes is a long time, we but feel that with this test, we get a good, realistic work sample, and we can forgo a lot of the other less effective interviews. (plug: we're still hiring [1]) [1] https://www.singularity6.com/careers https://www.singularity6.com/careers

throwaway815190 6y ago
Is the 90 minutes a time limit? And are you required to do it all in one sitting?
lazyant 6y ago
"scalable" (not sure about that name) questions or scenarios are the best to gauge competency. I do them although it's pretty hard to come up with good ones. A fallback for shorter question is to ask for a something with many possible answers, as typically somebody more experienced will have many answers besides the most popular ones. (server A can't ping server B, what can be the reasons?)
- jaaron 6y ago
  Yes, scalable problems are the best, but can be difficult to devise. A lot of folks tend to go the "optimization" route, by having a problem with multiple ways of extracting more performance, typically by better algorithms or data structures. These are ok, but not great. Most candidates will reasonably start with a simple naive solution that works and then try to optimize, but time may not allow for that and the optimization may require significant rewriting of the solution. So unless you either start out with the optimized solution or you have a lot of time, you're unlikely to ever see those solutions. I tend to prefer scaling via scope. For example, for our game engineering test, we start with a half-finished 2D "game" (think something like pacman). We then have a list of functionality that can be added with increasing difficulty. This allows us to measure "seniority" by both (a) how far down the list they get and (b) the quality of the individual solutions. Another example is starting with a single threaded solution and then extending into a multi-threaded or multi-process solution.

globular-toast 6y ago

I had the strangest technical interview recently. I didn't get an offer, but in every case where that's happened before it's been obvious to me where my deficiencies lie (which I then use to improve in that area). This time I learnt nothing. It was six individual one-to-one interviews, back to back. The first five were an ego trip for me. I was able to do everything perfectly it seems: read code, write code, talk about code. Then the sixth was this synthetic problem involving nested boxes. I figured out it was a tree problem and started writing code to build the tree. I had an approach in mind and asked the interviewer if he thought that was a good approach (given that there was only enough time for one attempt). He said no, he didn't think it would work. That completely threw me off. Later I realised me approach would have worked anyway. I didn't get an offer, but what in the ever-loving fuck was the point of putting me through 5 technical interviews only to fail the sixth? It really felt like they were looking for that ego boost but didn't get it from me. It's hard not to sound arrogant in this situation, but I've been humbled in the past. This time I was just confused.

phnofive 6y ago
If the whole thing was coordinated, that’s messed up; I wonder if it was a coincidence and #6 was testing your mettle, or even just genuinely disagreed. What did you do when he said no?
sushisource 6y ago
I'd say this happens semi consistently to me when I get rejected. I did a tech screen (of which this is the first I've ever failed). I chose to do it in Rust as that's my main language these days. I probably should've reconsidered that decision as Rust is notoriously difficult when it comes to dealing with trees and I spend most of my time managing pointers. I described a solution to the tree problem quickly, implemented it, and then dealt with the compiler for about 15 minutes. As a result I never fully finished the task, but it was pretty darn clear I knew what I was doing. Same thing, they came back and said no and I really have a hard time imagining why other than the interviewer not being familiar with Rust - but - hey, don't tell me it's fine to use then! That to say, rejection feedback is almost always useless.

hanoz 6y ago

So I've always wondered about these leetcode interviews, having never suffered one myself, if you're given one you've seen before, are you still supposed to pretend you're working it out from first principles?

pmiller2 6y ago
I don't know what the interviewers expect, but, generally, your "reward" for admitting you've seen the problem before is a harder question to answer. It seems more in the candidate's interest to pretend to work out the solution than to be honest.
- smabie 6y ago
  Yeah, I've been asked a lot of leetcode questions and always pause for a couple minutes before the answer hits me in a "brilliant" stroke of insight. This con works really well.
  - deleted 6y ago
    [deleted]
  - bradlys 6y ago
    You need to get advanced level tactics like one of my past coworkers. He told me he would purposefully go down the wrong path with a problem - to only later have "divine inspiration" just before the interviewer would interrupt him and try to give him a hint... He would raise his hand and exclaim, "But, maybe!" And then promptly explain and solve the problem. It was at this point that I realized I have no chance of getting into FAANG when I'm playing low-level tactics like just trying to just solve two medium problems in <40 minutes with the most optimal answer. :( (Or 1 hard problem in 30-35 minutes)
  - wolco 6y ago
    It would be more impressive if you solved it right away.
    - 6y ago

davidhyde 6y ago

> “Often, I will give them a scenario where the processes are failing the team to find what they would do to tackle inefficiencies and if they would be willing to speak up.“ While the intention here is good you are unlikely to get an accurate answer from the candidate using this method because the candidate “should” tell you what you want to hear rather than what they would do in reality. You basically want to find out how the developer delivers criticism. Do they bruise egos or are they tactful or do they simply stay silent. A better approach is allowing a candidate to demonstrate how they offer criticism. Give them a codebase to read and make sense of and ask them to explain it to you. Ask them to to point out parts that could be better designed. You can gather a lot of information this way. 1. Can the candidate read a foreign codebase and make sense of it. 2. Can the candidate pick up business logic from the code. 3. Does the candidate offer criticism that is likely to make another developer defensive or are they more guarded with their communication and offer higher level design alternatives.

glangdale 6y ago

Ego Trip is the right phrase. A lot of the traditional algorithms puzzler interviews amount to the material being covered in an adversarial, closed-book fashion for the interviewee, after the interviewer has themselves gotten to master the material in a "at your leisure" fashion with an open book. I wouldn't mind getting asked nasty questions about red-black trees or Krushkal vs Prim or something if I knew the person sitting across from me had taken a "pass this test under these same conditions or you're fired" type scenario. It wouldn't make these interviews a good idea, but it's the reek of hypocrisy about them that puts it over the top for me. I still contend these interviews - in any form - are a hazing exercise designed to convince you that your own expertise doesn't really matter. You may think of yourself as a accomplished professional developer but to BigCo you are a Smart Person (?) Grade N to be slotted into an arbitrary role. What better way to convey this message than put you through an interview that you would have been best equipped to pass straight out of university or grad school? I suspect my peak "pass the tech interview" would have been straight out of the core courses mid-PhD and my ability to do this has since gone down every year.

pmiller2 6y ago
> I wouldn't mind getting asked nasty questions about red-black trees or Krushkal vs Prim or something if I knew the person sitting across from me had taken a "pass this test under these same conditions or you're fired" type scenario. It wouldn't make these interviews a good idea, but it's the reek of hypocrisy about them that puts it over the top for me. The only equivalent I know of this is a PhD oral comprehensive exam. I get your point regarding the hypocrisy of it all, but I don't think I would be into it, even if my interviewer had a PhD and had done something similar.
commandlinefan 6y ago
> Ego Trip is the right phrase Well, here's the thing about that, though... somebody does eventually pass these interviews. It may be a tough blow to your own ego to realize that you actually weren't the best candidate out there, or that somebody more qualified than you would be willing to accept a position that you yourself are just qualified enough for, but probing the competence of the candidate is entirely the point of a job interview. This is doubly important for a technical position where a false positive is orders of magnitude more damaging than a false negative.

allenu 6y ago

I really like the interview process the author lays out here. As someone who has been working for about 20 years in the industry, this feels like a better, more direct gauge of how well someone will fit in the role than of seeing if they know how to invert a binary tree. I do think it's still worth doing some sort of coding question, but it doesn't have to be some intricate algorithmic puzzle. It can be as simple as, "How would you design X?" for design and some data structure algorithm question, but something that does not take up the bulk of the interview. (Perhaps one interview in the loop could be devoted to hands-on coding.) One of the best interviews I had, and I'm biased here since i hit out of the park, was one where the interviewer literally gave me a laptop and told me to code a simple iOS app. I was applying as a senior iOS developer with many years experience, so it was totally fair to ask it. Having written several apps on the side, I got straight to work and knew exactly how to set up data structures, algorithms, and trade-offs. Even with my experience, I was not able to finish the complete app in the time allotted, but I was able to breeze through all the elements of of what go into designing an app from scratch. I had a few more interviews and later they offered me a job, but I ended up working elsewhere. Interestingly, the place I did take a job at had more traditional tech interviews, which I actually found too easy compared to larger tech companies, however there was more long-term growth available there and the pay was much better.

roflc0ptic 6y ago

Man. I interviewed somewhere last week for a Scala position, advertising myself as a functional programmer. In the interview, they asked me, "What's the difference between fold left and fold right?" I said "Um, one of them starts on the left side of the data structure, one of them starts on the right. I never remember which is which." They said essentially: "okay. The answer I was looking for was that fold right is not stack safe." I protested weakly, and they dug in, so I graciously let it go. But it's patently not true. A naive implementation of fold right in Scala isn't stack safe, but the actual implementation is stack safe. It's been stack safe since like 2010. So rather than interrogating my knowledge of functional programming, they're just asking me bullshit language trivia, and dinging me when I don't come up with their arbitrary wrong answer. I wanted to work there before that, but the interview made me a little ambivalent, and then they just ghosted me. So I guess I dodged a bullet. But man, that was frustrating.

pmiller2 6y ago
Huh. Other than taking the opportunity to talk about tail call elimination, I'm not sure what you could have done to salvage that interview. Bullet dodged, indeed.
x87678r 6y ago
I hate that post interview ghosting too. Is super inconsiderate.
- roflc0ptic 6y ago
  I’ve never experienced it before now - how common is this? Is it a west coast thing? This was my first interview with a west coast shop. I don’t need an essay on why they thought it wasn’t a good fit, but radio silence seems eminently unprofessional.
  - nefitty 6y ago
    Not sure how common but this has happened to me as well. Coding challenge complete, follow-up interview scheduled... then cancelled. Rescheduled... then ghosted. It was a cheap way of figuring out I shouldn’t even consider working there.

uxenthusiast 6y ago

I'm doing a lot of interview as an interviewer these days mostly with junior candidate. The guy in charge of those before me was the kind that use aha question with no relevance whatsoever. Pure ego trip. If that guy had interviewe me I would have said "I don't know" a few times and eventually get up and leave. For my candidates, I tried a few things. Now I've got it down to explain to me your last project. I ask questions until I've understood every little detail of the project. Then we code a few simple "exercises" with increasing "difficulty". The candidate is allowed google, documentation, questions, anything. Then we read code. A piece of code with a "bug" or a feature to add. The key is to make them talk about concept from impérative, fonctionnal and object paradigm and interact like a junior and senior dev would in a dev team. I found that junior candidates react pretty well to these. Some of them thank me for having had the opportunity to learn about new things like functionnal programming. It's pretty cool and I feel that make them want to join us most of the time.

TheOtherHobbes 6y ago

YC2025 - "home.ly" - we aim to disrupt the remote technical interview process by replacing capricious human interviewers with the latest conversational AI leet-bots...

ricardobeat 6y ago

Sadly there is another side to this - by not doing any kind of technical assessment you expose yourself to fraud. I would have never expected that in the past, but after nearing a hundred interviews I saw a few cases of a candidate's skills as judged by code samples looking completely different once they were writing code on the spot. The exercises were all related to real tasks. I don't think we'd have caught on through product or problem-solving questions.

leafboi 6y ago
There's a real performance downgrade when performing in front of people. To add more accuracy to your assessment I would give these people the opportunity to perform in a room without someone watching.

deleted 6y ago

[deleted]

wwarner 6y ago

Look, you have to do technical interviews. You don't have to be a bully, but you have to find a way to probe the candidate's ability to solve technical problems and code. Pick a question that tests the skills you're looking for, but not too closely related to the problems you encounter every day, as that will introduce really strong bias. Pick a question that can be answered in 10 or 20 minutes on a white board. The question should seem really easy, so prepare a follow up question (or two) that adds difficulty for the candidate that needs the challenge. But here's the most important part: use the same question in at least 10 interviews. Test your questions by using them on many candidates. Don't introduce uncertainty by playing a different role in every interview. You'll get much better results.

sg47 6y ago
45 minutes - write a simple API matching the spec in one of the 3 languages on your/our laptop. Use Google if you have to. Someone will be in the room to help answer questions. API should be functional. Returning fake data is fine (or provide data in a sqlite db) 45 minutes - do code review of this extremely buggy code like you'd review a coworker's code 45 minutes - presentation on a technical topic to one or more members 45 minutes - behavioral. Let's talk about failures, conflicts in your career. Who are your role models? What do they do well? Leadership abilities, career progression 45 minutes - troubleshooting. Here's a docker container. Make this thing work. Rate all these on a scale of 1 to 10. Sum up the scores. Keep calibrating across all your candidates.

Google234 6y ago

I want to work with engineers that know their basic algorithms. Sorry, but complicated projects require smart solutions. If you don’t know the basics, you won’t be able to solve difficult problems efficiently.

hashkb 6y ago

If we aren't complaining about interviews where we got the offer and turned it down, there's a serious risk we're experiencing "sour grapes". Every interview I failed was an opportunity to get better. If it feels arbitrary and you don't get the job... you may just be below the bar. No shame in that... buy there's definitely shame in this sadly common framing attack on the concept of the tech screen.

px1999 6y ago

As an interviewer and decision maker around hiring engineers, there is zero legitimate reason to make the candidate feel like an idiot for not knowing something. It's easy enough to clarify what they're saying, and if there's a miss to just say "ok cool" and to ask the next question.

pstrateman 6y ago

Sometimes your job is just to make the button bigger. That job is not called software engineer, that job is called junior code monkey and pays $25k/yr.

deleted 6y ago

[deleted]

vasu_man 6y ago

"Every step, conversation and question must be pertinent to the day-to-day of the role" While I agree with the author's 'golden rule', I believe the complex data structure questions are just a way to filter interviewing candidates in a highly competitive job market. It's akin to the highly competitive Indian Joint Entrance Examination (JEE) where hundreds of thousands of students solve complex problems in Math, Physics, and Chemistry to get into premiere institutions with few thousand seats, most of whom do not pursue a career in sciences.

ozim 6y ago
I think that biggest issue for me is when some small startup acts like "premier institution". If you need to sling out cookie cutter code to deliver stuff to your customers don't pretend you are going to change the world. I just rejected one company because they had 4 pages of NDA and were small company.

fatjokes 6y ago

Unpopular opinion: I like technical interviews. They at least enforce some form of a standard hiring bar. I feel this way because I've seen hiring for non-technical roles, e.g., project management, etc. They basically end up being friends hiring friends, with minimal domain expertise.

mixmastamyk 6y ago
A bad hiring bar can be worse than random for hiring good candidates.

nojvek 6y ago

Ha! Zoox (the self driving car company) out of the 5 hours, 2 hours were math problems. Couldn’t google. Couldn’t use a calculator. No notepad. Had to use a zoom virtual whiteboard. What’s the area of an equilateral triangle ? Volume of a sphere? Sorry. Haven’t needed to use that in eons. I usually just google it.

oblio 6y ago
I'm guessing they were looking for game engine developers or 3D modelling engine developers, which probably know those by heart.

sleepysysadmin 6y ago

Most technical interviews aren't technical. You are expected to know irrelevant trivia like which port does ICMP use? There's literally no job on earth where that matters. So when I did technical interviews; I had a demo domain controller vm. I printed out 5 steps they need to do. dcpromo, slave domain.local to the dc, install wsus. pretty boring stuff that much candidates know how to do. My trick, there's lots of tiny details like did you get the server's name instead of SERVER-1897237534 Oh and I'll be talking about video games, tv and movies distracting you as much as possible during the testing. I just sit there asking them question after question about hobbies. Really really distracting.