9 ms·

On Interviewing Programmers

111 points by invalidOrTaken 6y ago

amznthrowaway5 6y ago
> you should not put much stock in the interview process. But there is a sense in which it is very impolite to say so. The interview processes are still very fair compared to things like "performance" reviews and company "levels". People often pretend these types of internal processes are indicators of actual competence when they are usually just based on things like nepotism and corruption. At least these algorithm interviews can successfully weed out people who can't write basic code. I can't say the same for promotion processes.
- donw 6y ago
  That depends entirely on the company. "Nepotism and corruption" is a very odd claim. Does this mean that only family members and friends of managers get promoted? Or that you have to bribe folks in the company to advance? What do you actually mean? What I would say is that most companies haven't really put much thought into building career ladders for their people. Or into defining roles that provide enough breadth to capture a diverse skillset, enough autonomy to get the job done, and enough in the way of pragmatic constraints to scope the role. Algorithms interviews only tell me that somebody can pass an algorithms interview -- one in which the solution space is very narrow, and there are a few correct answers. In real-world engineering, this is very rarely the case. There are always trade-offs to make. Good engineers know how to do things the cheap way now, and pragmatically invest more as we need to -- because they follow practices focused on, second only to delivering value, making the code easy to change.
  - amznthrowaway5 6y ago
    > Does this mean that only family members and friends of managers get promoted? Or that you have to bribe folks in the company to advance? What do you actually mean? In many cases I've seen people being promoted due to being close friends with the managers while contributing little to nothing of value. Also dishonestly claiming credit for others work is a great way to advance. Donald trump types get promoted. > What I would say is that most companies haven't really put much thought into building career ladders for their people. These career ladder guidelines often make the problem worse. They allow poor engineers to get away with avoiding real work in favor of soft "cross-team impact". Often the lower level engineers working on the difficult technical problems are making the real contributions. Good engineers should be focused on solving the most difficult problems, whether cross-team or not. They should not be focused on gaming silly HR guidelines, people who take these guidelines seriously make the worst engineers. > Algorithms interviews only tell me that somebody can pass an algorithms interview -- one in which the solution space is very narrow, and there are a few correct answers. > In real-world engineering, this is very rarely the case. I don't agree. Psychometrics shows general cognitive ability is very important, and algorithms interviews to an extent seem like a decent test of it. Coming up with difficult solutions isn't happening without proper grasp of the basics and strong general cognitive ability.
    - sanderjd 6y ago
      From reading this comment, I think it is possible that you undervalue non-coding work. That is, I think it seems like you don't see as much value in it as some companies you've worked for do. There isn't really an objective measure to say whether you're more right or whether those companies are, but it's definitely the case that career trajectories are driven by what companies value rather than what lower level engineers value. But take my thoughts in this with a grain of salt: my bias is toward believing that most engineers place way too much value on coding work and not nearly enough on the (in my opinion) harder work of figuring out how to successfully execute an ambiguously defined project.
- alexashka 6y ago
  It's nepotism and corruption when you are not part of the club, sure. It is like average looking girls calling hot chicks 'bitches'. Just because you weren't born beautiful, doesn't mean somebody else is a 'bitch', just means you wish you had what they've got :)
