71 ms·

The software industry's greatest sin: hiring

• redis_mlc 7y ago
  The interview question that best exemplifies what Neil wrote is, "Did you write it yourself, or as part of a team?" Both answers are wrong, depending on the interviewer. If you say "yourself", you're admitting you're a lone wolf. If you say "team", then you were along for the ride, even if only two people were on the team.
  • sumanthvepa 7y ago
    Just state the facts and let the chips fall as they will. There is no point trying to second guess your interviewer.
  • otab111 7y ago
    I mean a candidate should be able to distinguish their contribution to a project in some more fine grained way than this. If they come from freelance and say "I wrote the code on my own" that's fine but maybe you could mention how you communicated with the client to establish requirements and milestones and get to a successful delivery. If you worked in a team you should be even more able to explain your individual contribution & the context in which you worked. This is not a trick question. A good answer is "I did x, y, and z tasks, which required a, b, and c interactions with the world around me to make sure I was doing the right work and meeting expectations".
    • anonymoushn 7y ago
      I once failed this question at a FAANG company. We were talking about a recent project that my company did with Pivotal. So like every project Pivotal does, we spent about one day a week dividing up the upcoming work into tiny pieces, then we spent the other four days pair programming by doing whatever the top task on the backlog was. Predictibly, on a team that had 3 pairs, this means I or my pair did about 1/3 of all things, distributed somewhat uniformly throughout the project. "What parts are you solely responsible for?" 0 things, the same as everyone else who worked on this project! Wrong answer though.
  • renewiltord 7y ago
    But that's the best part! You can describe the truth and the way you would have liked it to have gone and the employer will self-select themselves out if they're not the kind of culture you desire. It's like they're doing the work for you so you don't end up at a job at a place you don't like!
• non-entity 7y ago
  That "bad hires" section describes a lot of people I've know and worked with and tbh, I kind of feel sorry for them. They're often incredibly intelligent people that want to apply themselves. We hired this one guy who constantly attempts to re-architect and rewrite various systems on his own, just to have his works rejected. At the same time, some of these guys are seniors. How on earth have you been in the industry for this long and not grasped what your job is?
  • drchickensalad 7y ago
    I think in this field, it's not at all guaranteed that years worked means better. For some people, they grow a mountain in a year. For others, barely at all. Honestly I agree with your pain because the above situation is also not completely tied to how much you care. Luckily though, most of the time it is.
• ra5 7y ago
  Agree with all points made. Especially with the first point (engineer hiring tends to be one dimensional) as well as the “your company is who you hire” point - and even the google example given for that point. Google is great at software. No one writes better software than google hands down, but what you/they learn is that it’s not always about how good you code (else GCP would be the #1 cloud platform). Great write up
  • throwaway00081 7y ago
    "No one writes better software than google hands down" When was the last time you worked within Google?
• sumanthvepa 7y ago
  This makes so much sense. I've stopped doing in-depth technical interviews for precisely this reason. Instead, I take the developer out for lunch and spend an afternoon discussing our software stack and business with them. It always gives be better results. There is no stress. I don't want to see their code, but I do want to understand how they think and work.
  • dsaavy 7y ago
    Love this idea, going to steal it for the next time I'm hiring someone.
  • mattbillenstein 7y ago
    You should absolutely see how they code - I've interviewed so many people on the phone who couldn't code their way out of a paper bag, but they could speak to it enough to fool you.
    • missosoup 7y ago
      Maybe enough to fool you. It's pretty easy to tell if someone knows a topic or not by just asking increasingly more specific technical questions to follow up on their answers.
      • sumanthvepa 7y ago
        This exactly. Start with general questions and get more specific until they are unable to answer or they exceed the depth of your own knowledge on the topic. You’ll be surprised how often that good candidate will take you out of your depth.
      • mattbillenstein 7y ago
        Maybe - I mean, you just get signal from actual coding, I think it's pretty hard to discount entirely. How they solve problems, what mistakes they make, how they debug - I think it's just too valuable to not spend some time on. And I'm not giving them riddles - I give them easily solvable problems that can be done in almost any programming language. And I've given the same problems enough to know what it canonically looks like in a dozen languages.
• mattbillenstein 7y ago
  You sorta evaluate the soft skills while evaluating the hard skills - how they approach a question, how they solve the problem, etc. Our general rule hiring was hire sharp people, but no assholes - at least nobody more of an asshole than I am ;) I think the biggest problem is actually whiteboard coding problems - nobody does that in real life.
  • the_arun 7y ago
    I think designing on whiteboard helps if not coding. Designing shows the big picture they have in mind for solving the problem.
    • jakear 7y ago
      Coding on a whiteboard is the worst. I’ve been in google interviews where I mention that the whiteboard format makes the process very difficult because of how much work it is to rework existing code. The interview replied “well wouldn’t you have to do the same on a computer?” chuckles to himself at how clever he is that he realized that No numb-nuts, on a computer I can move lines around by pressing Alt+Down. Here I need to erase the entire thing and re-write it, which wastes precious time, so instead I spend way more time pre-planning the exact layout of the code, which wastes more precious time. And in the end you take a picture of it to transcribe into the computer to send to the hiring overlords. Just let us use our tooling to begin with. Ugh.
      • sgerenser 7y ago
        Last time I interviewed with Google (in 2018) they had me code on a Chromebook. Still just dumb algo questions but much better than a whiteboard.
        • jakear 7y ago
          Interesting. This was 2019, but it was a SRE position. Don't know if that makes a difference. Probably not, because the interviewers didn't even know it was for an SRE position.
• thaumasiotes 7y ago
  > when a developer is hired, it is incredible the extent to which the process will ignore the human being and focus exclusively on algorithmic/technical aspects. It's a disguised IQ test, and we all know it. > What's crazy is most people hiring will even throw away your ability to learn and adapt! These conflict. At the very least, the second quote illustrates that the hiring people are not aware that the interview is meant to be a disguised IQ test.
• bfrog 7y ago
  I feel like this explains the needless product abandonment and reinventing at Google.
• jorblumesea 7y ago
  The worst part about hiring is once you're into the "elite circles" it becomes less work. Work for a FAANG? Getting a much becomes far easier and sometimes with less difficult questions. Whether you agree with the IQ test or not, it's not even a level playing field or merit based. It's about an elite club keeping things elite. Half the engineers working for FB, Google etc would not get hired today. Yet they still ask questions that they would not be able to answer as a form of gate keeping.
  • tictoc 7y ago
    If they prepared, why wouldn't they be hired? Unless there is rampant ageism.
  • mwerty 7y ago
    >Half the engineers working for FB, Google etc would not get hired today. I thought people jump around a lot these days.
    • TheSpiceIsLife 7y ago
      That doesn’t invalidate the idea that half, or some other portion, don’t.
      • mwerty 7y ago
        don’t =/= can’t.
    • AnimalMuppet 7y ago
      Good people may. But if you work at FB or Google, and you realize that you're less talented than many of the others there, but they're willing to keep paying you FB or Google salaries... you probably don't leave.
  • asveikau 7y ago
    > Half the engineers working for FB, Google etc would not get hired today. I think this is actually getting at why people ignore work history and what projects a candidate was involved in. When you get into these places you realize how little that name brand means. There are a lot of not particularly bright people at those places. Or more charitably, maybe bright people but not particularly skilled at software engineering, for some definition thereof. Sometimes those people can attach themselves to a well known project name. But what did they do for that project? Were they constructive or not? You can't really tell based on their word alone. Maybe they can charm their way out of that discussion. It's also not unheard of that they could be taking some credit from peers. So people come up with the quizzes and IQ tests, however flawed, as a way to "verify".
• tictoc 7y ago
  Is it actually an IQ test? Can you practice for an iq test like you can for an interview? I don't see it being that difficult to just grind on leetcode enough to snag a FAANG job.
  • SpicyLemonZest 7y ago
    It's not that difficult for people smart enough to get a FAANG job. Personally, I've heard anecdotes from people who can't understand leetcode problems even when given the solution. Professionally, I've seen multiple people who were clearly trying to recite a memorized solution for an interview problem, but just weren't clever enough to do it properly or talk about how it works.
    • opportune 7y ago
      For all the complaints about whiteboarding, it does filter out a lot of people who can't seem to generalize problems or are weak at either problem solving or coding. I don't see how anyone who has given technical interviews could say whiteboarding is a waste of time, unless they are not good enough at whiteboarding to be able to productively give such an interview.
  • oreally 7y ago
    Nope, it's more of a case of software engineers stroking their own egos. Grinding leetcode is the prime example of that - developers worshipping crystallized knowledge when the IQ test is supposed to test for how quickly someone can learn rather than relying on rote.
