Ask HN: Would you pass own your company's interview?
And does it matter either way?
26 comments
If I were to have to repeat it, odds are I would most definitely not.
I consider it a miracle that I got in. I thank God every day.
Did the interview matter, in terms of technically assessing for what I do day to day? Very little.
I consider it a miracle that I got in. I thank God every day.
Did the interview matter, in terms of technically assessing for what I do day to day? Very little.
Over the last decade+ I've been involved in the hiring process at every company I've been an employee at. I've either been a key technical interviewer, or the hiring manager. I would be able to pass all my interviews, and I'm pleased to say that (with one exception) all of my hires have succeeded in their roles. I have a very straightforward process.
- Look at every resume, pass/fail fast. Ask the Recruiter or HR to give you more resumes, not less (they typically are not equipped to assess techncal resumes)
- 15 minute phone screen. Make sure the role fits expectations, make sure the salary range is acceptable, get and give a verbal background.
- At-home code task. Something that takes an hour or so to get functional. More if the interviewee wants to put some spit-shine on it. I ask for a git repo back, and I tell the applicant up front that the code will be used to springboard the technical interview.
- 2 hour technical interview, no live-coding. In person or virtual. This involves other engineers from the org -- we code review the git repo. For each code task I have a set of 3/4 "Product Manager" style enhancement requests, we then verbally talk through the technical changes & challenges for each ask.
- 15 minute chat with the CT or VP or whomever is my boss.
- Extend an offer.
It's all very real, and very pragmatic, and shouldn't suck more than 4-6 hours out of an applicants life, total. I want to be able to extend an offer within days, assuming everyone's schedule aligns. There is 0 reason to go deeper. If you cannot asses someone's technical chops in a 2 hour conversation, you shouldn't be involved in hiring. If you couldn't complete the coding challenges to your own satisfaction, you shouldn't be involved in hiring (there are engineers I've worked with who are no longer involved in hiring due to unneeded pedantry that they themselves would not tolerate if the shoe was on the other foot).
- Look at every resume, pass/fail fast. Ask the Recruiter or HR to give you more resumes, not less (they typically are not equipped to assess techncal resumes)
- 15 minute phone screen. Make sure the role fits expectations, make sure the salary range is acceptable, get and give a verbal background.
- At-home code task. Something that takes an hour or so to get functional. More if the interviewee wants to put some spit-shine on it. I ask for a git repo back, and I tell the applicant up front that the code will be used to springboard the technical interview.
- 2 hour technical interview, no live-coding. In person or virtual. This involves other engineers from the org -- we code review the git repo. For each code task I have a set of 3/4 "Product Manager" style enhancement requests, we then verbally talk through the technical changes & challenges for each ask.
- 15 minute chat with the CT or VP or whomever is my boss.
- Extend an offer.
It's all very real, and very pragmatic, and shouldn't suck more than 4-6 hours out of an applicants life, total. I want to be able to extend an offer within days, assuming everyone's schedule aligns. There is 0 reason to go deeper. If you cannot asses someone's technical chops in a 2 hour conversation, you shouldn't be involved in hiring. If you couldn't complete the coding challenges to your own satisfaction, you shouldn't be involved in hiring (there are engineers I've worked with who are no longer involved in hiring due to unneeded pedantry that they themselves would not tolerate if the shoe was on the other foot).
Just thinking about all the roles I’ve interviewed for across from someone with 2 yoe asking a version of an A* algorithm implementation for web development.
Sounds like a decent place!
Sounds like a decent place!
No. Because it is a problem that has nothing to do with real work. I would need to spend at least a month practicing those kinds of problems to be able to perform well in that 1 hour.
thanks for your honesty. have you informed management the interviews are unfair?
Yes. They don't care. They push it back onto various interviewer committees who also don't care.
The last few times we have done interviews I’ve done the same coding test as the applicants while they are working on it. I try to solve it in a slightly different way each time.
We are currently revamping our hiring process and the questions we keep asking are “Would X, Y, Z pass this or get hung up on this coding test, question, etc”. As in taking care to think about how existing employees would do on the new process.
We are currently revamping our hiring process and the questions we keep asking are “Would X, Y, Z pass this or get hung up on this coding test, question, etc”. As in taking care to think about how existing employees would do on the new process.
but you have solved it before, so it does not give you a good idea of whether your coding test can reasonably be solved in time.
A few years ago we started using HackerRank and created a test with 4 or 5 coding questions for candidates to do on their own. They could pick the programming language from about 10 options and the questions had varying degrees of complexity, with one being particularly difficult.
I sent it to almost all engineers on the team before we started using it and none could hit a 100% on it.
We still went ahead and started using it in our process. Non surprisingly, most folks would fail to get a perfect score but we still use it to see what they tried and also one of the following interviews was a review of the whole test with the applicant as we discussed their thought process and what other odeas they may have come with since they took the test.
Our intention with the test was mostly basic problem solving skills and was the first step in the process so it also worked as a filter.
I sent it to almost all engineers on the team before we started using it and none could hit a 100% on it.
We still went ahead and started using it in our process. Non surprisingly, most folks would fail to get a perfect score but we still use it to see what they tried and also one of the following interviews was a review of the whole test with the applicant as we discussed their thought process and what other odeas they may have come with since they took the test.
Our intention with the test was mostly basic problem solving skills and was the first step in the process so it also worked as a filter.
Yes. My company thankfully does not do leetcode stuff. When I was interviewing I was tasked with some serialization/deseriazation, which we actually used inside our company.
[deleted]
Yes, but not every time, because there are certain algorithmic problems I'm just more comfortable with than others, even amongst unseen problems.
Back in late 00's I worked for a very small shop where it was known that I was toying with the idea of moving on, so we were actively seeking to hire my replacement while I was still there (sounds insane, I know, but it was the right thing to do).
We had an application developed in-house (by me) and the new hire was to take it over -- this implied needing somebody who could become productive quickly and think on their feet. The app itself wasn't insane, just pretty standard (but bespoke) PHP/MySQL/JavaScript that powered a bunch of client sites, so I put together and proctored a "code test" to probably 15 applicants over the course of a year or so.
The extent of it was sitting them down in front of a computer in the office with a couple of simple tasks to be completed (outlined on paper), and a folder of files on the desktop. The tasks themselves were then almost entirely-documented in a big comment at the top of the relevant entry file (index.[php|html|js]). It should've taken somebody experienced an hour to do a decent job at -- yet, not a single person was ever able to complete it. Very few even got close, even though 80% of the work was literally done in the opening comment section, waiting to be copied and pasted. Almost nobody asked any questions whatsoever either, which I've always found strange.
Anyways, I did end up moving on and later participated in many dozens of incoming developer interviews at a much larger place -- other interviewers had their very-technical approaches, but I never again asked anybody to complete a coding task or whiteboard anything. I would simply ask them to walk me through where they've been, what they've done (built, contributed to, etc), and what they like to do. You can tell almost instantly when somebody is full of shit if they can't talk about previous projects in-depth or with fluency (or simply admit that they have no real experience and are hungry to learn).
The interviews where I would report back "not full of shit" turned out to be a bunch of great hires (including one guy who I had actually interviewed years prior with the doomed code test!)
Take all that for what you will -- my personal opinion is that companies are missing out on some really great people specifically because of the interview process, but I also get the feeling that lots of companies aren't actually looking for the people that would be the best hires -- good-enough / "warm body" hires promote business continuity, and that's really better for the bottom line in larger organizations.
We had an application developed in-house (by me) and the new hire was to take it over -- this implied needing somebody who could become productive quickly and think on their feet. The app itself wasn't insane, just pretty standard (but bespoke) PHP/MySQL/JavaScript that powered a bunch of client sites, so I put together and proctored a "code test" to probably 15 applicants over the course of a year or so.
The extent of it was sitting them down in front of a computer in the office with a couple of simple tasks to be completed (outlined on paper), and a folder of files on the desktop. The tasks themselves were then almost entirely-documented in a big comment at the top of the relevant entry file (index.[php|html|js]). It should've taken somebody experienced an hour to do a decent job at -- yet, not a single person was ever able to complete it. Very few even got close, even though 80% of the work was literally done in the opening comment section, waiting to be copied and pasted. Almost nobody asked any questions whatsoever either, which I've always found strange.
Anyways, I did end up moving on and later participated in many dozens of incoming developer interviews at a much larger place -- other interviewers had their very-technical approaches, but I never again asked anybody to complete a coding task or whiteboard anything. I would simply ask them to walk me through where they've been, what they've done (built, contributed to, etc), and what they like to do. You can tell almost instantly when somebody is full of shit if they can't talk about previous projects in-depth or with fluency (or simply admit that they have no real experience and are hungry to learn).
The interviews where I would report back "not full of shit" turned out to be a bunch of great hires (including one guy who I had actually interviewed years prior with the doomed code test!)
Take all that for what you will -- my personal opinion is that companies are missing out on some really great people specifically because of the interview process, but I also get the feeling that lots of companies aren't actually looking for the people that would be the best hires -- good-enough / "warm body" hires promote business continuity, and that's really better for the bottom line in larger organizations.
You should have 50/50 odds. If you don't, you're dropping the overall bar on each hire.
It’s the same interview so probably
Geez, I hope not. If I'm lucky enough to build a profitable company someday I hope I can hire some people who are much smarter than me to keep it that way.
Nope, not even close.
My skills have declined since I started. I've gotten older and more cynical, so they'll see way less potential. They'll also be wondering what's wrong with me that I'm still a midlevel dev after a decade of experience (hint: I have a disability).
It doesn't really matter if I'd pass today. Although many of these points come up or apply to my year end evaluations (it's not pretty).
My skills have declined since I started. I've gotten older and more cynical, so they'll see way less potential. They'll also be wondering what's wrong with me that I'm still a midlevel dev after a decade of experience (hint: I have a disability).
It doesn't really matter if I'd pass today. Although many of these points come up or apply to my year end evaluations (it's not pretty).
Would you be willing to speak more about your disability, evaluations, and your day-to-day? I’d also be curious as to your evaluations, and whether or not you’ve appealed via the ADA?
If you have disability/medical issues, keep your mouth shut about them. Source: I have some.
Doubt it. Software engineering is such a silly career.
Probably not. TBH it depends somewhat on interviewer type.
How did you get the job in the first place ?
Based on the 5 years ago interview :-)
Well, yeah, because I did.
I walked into a conference room to meet with the CTO, CFO, and lead dev. A huge whiteboard in the room, I was like _sh*t_.
But the test was basically a few sheets of paper with some technical questions, along with a conversation. There was a take-home as well, which annoyed me because I already answered ~12 meant-to-be tricky questions, drove ~45 minutes, spent 30 minutes waiting for everyone, and an hour conversation. But it was worth it in the end.
I have flat out refused a few companies interview processes in the past, telling them I don't have the time nor patience for the games. I still managed to get those jobs, surprisingly.
I walked into a conference room to meet with the CTO, CFO, and lead dev. A huge whiteboard in the room, I was like _sh*t_.
But the test was basically a few sheets of paper with some technical questions, along with a conversation. There was a take-home as well, which annoyed me because I already answered ~12 meant-to-be tricky questions, drove ~45 minutes, spent 30 minutes waiting for everyone, and an hour conversation. But it was worth it in the end.
I have flat out refused a few companies interview processes in the past, telling them I don't have the time nor patience for the games. I still managed to get those jobs, surprisingly.
If I didn't have a cold, if I had not worked 80 hours the week before, if my wife and kids were ok.....and if I had time to spend about 5 hours a day for 3 months on leetcode....
....sure I could pass it.
....sure I could pass it.
why would i bother?