ZainRiz 6y ago
Makes sense that when you're interviewing programmers you don't have to look for candidates proficient in your particular area. You need someone willing to learn Conversely, if you're interviewing, signaling that you are highly interested in learning turns you into a strong candidate. I learned this one by accident when I interviewed at a company I didn't care about Relevant excerpt from a blog post I wrote [1]: > I was wandering around the booths with my bag full of swag. My eyes caught a pile of rubik’s cubes being given away by some company I’d never heard of. I wanted one! Of course I couldn’t just go up and ask for it directly, so I went and chatted with the guy manning the booth. His name was Vince. A few minutes later I walked away with my prized rubik’s cube in hand. That evening Vince called me up offering to conduct a full interview loop on campus. I already had a job offer from a company I liked, but I thought “Sure, why not? I could use the experience” > I had no intention of joining the company, they were some boring finance business. There was nothing to lose. So during the interview I felt free to ask any question I wanted. When I thought I got the answer to an interview question wrong, I’d ask “I don’t think I did so great here. What’s the right answer to this problem?” (I wanted to learn the answer for future interviews!). When asked a challenging question I could grin and delight in the problem solving aspect instead of worrying about how badly it would reflect on me. (Remember my smart aleck remark in the intro? That was this interview.) > Turns out they liked that: the next day I had a second job offer. At a significantly higher salary than my first one. Oh, and they wanted to fly me to New York in two weeks for an introduction to the company. I still didn’t want to join, but a free trip to New York? Sign me up! The company’s name: Bloomberg > Bloomberg was a practiced hand at recruiting. They had a full two days of events to leave us starry eyed about the company (I came thiiiiis close to accepting their offer). While there, Vince told me I’d made a great impression by fearlessly asking questions, even when I was stumped. > Since then I’ve stopped hesitating before asking any question in an interview. Let your curiosity run free! Don’t cage it! And as an interviewer, I can attest: sincere interest is always a good sign. [1] https://zainrizvi.io/blog/the-interview-advice-no-one-gives-you/ https://zainrizvi.io/blog/the-interview-advice-no-one-gives-...
- pertymcpert 6y ago
  I completely agree that that's the best way to do an interview, without pressure and treating it as an intellectual exercise with some fun. Unfortunately FANGs (well at least FB) have a tendency to mark you down mentally when you show any weakness. To them you're up against 10 other candidates who got to the right answer not only correctly, but fast.
WrtCdEvrydy 6y ago
I've had some good experiences in hiring by having a conversation with the other person like if they were a human being. I know it's weird, but I just ask them what they're learning, if they have personal projects and just use that to see if they have experience writing software. Some people are super-excited about what they're learning, want to talk about the technology and end up making a good impression. Some people are only able to talk about what they're doing at work, the technical challenges and usually make a good impression as well. Whiteboarding is usually kept to high level concepts like normalization, data flow, logical architecture and things like that.
- thechao 6y ago
  This is how you end up with a team that’s 10x it’s components: why have _one_ 10x engineer, when you could have 7?
  - glouwbug 6y ago
    There's a 10x Engineer achievement you can unlock by doing 300 leet code problems iirc
- neilv 6y ago
  I like this idea of interviewing by talking about interests and things worked on, though it's complicated, and I can't claim to have figured it all out. A few thoughts... I used to interview people by looking at their resume, and starting asking curiosity questions about things they worked on, and going from there. I didn't have anything in particular I was looking for, just a vague sense from how they talked about it. That's more complicated when organizations want to avoid the appearance of IP taint, so, it'd help if they had a side project/interest to talk about. But I'm not assuming everyone has time for that. Also, they might be slammed by work, and in project mental space they can't talk about, and temporarily skewing the impression they give about their curiosity about other things. What's really unfortunate is all the formulaic, going-through-the-motions interviews these days. We used to make fun of the practice of hiring based on firmness of handshake, how well you dressed, and ridiculous standard interview behavioral questions that might as well be shibboleths for the people who prep for them. Now most young developers are told to prep for conveying culture fit, and answering particular kinds of CS101 coding questions/hazing, which seems to be much the same thing. That said, though I think I can do better at finding great people than that, I still need to remember to add a big dose of humility, to the idea that I can get a sense of a person as an engineer, just by talking with them. I believe I can do a pretty good job of that, with some conscious uncertainty, and I'm self-aware enough not to simply hire people in my own self image. But of course I surely have more biases than I know, and there's a lot unknowns, and our practice is not science. So I should add in extra humility than I'd naturally have about this, and find the right balance between vision of what I think is needed, and being open to seeing things I didn't already see. I also need to recognize that I'll have people coming to interview, having read the "Cracking the Interviews of FAANGs and All the Other Companies Who Act Like Stodgy Fortune 500 Hiring Large Numbers of Commodity Brogrammers" prep books, and probably seen that in some/most of their other interviews. :) And if someone shows up expecting the current usual rituals, I shouldn't hold it against them, but rather, it's my responsibility to communicate that I'd like to try to do this a bit differently. One fear is that I'll explicitly tell people I'm looking to do this "genuine", and some will interpret that as an empty platitude or conceit, in interview prep book behavioral right answer terms. :)