• analog31 7y ago
  To the best of my knowledge, my workplace uses a fairly traditional hiring process that's the same for hiring a programmer or a machinist: Resume screen, phone screen, on-site, offer. I have to say we do really darn well, especially given we're located in the Midwest and supposedly the brightest programmers have fled to the hot markets. One thing I like is that we get a range of ages, which is heartwarming given that I'm over 50 myself. The thing to do is look around at your colleagues and ask if the hiring process is really broken. It may be that we've all been driven into a panic about hiring, by the hiring industry.
  • ahmedalsudani 7y ago
    Out of curiosity, where in the Midwest?
    • AnimalMuppet 7y ago
      And, if you have both software people and machinists, do you do embedded software?
      • analog31 7y ago
        I don't want to identify myself too much, but we make measurement equipment, so we have a real mix of skill sets. The machinist is kind of an extreme case, but we also have people in general administrative roles, etc.
  • thaumasiotes 7y ago
    > a fairly traditional hiring process that's the same for hiring a programmer or a machinist: Resume screen, phone screen, on-site, offer. Some years ago, I was looking for a job, and an employed friend of mine sent me a problem and said "this is our hiring challenge. Try it out". I completed it, and she asked for my resume, and turned in both to whoever the relevant person was at her company. She then reported back to me "he said this is the best response he's ever seen to the challenge, but we're looking for someone with more experience". I was not contacted by anyone else. And years later, when I ribbed her about this, she told me "he regretted that, later". I note that by putting the resumé screen first, you're committing yourself to the idea that whatever you're looking for in the resumé screen is more important than anything you might learn in the phone screen or the on-site. Do you believe that? Are the phases looking for the same things? If not, is that intentional?
• ausjke 7y ago
  The best way I see it, is to have this guy to work for a while, say a few weeks or a few months as a contractor, then either ends it or converts to a permanent job. This is the best interview approach.
  • the_arun 7y ago
    +1, agreed. The industry needs to have a better process for it. Say first month is evaluation or something and if you have two job offers, you schedule it on your calendar sequentially.
  • renewiltord 7y ago
    You're probably locking out a lot of foreigners that way, but if you find that your top-of-funnel has enough people, this will work really well. Lots of the consultant gigs that people do actually end up with being hired at the company they consulted for.
  • tonyedgecombe 7y ago
    When I was contracting I would nearly always get a job offer at the end of the contract. I always turned them down because I wanted to be a contractor, not an employee. I expect the converse applies as well, someone who likes being an employee is unlikely to take up your offer.
  • rsynnott 7y ago
    Honestly that would filter out basically anyone senior, and anyone who could get an actual job elsewhere. Given the choice of going through a normal tech interview process before leaving my current job, or leaving my job for this, why on earth would I pick this?
• quezzle 7y ago
  I did a coding test the other day. To be fair they said don’t put more than 2 to 4 hours in. However I’m not someone who can fail to meet the requirements so I spent 8 hours building it to meet the requirements exactly. Heard nothing at all back. Silence.
  • magicalhippo 7y ago
    I'm assuming it was for other reasons, but it is possible they did see you put all that extra effort into it and figured that's not the sort of person they want. At least at my job, balancing the time spent on various issues is very important.
    • quezzle 7y ago
      No matter what they say, handing in a half done coding test because you ran out of time is a fail. IMO anyway. Probably it was virus related but I’m not very enthused about doing coding tests any more.
      • zebnyc 7y ago
        Totally agreed. More often than not, I have failed the automated graded filter tests. I seem to have better results when I know that the company is also taking the process seriously for e.g., allocating an employee's time to evaluate me over the phone / in-person
    • gouggoug 7y ago
      > figured that's not the sort of person they want For sure; Now it is still absolutely inadmissible and disrespectful to ghost a candidate.
  • gwbas1c 7y ago
    I always walk away from those situations. I just don't have 8 hours I can give unless I'm 80% confident it'll work out, or I just want an excuse to try some new tech.
• jackcosgrove 7y ago
  Technical interviews were once seen as a breath of fresh air. You can be a nobody without connections or degrees and if you can prove you have skills during an interview process you may be hired. Contrast this with other hiring processes which are more irrational, like med residency match, investment banks favoring "target school graduates", law firms favoring "top 14 graduates", etc. I think whiteboarding is dumb and I'm increasingly unwilling to go through with it. That's a hurdle. But in many careers the hiring processes are walls, as in there is 0% chance you'll get hired. Because you don't know someone, because you didn't go to the right school. The barriers have little correlation with ability to do the job, and more importantly after some milestone has been crossed it's impossible for you to improve your chances.
  • agumonkey 7y ago
    Maybe due to the importance of soft skills ? or maybe a shift into the belief that they are important ? How was it in the 80s or 90s ? could you be hired just because you can fix or implement something even if you don't fit that well with a group ?
    • jackcosgrove 7y ago
      80s: we need to hire somebody who can code 90s: we need to hire everybody who can code
  • fossuser 7y ago
    It’s largely still that way - you need to know someone to get the referral to get the whiteboard interview (after two phone screens). That said it’s at least a partially objective skill check and I don’t know a better way.
    • kamikaz1k 7y ago
      Plenty of people freely offer referrals, since they get referral bonuses (or feel like they wanna help people out).
• johnmarcus 7y ago
  As someone currently interviewing, with 10ys exp scaling multiple successful companies, I couldn't agree more. Some of the tech questions I've been asked are so useless in practice it's unnerving.
• renewiltord 7y ago
  You've got to know if the other person can code. Lots of people can talk a mean game and make nothing and few people can spot them. That's the thing, though. If you make a reputation as the kind of guy who can near 100% spot the good engineers, you will make boatloads of money. An employer will pay you more than $30k if you only do great hires. You do 10 of them with your conversation out to lunch and you've made $300k. That's the low-end. But no one can do that and the few with high hit-rates act as executive-search agencies where they make a lot more. But I think I would never interview anyone I've worked with. That just seems like a waste. I already either know that they can or can't do things.
  • lumost 7y ago
    It's worthwhile to interview the people you've worked with as they change over time, usually for the better with Junior Engineers becoming Senior or Principal Engineers, DBAs becoming engineers etc. But sometimes a long stint in management or getting stuck in KTLO hell for a few years can dull technical skills.
    • renewiltord 7y ago
      That's a fair point. Perhaps this is what people are talking about the conversations over lunch. I find it hard to believe that someone who wants to work as an IC and knows you would try to do that knowing their skills had dulled. The shame of failing someone who trusted you to deliver would be too much!
    • redis_mlc 7y ago
      > DBAs becoming engineers Excuse me. Most of the top DBAs in Silicon Valley are former C programmers who probably are better programmers than you. I wish programmers would get over themselves. I've met CTOs who didn't know EXPLAIN. So who's the real engineer?
      • google234123 7y ago
        What is EXPLAIN?
• papeda 7y ago
  The problem I keep running into is that the more room for nuance and fit and holistic evaluation that you inject into a hiring process, the more room there is for interviewers to fill that space with their own biases toward hiring people like themselves. In that sense, the white board problems are pretty fair, even if they're (very) imperfect.
• lazyjones 7y ago
  People who hire developers wouldn't be as focused on the candidates' experience with the technology in the job ad if developers were typically more open for new tech that would be learnt at the job. Try to teach a 40+ Perl developer a new language if you want to see what I mean... When you compare IT with other industries like the author did, this is what makes hiring so different. Other industries are fine with hiring graduates with no specific experience and the candidates are eager to learn on the job. Whereas in IT, half the people will tell you "can't do this", "don't like that", "won't learn Java" ...
  • michael_storm 7y ago
    Ageism isn't cool, dude.
    • deleted 7y ago
      [deleted]
  • cableshaft 7y ago
    I’m almost 40. I can learn new programming languages just fine, thank you. And new languages/tech generally aren’t too hard to pick up once you’ve learned a few, for the most part. They do a lot of the same things, just the incantations are different. I do have more non-coding hobbies now and other responsibilities sucking up more time than when I was young, so I don’t have as much time to learn them on my own, but I still can and do learn them, especially if needed at work.
    • scollet 7y ago
      Thanks for that. Necessity is is me chopping wood for 8 hours. Everything else is enjoying the fire.
  • grumple 7y ago
    I've worked with guys in their 50s and 60s who learned new languages and picked them up and wielded them with far more skill than some 20-something kid.
• dahart 7y ago
  > Developer hiring is broken This seems to be a pretty popular opinion. It totally might be right, but it’s not my own experience, so I have a serious question because maybe I don’t know what’s happening out there with most hiring today - what are the broad-stroke outcomes that demonstrate that hiring isn’t working? Are there statistics that show that hiring has problems? All of the reasons given in the article are claims without evidence, nor objective comparison to hiring for other industries. When looking for jobs, I’ve never been evaluated on IQ or code alone, it has always come with communication and personality and culture fit evaluations, among many other things. When hiring, my own team does everything this article claims isn’t being done. So I might be completely unaware of the major trends out there... how can I see those trends from where I sit? Are people not getting jobs who should, has there been high unemployment? Are companies not able to hire people? If hiring is broken, what are the problems it’s causing? > It's a disguised IQ test It is amusing to me that many blog posts and comments around here argue for exactly that under the same banner ‘hiring is broken’. Lots of developers are frustrated about being evaluated by how well they communicate and not by their code. Lots of people here complain about in-person interviews and tests and argue that take-home coding should be the norm, or that coding tests should not used at all.
  • jariel 7y ago
    One thing I do is: a) Open time. I give them a couple problems in the morning and they can take as long as they want to think about them before the interviews. This takes away the 'deer in headlights' situation that so often happens to people - all of us. I'm good on my feet, but 1 time out 3 'I just don't see it' immediately. But if I have some stress-free time, I usually do. b) Don't test their knowledge of algorithms. Who cares if they've practiced certain things a lot? Doing homework is a small measure of what you want. I give them fairly basic problems that have nice side-show questions to ask and just have a discussion. c) I try to test for knowledge where they should have it: if they've been on tools & build or dev ops they should have a good grasp of things there. Another way to say: you're looking for strengths not weaknesses. I keep an open mind and think 'how can we leverage this person's talent'? Maybe they're not good over here, but better over there. d) Fairly simple code, idiomatic, etc. not rocket science. e) Mature communicator and by that I almost literally mean not too crazy. I think most of us are 'abnormal' and that being a 'decent communicator' is a little bit rare. Companies are full of weird dynamics they have to be resilient a little bit.
