9 ms·

Tech Job Interviews Are Out of Control

49 points by ra7 3y ago

cranberryturkey 3y ago
oh yes. i ask one advanced question when i interview. something like "what's the difference between git rebase and git pull" -- if they know you're good to go. the other route I take is to have a candidate walk me through some code they have, if they don't have any code then i don't hire them. period.
- hardware2win 3y ago
  Git questions are weird for me Cuz, I use git gui and I switch to cli like a once a month at best, so I dont really remember the commands nor see the value in putting effort into it It feels like people fixated on git details think everyone has the same work flow as they do, so for them it feels like git cli proficiency is really needed. It is like asking about vsCode shortcuts (it'd probably be even more useful, since you spend more time in your editor) Id really prefer being asked about algos, compilers, web dev, system design, whatever heavily software related (even religious topics like SOLID) than boring tools which can be used in various ways
  - cranberryturkey 3y ago
    that's a fair point but i valud people who value the cli over guis. not that you can't use a gui but its much better to know what its doing under the hood.
    - hardware2win 3y ago
      >its much better to know what its doing under the hood. I agree when it comes to programming langs, libs, compilers and in general computers. Because knowledge of those things significantly affects your output (code) But git? I treat it the same way I treat email client, power point or chat app used at work. Hell, I could probably benefit more from high power point skills than high git skills.
      - cranberryturkey 3y ago
        I also ask people to walk me through some recent code they write. So if you didn’t know the git answer no biggie
        tharkun__ 3y ago
        Caveat not your parent. What's recent? I have a busy life. I don't really code outside of work any more. I do woodworking or something else. The newest code you'll see from me is probably when I tried to make a game using Roblox just for fun for the kids. That's been a while. I don't have a github account and that's on purpose. I don't do open source work any longer and the most recent you'll find is probably 20 years old. Code from work? Not gonna show that to you or you're not gonna hire me because I break NDAs ;) Personally I do like the git one tho. Even if you use a GUI (unless it renames things it really shouldn't) would allow someone to answer what the conceptual differences are between pulling and rebasing! FWIW: pull is a combination of fetch+merge, so not a rebase at all. They can be similar, in case your pull and rebase both happen to result in a simple fast-forward operation, which is literally just "moving a label" (or in 'real' terms, changing a commit hash inside one file in the .git directory). Am I hired?
        grayhatter 3y ago
        you answered the git question passibly IMO, so perhaps you could be hired? But what heuristic would you suggest for someone that doesn't know git at all, and doesn't ever write code for fun or to solve problems on their own?
        tharkun__ 3y ago
        If someone has never used git, they probably used <somethingElse>. I would hope they're witty enough to ask the interviewer back: "I dunno, never used git, we use Rational ClearCase. Can you tell me what the difference is between a reserved and unreserved checkout and when would you use each?" Probably not in an interview situation, especially if they need the job, but would be fun! Just coz I don't code for fun any longer, what tells you I don't solve problems on my own (both at work or at home)? Getting into woodworking required a lot of figuring out new stuff, including the part of actually doing something with my hands. It was particularly fun because it was new and needed figuring out. Figuring out why the heck the last distro upgrade decided to not be able to find my LVM volumes on software RAID and I thought I had lost all my data was also a fun problem to solve. It required zero code. But it required a lot of debugging and interpreting things I don't know the actual implemtation details of. Something I see a lot of devs being bad at. Fixing bugs. I.e. investigating unknowns.
    - gregors 3y ago
      I think it's a fair question. I would never not hire someone over not knowing that particular flow though. Also, I've never had any developers I've hired not be able to learn it quickly. The fact that they don't know it does tell you that they're either not rebasing or not using the cli. The discussion around those process topics are more interesting to me than them not knowing it to begin with. For example, "well what is your process around git usage in general?" etc, "how well do you know the cli?" etc. Interviews are all about conversations. I would tell them they'll learn the cli git if they join my team. Maybe that's not something they're into? I guess that's part of the "fit" of a team. At one point there was lots of discussion regarding rebasing in general on our team and another shop. This blog post came out of that. I know many people who feel differently of course. I do expect seniors to have an opinion on the matter either way I guess. https://blog.carbonfive.com/always-squash-and-rebase-your-git-commits/ https://blog.carbonfive.com/always-squash-and-rebase-your-gi...
  - grayhatter 3y ago
    > so I dont really remember the commands nor see the value in putting effort into it curiosity? knowing everything you can about the world around you? having used what is possibly the most critical piece of software for working with other people that you encountered some rare exception to common workflows that required you to learn more about the plumbing? > It is like asking about vsCode shortcuts (it'd probably be even more useful, since you spend more time in your editor) My editor isn't vscode, so vscode shortcuts wouldn't be helpful to me, the interviever. But again, it's about ability to work with others, the demonstration that you understand systems that you could get away without knowing. You're right, you can be productive while understanding nothing about git, that doesn't mean you're good, or competent, just productive. I don't want to hire people who can write thousands of lines of code, I want to hire people who can do the same in just 100 lines. > than boring tools which can be used in various ways that's really what it comes down to isn't it. It's not interesting to you so you don't want to invest the time in learning it because it's boring. I doubt anyone would agree knowing fewer things is better, so I cant help but read this as sharpening my ax is boring, so I just don't do it.
    - AnimalMuppet 3y ago
      > > so I dont really remember the commands nor see the value in putting effort into it > curiosity? knowing everything you can about the world around you? There is far more out there to learn than I have time and energy to learn. "Here's something you can learn" does not even begin to reach the bar of "I should learn this". > having used what is possibly the most critical piece of software for working with other people that you encountered some rare exception to common workflows that required you to learn more about the plumbing? With one exception, everywhere I have worked has not used git. The one exception used it for one or two years. I know more about four other version control systems than I do about git. And, since you're talking about learning to use the most critical piece of software for working with other people, and chewing out the GP for not wanting to invest the time... why don't you begin your sentences with capital letters? Written English is one of the most critical pieces of, not software exactly, but at least "tech", for working with other people.
      - 3y ago
- bsder 3y ago
  Those of us who have been around long enough know that Git knowledge is useless knowledge as it will disappear at some point. As did SCCS, RCS, CVS, and SVN ... Build systems and source control systems are shit work that are in the way of doing what I need to do. Basing interview questions on that is absurd.
  - lucisferre 3y ago
    It is a simple matter of having current and relevant knowledge for the role. Would I hire a junior developer who didn't know much or even anything about using git? Probably. Would I question the seniority of a so-called senior developer who didn't know the basic usages of the most dominant source control tool for the past 15 years? Absolutely. If they had a good explanation for that gap in knowledge, like working for the past 20 years somewhere that was stuck in legacy code and running on SVN, I'd definitely take that into consideration. I might still want to be certain this candidate is smart enough to quickly pivot into a new codebase and new tools. I've met many people who struggle with exactly that kind of change which is exactly why they don't keep their knowledge current. I'll admit that asking people how git works isn't a question I would ask in an interview. Playing devil's advocate though, I would probably not hire someone claiming to be a senior developer who doesn't know how git works.
    - bsder 3y ago
      Maybe I think that the user experience of Git sucks balls and have no desire to learn it at any level beyond the bare minimum. Maybe I use better systems like Mercurial or Perforce or anything designed more recently than the last 20 years. Maybe I think that Github is a pox upon the planet and their promulgation of the One True Workflow(tm) (pull requests) is an abomination brought about by technical architecture limitations of Github. I use Git only because other people force me to use Git. Otherwise, I use something better.
      - lucisferre 3y ago
        I mean that's certainly an opinion, but I'm not sure I'd be confident hiring someone into a company that uses a tool that the candidate hates so passionately. Also Git and Mercurial are about the same age and less than 20 years old. Perforce is far older than both of them.
- kjkjadksj 3y ago
  Thats so strange to me. I work with git every day and don’t use rebase. If you asked me in the interview I’d fail that. But if you asked me that question in real life I’d give you the answer in 30 seconds after looking at the documentation, and everything would carry on without a hitch.
  - grayhatter 3y ago
    you don't even know what it does enough to say, > I don't really use it but from what I remember... also here's a lot of details about the steps that go into the porcelain command git pull. I don't use VS code but I know the difference between the command palette and the sidebar file explorer and could answer a bunch of questions about it. I think the point of the question is to filter out people who aren't curious. Which isn't perfect for the ability of a job candidate to be successful, but does happen to have an incredibly strong correlation.
    - mech422 3y ago
      >>I think the point of the question is to filter out people who aren't curious. I think you're actually filtering on people that are curious about the same things you are. Learning things because you're curious is pretty much a 'free-time' activity. Tech is huge, and with all the stuff to learn - I guarantee I'd learn algorithms and data structures over most other stuff... That doesn't mean I don't like learn, just that I like to learn different stuff from you... As others have pointed out, its easy enough to check the docs for command line tools
      - grayhatter 3y ago
        > I think you're actually filtering on people that are curious about the same things you are. Learning things because you're curious is pretty much a 'free-time' activity. Tech is huge, and with all the stuff to learn - I guarantee I'd learn algorithms and data structures over most other stuff... You're right, by the very nature of asking questions that I can think up, I am filtering for a shared knowledge set... But that's kinda the point. There needs to be some shared knowledge set. The person I want to hire needs to be able to talk about more than just data structures. And, unless you've invented one of your own, to me, that seems nothing but rote memorization? How many data structures have you memorized? 1 a week for the past 2 years? and in those last two years, you never used git enough to figure out how to rewrite a commit, nor have an opinion about if you should or shouldn't? > That doesn't mean I don't like learn, just that I like to learn different stuff from you... As others have pointed out, its easy enough to check the docs for command line tools again, for the same reason above, I can look up documentation myself, I don't want to hire someone really good at reading documentation, I need someone who can think, and solve new novel problems... Another of my favorite questions to ask is "what's the first thing you'd do once you found out you were living in a zombie apocalypse?" Nothing to do about tech, but it's a great question to dig into how someone thinks, and if they're able to solve problems they weren't expecting. Just like any interview question worth asking, there's no one right answer. Sure it's great you've memorized every single data structure that exists, and the list of uses that are approved in some text book. But I can read too, that's not impressive, and not a sign of someone who I'd enjoy working with.
- heyitsguay 3y ago
  What if all of their serious coding was done as part of previous employment and they can't just walk you through it?
  - cranberryturkey 3y ago
    Any programmer who isn’t at least coding something on their own to learn something new or out of curiosity isn’t a programmer I would hire.
- deleted 3y ago
  [deleted]
- andrewflnr 3y ago
  Hopefully the fact that pull and rebase are not quite directly comparable is part of your expected answer?
- dmuso 3y ago
  The tech you use to get code to production is so broad, asking these kinds of questions is at best a random chance of successfully hiring a good engineer. You may as well flip a coin. A better approach is to ask a candidate something specific about their experience. Even if someone mentions “git expert” on their resume, the question is not what you proposed but instead asking about their experience and digging in from where they go. An engineer you’re interviewing may have fixed a bug in “git push” but not know anything about how “pull” or “rebase” works.
- renegade-otter 3y ago
  In general, trivia questions are not great, and this is trivia. A candidate may come from an environment where the policy was to merge instead of rebase, and so they might not even be aware of what rebase does.
goles 3y ago
https://archive.is/TmCMd https://archive.is/TmCMd
Terretta 3y ago
Think about time invested in the purchase of an automobile or a house, relative to the cash outlay. Consider how one can get information and predictability around that purchase, as well as the known knowns and unknown unknowns. For a new job from the individual's point of view, think of the life-event risk they're taking on by betting on this new firm. From the firm point of view, particularly for smaller firms (1 - 50), think of the return on equity and opportunity cost. Finally, think about the time spent dating before people move in together, not even get married. On a time per commitment cost / risk-adjusted basis, extensive job interviews may still be underinvesting. All that said, a majority of candidates can be filtered out within 15 minutes. As could, if you care, a majority of workplaces. See also “information asymmetry” and “adverse selection” resulting in disproportionate number of lemons on the market as discussed in “The Market for Lemons: Quality Uncertainty and the Market Mechanism”: https://en.wikipedia.org/wiki/The_Market_for_Lemons https://en.wikipedia.org/wiki/The_Market_for_Lemons
- jackblemming 3y ago
  It doesn’t matter how many hundreds of rounds of interviews and checks you have, you will always run into Bayes Error. You will never be able to filter out assholes who can hold it together for an interview. Or lazy people who get hired and rest and vest. The solution is not to create a hellish interview pipeline that actually competent people will just say no to. The answer is to accept firing people if they’re a bad fit early, with appropriate severance.
  - deleted 3y ago
    [deleted]
  - Terretta 3y ago
    I agree with this. And going further, it would also be nice to normalize "dating around" where a candidate and firms could learn a bit about each other while if it's not a fit, the candidate can continue where they are. If we can do parental leave, we should be able to manage life-change leave. Granted, the logistics, IP, confidentiality, and many other things feel incredibly complicated to sort out. And yet firms work with consultants running around talking to all their competitors, and the world doesn't end. At the same time, keeping people in roles that aren't satisfying for either party makes little pragmatic or personal fulfillment sense, yet most of employment law seems oriented for that. Given the asymmetric stakes, seems worth figuring out ways we could prioritize humans over firms.
impish9208 3y ago
Dupe: https://news.ycombinator.com/item?id=39475214 https://news.ycombinator.com/item?id=39475214
ooterness 3y ago
If your company's interview process involves several days of work, then I'd better be paid at a fair rate for that time.
Manuel_D 3y ago
> Now interviewees are regularly given projects described as requiring just two to three hours that instead take days of work. Not to disparage the subjects, but it sounds like these applicants failed the interview. If a qualified candidate is meant to complete the project in 2-3 hours and it's taking over a day, then that candidate isn't passing this test of productivity. However, companies absolutely should be time-limiting their problems. Precisely because people could use more time than others and generate false positives.
- ozim 3y ago
  How do I schedule 2-3 hours right away after you send me a task? I tell people to do it over the weekend and don’t really count the time. Code solution can be bad and if someone returns bad code after he was able to pick his time. Well. Some people refuse to do 1-2hr take home task, I also thank them for the time. Some people take 2 weeks and then I usually have someone who did task last weekend so I pick one that did it earlier. Some people do it right away after getting task I schedule 2nd round also asap for them. You see I don’t have to limit time just pick candidates that are interested enough to do the task. Also sometimes most productive employees are worst. We had a guy that was so productive refactoring BS in code that he took down month or two months of work of the team.
  - Manuel_D 3y ago
    The timer starts when the problem is revealed. That's how it worked at a company I previously interviewed at. They sent me a link to a page that explained the 3 hour time limit once the prompt is revealed. I had I think two weeks to choose when to start the problem. It was a totally automated interview
    - ozim 3y ago
      Fair enough, I also took some of these interview tasks where you get the link and time counts from when you accessed, totally forgot about them.
- EchoChamberMan 3y ago
tayo42 3y ago
> “After years of tech workers being pampered, of ‘bring your whole selves to work’ and ‘work from anywhere,’ executives are now overcompensating in the other direction,” he says. > “Tech industry job interviews have, of late, reached a new level of absurdity.” This is funny. I wonder if with lay offs a whole bunch of people are finally realizing how abusive the tech interview is. Ive done 3 job searches and each one has been horrible, leaving me multiple times considering switching careers. The one I just finished at the end of last year didnt feel any different process or expectation wise as the one I did 6 years ago. The only difference was it felt like there were less openings and more competition. But the actual interview it self was the same, just as horrible as it has been. I used to give interviews for a team I got promoted multiple times with, I couldn't pass the interview they were having me give. They didn't change it though. > Another worker complained on Blind that preparing for LeetCode questions requires “hundreds of hours” of preparation: “Why are we expected to do the coding Olympics for every company that wants to interview you?” Cracking the coding interview came out in 2008. 14 years ago, none of this is new.
- callwhendone 3y ago
  > Cracking the coding interview came out in 2008. 14 years ago, none of this is new. Considering that Cracking the Coding Interview is no longer enough for most people, I think it's fair to say that the difficulty has increased.
  - tayo42 3y ago
    Is it really not enough? It seems the same, except its a $40 book when leetcode just has more stuff and its free.
    - EchoChamberMan 3y ago
      It sounds like you've done 2 interviews in 6 or more years... Maybe you're not up to speed with the average experience?
randcraw 3y ago
For perspective, applying for a coding job 30 years ago used to involve ONE phone interview that lasted no more than an hour, followed within a week by an in-person visit at the site. In contrast today's insanely laborious interview process sounds like undergoing the Spanish Inquisition. Before the rise of FAANGs, the interview visit consumed between 1-2 hours (if it was a car drive away) and no more than one day (if a plane ride) with absolutely no homework. In-person, you talked to between 3 and 8 people. At most onerous, the discussion might involve a little pseudocode or drawing diagrams on a white board to show you possessed the skills most prized back then -- fluency in design concepts, the ability to focus and reason well, to communicate ably, and to think on your feet. Syntax skills were presumed given that you had a degree in CS and a history of not being fired from previous jobs. References were checked which also filtered out the boobs, so testing your your code fluency was overkill. Multiple rounds of phone interviews were rare; multiple visits happened NEVER. Apparently these days, your academic and professional track record and references count for zero. Instead, you must show you can generate code at high speed -- as if you were a newb grad who likely might turn out to be able only to pass true/false tests in the classroom. Do degrees and references now count for so little? Must the number of interviewers exceed double digits? If so, THAT's a broken system.
- btreecat 3y ago
  Most schools still teach CS, but most the industry needs SWE. So the degree isn't an indicator you know how to build products as much as it is you can't stick out a 4yr program and do Big O notation.
- ThrowawayR2 3y ago
  For perspective, thirty years ago programming was a career for motivated dorks and weirdos and didn't interest normal people, computers were so underpowered that simply getting it to do something implied much more competence than it does today, and software industry salaries weren't insanely overinflated so there were fewer unqualified applicants. The hiring situation thirty years ago doesn't seem that relevant to today.

49 points by ra7 3y ago

oh yes. i ask one advanced question when i interview. something like "what's the difference between git rebase and git pull" -- if they know you're good to go. the other route I take is to have a candidate walk me through some code they have, if they don't have any code then i don't hire them. period.

hardware2win 3y ago
Git questions are weird for me Cuz, I use git gui and I switch to cli like a once a month at best, so I dont really remember the commands nor see the value in putting effort into it It feels like people fixated on git details think everyone has the same work flow as they do, so for them it feels like git cli proficiency is really needed. It is like asking about vsCode shortcuts (it'd probably be even more useful, since you spend more time in your editor) Id really prefer being asked about algos, compilers, web dev, system design, whatever heavily software related (even religious topics like SOLID) than boring tools which can be used in various ways
- cranberryturkey 3y ago
  that's a fair point but i valud people who value the cli over guis. not that you can't use a gui but its much better to know what its doing under the hood.
  - hardware2win 3y ago
    >its much better to know what its doing under the hood. I agree when it comes to programming langs, libs, compilers and in general computers. Because knowledge of those things significantly affects your output (code) But git? I treat it the same way I treat email client, power point or chat app used at work. Hell, I could probably benefit more from high power point skills than high git skills.
    - cranberryturkey 3y ago
      I also ask people to walk me through some recent code they write. So if you didn’t know the git answer no biggie
      - tharkun__ 3y ago
        Caveat not your parent. What's recent? I have a busy life. I don't really code outside of work any more. I do woodworking or something else. The newest code you'll see from me is probably when I tried to make a game using Roblox just for fun for the kids. That's been a while. I don't have a github account and that's on purpose. I don't do open source work any longer and the most recent you'll find is probably 20 years old. Code from work? Not gonna show that to you or you're not gonna hire me because I break NDAs ;) Personally I do like the git one tho. Even if you use a GUI (unless it renames things it really shouldn't) would allow someone to answer what the conceptual differences are between pulling and rebasing! FWIW: pull is a combination of fetch+merge, so not a rebase at all. They can be similar, in case your pull and rebase both happen to result in a simple fast-forward operation, which is literally just "moving a label" (or in 'real' terms, changing a commit hash inside one file in the .git directory). Am I hired?
        grayhatter 3y ago
        you answered the git question passibly IMO, so perhaps you could be hired? But what heuristic would you suggest for someone that doesn't know git at all, and doesn't ever write code for fun or to solve problems on their own?
        tharkun__ 3y ago
        If someone has never used git, they probably used <somethingElse>. I would hope they're witty enough to ask the interviewer back: "I dunno, never used git, we use Rational ClearCase. Can you tell me what the difference is between a reserved and unreserved checkout and when would you use each?" Probably not in an interview situation, especially if they need the job, but would be fun! Just coz I don't code for fun any longer, what tells you I don't solve problems on my own (both at work or at home)? Getting into woodworking required a lot of figuring out new stuff, including the part of actually doing something with my hands. It was particularly fun because it was new and needed figuring out. Figuring out why the heck the last distro upgrade decided to not be able to find my LVM volumes on software RAID and I thought I had lost all my data was also a fun problem to solve. It required zero code. But it required a lot of debugging and interpreting things I don't know the actual implemtation details of. Something I see a lot of devs being bad at. Fixing bugs. I.e. investigating unknowns.
  - gregors 3y ago
    I think it's a fair question. I would never not hire someone over not knowing that particular flow though. Also, I've never had any developers I've hired not be able to learn it quickly. The fact that they don't know it does tell you that they're either not rebasing or not using the cli. The discussion around those process topics are more interesting to me than them not knowing it to begin with. For example, "well what is your process around git usage in general?" etc, "how well do you know the cli?" etc. Interviews are all about conversations. I would tell them they'll learn the cli git if they join my team. Maybe that's not something they're into? I guess that's part of the "fit" of a team. At one point there was lots of discussion regarding rebasing in general on our team and another shop. This blog post came out of that. I know many people who feel differently of course. I do expect seniors to have an opinion on the matter either way I guess. https://blog.carbonfive.com/always-squash-and-rebase-your-git-commits/ https://blog.carbonfive.com/always-squash-and-rebase-your-gi...
- grayhatter 3y ago
  > so I dont really remember the commands nor see the value in putting effort into it curiosity? knowing everything you can about the world around you? having used what is possibly the most critical piece of software for working with other people that you encountered some rare exception to common workflows that required you to learn more about the plumbing? > It is like asking about vsCode shortcuts (it'd probably be even more useful, since you spend more time in your editor) My editor isn't vscode, so vscode shortcuts wouldn't be helpful to me, the interviever. But again, it's about ability to work with others, the demonstration that you understand systems that you could get away without knowing. You're right, you can be productive while understanding nothing about git, that doesn't mean you're good, or competent, just productive. I don't want to hire people who can write thousands of lines of code, I want to hire people who can do the same in just 100 lines. > than boring tools which can be used in various ways that's really what it comes down to isn't it. It's not interesting to you so you don't want to invest the time in learning it because it's boring. I doubt anyone would agree knowing fewer things is better, so I cant help but read this as sharpening my ax is boring, so I just don't do it.
  - AnimalMuppet 3y ago
    > > so I dont really remember the commands nor see the value in putting effort into it > curiosity? knowing everything you can about the world around you? There is far more out there to learn than I have time and energy to learn. "Here's something you can learn" does not even begin to reach the bar of "I should learn this". > having used what is possibly the most critical piece of software for working with other people that you encountered some rare exception to common workflows that required you to learn more about the plumbing? With one exception, everywhere I have worked has not used git. The one exception used it for one or two years. I know more about four other version control systems than I do about git. And, since you're talking about learning to use the most critical piece of software for working with other people, and chewing out the GP for not wanting to invest the time... why don't you begin your sentences with capital letters? Written English is one of the most critical pieces of, not software exactly, but at least "tech", for working with other people.
    - 3y ago
bsder 3y ago
Those of us who have been around long enough know that Git knowledge is useless knowledge as it will disappear at some point. As did SCCS, RCS, CVS, and SVN ... Build systems and source control systems are shit work that are in the way of doing what I need to do. Basing interview questions on that is absurd.
- lucisferre 3y ago
  It is a simple matter of having current and relevant knowledge for the role. Would I hire a junior developer who didn't know much or even anything about using git? Probably. Would I question the seniority of a so-called senior developer who didn't know the basic usages of the most dominant source control tool for the past 15 years? Absolutely. If they had a good explanation for that gap in knowledge, like working for the past 20 years somewhere that was stuck in legacy code and running on SVN, I'd definitely take that into consideration. I might still want to be certain this candidate is smart enough to quickly pivot into a new codebase and new tools. I've met many people who struggle with exactly that kind of change which is exactly why they don't keep their knowledge current. I'll admit that asking people how git works isn't a question I would ask in an interview. Playing devil's advocate though, I would probably not hire someone claiming to be a senior developer who doesn't know how git works.
  - bsder 3y ago
    Maybe I think that the user experience of Git sucks balls and have no desire to learn it at any level beyond the bare minimum. Maybe I use better systems like Mercurial or Perforce or anything designed more recently than the last 20 years. Maybe I think that Github is a pox upon the planet and their promulgation of the One True Workflow(tm) (pull requests) is an abomination brought about by technical architecture limitations of Github. I use Git only because other people force me to use Git. Otherwise, I use something better.
    - lucisferre 3y ago
      I mean that's certainly an opinion, but I'm not sure I'd be confident hiring someone into a company that uses a tool that the candidate hates so passionately. Also Git and Mercurial are about the same age and less than 20 years old. Perforce is far older than both of them.
kjkjadksj 3y ago
Thats so strange to me. I work with git every day and don’t use rebase. If you asked me in the interview I’d fail that. But if you asked me that question in real life I’d give you the answer in 30 seconds after looking at the documentation, and everything would carry on without a hitch.
- grayhatter 3y ago
  you don't even know what it does enough to say, > I don't really use it but from what I remember... also here's a lot of details about the steps that go into the porcelain command git pull. I don't use VS code but I know the difference between the command palette and the sidebar file explorer and could answer a bunch of questions about it. I think the point of the question is to filter out people who aren't curious. Which isn't perfect for the ability of a job candidate to be successful, but does happen to have an incredibly strong correlation.
  - mech422 3y ago
    >>I think the point of the question is to filter out people who aren't curious. I think you're actually filtering on people that are curious about the same things you are. Learning things because you're curious is pretty much a 'free-time' activity. Tech is huge, and with all the stuff to learn - I guarantee I'd learn algorithms and data structures over most other stuff... That doesn't mean I don't like learn, just that I like to learn different stuff from you... As others have pointed out, its easy enough to check the docs for command line tools
    - grayhatter 3y ago
      > I think you're actually filtering on people that are curious about the same things you are. Learning things because you're curious is pretty much a 'free-time' activity. Tech is huge, and with all the stuff to learn - I guarantee I'd learn algorithms and data structures over most other stuff... You're right, by the very nature of asking questions that I can think up, I am filtering for a shared knowledge set... But that's kinda the point. There needs to be some shared knowledge set. The person I want to hire needs to be able to talk about more than just data structures. And, unless you've invented one of your own, to me, that seems nothing but rote memorization? How many data structures have you memorized? 1 a week for the past 2 years? and in those last two years, you never used git enough to figure out how to rewrite a commit, nor have an opinion about if you should or shouldn't? > That doesn't mean I don't like learn, just that I like to learn different stuff from you... As others have pointed out, its easy enough to check the docs for command line tools again, for the same reason above, I can look up documentation myself, I don't want to hire someone really good at reading documentation, I need someone who can think, and solve new novel problems... Another of my favorite questions to ask is "what's the first thing you'd do once you found out you were living in a zombie apocalypse?" Nothing to do about tech, but it's a great question to dig into how someone thinks, and if they're able to solve problems they weren't expecting. Just like any interview question worth asking, there's no one right answer. Sure it's great you've memorized every single data structure that exists, and the list of uses that are approved in some text book. But I can read too, that's not impressive, and not a sign of someone who I'd enjoy working with.
heyitsguay 3y ago
What if all of their serious coding was done as part of previous employment and they can't just walk you through it?
- cranberryturkey 3y ago
  Any programmer who isn’t at least coding something on their own to learn something new or out of curiosity isn’t a programmer I would hire.
deleted 3y ago
[deleted]
andrewflnr 3y ago
Hopefully the fact that pull and rebase are not quite directly comparable is part of your expected answer?
dmuso 3y ago
The tech you use to get code to production is so broad, asking these kinds of questions is at best a random chance of successfully hiring a good engineer. You may as well flip a coin. A better approach is to ask a candidate something specific about their experience. Even if someone mentions “git expert” on their resume, the question is not what you proposed but instead asking about their experience and digging in from where they go. An engineer you’re interviewing may have fixed a bug in “git push” but not know anything about how “pull” or “rebase” works.
renegade-otter 3y ago
In general, trivia questions are not great, and this is trivia. A candidate may come from an environment where the policy was to merge instead of rebase, and so they might not even be aware of what rebase does.

goles 3y ago

https://archive.is/TmCMd https://archive.is/TmCMd

Terretta 3y ago

Think about time invested in the purchase of an automobile or a house, relative to the cash outlay. Consider how one can get information and predictability around that purchase, as well as the known knowns and unknown unknowns. For a new job from the individual's point of view, think of the life-event risk they're taking on by betting on this new firm. From the firm point of view, particularly for smaller firms (1 - 50), think of the return on equity and opportunity cost. Finally, think about the time spent dating before people move in together, not even get married. On a time per commitment cost / risk-adjusted basis, extensive job interviews may still be underinvesting. All that said, a majority of candidates can be filtered out within 15 minutes. As could, if you care, a majority of workplaces. See also “information asymmetry” and “adverse selection” resulting in disproportionate number of lemons on the market as discussed in “The Market for Lemons: Quality Uncertainty and the Market Mechanism”: https://en.wikipedia.org/wiki/The_Market_for_Lemons https://en.wikipedia.org/wiki/The_Market_for_Lemons

jackblemming 3y ago
It doesn’t matter how many hundreds of rounds of interviews and checks you have, you will always run into Bayes Error. You will never be able to filter out assholes who can hold it together for an interview. Or lazy people who get hired and rest and vest. The solution is not to create a hellish interview pipeline that actually competent people will just say no to. The answer is to accept firing people if they’re a bad fit early, with appropriate severance.
- deleted 3y ago
  [deleted]
- Terretta 3y ago
  I agree with this. And going further, it would also be nice to normalize "dating around" where a candidate and firms could learn a bit about each other while if it's not a fit, the candidate can continue where they are. If we can do parental leave, we should be able to manage life-change leave. Granted, the logistics, IP, confidentiality, and many other things feel incredibly complicated to sort out. And yet firms work with consultants running around talking to all their competitors, and the world doesn't end. At the same time, keeping people in roles that aren't satisfying for either party makes little pragmatic or personal fulfillment sense, yet most of employment law seems oriented for that. Given the asymmetric stakes, seems worth figuring out ways we could prioritize humans over firms.

impish9208 3y ago

Dupe: https://news.ycombinator.com/item?id=39475214 https://news.ycombinator.com/item?id=39475214

ooterness 3y ago

If your company's interview process involves several days of work, then I'd better be paid at a fair rate for that time.

Manuel_D 3y ago

> Now interviewees are regularly given projects described as requiring just two to three hours that instead take days of work. Not to disparage the subjects, but it sounds like these applicants failed the interview. If a qualified candidate is meant to complete the project in 2-3 hours and it's taking over a day, then that candidate isn't passing this test of productivity. However, companies absolutely should be time-limiting their problems. Precisely because people could use more time than others and generate false positives.

ozim 3y ago
How do I schedule 2-3 hours right away after you send me a task? I tell people to do it over the weekend and don’t really count the time. Code solution can be bad and if someone returns bad code after he was able to pick his time. Well. Some people refuse to do 1-2hr take home task, I also thank them for the time. Some people take 2 weeks and then I usually have someone who did task last weekend so I pick one that did it earlier. Some people do it right away after getting task I schedule 2nd round also asap for them. You see I don’t have to limit time just pick candidates that are interested enough to do the task. Also sometimes most productive employees are worst. We had a guy that was so productive refactoring BS in code that he took down month or two months of work of the team.
- Manuel_D 3y ago
  The timer starts when the problem is revealed. That's how it worked at a company I previously interviewed at. They sent me a link to a page that explained the 3 hour time limit once the prompt is revealed. I had I think two weeks to choose when to start the problem. It was a totally automated interview
  - ozim 3y ago
    Fair enough, I also took some of these interview tasks where you get the link and time counts from when you accessed, totally forgot about them.
EchoChamberMan 3y ago

tayo42 3y ago

> “After years of tech workers being pampered, of ‘bring your whole selves to work’ and ‘work from anywhere,’ executives are now overcompensating in the other direction,” he says. > “Tech industry job interviews have, of late, reached a new level of absurdity.” This is funny. I wonder if with lay offs a whole bunch of people are finally realizing how abusive the tech interview is. Ive done 3 job searches and each one has been horrible, leaving me multiple times considering switching careers. The one I just finished at the end of last year didnt feel any different process or expectation wise as the one I did 6 years ago. The only difference was it felt like there were less openings and more competition. But the actual interview it self was the same, just as horrible as it has been. I used to give interviews for a team I got promoted multiple times with, I couldn't pass the interview they were having me give. They didn't change it though. > Another worker complained on Blind that preparing for LeetCode questions requires “hundreds of hours” of preparation: “Why are we expected to do the coding Olympics for every company that wants to interview you?” Cracking the coding interview came out in 2008. 14 years ago, none of this is new.

callwhendone 3y ago
> Cracking the coding interview came out in 2008. 14 years ago, none of this is new. Considering that Cracking the Coding Interview is no longer enough for most people, I think it's fair to say that the difficulty has increased.
- tayo42 3y ago
  Is it really not enough? It seems the same, except its a $40 book when leetcode just has more stuff and its free.
  - EchoChamberMan 3y ago
    It sounds like you've done 2 interviews in 6 or more years... Maybe you're not up to speed with the average experience?

randcraw 3y ago

For perspective, applying for a coding job 30 years ago used to involve ONE phone interview that lasted no more than an hour, followed within a week by an in-person visit at the site. In contrast today's insanely laborious interview process sounds like undergoing the Spanish Inquisition. Before the rise of FAANGs, the interview visit consumed between 1-2 hours (if it was a car drive away) and no more than one day (if a plane ride) with absolutely no homework. In-person, you talked to between 3 and 8 people. At most onerous, the discussion might involve a little pseudocode or drawing diagrams on a white board to show you possessed the skills most prized back then -- fluency in design concepts, the ability to focus and reason well, to communicate ably, and to think on your feet. Syntax skills were presumed given that you had a degree in CS and a history of not being fired from previous jobs. References were checked which also filtered out the boobs, so testing your your code fluency was overkill. Multiple rounds of phone interviews were rare; multiple visits happened NEVER. Apparently these days, your academic and professional track record and references count for zero. Instead, you must show you can generate code at high speed -- as if you were a newb grad who likely might turn out to be able only to pass true/false tests in the classroom. Do degrees and references now count for so little? Must the number of interviewers exceed double digits? If so, THAT's a broken system.

btreecat 3y ago
Most schools still teach CS, but most the industry needs SWE. So the degree isn't an indicator you know how to build products as much as it is you can't stick out a 4yr program and do Big O notation.
ThrowawayR2 3y ago
For perspective, thirty years ago programming was a career for motivated dorks and weirdos and didn't interest normal people, computers were so underpowered that simply getting it to do something implied much more competence than it does today, and software industry salaries weren't insanely overinflated so there were fewer unqualified applicants. The hiring situation thirty years ago doesn't seem that relevant to today.