donw 6y ago
The best programmer interviews I have ever underwent -- as a candidate -- were almost identical to "doing real work". Either because we actually did real work -- the interview was literally "work with us for a day and see how you like it" -- or because the interview process primarily centered around exploring problems in a wide solution space, collaboratively with the interviewers.
- malechimp 6y ago
  That probably is the best but there's no time for most people to do that as they try to offload the interviews outside workhours.
l0b0 6y ago
Getting rid of the litmus test and embracing the idea that the first thing you cut your teeth on might be alien to good developers are both amazing ideas. Working on a toy problem is a terrible way to figure out whether a person will actually be beneficial to an organization. They might take twice as long but produce 1/10 the bugs, they might be someone willing and able to dig deeper than anyone else to solve those long-running problems, or something else amazing. Even giving them a meaningful task manipulating the organization's code might be bogus - with the complexity of current tech stacks there's a damn good chance they've never used yours. If you happen to give them a problem which touches any part of the tech stack they aren't familiar with, they are likely to come up with a clunky solution or no solution at all, no matter how good they are, simply because they are not familiar with the idioms.
TrackerFF 6y ago
I know this is a very polarized method, but I currently feel that take-home coding problems is the best method for prepping / selecting programmers for interviews. For it to work, you obviously need to impose some constraints - it's unreasonable (IMO) to demand too much time and energy out of candidates, but it should also be complex enough to highlight a wide variety of skills. But what's more important, is how you use it. It's an excellent tool in interviews, because you can pretty much spend an entire (technical) interview just discussing their implementation, and have more low-stress discussions around their choices and strategies. A good and experienced candidate will both showcase good code, and will be able to discuss quite fluidly and in-depth around their various choices. And if you want them to expand a bit one some technical things, you can just ask them then and there. But, again, I understand this is a wildly polarized method. Some coders would rather spend xxx hours on leetcode / hacker rank / etc. and learn every problem under the sun, and then tackle some random whiteboard question. I guess if you're fresh out of academia, that's the method which most resembles your previous experiences with testing. Some are good test-takers and love trivia. But for me, I'll stick with the take-home problems for now. Both when looking for devs, and when looking for jobs myself. Simply put, you get more data out of such problems. If a candidate cheats by hiring someone to do their work, it'll more likely than not still show up under the interview and questioning. edit: But as mentioned, it all boils down to how well you design such problems, how they are executed, and how you choose to use them in interviews. There are many ways to effectively render them useless, or even hurt your chances at attracting good devs.
- Google234 6y ago
  I personally don’t care to give up the time for take home type problems. Just interview me for 4 hours and be done with it
- C1sc0cat 6y ago
  But your excluding a large group of possible candidates
- malechimp 6y ago
  There's simply no time for that if you're already working and have a busy life (i.e. kids). One thing that I don't see much in the discussion is the assumption that we all have time to go through the interview-course material which often is irrelevant to our day to day work -and also irrelevant to the advertised role. But then again, everyone knows it, interviewing is just another role-playing. You do your part you get the role. That or you get in the company via a good recommendation avoiding all that sh!t. Like someone in valley put it, "competition is for losers". It applies to jobs too IMO.