• erdos4d 7y ago
  No, the greatest sin of the software industry is the sprint meeting. That's literally a lie we perpetrate every day.
• illuminati1911 7y ago
  Is this really a thing outside US/US companies? I've been now 10 years in software industry (as a developer) in Asia and Europe and never had one of these "whiteboarding algorithm"-interviews. Interviews I have attended might have included something like that, but it's usually 1-5%. Most of the interview is talking about my previous experience, "how would you design a system xyz", homework tasks, "Take a look at this piece of source code for 15mins and tell me what's good and bad about it" etc.
  • stevenwoo 7y ago
    I’m in California but applied for a couple of jobs in Europe. One had a 24 hour timed test on hackerrank to complete 4 of 6 problems (unrelated and complete mini games) and another for an Android position had a timed hackerrank test in Java trivia (disguised as a programming test) with a short time limit. These were the screens so the follow up on sites were probably worse.
  • sgerenser 7y ago
    It’s very common at the big tech companies in the US (FAANG), and by extension many smaller companies that are cargo cutting their hiring practices. But certainly not universal.
• peterwwillis 7y ago
  Maybe that's just a software developer thing? When we hire technical but not primarily software-developer roles, we focus on the particular role's requirements, and the skillset and experience the candidate is bringing. If this is a product support role, have you done product support? If this is an ops role, have you fielded random "urgent" requests from development teams and recovered bad production deploys? Do we need someone who can get something done ASAP, and as such do they have all the needed skills now, or can we wait while they familiarize themselves with a bunch of new stuff? I generally ask few technical questions because I'm mostly interested in everything other than your technical knowledge. I can find 50 people who have taken a coding bootcamp and memorized an entire language's inner workings. And I can usually quickly determine how deep your technical knowledge is by throwing stupidly specific questions at you. But I won't know whether you can apply that knowledge in a way that will gel with the team and the requirements of the role. Which is why most quality candidates come from personal referrals. If you want to get a good job, develop good working relationships.
• ransom1538 7y ago
  My favorite interview was at digg.com. A four hour interview was going great. My dream job. I knew their tech solid. Then the last guy - walked in [ianeure]. He asked: "What is a having statement in sql". I leaped in - rambled on and on how you can filter aggregated sets. His response: "I don't think you know how they work." I sat there confused and concerned. He explained you don't need a group by with a having statement and that I needed to go back and study sql. I sat there awkwardly [I have been writing sql since I was 14 - I was 25]. Welp, he then rolled his eyes and left. Four hours of an interview ruined. Oh well. Yep. That is how tech interviews go. He went on to ruin digg.com (the rewrite everything guy) and I promised myself to never be a dick to people I interview.
  • xigency 7y ago
    Good lesson to take out of a negative experience.
  • gruez 7y ago
    > He explained you don't need a group by in a having statement and that I needed to go back and study sql. I sat there awkwardly [I have been writing sql since I was 14 - I was 25]. He's technically right though. For instance in postgres, you don't need to have a GROUP BY clause when using HAVING https://www.postgresql.org/docs/current/sql-select.html#SQL-HAVING https://www.postgresql.org/docs/current/sql-select.html#SQL-...
    • deleted 7y ago
      [deleted]
    • __s 7y ago
      SQL isn't the most portable language. Postgres has special behavior for aggregates/having without group by which essentially creates an implicit group by, other engines will raise an error (SQL Server iirc) Clearly not something to nitpick over in an interview
    • war1025 7y ago
      "Technically correct", the most irritating form of "correct"
• sultanofswing 7y ago
  The software industry's greatest blog post sin: "Hiring in tech is broken" This topic is trite. Furthermore no one seems to be able to offer up actual tangible suggestions as to how to fix this, or some objective 'better way'. Disclaimer I work at a FAANG etc company: Also this has been distinctly "not" my experience at many FAANG type companies. Usually these interviews, even the one's I haven't done well in, have been highly conversational, and all contain a fairly in depth 'soft skills' interview as well. Yes, your technical knowledge has to be good, but a good interview will keep pressing at the edge of your knowledge (not to make you 'fail'), but to see how you handle the unknown. In fact for one of the companies I ended up working at I was called in for a second soft skills interview just to dig even deeper on the dimension the author claims is 'never tested for'. Much like these authors I don't have a perfect solution to this, however I will say one of the most rewarding interviews I've ever done (at a well funded startup where I did NOT get the offer was comprised of): - 1 Algo question (standard fare) - 1 Architecture question (standard fare) - 1 'find a bug in this mock part of the codebase / pair program with me' question. Implementation didn't necessarily have to be perfect, mostly was interested in diagnosing the actual problem and talking about 'how' we might solve it (very fun) - 1 Product Sense (!) question with actual PMs (very fun) - 1 General culture fit / experience interview
  • irl_zebra 7y ago
    I accidentally did a PM interview one time at FAANG and couldn't have done well, but it was fun! Really did enjoy it.
  • vsareto 7y ago
    >Furthermore no one seems to be able to offer up actual tangible suggestions as to how to fix this, or some objective 'better way'. There are other professions with models of credentials that could be adopted to software given some time and adjustment and faith. Then we could shed our current technical interviews in favor of shorter interviews overall. You naturally need more people to handle interview bandwidth as your company grows. People want to show some credential and not have to deal with technical interviews at every potential opportunity. We've learned enough about technical interviews that we should be able to make this kind of widely-recognized credential. We just don't want to do it. We'd rather keep recruiters employed and force developers to budget large blocks of interviewing time.
• jmpeax 7y ago
  "I failed my technical interview, so here's a blog post". Software is one of the very few industries where lying on your resume and lying through your teeth about your prior accomplishments can be very easily tested.
• codeisawesome 7y ago
  Literally any single person can aspire to be a Software Engineer at a major tech company by studying online, on their own, with resources that are either free or modestly expensive. I disagree that it is a broken process. I do not want the software world to also start selecting for non-hard-work metrics like who your parents were.
  • tomnj 7y ago
    You can work hard at things other than leetcode though, like actual jobs, personal projects, or learning tech in your field (web frameworks, programming languages, whatever).
• 12yrprogrammer 7y ago
  It's weird, I've programmed Everything from Random Forest in VBA to full stack apps to embedded, but I can't get an interview. "Just do projects" they told me. Maybe I'm asking for too much money? 90k/yr. I want to switch from Engineering(120k/yr) to programming, but I've been unable. SE Michigan.
  • sgerenser 7y ago
    Getting your foot in the door is the first step. It’s helpful to have a good presence on LinkedIn and not ignoring recruiters even if you think they sound clueless. Getting a referral helps a lot too. That got me interviews with Google but Microsoft, Faceboook and Amazon were all either applying online or responding to recruiter spam. I’m finally about to jump to a big tech company but up until now I worked for a small company on the east coast and don’t have a blog or any public projects on GitHub.
  • hackinthebochs 7y ago
    Do you have X number of years of non-programming related roles on your resume? Do you list the year of your college degree? These things might signal your age/over-experience/lack of programming experience enough to get your resume culled. There's also the fact that most jobs are looking for exact matches rather than someone smart enough to get up to speed on their tech stack. So they want to see X years with Y technology. If you're coming from a different field it can be hard to check those boxes.
  • fennecfoxen 7y ago
    90k a year is totally doable for medium-experience software in principle, but in southeast Michigan I'm much less sure. The salaries are laid out differently. For those coming into the industry from outside, the real questions may be less about what you're capable of programming, and more about your wisdom in producing code that works well with other code and with the realities of failure. It's hard enough to get a good sense of how much of that wisdom you have even when you are a software engineer...
• OliverJones 7y ago
  1. Fizzbuzz 2. If you claim SQL: Explain LEFT JOIN ... IS NULL pattern. Do you know about little bobby tables (injection exploit). 3. "How does the internet work?" 4. "Tell me about a hard / interesting / instructive bug you had to handle. 5. What would you do differently if you were the lord high poobah on your last job? 6. Tell me about something you helped finish and ship to users. 7. What do you have to say about OUR product? Those questions have helped me hire some great people. They apply to anybody from a fresh-out to a self-taught to famous programmers. You CAN shove into their face some strange line of code that depends on arcana of operator precedence. But the only useful answer there is "I would never write something so obscure."
  • StandardFuture 7y ago
    Or you could have gotten lucky in the pool of candidates you are sampling from. If you end up only interviewing good (or bad) programmers, then your interviewing process never really mattered in the first place. So, no formulaic interview process is going to ever be proven effective (and in fact, is very likely never going to be much more effective than a coin toss). People really need to get over themselves with their "clever" questions and answers.
• wrnr 7y ago
  People still acting like we all live in silicon valley and the dot com bubble hasn't bursted twice, software engineering is over as a high impact career, the meta has shifted from solving problems to finding problems. There are too many smart people in this industry who won't/can't code but act as gatekeeper to valuable problems. My advice is to search out these problems yourself, its a much more challenging problem then any programming. Or spend two weeks preparing for your technical interview to learn stuff you won't ever use again and then do the bitch work of someones over-engineered vanity project while the plebs are doing "research", "marketing", "design", and "business development".
• gregrata 7y ago
  I wrote a book on this last year, out of my frustration with dev interviews https://www.amazon.com/Whiteboard-better-hire-best-developers-ebook/dp/B07FJ6N8P1 https://www.amazon.com/Whiteboard-better-hire-best-developer... I've interviewed and hired a lot of people over the years, and have been interviewed a fair amount. The way a lot of companies do it didn't make sense to me, so 5+ years ago I decided to figure out a better way to do it. My basic premise in the book is that in an interview when asking someone to show skill, it should be as close as possible to what the job is. Most interviews are just not anything like a whiteboard interview or algorithm question. I get that can show how someone thinks, how they ask questions, etc. - but to be honest I rather have them actually DO something as they would do if I hire them. I've had a lot of luck with this way of interviewing. The reality is it can still be a crapshoot - you really don't know what someone is going to be like until you work with them for a while - but this at least gets closer to making a more informed decision ('cause you basically work with someone, in a small way!)
• deedubaya 7y ago
  There are two camps here that strongly correlate to their opinions: those who have been through a job hunt in the last 5 years, and those who haven’t.
• screye 7y ago
  Developer hiring is not broken, it is the people who do the hiring that are. It could not be more clear to me and their conclusion only makes me more sure of it We need to throw away this idea that you can get the measure of a person just by subjecting them to a faux-IQ test. We need to fully internalize that being a great software developer is holistic and draws on abilities ranging from, yes, technical skill, but also empathy, experience, taste, grit, perseverance, and independence. Being a great software developer is multi-disciplinary and we need to actively and vigorously reject the notion that just being good at "cutting code" and inverting a binary tree is the end of the story and is therefore the only axis on which to assess people who work in teams and build products for other human beings. The kind of person who is able to judge someone for such skills, is also probably very high up the company ladder, a busy person who cannot interview every candidate. At the end of the day, 50% of interviews are going to be conducted by people who were until recently new-grads and have only taken exams which are neither technologically holistic nor gauge for non-technical essentials. This is not a problem in the system. This is a problem of scale.
• asn0 7y ago
  We (Ambra Health) a few years ago decided our "typical" multi-hour multi-week interview process was a lot of effort for pretty mixed outcomes. We realized an interview can't really answer the most important questions: how a candidate works, and what's it like to work together. So we added an option to interview by way of a paid trial period (work part-time nights/weekends for a few weeks with the hiring team). Figured maybe some people might prefer that, but probably wouldn't be feasible for most. Every candidate since has chosen that route, with very good outcomes - so far, everyone who did well in the trial period has been a good hire. Some of our best hires did not interview well (and would not have been hired under our old process), but were outstanding in the trial period. And, a couple candidates interviewed so well we almost skipped the trial period, but they struggled to complete even simple tasks during the trial. We've now optimized interviews for that process, where the decision is primarily about whether it's worth moving to a trial period. That usually only takes a short screening call and a 1-hour call with the team (we're a remote team, even before quarantines). BTW, if you'd like to experience this first-hand, we're hiring - https://news.ycombinator.com/item?id=22753515 https://news.ycombinator.com/item?id=22753515
  • zhoujianfu 7y ago
    I do think this is really the best way to "interview"... it's weird how hard it is to correctly evaluate somebody in two hours of talking to them and yet how easy it is to evaluate somebody in even two days of working with them.
  • bleah1000 7y ago
    I'm sure you get good outcomes from this, but I'd be willing to bet you are completely weeding out whole classes of people. For example, most parents or caregivers (single or otherwise) don't necessarily have the time for this. Senior engineers are less likely to want to go through this. I would guess that most of your hires are single young people. And you are already kind of teaching them to work nights and weekends, which sounds like you are, again, choosing people who would not have a problem with a bad work life balance. I also wouldn't be surprised if your process isn't teetering on the illegal side. Not on purpose, but it might be accidentally favoring or disfavoring a race/gender. Probably not enough to get you in trouble though, because those things are hard to spot. And unless your company is really big, probably nobody cares.
• crimsonalucard 7y ago
  I had a candidate totally fail the algorithm interview. Is a binary tree balanced? I thumbs downed him. I was overruled and he was hired based off of his credentials, resume and what he talked about in the interview with another person who just had a talk about "architecture." Turns out the guy can't even code. He constantly just talks about architecture and tries to tell everyone to completely change the architecture to be event driven. But when given an assignment to work on the actual product he totally fails. It's crazy, the man is a complete clown. Here's what I think. You can't hire a candidate based off of just a technical interview alone. But you can't just hire a candidate off of his credentials either. There's too much room for lies and deception in this area. You need both metrics in order to get the most information out of a candidate. It goes both ways. The Technical Interview was invented because of too much of the above problem. People who are charismatic and exaggerate their resume and turn out not being able to code. Of course nowadays with canned memorization going rampant and technical interviews becoming IQ tests there's really no accurate way measuring a candidate. I'll just say that as bad as an IQ test is in identifying good programmers who are bad at IQ tests, a person with high IQ is likely going to be a good programmer.
• doorty 7y ago
  Yes, it's the reason I'm not currently employed in the software industry. After a decade of being a professional developer, I decided to start building physical things and learning other maker skill sets. Whenever I need some extra income I start looking at software jobs, but I'm not able to think clearly during these sort of test situations, and they don't usually go well. I've built so many things from software products and businesses from scratch and could do so again, but it just makes me bitter to even subject myself to this initiation. I would be much happier (and companies would have more diverse candidates) if a resume and past experience did the talking like other professions.
• starpilot 7y ago
  Would companies make more money if they hired in this "wholistic" way? Every time this comes up, I struggle to see how these top tier companies with these algo-intensive interview practices are compromised by not being "wholistic." They're raking in cash. By all quantitative measures their hiring is working extremely well for them.
• jppope 7y ago
  I wrote about a better way to hire people: https://jonpauluritis.com/a-better-way-to-hire-people https://jonpauluritis.com/a-better-way-to-hire-people It works remarkably well if you're flexible enough to follow it.
• ojr 7y ago
  I did on a onsite at Google and learned the most during the lunch portion, my interviewers didn't know basic ES6. At lunch, I talked with an engineer who was a teacher before his first industry job at Google which he has worked for 5 years, in contrast with me that had work at 4 different places in 5 years. I didn't get the job even though my github and industry skills were more vast. They would rather hire "theory over practice" developers because they are easier to retain, which is fair.
• ccleve 7y ago
  The core problem is that many people who apply for software developer jobs are attracted to the money, and just aren't very good at coding. Slogging through these interviews is a drag and a waste of time for capable developers. So, the process is delegated to junior people who don't yet have the judgment or experience to know what's important. This is a joke, but uncomfortably close to the way junior people interview: https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_carpenters_were_hired_like_programmers/ https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...
• mberning 7y ago
  If you were to go in to an interview for a welding gig you would likely be asked to produce something simple like a cube or other basic shape. Nothing extravagant, but it demonstrates competency with the tools, materials, and techniques. I have tried very hard to replicate this in our hiring process. But the sad reality is that many applicants cannot code to the level suggested by their resume.
• ddrt 7y ago
  I interviewed for an agency in my city. The first three interviews went well. Then the interviewer vanished for a week or so. I thought things were done after following up a few times with no response. Then I heard from them again a month later, the position was infilled and they wanted me to come in and meet the team. So I did, they made fun of my suit, they grilled me and then acted like I was unsure of the job roles... however I’d gone over them many times in the listing, prepared, and had three successful interviews. The person I originally interviewed was there, I have him an odd look, he gave me an “I’m sorry” shrug. And I left, perplexed. I was polite and professional the entire time. Then they called again, now the CEO wants to meet me face to face. So I did, the other person who was his partner didn’t show up until 40 minutes later. I was having a great time with the CEO and asked him a lot about how he built the company, what the future looked like, and what Em he enjoyed most about the culture. I was getting into my work and history when the second individual showed up. He arrived, interrupted the story unintroduced, made fun of my suit, looked at his watch, and gave me an annoying look. I started from the beginning as requested, I got a sentence in and he nudged the CEO and said “were late”. And that was that. While they were walking away he made fun of my suit again.
  • fxtentacle 7y ago
    I used to own a suit like that ;) No, really. In my case I went with white-green because I liked it. It was quite obvious that it made the bank employees feel unsure if they should mock me or if I was some sort of secret celebrity.
• pdimitar 7y ago
  Anecdotal evidence: Several times in my life I've had the strange luck of being told the internal workings of a decision after I was rejected for a job. Usually somebody from the interviewers liked me but couldn't convince the others, and subsequently decides to find me on LinkedIn and send me a direct message. The messages have been eerily similar and are usually like this: "Hey Dimi, I want you to know that I think you would be a perfect senior dev for our team. But the other guys said you were awkward part of the time, you didn't feel like you'll fit with the rest of us, and one of them heavily emphasised that you hesitated before answering one question very specific for our work... and when I pressed them to elaborate further they just angrily told me that I don't get it. I wish you luck in your future searches but you should know that if it were up to me you'd be working with us now." You can lose your balance for a minute while being evaluated live by several people? You can hesitate before answering a trick question about a niche project? Imagine that. It's really bittersweet to get these internal insights and can make you want to pull your hair out -- but it did give me the perspective that most of the people charged with hiring go by a gut feeling and personal sympathy.
  • non-entity 7y ago
    Heh, I'd rather hesitate on a question and give any answer than boastfully blurt out something that's incorrect
    • pdimitar 7y ago
      Same, and apparently if you can't fake 100% confidence you are not good enough for some. Oh well. In the end it all works out well because you are not stuck with a company you dislike (and they with you). But during the process... it's painful and takes a toll on your mental health while you're going through all that.
  • frankzinger 7y ago
    Yeah almost anything is possible so one really has to try not to obsess about it too much. I know it's hard. I can't say I'm able to do it either. Anyway, my anecdote: we were interviewing for a C developer position. The next candidate was in his 50s. Our project leader took a dislike to him the moment he saw his resume. No idea why but I assumed it was either his age or that this project leader knew him and didn't want to work with him for some personal reason. The project leader arrived to the interview at least 40m late. In that time this candidate impressed me (as the C guy) very much and I said 'hire' immediately. However, as presaged, the project leader said no. This candidate had no way of knowing what had happened. He definitely could tell I was impressed so he probably assumed it was his age. Just imagine how he must've felt. I probably should've contacted him to let him know how messed up the our process was.