vin2502 6y ago
Great read! Another reason companies don't like to do this is due to having less trust as companies grow. Consider a one or two person company's interview process. Because the everyone trusts each other completely (otherwise you wouldn't be trying to build a company), its easier to have an interview process that simulates real work because you trust you colleague doing the interview and don't have time to come up with a text-book process. As the company gets bigger, the chain of trust weakens. The only way to keep something that resembles trust is to comeup with a process that everyone can trust rather than just trust each other. If such a process didn't exist it would always be one person's opinion vs someone else and there would never be consensus. This is made worse by companies hiring way too aggressively chasing that next funding round or IPO than hiring when they really need to. And would rather hire someone vetted by a text book process than trust their colleagues to look for diverse skills for their teams. This vicious cycle has been going on for way too long and will have to end sometime. I feel strongly about this topic too that I wrote about sometime back, https://news.ycombinator.com/item?id=23777149 https://news.ycombinator.com/item?id=23777149
eru 6y ago
Compare the classic https://sockpuppet.org/blog/2015/03/06/the-hiring-post/ https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
raghava 6y ago
Over the years, I have grown too weary of techniques/methods (that involve things like whiteboarding to prove one's worth as an algoninja) and a 2 hourish interview. I have found good succes with the following approaches. Being in a small firm helped, but I haven't had too many difficulties following this in a large-ish firm too. (product unit in an Indian firm) - don't hire in urgency. I believe in building a talent roadmap/planfor the team, capabilities over next 6 months, and thus hire someone who I see fit enough to grow into that role - have a questionnaire sent before, which has open-ended topics ( views and perspectives on containers, infosec, cloud, imperative vs declarative, microservices vs monoliths, their fitment (and otherwise) to use-cases - etc) - talk about a recent tech challenge the person was able to tackle and resolve, try getting to extreme levels of detail (to understand whether the solutiion was a true fix or just a patchy workaround), the tradeoffs made while going that route etc - try to do a systems design session, jointly. the problem statement closer to the actual line of work - try to use a seemingly open ended objective (cost optimization, reduction in MTTR. increase MTBF, increase scalability etc) relevant to our line of work or current set of problems and see if the candidate can find a good set of questions to find their way towards a workable solution, etc. - for simpler stuff, hiring interns and then grooming them into productive, trained members of teams is often a useful way - responsibility doesn't end at offer rollout. setting their teammates for success till they are in the system is the leader's responsibility However, when am on the other side (am the one who is answering, pursuing a job elsewhere), I have come to hate the find-the-algoninja ritual so much that have stopped taking up any that forces such a deal. Am better off retaining my sanity.
DoingIsLearning 6y ago
Take 4 pages worth of interesting/diverse parts of real production code (Non-IP sensitive) and do a 'code review' where the candidate is the reviewer. For more junior candidates add blantant defects or bad design into the sample code. I have experienced this both as a candidate and as an interviewer. As a candidate, I found this a lot less adversarial and less stressful. As an interviewer, IMHO this gives a lot of insight into how a candidate thinks, without being a huge time sink, like 4 hour whiteboard tests or take-home assignments.
- collyw 6y ago
  I like this idea on principle, but I don't find it easy to jump into new codebases and see what is going on. Its usually after working with it for a couple of weeks that you see what is good and bad. Maybe something like this but given to the candidate to look over in their spare time. One of the best interviewing experiences that I had was when I was asked to bring in my laptop with some of my code to discuss. I had a side project that I was working on at the time so that was not a problem. I showed the interviewer, he asked questions, asked me to add a simple feature, I did. No algorithimc nonsense (which is basically about as reliable as a coin toss as to whether I will get the answer on the spot). No hours of my spare time wasted on take home challenges. It felt like less pressure than usual as it was code that I knew.
toomanybeersies 6y ago
Everyone talks about how hard it is to hire programmers, but is it actually harder than any other white-collar engineering-type jobs? How do you hire good electrical engineers? Every method of hiring candidates discussed seems to be accompanied by related horror stories.
nottorp 6y ago
One strategy I used - succesfully so far, but only on a small sample at my tiny company - is tell the interviewee what we do instead. And watch what questions they ask.
ateamtexas 6y ago
https://www.ateamindia.com/hire-software-developers-from-india-3x-the-development-resource-for-the-price-of-1/ https://www.ateamindia.com/hire-software-developers-from-ind...
ateamtexas 6y ago
https://www.ateamindia.com/hire-senior-angular-developer-3x-the-development-resource-for-the-price-of-1/ https://www.ateamindia.com/hire-senior-angular-developer-3x-...
badestrand 6y ago
> Ask them "What makes you think you could contribute around here?" and then listen to them. I think the author didn't lead msny interviews and only imagines themselves as the applicant. I had so many people apply for programming positions who couldn't even type the most basic for loop. The reality is, you need to find out the "level" of the applicant - are they a complete beginner, can they contribute basics, can they design medium sized projects themselves or can they be solely responsible for a larger one. That quoted approach doesn't help with that at all because many people will just tell you what you want to hear. Live coding and whiteboarding can give you good insights.

> you should not put much stock in the interview process. But there is a sense in which it is very impolite to say so. The interview processes are still very fair compared to things like "performance" reviews and company "levels". People often pretend these types of internal processes are indicators of actual competence when they are usually just based on things like nepotism and corruption. At least these algorithm interviews can successfully weed out people who can't write basic code. I can't say the same for promotion processes.

donw 6y ago
That depends entirely on the company. "Nepotism and corruption" is a very odd claim. Does this mean that only family members and friends of managers get promoted? Or that you have to bribe folks in the company to advance? What do you actually mean? What I would say is that most companies haven't really put much thought into building career ladders for their people. Or into defining roles that provide enough breadth to capture a diverse skillset, enough autonomy to get the job done, and enough in the way of pragmatic constraints to scope the role. Algorithms interviews only tell me that somebody can pass an algorithms interview -- one in which the solution space is very narrow, and there are a few correct answers. In real-world engineering, this is very rarely the case. There are always trade-offs to make. Good engineers know how to do things the cheap way now, and pragmatically invest more as we need to -- because they follow practices focused on, second only to delivering value, making the code easy to change.
- amznthrowaway5 6y ago
  > Does this mean that only family members and friends of managers get promoted? Or that you have to bribe folks in the company to advance? What do you actually mean? In many cases I've seen people being promoted due to being close friends with the managers while contributing little to nothing of value. Also dishonestly claiming credit for others work is a great way to advance. Donald trump types get promoted. > What I would say is that most companies haven't really put much thought into building career ladders for their people. These career ladder guidelines often make the problem worse. They allow poor engineers to get away with avoiding real work in favor of soft "cross-team impact". Often the lower level engineers working on the difficult technical problems are making the real contributions. Good engineers should be focused on solving the most difficult problems, whether cross-team or not. They should not be focused on gaming silly HR guidelines, people who take these guidelines seriously make the worst engineers. > Algorithms interviews only tell me that somebody can pass an algorithms interview -- one in which the solution space is very narrow, and there are a few correct answers. > In real-world engineering, this is very rarely the case. I don't agree. Psychometrics shows general cognitive ability is very important, and algorithms interviews to an extent seem like a decent test of it. Coming up with difficult solutions isn't happening without proper grasp of the basics and strong general cognitive ability.
  - sanderjd 6y ago
    From reading this comment, I think it is possible that you undervalue non-coding work. That is, I think it seems like you don't see as much value in it as some companies you've worked for do. There isn't really an objective measure to say whether you're more right or whether those companies are, but it's definitely the case that career trajectories are driven by what companies value rather than what lower level engineers value. But take my thoughts in this with a grain of salt: my bias is toward believing that most engineers place way too much value on coding work and not nearly enough on the (in my opinion) harder work of figuring out how to successfully execute an ambiguously defined project.
alexashka 6y ago
It's nepotism and corruption when you are not part of the club, sure. It is like average looking girls calling hot chicks 'bitches'. Just because you weren't born beautiful, doesn't mean somebody else is a 'bitch', just means you wish you had what they've got :)

ZainRiz 6y ago

Makes sense that when you're interviewing programmers you don't have to look for candidates proficient in your particular area. You need someone willing to learn Conversely, if you're interviewing, signaling that you are highly interested in learning turns you into a strong candidate. I learned this one by accident when I interviewed at a company I didn't care about Relevant excerpt from a blog post I wrote [1]: > I was wandering around the booths with my bag full of swag. My eyes caught a pile of rubik’s cubes being given away by some company I’d never heard of. I wanted one! Of course I couldn’t just go up and ask for it directly, so I went and chatted with the guy manning the booth. His name was Vince. A few minutes later I walked away with my prized rubik’s cube in hand. That evening Vince called me up offering to conduct a full interview loop on campus. I already had a job offer from a company I liked, but I thought “Sure, why not? I could use the experience” > I had no intention of joining the company, they were some boring finance business. There was nothing to lose. So during the interview I felt free to ask any question I wanted. When I thought I got the answer to an interview question wrong, I’d ask “I don’t think I did so great here. What’s the right answer to this problem?” (I wanted to learn the answer for future interviews!). When asked a challenging question I could grin and delight in the problem solving aspect instead of worrying about how badly it would reflect on me. (Remember my smart aleck remark in the intro? That was this interview.) > Turns out they liked that: the next day I had a second job offer. At a significantly higher salary than my first one. Oh, and they wanted to fly me to New York in two weeks for an introduction to the company. I still didn’t want to join, but a free trip to New York? Sign me up! The company’s name: Bloomberg > Bloomberg was a practiced hand at recruiting. They had a full two days of events to leave us starry eyed about the company (I came thiiiiis close to accepting their offer). While there, Vince told me I’d made a great impression by fearlessly asking questions, even when I was stumped. > Since then I’ve stopped hesitating before asking any question in an interview. Let your curiosity run free! Don’t cage it! And as an interviewer, I can attest: sincere interest is always a good sign. [1] https://zainrizvi.io/blog/the-interview-advice-no-one-gives-you/ https://zainrizvi.io/blog/the-interview-advice-no-one-gives-...

pertymcpert 6y ago
I completely agree that that's the best way to do an interview, without pressure and treating it as an intellectual exercise with some fun. Unfortunately FANGs (well at least FB) have a tendency to mark you down mentally when you show any weakness. To them you're up against 10 other candidates who got to the right answer not only correctly, but fast.

WrtCdEvrydy 6y ago

I've had some good experiences in hiring by having a conversation with the other person like if they were a human being. I know it's weird, but I just ask them what they're learning, if they have personal projects and just use that to see if they have experience writing software. Some people are super-excited about what they're learning, want to talk about the technology and end up making a good impression. Some people are only able to talk about what they're doing at work, the technical challenges and usually make a good impression as well. Whiteboarding is usually kept to high level concepts like normalization, data flow, logical architecture and things like that.

thechao 6y ago
This is how you end up with a team that’s 10x it’s components: why have _one_ 10x engineer, when you could have 7?
- glouwbug 6y ago
  There's a 10x Engineer achievement you can unlock by doing 300 leet code problems iirc
neilv 6y ago
I like this idea of interviewing by talking about interests and things worked on, though it's complicated, and I can't claim to have figured it all out. A few thoughts... I used to interview people by looking at their resume, and starting asking curiosity questions about things they worked on, and going from there. I didn't have anything in particular I was looking for, just a vague sense from how they talked about it. That's more complicated when organizations want to avoid the appearance of IP taint, so, it'd help if they had a side project/interest to talk about. But I'm not assuming everyone has time for that. Also, they might be slammed by work, and in project mental space they can't talk about, and temporarily skewing the impression they give about their curiosity about other things. What's really unfortunate is all the formulaic, going-through-the-motions interviews these days. We used to make fun of the practice of hiring based on firmness of handshake, how well you dressed, and ridiculous standard interview behavioral questions that might as well be shibboleths for the people who prep for them. Now most young developers are told to prep for conveying culture fit, and answering particular kinds of CS101 coding questions/hazing, which seems to be much the same thing. That said, though I think I can do better at finding great people than that, I still need to remember to add a big dose of humility, to the idea that I can get a sense of a person as an engineer, just by talking with them. I believe I can do a pretty good job of that, with some conscious uncertainty, and I'm self-aware enough not to simply hire people in my own self image. But of course I surely have more biases than I know, and there's a lot unknowns, and our practice is not science. So I should add in extra humility than I'd naturally have about this, and find the right balance between vision of what I think is needed, and being open to seeing things I didn't already see. I also need to recognize that I'll have people coming to interview, having read the "Cracking the Interviews of FAANGs and All the Other Companies Who Act Like Stodgy Fortune 500 Hiring Large Numbers of Commodity Brogrammers" prep books, and probably seen that in some/most of their other interviews. :) And if someone shows up expecting the current usual rituals, I shouldn't hold it against them, but rather, it's my responsibility to communicate that I'd like to try to do this a bit differently. One fear is that I'll explicitly tell people I'm looking to do this "genuine", and some will interpret that as an empty platitude or conceit, in interview prep book behavioral right answer terms. :)