• DeathArrow 7y ago
  I think it depends on the company. In a small company it's vital that developers understand user needs and want to provide a great user experience. Bigger companies can, but not always will - see Google, have dedicated people to think about the product the user experience and how the product should catter to a particular user base. Those people can translate the requirements for developers. I am not saying that developers should be autistic and completely ignore anything that is not code related but it can be done. Google failed but others succeeded, see Adobe or Ubisoft. I certainly like to code and like technical intricacies but I always looked to code from an entrepreneur pov: always trying to work on something which will be useful for someone and ask myself what feature is going to be useful, to how many people and in what way. I did my share of "inverting binary trees" but that was when I was a student and needed to learn. I always tryed though to use such a technique to solve a real issue. Maybe CS programs at universities should start teaching not only CS and programming courses but also concepts about thinking products, understanding user needs, assessing user needs. Architects are trained not only on visual and technical aspects of planning buildings but also on understanding user needs and making the building useful for a particular customer. It's useless if a house looks good, uses clever technical solutions but no one is wanting to live in it.
• p0nce 7y ago
  I liked most interviews, but the one that irks me are when the interviewer asks very specific questions that are specific to the particular domain the company is in. But one of the biggest reason to apply somewhere as a developer is precisely to get to know a problem domain. Money is not the only incentive, by far.
• badrabbit 7y ago
  Whiteboarding sucks. I was asked to do this once or twice, I can't think while others watch because I am focusing on what they are seeing, and my penmanship sucks. It's not for anyone that gets nervous easy. I just don't get it, why not put up a text editor on a wall screen and ask people to write the same code there?
• KingOfCoders 7y ago
  I did love the way eBay did hiring with 360 interviews. I interviewed my future boss and recommended that she should be hired.
• alkibiades 7y ago
  some frustrating parts for me: 1. if i got an offer from your company a year ago, why do i need to redo the phone screen and entire process? 2. if someone has 10 years of experience at google and is L6, why do they need to do the standard process to work at some rinky startup?
  • chihuahua 7y ago
    The reason for (2) may be the following: can the company verify that the candidate did in fact work at Google for 10 years and reached L6? I don't know about Google, but if someone claims they worked at Microsoft as an L65, and they call Microsoft to fact-check, Microsoft will only tell them when that person started and ended their employment there. They will not disclose any other information.
  • rsynnott 7y ago
    > if someone has 10 years of experience at google and is L6, why do they need to do the standard process to work at some rinky startup? The startup doesn't trust that Google's process is absolutely infallible, presumably. For good reason, probably; a bad hire is much more of an existential risk for a small startup than for Google.
• thorstenn 7y ago
  Leonardo da Vinci means Leonardo from Vinci. Trivia is not always useful but is an indicator of curiosity.
• ChicagoDave 7y ago
  I hire people from direct conversation that jumps around many subjects. My goal is to see the wheels turning, find what excites them, get the lights in their eyes shining. If I can’t do that in even 15 minutes, then I lose interest fast. If I can, an hour goes by in a flash and I really get to determine if they align with the role they’ve applied to. I could care less about data structures and graphs. Do they care about code and can they learn and can they communicate. That’s what matters.
  • starpilot 7y ago
    Many companies get by with mediocre developers, mine is one of them. You're not demonstrating that your interviewing style generates superior results.
    • ChicagoDave 7y ago
      As a consultant, I’m almost exclusively on high pressure projects that require a higher level of talent. I have zero problems hiring adequate talent if there are suitable roles.
• globular-toast 7y ago
  > It's a disguised IQ test. No. It also tests knowledge and familiarity with whatever technology is required. But yes, of course it tests IQ. What else is important? The way you look? The way you speak? Your background? I don't care about any of that. If you can express yourself in a technical context then you automatically satisfy all other requirements. I like technical interviews. They remove bias. It means someone isn't going to get the job just because I "like" them or, worse, I want to fornicate with them. I've hired people of all ages, races, and other "identities" thanks to the technical interview.
  • sillyconvalley 7y ago
    This entire post would be incredibly concerning if I were your superior.
• joelbluminator 7y ago
  I think a very important point from this article got lost in this discussion; many engineers aren't aligned with the business and the end users, but instead often needlessly chase new stacks, over engineer the code base, migrate to micro services (prematurely), rewrite an existing codebase in a new hot language instead of just refactoring, needless throwing React/Redux at the problem etc etc. So many times these efforts give zero value to the code base or the product. This type of behaviour seems to go unnoticed since business doesn't understand engineering and has to trust the engineering managers.
• louiskottmann 7y ago
  The thing is, when you start having a lot of candidates at your door, say, because you are a big company with interesting problems and/or good benefits, and the position is sought-after, your recruitment process costs even more. So you look to lower that cost by filtering out applicants based on some criterias. People from renowned schools go first because they are more likely to be skilled on average, if you ever deplete that pool, you look for the rest. I recruit for my company, and we don't do that, in fact we do quite the opposite. But I'm pretty sure that's how big companies see it.
• resume384 7y ago
  Nice insight. Recently posted my take after jumping into the industry head first after going it independently for decades.... https://www.linkedin.com/pulse/let-me-open-you-adam-m https://www.linkedin.com/pulse/let-me-open-you-adam-m https://news.ycombinator.com/item?id=22820905 https://news.ycombinator.com/item?id=22820905
• thomk 7y ago
  I never understood why companies don't take a slower, ramp up approach for interviewing. ROUND 1 THE INTERVIEW Step 1: Interview candidates for 'culture fit'. Chat on the phone, get to know the person a bit, ask questions about what they did before. See if they have a sense of humor, get them to relax. Don't try to trick them, just have a chat. Step 2: Ask a few 'how do you think questions'. Why are manhole covers round? How many school busses are in New York City, etc. These are questions with no clear answer and missing input data (like real life). Listen to how they work out problems in their head. Then ask fuzzy questions with no clear answer, and relatively high consequences for rightness or wrongness. See how they deal with that. Ask workplace conflict questions and irate coworker questions, see how they respond. Give them all the time they need. Step 3: At the end of the interview, send them some take home code projects without a time limit. Give them some toy software program and ask them to fix a few reported bugs in it. Then give them a small greenfield project and see how they structure and document their code. ROUND 2: THE DATING PERIOD If all of the above goes well; hire them on a 1 month trial basis and see how everyone works together. Maybe they don't like your company? Maybe they smell funny? Maybe you force everyone to do yoga? Maybe they MUST travel with their service chimpanzee? Who knows? Spend a month working together and find out. If either of you see a red flag; shake hands and go your separate ways. - - - My point is this; putting someone through a gauntlet of stressful, random interview questions and whiteboard coding issues makes people stressed and nervous so they do not act like themselves. If the job is a high stress job and it's important to handle a lot of stress; you'll see that during the dating period. Imagine having to decide if you were going to marry someone based on a few hours of conversation and 'whiteboard coding problems'. It's too much of a commitment with too little information. Hire people, not machines.
  • thomk 7y ago
    One last point on this. The general idea is to see HOW someone thinks. One way to do that is to have them map out and work through a problem on a whiteboard without code. I'm talking boxes and arrows. Ask a question like 'How does (for example) bittorrent work IN GENERAL?' Have them map out the answer on a whiteboard for one person who knows how bittorrent works and can nudge them along if needed. The idea is to see how well they communicate complex ideas, not how well they have memorized the bittorrent protocol.
• loup-vaillant 7y ago
  > Almost no other "white collar" profession I'm aware of will so completely and thoroughly ignore your actual proven ability, historical accomplishments, and holistic qualities, as part of the hiring process. Perhaps that's because programmer is not a white collar profession? Those who don't manage other programmers are naturally at the bottom of the hierarchy, just like a machinist (clearly a blue collar profession, though I would certainly show proper deference to them before I even dare approach a machine). Never mind how useful, or how skilled, people at the bottom are. They're at the bottom, and that alone probably affects how they are treated. The hiring process is just an effect of this.
  • rsynnott 7y ago
    "White collar" doesn't normally exclusively mean managerial, it means 'professional' in a kind of poorly-defined, rather obsolete, classist way. A "you know it when you see it" thing. For instance, a doctor is white collar (but probably not a manager). So's an accountant, or an engineer; again, they're mostly not managers.
    • loup-vaillant 7y ago
      How about a cordwainer? Many are highly qualified professionals, and I bet they're "blue collar" all the same. They're working with their hands making shoes after all. I think this "white/blue" distinction blinds us somewhat. What really matters is how others (in particular those who have power over us) perceive us. As for being a profession, relatively few programmers are independent. Most work under a boss, with the same hierarchical constraints as a factory worker. We're not organised as a profession. I dare say we aren't a profession just yet. Our trade is too young for us to have achieved good average competence (doubling our numbers doesn't help, and is an indication that there's no selection pressure yet). The only thing that makes us "white collar" is that we work in clean environment, without physical exertion.
      • rsynnott 7y ago
        > How about a cordwainer? Many are highly qualified professionals, and I bet they're "blue collar" all the same. Yup. That's largely where we get into the classism thing. "White collar" doesn't say anything in particular about skill or earnings (or even education, necessarily; you don't need a degree to be white collar); it's a class signifier. > As for being a profession, relatively few programmers are independent. Most work under a boss, with the same hierarchical constraints as a factory worker. Same goes for doctors (in most countries), accountants, etc. And of course, a middle-manager is white collar. While collar doesn't necessarily mean self-employed/company owner/bourgeois. It's more complicated than that.