donw 6y ago

The best programmer interviews I have ever underwent -- as a candidate -- were almost identical to "doing real work". Either because we actually did real work -- the interview was literally "work with us for a day and see how you like it" -- or because the interview process primarily centered around exploring problems in a wide solution space, collaboratively with the interviewers.

malechimp 6y ago
That probably is the best but there's no time for most people to do that as they try to offload the interviews outside workhours.

l0b0 6y ago

Getting rid of the litmus test and embracing the idea that the first thing you cut your teeth on might be alien to good developers are both amazing ideas. Working on a toy problem is a terrible way to figure out whether a person will actually be beneficial to an organization. They might take twice as long but produce 1/10 the bugs, they might be someone willing and able to dig deeper than anyone else to solve those long-running problems, or something else amazing. Even giving them a meaningful task manipulating the organization's code might be bogus - with the complexity of current tech stacks there's a damn good chance they've never used yours. If you happen to give them a problem which touches any part of the tech stack they aren't familiar with, they are likely to come up with a clunky solution or no solution at all, no matter how good they are, simply because they are not familiar with the idioms.

TrackerFF 6y ago

I know this is a very polarized method, but I currently feel that take-home coding problems is the best method for prepping / selecting programmers for interviews. For it to work, you obviously need to impose some constraints - it's unreasonable (IMO) to demand too much time and energy out of candidates, but it should also be complex enough to highlight a wide variety of skills. But what's more important, is how you use it. It's an excellent tool in interviews, because you can pretty much spend an entire (technical) interview just discussing their implementation, and have more low-stress discussions around their choices and strategies. A good and experienced candidate will both showcase good code, and will be able to discuss quite fluidly and in-depth around their various choices. And if you want them to expand a bit one some technical things, you can just ask them then and there. But, again, I understand this is a wildly polarized method. Some coders would rather spend xxx hours on leetcode / hacker rank / etc. and learn every problem under the sun, and then tackle some random whiteboard question. I guess if you're fresh out of academia, that's the method which most resembles your previous experiences with testing. Some are good test-takers and love trivia. But for me, I'll stick with the take-home problems for now. Both when looking for devs, and when looking for jobs myself. Simply put, you get more data out of such problems. If a candidate cheats by hiring someone to do their work, it'll more likely than not still show up under the interview and questioning. edit: But as mentioned, it all boils down to how well you design such problems, how they are executed, and how you choose to use them in interviews. There are many ways to effectively render them useless, or even hurt your chances at attracting good devs.