• theelous3 7y ago
  This article was painful for me to read, mostly because of how accurately it reflected my experience with job searching. I'm not the worlds most experienced dev who's shipped multiple products, but for a relatively inexperienced (2y professional, 5y total), I feel I am overlooked for positions I would excel in because I am just plain bad at technical interviews. I have a fairly impressive github, a creative cv and recruitment page, and a bunch of nice addons that show how much I care about programming both technically and socially. I have probably the best possible background for remote positions in particular. I get interviewed a lot because of all this, and then facepalm my way out during technical interviews. I'm the kind of dev that can eventually solve pretty much any leetcode-y type problem, but it takes me a long time of sitting in silence and playfully experimenting with a repl or similar. This translates extremely poorly to interviews. I have also noticed that my brain will just disconnect midway through interviews and I will fail something that under ordinary circumstances I would never miss. A combination of my style of thinking mapping poorly to the interview format, and stage fright, means that my odds are poor; even against candidates who would be both technically and personably worse fits. Not really sure how to tackle this :)
  • azhu 7y ago
    Sounds like you know exactly what your problem is. Technical interviewing is just like normal problem solving, just you have to narrate your thoughts as if the interviewer's inside your head with you. Get some sample problems that match what you're seeing in your onsites, roleplay having an interviewer there with you, and practice them while recording yourself. Best is if you can have a real human. If you're passionate enough, it would be a great idea to organize some kind of group for people in similar positions. Either you will learn the skill enough or you will find a position that fits your current skillset along the way. Being understood by other people is where the rubber meets the road for ideas having any impact and communicating your technical ideas is an important skill in general.
    • theelous3 7y ago
      Aye, I hear you. I was giving it more thought over the last few days having written the above comment, and I realised that what happens in tech interviews is that I switch my mode of thinking. Under normal circumstances, I sit and problem solve, thinking only of the issue at hand, branching out and following leads and so on. Under interview circumstances, I instead try to anticipate what the person scrutinising me wants to see, and try to like, game an ungameable situation, which blocks my natural problem solving thinking. I have noticed that when I'm in a position of subordination, I do worse creatively. This isn't to say I can't work as employee, but rather in specific situations, such as "person knows x and is just watching me try to do x", I enter this reactive thought mode. Conversely, when I am in a superordinate position, I find myself much more creative than my baseline, thinking clearly and well. I don't know how to handle this for interviews.
• kafrofrite 7y ago
  Just adding on the post. I used to work for big tech companies, I interviewed for some and also I had the pleasure of interviewing candidates. I mostly interviewed for security related roles but at some stage, I had constantly positive feedback from the candidate so I was thrown in to interview candidates for other roles as well. I agree with the article, and had my fair share of bad apples so my thoughts here. Unless the role was something that required dealing with incidents, there was no point on doing a technical interview onsite and seeing how the candidate reacts under stress. Generally, noone cares how well a candidate performs under stress. Instead, I'd let them deal with technical problems on their own time, if they wanted and tell them to spend no more than 2 days (I'd actually kill the instance to ensure that). For security positions, I ended up building a CTF platform and told them to solve as many challenges as they wish and send back a report. For the onsite interviews, we did mostly cultural interviews. There was a bit of technical questions involved, mostly open-ended questions to see how they approached a problem. This usually was to design some system or, given a tiny codebase, how they'd go implementing a feature. Also, I did what we ended up naming "spirals". Successive questions, increasing in difficulty to see how much in depth they went during their research. E.g. Traceroute -> Ping -> ICMP -> Differences in Linux vs Windows. This had two benefits. It was clear how much in depth they would go and two, it was almost guaranteed that at some point they wouldn't know the answer, which is fine, but forces them to explain how they would go to find the answer. Almost always, I'd tell them whether they were on the right path and if they were stuck kinda help them. I'd give about 5-10 minutes for the candidate to ask me anything. Literally, anything. For me, this was important because I would get a sense for how candidates evaluated the company and what they were interested in. Beyond that, at some stage, we added some questions called internally the "I read it on the internet". The questions were pretty straightforward, e.g. given a terminal, tell me how would you ssh in this box as XYZ user or how would you rm a directory. Fun fact. I initially made fun of the operations guys asking those questions until I interviewed a series of people where noone knew how to do simple stuff with their terminals. Btw, I didn't focus at all on technologies. Given the size of the company, asking "How much you know about $LANGUAGE" would be futile. I wanted to hire people who could pick up new technologies and, given the size of the company most of the tools were custom-built or heavily modified. It was pointless asking "$LANGUAGE" and then telling them "Well, great, just keep in mind we don't actually use exactly $LANGUAGE but rather our own version of it". Last, and probably the most important. I asked myself how I wanted to be treated during an interview. I kept in mind that I generally wanted to be treated with dignity and respect, I kept in mind that the resume is basically a snapshot of someone's life and the candidate is a human being and acted accordingly. Also, I valued for candidates who asked for feedback and actually I'd give them some and tell them stuff to read reg. things I felt they could do better. Btw, I also assumed that each candidate would get an offer and I didn't want them coming in and thinking "That's the idiot that was acting cocky during the interview".
• dccoolgai 7y ago
  "disguised IQ test" If only. It's more like a Wonderlic Test.
• Lio 7y ago
  I’m not a technical interviewer specialist, I’m a developer who has in the past given interviews. Other than filtering out chancers with a lack of required basic skills, one thing that’s always bothered me is how my own personal Dunning-Kruger effect alters the interview process. I obviously only ask questions I think I know the answers to otherwise how would I know if they were correctly answered?. So that may mean I miss out on candidates with a range of skills I lack and can’t detect in interviews. Interviewing successfully, I suspect, is a ”difficult” problem if you take it really seriously. Like those pointless “skills matrixes” that inexperienced managers like to set up for their teams. I mean you can ask me my skill level for a particular subject matter but how can I answer you with any accuracy if I don’t know what I don’t know?
• netjiro 7y ago
  Tossing my 2c in the ring, this is how I usually hire new dudes[1]: - Ask the existing team for a set of dude recommendations, and the reasons. - Track down a set of dudes myself. Usually from publications, open source, or previous products. - Discuss with the dudes regarding the greater project target, team, goals, initial tasks, scheduling. Ask the dudes for other dudes they can recommend, and why. - From here on I pay the dudes for their time and effort during recruitment, always: - Have the dudes look at previous problems and solutions, if available, and ask for feedback. - Have the dudes spend time with existing team on current work and ideas. When populating entire teams I have dudes work with each other. I especially look for people who are freely sharing even with people they are (technically) in competition with. - I always followup on my initial predictions over time, to see where I'm right or wrong, and what to look for in the future. I often hire scientists or other people who do a lot of work out in the open. It's just so much easier to quickly get a feel for peoples' output by looking at, and discussing, previous work. And most of my projects require bleeding edge specialists. I advertise <25% of my positions (guesstimate). This is a failing on my part. I have no magic lens to read CVs, so they carry no additional information value for me. Hiring is expensive and often takes a long time, but hiring the wrong people is much worse. Throughout my projects I have only had one person leave, and that was for a once in a lifetime offer. I very rarely need to fire anyone. I would rather hire two excellent dudes than five good dudes. So I tend to have the budget to pay good rates. Then I call up temporary manpower to solve the more mundane tasks so I can keep my excellent people on the more difficult and interesting items. Red flags I look for when I'm on the other side of the table: - Who is doing the hiring? Some checkbox HR drone, the owners/investors, or the actual team? - Hiring evaluation tools. Have they actually bothered to read up on the latest few decades of research, or are they just following dogmatic trends? Do they even track their own prediction skills when hiring? - What is their understanding of the project, tasks, etc? - Do they respect my time investment? 1) a "dude" is gender and ageless, of no persuasion, has neither skin nor eye colour, and so on.
  • JohnL4 7y ago
    > 1) a "dude" is gender and ageless, of no persuasion, has neither skin nor eye colour, and so on. In that case, s/dude/person/g Language affects thought, right?
• dudul 7y ago
  A week on HN wouldn't be complete without the traditional "hiring is broken" blog post.
• ben7799 7y ago
  The problem as I see it with focusing on history & people skills too much is a lot of the weak candidates are flat out lying about those kind of things. I've interviewed more people in the last year than any previous year of my career. We found numerous candidates cheating on online coding tests. Weak candidates that fall flat on their face when asked to do something super simple like a FizzBuzz problem list massive accomplishments on their resumes. Often it seems like they are listing everything the team they worked on accomplished, not what they accomplished. And the weak candidates frequently list things like "Expert at Spring Framework" or "Expert at J2EE". To be an expert on those things is very rare since they are enormous frameworks. Not many strong candidates will list themselves as experts on giant projects unless they were one of the founders of the project. He is talking about filtering out developers with good technical skills who have other aspects of their personality/behavior that don't mesh with his business. But the bigger problem seems to be finding people who actually have real technical skills. The things he's worrying about are easier for management to correct/control.
  • yellowstuff 7y ago
    Ability to invert a binary tree is not what you actually want to measure, but you can't bluff your way through it, so it's an attractive target to measure, especially at a large company trying to have standardized practices. Professional accomplishments is much closer to what you care about, but you can bluff. But it's still possible to give a good subjective interview. Good interviewers will find a area on someone's resume that they have deep knowledge of and drill deep. It takes longer to sniff out a complete fraud than FizzBuzz, but it can still be an effective approach.
    • ben7799 7y ago
      Inverting a binary tree is actually something that weak candidates seem to find a way to cheat on though. Same thing with Fizzbuzz, so it was an artificial example in my post. The best thing for us seems to be relatively simple coding questions that are domain specific problems. My go-to the last year or so has been an interview like this: 1) Give a demo of the product 2) Explain a problem the product has/had to solve 3) Go over the entities/objects involved in the problem 4) Present this as a simplified whiteboard problem 5) Candidate needs to write some code on the board to solve the issue (Typical solutions < 20 lines of code) 6) Discuss scalability of the solution 7) Discuss alternate ways to refactor the larger code base to avoid having to write the algorithm that was written on the whiteboard at all The process of having to take a problem that comes from a specific product & translate that into code seems to catch the weak candidates that cheated on the online coding tests and bluffed the recruiter nearly every time. This is as opposed to places like Google that just constantly try to ramp up the difficulty of the non real-world coding questions they're asking the interviewee.
• unexaminedlife 7y ago
  I decided pretty early in my career that I wasn't going to concentrate on figuring out how to get hired to what folks consider the top tech companies in the world. I decided to take a different route. Take the decent-paying, but average job at an average-ish company, which will require immersive experience in all aspects of running a web infrastructure. The reason for this, I didn't see "getting a job at Google" as the pinnacle for me and my achievements. I saw "creating my own successful company" as the end goal. Sooo many benefits to this I think. You'll get the IMPORTANT experiences and knowledge, which will benefit you regardless of whether you are able to achieve the end goal of creating a successful business. The ceiling in terms of compensation is SOOO much higher. And in this scenario you're ALWAYS doing the most important things. In my experience working for large corporations you will typically be doing things that are far less important and in most cases your job will not push your limits. You will be a cog in a wheel using maybe 20% of your capacity to do amazing things. Worst case you go back to doing what you love making a decent living. Best case you far exceed anything any of the FAANG companies could ever offer you.
  • ativzzz 7y ago
    The only way you are going to exceed FAANG compensation at an average-ish company is if you go into senior management at that company, which is a completely different career track. You make it sound like being a web developer at a non-FAANG is somehow different than being a web develiper at a FAANG. Regardless, you are going to be working on some permutation of a CRUD app.
• cryptica 7y ago
  People have been saying that tech hiring is broken over and over for a decade now but nothing was done about it. Hiring processes are still rooted in the "If you can solve this tricky textbook problem, you're smart" ideology which is completely wrong because it commoditizes a very narrow type of intelligence which is not related to value creation. Unfortunately it's too late to fix that problem now. If a top value-creating developer was hired by one of these companies today, their approach and thinking style would be fundamentally incompatible with most of the other people who work in the company today (due to the legacy of bad hiring). Moreover, their boss would probably be one of those textbook and process-oriented people who is completely detached from actual value creation; working under such people is deeply depressing for value creators who have developed a laser-focus "eye on the prize" and "simplest is best" mentality from years working in harsh startup environments. I would argue that the "simplest is best" mindset is good at any scale but the corporate hiring process has systematically weeded those people out. That's why corporate monopolies are harmful for society, some entrepreneurial people just can't fit in at the bottom of large corporate hierarchies but yet they are often left without any alternatives.
• chronofar 7y ago
  Nothing will ever beat a trial. It's more expensive, but it's clear shortcuts just don't work that well. Give people a chance to work with you and then you both can make a well informed decision about how the situation is likely to play out.
• master_yoda_1 7y ago
  Here is the text from one of the interviewer who clear the fb interview "The second interview was very hard they asked me a leetcode hard question and I was only able to solve it because I did the exact question before. Complete luck there. Personally I think it was unreasonable to expect someone to solve that difficult of a question in 30 minutes. The overall acceptance rate on the question on Leetcode is around 20%." https://leetcode.com/discuss/interview-question/563659/facebook-ml-engineer-santa-monica-pending https://leetcode.com/discuss/interview-question/563659/faceb...
• helen___keller 7y ago
  It's often very unclear what you really want out of a candidate, much less how to select for that. Maybe a workplace wants someone who will conform to corporate culture and cheerlead for the company. Maybe a workplace wants someone who will learn a big stack of internal tools quickly. Maybe a workplace wants someone who will grind out intense hours without complaint. Maybe a workplace wants someone who isn't going to "waste time" paying technical debt and instead just ship an MVP as soon as possible. Maybe a workplace wants someone who learns new skills on their free time tries to incorporate them at work. Workplaces don't identify or admit what they really want out of a candidate. And they certainly don't have a way for testing against it in interview. Top tier (read: cash-flush) companies have settled for hiring strategies that effectively select for "yuppies" (I dont mean this in a derogatory way) who are willing to bust their ass and do whatever it takes to overcome any obstacle they are given. This mentality is common among top schools that are already intensely selective and competitive. People with this mentality are much more likely to spend hundreds of hours prepping for tests, such as the leetcode meta today. Ultimately, while it's very annoying during a job search, I'm thankful for the fucked state of hiring because it means software engineers aren't commoditized. If we were indistinguishable cogs, and any engineer with N years experience can be replaced by any other engineer with N years experience, that kind of dynamic ultimately results in a strong downward pressure on employee's power and wage. We are closer to a talent dynamic where every engineer is unique and some are much better hires than others. You wouldn't hire an actor just based on their resume. Knowing how many years they've acted or in how many roles isn't enough, you need an audition. Software engineering is halfway between these extremes, and we should be thankful that we aren't (yet) indistinguishable cogs in the corporate machine.
• dfilppi 7y ago
  Oddly, the more real experience you have diminishes your chance of being hired. You might recall how to 'invert a binary tree' had you recently graduated from college. But since inverting binary trees is an extremely rare need in the real world, you are doomed if you have significant experience.
• 11thEarlOfMar 7y ago
  We use a 3 step process: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems, but come out of the designs we've implemented. We ask for 100 lines of code and not more than 2 hours. They take as much time in days as they need, and let us know when you're done. The candidate then comes back and hosts a code review in front of our team. I give strict instructions before hand: The purpose of the review is to learn how they thought through the problem and how they solved it, not do criticize their style and approach. 3. If we decide we like them to this point, the third interview is with managers from other functions. How well does the candidate communicate, come across to non-developers, express interest in the company and role, etc. It's a check point to look for concerning weaknesses, as well as get buy in from the broader organization. This approach so far has yielded excellent results. We ask developers how much time they took in the programming task and why they chose the one they solved. The programming task is telling, not in the quality of their code and how long they took, but how much did they get into it? We have had the range from candidates who did not complete it at all and opted out, to candidates who stumped 40 year veterans with elegant code. In every case, we learn how well they can express their thoughts, and importantly, their level of love for the discipline. This is as important to me as any other attribute.
• Drecula 7y ago
  Given HN's demographics, I'm probably older than most here. I've worked with and personally invented quite a few great products, usually spanning Product, UX, and Engineering work. It's a joke to pretend ageism isn't a thing, and asking questions that only a recent CS grad is going to remember is not a tacit form of filtering for age. There's not many technical questions a fairly smart, non-lazy person with some experience can't either find with a Google search, a conversation with a peer, or a bit of hacking to figure it out. It's been a LONG time since I had to write the code to invert a binary tree, but I've done stuff orders of magnitude more tricky and valuable than that countless times, as have many others. What makes a great engineer? I've lost count of how many times I've had to rewrite the code of many engineers who aced the 'whiteboard shuffle', then wrote hopelessly over-complex and unmaintainable garbage. Most of software engineering is not that hard from a 'learn the things or look them up to get stuff done' perspective. What's hard is working well with others and consistently emitting tight, semantic, legible code that's fun to look at and extend.
  • el_benhameen 7y ago
    Thanks for sharing your experience. Where do you tend to find jobs?
    • Drecula 7y ago
      I already know I'll never get into a FAANG, so I don't bother looking there. Also, I look at the team photos on startup websites, and if no one looks over 40, I don't bother with that either. Otherwise, it's just down to finding a place that has problems to solve that are hard enough to be interesting.
  • ativzzz 7y ago
    Ok cool, so how do companies adjust their hiring processes and be able to objectively measure what makes you a qualified candidate?
    • Drecula 7y ago
      I've got close to a 100% success rate at take home coding challenges. I usually get pulled in because I'm an Architect that codes, so I ask for an end to end thing to solve.