Google234 6y ago
I personally don’t care to give up the time for take home type problems. Just interview me for 4 hours and be done with it
C1sc0cat 6y ago
But your excluding a large group of possible candidates
malechimp 6y ago
There's simply no time for that if you're already working and have a busy life (i.e. kids). One thing that I don't see much in the discussion is the assumption that we all have time to go through the interview-course material which often is irrelevant to our day to day work -and also irrelevant to the advertised role. But then again, everyone knows it, interviewing is just another role-playing. You do your part you get the role. That or you get in the company via a good recommendation avoiding all that sh!t. Like someone in valley put it, "competition is for losers". It applies to jobs too IMO.

vin2502 6y ago

Great read! Another reason companies don't like to do this is due to having less trust as companies grow. Consider a one or two person company's interview process. Because the everyone trusts each other completely (otherwise you wouldn't be trying to build a company), its easier to have an interview process that simulates real work because you trust you colleague doing the interview and don't have time to come up with a text-book process. As the company gets bigger, the chain of trust weakens. The only way to keep something that resembles trust is to comeup with a process that everyone can trust rather than just trust each other. If such a process didn't exist it would always be one person's opinion vs someone else and there would never be consensus. This is made worse by companies hiring way too aggressively chasing that next funding round or IPO than hiring when they really need to. And would rather hire someone vetted by a text book process than trust their colleagues to look for diverse skills for their teams. This vicious cycle has been going on for way too long and will have to end sometime. I feel strongly about this topic too that I wrote about sometime back, https://news.ycombinator.com/item?id=23777149 https://news.ycombinator.com/item?id=23777149

eru 6y ago

Compare the classic https://sockpuppet.org/blog/2015/03/06/the-hiring-post/ https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

raghava 6y ago

Over the years, I have grown too weary of techniques/methods (that involve things like whiteboarding to prove one's worth as an algoninja) and a 2 hourish interview. I have found good succes with the following approaches. Being in a small firm helped, but I haven't had too many difficulties following this in a large-ish firm too. (product unit in an Indian firm) - don't hire in urgency. I believe in building a talent roadmap/planfor the team, capabilities over next 6 months, and thus hire someone who I see fit enough to grow into that role - have a questionnaire sent before, which has open-ended topics ( views and perspectives on containers, infosec, cloud, imperative vs declarative, microservices vs monoliths, their fitment (and otherwise) to use-cases - etc) - talk about a recent tech challenge the person was able to tackle and resolve, try getting to extreme levels of detail (to understand whether the solutiion was a true fix or just a patchy workaround), the tradeoffs made while going that route etc - try to do a systems design session, jointly. the problem statement closer to the actual line of work - try to use a seemingly open ended objective (cost optimization, reduction in MTTR. increase MTBF, increase scalability etc) relevant to our line of work or current set of problems and see if the candidate can find a good set of questions to find their way towards a workable solution, etc. - for simpler stuff, hiring interns and then grooming them into productive, trained members of teams is often a useful way - responsibility doesn't end at offer rollout. setting their teammates for success till they are in the system is the leader's responsibility However, when am on the other side (am the one who is answering, pursuing a job elsewhere), I have come to hate the find-the-algoninja ritual so much that have stopped taking up any that forces such a deal. Am better off retaining my sanity.

DoingIsLearning 6y ago

Take 4 pages worth of interesting/diverse parts of real production code (Non-IP sensitive) and do a 'code review' where the candidate is the reviewer. For more junior candidates add blantant defects or bad design into the sample code. I have experienced this both as a candidate and as an interviewer. As a candidate, I found this a lot less adversarial and less stressful. As an interviewer, IMHO this gives a lot of insight into how a candidate thinks, without being a huge time sink, like 4 hour whiteboard tests or take-home assignments.

collyw 6y ago
I like this idea on principle, but I don't find it easy to jump into new codebases and see what is going on. Its usually after working with it for a couple of weeks that you see what is good and bad. Maybe something like this but given to the candidate to look over in their spare time. One of the best interviewing experiences that I had was when I was asked to bring in my laptop with some of my code to discuss. I had a side project that I was working on at the time so that was not a problem. I showed the interviewer, he asked questions, asked me to add a simple feature, I did. No algorithimc nonsense (which is basically about as reliable as a coin toss as to whether I will get the answer on the spot). No hours of my spare time wasted on take home challenges. It felt like less pressure than usual as it was code that I knew.

toomanybeersies 6y ago

Everyone talks about how hard it is to hire programmers, but is it actually harder than any other white-collar engineering-type jobs? How do you hire good electrical engineers? Every method of hiring candidates discussed seems to be accompanied by related horror stories.

nottorp 6y ago

One strategy I used - succesfully so far, but only on a small sample at my tiny company - is tell the interviewee what we do instead. And watch what questions they ask.

ateamtexas 6y ago

https://www.ateamindia.com/hire-software-developers-from-india-3x-the-development-resource-for-the-price-of-1/ https://www.ateamindia.com/hire-software-developers-from-ind...

ateamtexas 6y ago

https://www.ateamindia.com/hire-senior-angular-developer-3x-the-development-resource-for-the-price-of-1/ https://www.ateamindia.com/hire-senior-angular-developer-3x-...

badestrand 6y ago

> Ask them "What makes you think you could contribute around here?" and then listen to them. I think the author didn't lead msny interviews and only imagines themselves as the applicant. I had so many people apply for programming positions who couldn't even type the most basic for loop. The reality is, you need to find out the "level" of the applicant - are they a complete beginner, can they contribute basics, can they design medium sized projects themselves or can they be solely responsible for a larger one. That quoted approach doesn't help with that at all because many people will just tell you what you want to hear. Live coding and whiteboarding can give you good insights.