• rafiki6 7y ago
  I feel similarly as the author but I'm starting to take a more balanced approach to all of this and it's helping me put things into perspective. I'll play the game because I'm not sure what other choice I have. I don't enjoy my current job and in order to get the jobs I want with the people I want to work with this is the price. That being said, it's absurd we have to do this EVERY DAMN TIME. Even moving between FAANG requires you to do this. That in and of itself is a clear indication of how bad of a signal this interview process is. Reviewing reddit and team blind and HN (as this is the best data that I have), it seems many folks working at a big tech company still need to leetcode to move to another big tech company despite already passing the bar at one! If that isn't a clear indication of the type of information these interviews provide I don't know what other evidence we need. And here is the real crux of the whole thing. Considering how standard it is, we might as well just make it a part of a software developer certification/license that you have to do once to break into the industry. The funny thing is, despite our best efforts to not become a real standard profession we are behaving a lot like one, except we don't realize it and keep making candidates jump through the same hoops repeatedly. Now many of you will balk at the prospect of standardizing but hear me out. Are we really that different from any other profession? At the end of the day most CS curriculums are very much the same. Why can't we do standardized tests to "pass the bar" so to speak? And additional certifications can be taken for specialties (e.g. ML, Cyber Security, Finance etc.) like in many other engineering professions or like specializing in medicine. Yes, knowing algorithms and data structures IS imporant to being a good software developer, even if you are building CRUD or mobile apps. But, how many times to do I need to prove I know them? Yes, showing leadership skills IS important to being a good software developer. But isn't being a leader mostly about conflict management, moral obligation and being ethical? Maybe we can stop fearing becoming a real profession that is beholden to standards and public scrutiny and embrace it. It will end up being better for everyone. For juniors (not in age, but in experience), it offers a consistent predictable way to learn and grow, and a set of criteria they can focus on learning to land junior positions. From there we can treat them like apprentices, and to get certification you need to spend x number of years being supervised. This allows companies to also retain their junior talent for longer and their investment in their training can pay off in the long run because even if they lose a junior who's now certified, they can hire a recently certified intermediate from another company! For seniors, it means we can focus on demonstrating why we are seniors (i.e. I've built these systems, led these projects, etc.), and offers a real honest predictable path to becoming a staff or principal (i.e. a master). For companies, it means they can focus on hiring PEOPLE, not leetcoding machines. They shouldn't have to worry about assessing the technical skills of individuals. The only reason they do so is because they feel they have to. If they had confidence that the people they are interviewing are likely qualified as it is, then they can actually focus their time and effort on more important things to assess such as if a person is a good fit for the mission. People assume companies do this because they want to haze candidates. The reality is, companies just don't have any better way of de-risking their hires at this time. We can revisit the criteria regularly to make sure the tests we need to pass represent what it means to be do our jobs and do them well. We can have industry input, academic input and so on. We can even have the professional body accredit programs so as not to have candidates waste their time and to ensure academic programs keep up with the advances industry makes. Further, we can make this a global thing. Rather than shunning becoming a true profession, let's learn from the mistakes of other professions and build a process that helps everyone.
• Drecula 7y ago
  Let's also not forget the bias of Indians only hiring other Indians. There's entire product development teams in the Bay area that are close to 100% Indian. Sorry, I don't buy the excuse that's the only people available to hire. How does this relate to competence and the quality of the engineering work product? Race, gender, age, do NOT matter. So, why the pro-Indian bias?
  • ativzzz 7y ago
    I've noticed this trend in companies with Indian middle managers who tend to aggressively pursue hiring outsourcing firms (like Accenture) to bring in offshore Indian resources, and the project inevitably fails. Every time I've seen this, the decisions to hire the outsourcing firm never really made sense, so the easiest guess to make is the managers were receiving some kind of kickback, but we can only guess.
    • arvinsim 7y ago
      I would hazard to say that it is an Indian cultural thing. But it seems to be a spectrum since I have read accounts that some Indians don't hire Indians who don't belong to the same caste/region/state.
• austincheney 7y ago
  I posted this comment yesterday buried in some thread and even though it was buried it still got 37 up votes. https://news.ycombinator.com/item?id=22821318 https://news.ycombinator.com/item?id=22821318 I post a similar comment in this thread and it gets downvoted to user flagged: https://news.ycombinator.com/item?id=22831474 https://news.ycombinator.com/item?id=22831474 Perhaps the largest handicap in developer hiring is bias as evident by the stark contrast in response to these two comments that convey identical sentiments about the same subject with slightly different language and yet receive opposite response. A company is a absolutely not objective in their candidate selection if developers are the deciding factor in the hiring of other developers.
• ggggtez 7y ago
  > neil with data .com > no data in the article to back up claims Yet another person who claims that hiring is broken. If this is the case, then show me the company that is not using technical interviews, and demonstrate to me that all these other companies are failing to hiring the best people for the job. The closest they get to evidence of their claim is that Google didn't hire 1 random guy 4 years ago. Oh, and that Google built Stadia (??? huh ???). Did I just read an anti-Google blogpost disguised as an anti-interview blogpost? What does Stadia have to do with interviews?
• smilekzs 7y ago
  I'm in a mid-sized startup with headcount in the mid hundreds, and my mental model is like this: Say you have a batch of 100 ppl applying for the generalist SWE position, among which you can only afford to bring onboard ~10. So you need a filter that approximates this desired selectivity, and it needs to be consistently applied across the board for fairness. Also, you can't afford to spend too much time + effort per candidate. What do you do? It so turns out that simple technical problems that requires coding, in conjunction with active spotting for deal-breaking red-flags, can be calibrated well to achieve both fairness and desired selectivity. I can't think of anything else that can so conveniently satisfy the rather essential conditions above. Of course the devil is in the details... which lies mostly in the kind of technical problem you ask. Personally I prefer handing out distilled real problems encountered at work, with a hint of realism, no dependency on know-how other than a solid understanding of CS fundamental, and reduced to be self-contained. Think of the "kinda smart" bits sprinkled across your codebase. This of course requires careful design and calibration, and risks spoilers online, but it's been consistently working well. Personal anecdote though so YMMV.
• hlmencken 7y ago
  Being a manager and hirer is very different from being the interviewee. It's great to believe that you could have some innate ability to judge one's empathy and character in a set of interviews but so much of that runs to favor people who can talk well, which is a wholly different skill from being to code well. Saying technical interviews are disguised IQ tests is quite the horse-shit metaphor. I won't dig into all the problems with IQ tests. Certainly some people have innate ability to do well in quantitative tests, but I know so many people who have put in so much work to get so good at what they do against difficulty and belittling their success at interviewing as something inherent like IQ is awful. Getting to that level takes experience. It takes grit. Programming is a highly technical skill, I have worked with people I don't get along with and people I can't talk to comfortably who have written amazing code and when I am reviewing code that is going to be depended upon by millions of people each day I will always merge good code over someone I like personally. Lots of developers also have responsibilities that use empathy and character and leadership and those people you should always hire along that rubric as well, but if what you need is strong technical skill and ability to solve hard problems with code. You have to find someone who can program well; after that you can have a lot of flexibility in how you work with them and what other responsibilities you give them. I think you are off in comparing programmers to white collar professions. Compare them to skilled professions ala crane operators, machinists, or surgeons. If you don't have hard technical problems then you have the luxury of not needing people who are very good technically, so you can have the luxury of rounding out your interview, but if you have programs for which code quality is very important, you should trust someone who can build good software.
• danielscrubs 7y ago
  "Your interviews are hurting my ego." "How did they hire that guy? He can't code his way out of a paper bag!" We (me included) protect our egos like our lives depend on it. Very few people have the balls to just admit the interview went terrible because of themselves, it's always the person on the other sides (interviewer OR interviewee) fault.
• kcorey 7y ago
  In my experience the UK is slightly less focused on credentials than the backwards boneheads in the US. That's the good news. The bad news is that tech interviews in the UK tend toward the same faux-IQ test mentality. When are recruiters going to realise that just because you can reduce a person to a HackerRank score, that doesn't inform a good hiring decision? I've often said the only way to see how someone is going to work out in an office is to hire them and let them work for a month on probation. After a month, if they've demonstrated an ability to talk, to collaborate, and to learn, then keep 'em. If not, cut 'em loose. everything else in tech hiring is B.S. I have yet to see an alternative that can't be gamed, that takes in the holistic person. And none of my jobs have really brought out the best in me. In jobs I've done well, I drove that myself. In jobs I didn't, it usually came down to bad communication (in both directions). Nothing to do with the recruitment at all.
  • frankzinger 7y ago
    > When are recruiters going to realise that just because you can reduce a person to a HackerRank score, that doesn't inform a good hiring decision? Never. If tech people can't find a way to do it there is no way a non-technical person will be able to. Pretty sure this is why Google has its own recruiters. Your average recruiter has no clue how to grade candidates. For other companies it's probably best to find a way to apply directly. I recently went through the process and got a job from a direct application. I dealt directly with the tech lead. The process was entirely devoid of BS. We understood each other right from the beginning---perfect clarity. After the little bit of time I spent looking through job ads and dealing with recruiters I am endlessly thankful that I got this job before having had to deal with all that for longer than a couple of weeks. The difference was stark.
• wffurr 7y ago
  >> It's a disguised IQ test Funny, an IQ test has one of the best correlations with job performance among all hiring methods; one of the few to do better than random chance. >> Does this person have incredible grit and perseverance? Who cares! Does this person communicate and write well? Who cares! How friendly and amicable is this person? Who cares! I specifically evaluate all of those things and write them up in the report after a technical interview. I don't know where this person is interviewing, but all of these do matter. But it doesn't matter how friendly you are if you can't also demonstrate problem solving and coding ability. Also, what a disaster these threads always are. Depressing.