6 ms·

That is a pretty huge statistic, - what also pops out to me is: "stop practicing ". This seems to imply that these technical interviews are skills that you don'

by divbit 10y ago

That is a pretty huge statistic, - what also pops out to me is: "stop practicing ". This seems to imply that these technical interviews are skills that you don't really gain on the job. I know that personally would 9 times out of 10 spend time on a cool / beneficial project rather than making time to practice trivia problems.

trhway 10y ago
>This seems to imply that these technical interviews are skills that you don't really gain on the job. the technical interviews skills are gained, at least in my experience, as result of the technical interviews - which normally implies, and did happen in my case, high rate of interview failures initially. Taking failures hard would naturally lead to Catch-22 here.
- foolfoolz 10y ago
  the biggest catch 22 for me is when you work with someone for years at a job. at this job you have a strong interview process. you reject the same 80%+ of candidates. then you move somewhere else. you refer your friend. they get rejected. were they a bad employee? did they sneak in the door at the last place? Is there a problem with how we do interviews?
  - sjburt 10y ago
    Speaking as someone who has taken on a lot of hiring responsibility: the cost for rejecting a good applicant is 4-5 hours of my teams time while they interview someone else. The cost for accepting a bad applicant is several months of salary, reduced productivity for my team, risk of a discrimination suit if I don't put them on a PIP, etc. So as a hiring manager I am pretty OK with rejecting a lot of good applicants just because some little part of the interview didn't go well, if it means that I never hire anyone really bad. The good applicants will get jobs somewhere else, it's OK. The technical interview is part of that. The coding test is part of that. Sitting down with them and making sure they can talk through a problem with their future teammates is part of that. There's no one piece. And finally, if your career is to write code and solve problems, and someone gives you a test where you have to write code and solve problems, you should be elated. Is there anyone that wants to answer the "Tell me about a time where you had a disagreement with a supervisor"-type questions that the rest of the world has to deal with?
    - MustardTiger 10y ago
      >the cost for rejecting a good applicant is 4-5 hours of my teams time while they interview someone else The cost seems much higher to me. I have to interview dozens of people to find a single good applicant. Rejecting one good applicant costs me dozens of interviews, not one.
    - mjevans 10y ago
      Maybe actual apprenticeships are the answer. 3-6 months to get someone trained up, and a lot of their pay would be in /training/ them (you'd still pay at least a living wage for the area, but you might upfront plan and disclose to relocate them if hired). The benefit would be both in seeing if they're a good fit, and also enriching that employee as an employee. Both sides would have a much better perspective of if it's a good fit, if they want to restart the process with a different team, or if the employee can find better value in society elsewhere.
      - kagamine 10y ago
        When you think about it, college degrees in IT/CS are the wrong way to go about IT/CS learning. A 3 year apprenticeship like an electrician or plumber does would make a lot more sense. 60% of your time is spent at work, shadowing and helping an experienced professional who can show you the ropes and explain concepts in the real world. Remaining time spent in the classroom doing theory and learning new stuff. My degree attempted something like this, with a lot of guest companies providing projects that amounted to coursework. For example, one coursework was to make a front and back end in asp.net with a predefined set of features for a company. The problem with apprenticeships is that educators are handing over a large part of your training to a company with unknown factors, like mental people with random hangups. Still, I'm sure many of us when we got our first job felt hopelessly unprepared for working in a real company.
      - wyclif 10y ago
        My experience, when I ask decision-makers about training, is that there's a lot of resistance to the idea because of fear of poaching.
- bostik 10y ago
  > technical interviews skills are gained Oh yes, and that applies to both sides of the table. Interviewing skills are learned as well - and they can be taught. (A friend is proud of the fact that he's had actual interviewing training.) Interviewing is not that hard, but it sure as hell is a difficult thing to master. I'm reasonably good, but still nowhere near as good as I'd want to be. Nonetheless, it's still a skill that can be learned and improved. The irony is that it'll be easier to improve one's interviewer skills than those of being interviewed. The reason is that if you're conducting technical interviews, you'll be doing it as part of your job, and any reasonably good interviewer will have his or her calendar full of learning opportunities. Candidates will have less opportunities and due to the nature of the experience, are likely to be demoralising to boot. I recently wrote a post about things I've picked up and learned when doing technical interviews: https://smarketshq.com/notes-on-interviewing-engineers-a4fa4383968a https://smarketshq.com/notes-on-interviewing-engineers-a4fa4... ; when judging the experience from HN posts, I cannot help the feeling that most engineers are subjected to pretty horrible, even recurring interviewing experiences.
wpietri 10y ago
> these technical interviews are skills that you don't really gain on the job I believe that's definitely the case. That's why I shifted my interviews to be as much like the work as possible. First round was a pair programming interview plus a bit of technical discussion. Second round was kicking around a feature and its implementation with the team. My goal was also to see people at their best, so I did as much as possible to make them comfortable. E.g., for the programming portion they were welcome to use their own device, their favorite editor, and their strongest language. I was very happy with the results, and aim to keep moving in that "make it real" direction. I wrote more about my approach here: http://williampietri.com/writing/2015/slightly-less-awful-hiring/ http://williampietri.com/writing/2015/slightly-less-awful-hi...
- Scea91 10y ago
  > Second round was kicking around a feature and its implementation with the team. I suppose it was a toy feature. Isn't it detrimental to the teams performance if all of them have to be present at the interview?
  - Declanomous 10y ago
    Wouldn't it be more detrimental to a team's performance to hire someone who isn't a cultural/productive fit? I think that would make the temporary performance hit when hiring worthwhile.
    - wpietri 10y ago
      Exactly. A good hire will add thousands of hours of productivity. A bad hire can be negatively productive, either personally, by harming team performance, or by driving off productive people. Trying to minimize team-minutes spent per candidate on late-stage interviews is a false economy. In practice, I don't try to get absolutely every team member involved, just a quorum. If everybody wants to have a say, that's fine by me, but often once you get past 3 participants somebody will say, "Oh, whatever you folks think is fine by me."
Scea91 10y ago
I've had 4 technical interviews in my life and passed all of them. I didn't practice for them, I just have strong foundations in CS. The most criticism of interviews comes from people who can't get past them.
- divbit 10y ago
  > I didn't practice for them, I just have strong foundations in CS. Perhaps my take on things is different since my degrees are in math, so I don't have a bunch of 'canned' algorithms stored in my head, and so in a whiteboard would come up with my own technique, even for possibly basic things like trees / sorting.
  - Ar-Curunir 10y ago
    I'm sure that even in math you need to know some basic things; for instance every math major knows basic theorems about groups, fields, rings, about real analysis, and so on. It's the same for CS; basic knowledge of algorithms and data structures, and how these can be composed, is what a technical interview tests.
    - divbit 10y ago
      Maybe it is worth pushing 'pause' on my list of project ideas and just spend a month or so memorizing all the different sort algorithms etc.
      - Ar-Curunir 10y ago
        There's just three sorting algorithms anyone cares about, and they're not particularly complex. Someone with a math background should be able to pick them up in a few hours at most.
        divbit 10y ago
        Probably useful to cut it down as much as possible.
gozur88 10y ago
Getting a job and actually performing the job are two entirely different skillsets. There are a whole lot of people who bounce from one three month gig to the next as the people who hire them realize it was a mistake.

by divbit 10y ago

trhway 10y ago

>This seems to imply that these technical interviews are skills that you don't really gain on the job. the technical interviews skills are gained, at least in my experience, as result of the technical interviews - which normally implies, and did happen in my case, high rate of interview failures initially. Taking failures hard would naturally lead to Catch-22 here.

foolfoolz 10y ago
the biggest catch 22 for me is when you work with someone for years at a job. at this job you have a strong interview process. you reject the same 80%+ of candidates. then you move somewhere else. you refer your friend. they get rejected. were they a bad employee? did they sneak in the door at the last place? Is there a problem with how we do interviews?
- sjburt 10y ago
  Speaking as someone who has taken on a lot of hiring responsibility: the cost for rejecting a good applicant is 4-5 hours of my teams time while they interview someone else. The cost for accepting a bad applicant is several months of salary, reduced productivity for my team, risk of a discrimination suit if I don't put them on a PIP, etc. So as a hiring manager I am pretty OK with rejecting a lot of good applicants just because some little part of the interview didn't go well, if it means that I never hire anyone really bad. The good applicants will get jobs somewhere else, it's OK. The technical interview is part of that. The coding test is part of that. Sitting down with them and making sure they can talk through a problem with their future teammates is part of that. There's no one piece. And finally, if your career is to write code and solve problems, and someone gives you a test where you have to write code and solve problems, you should be elated. Is there anyone that wants to answer the "Tell me about a time where you had a disagreement with a supervisor"-type questions that the rest of the world has to deal with?
  - MustardTiger 10y ago
    >the cost for rejecting a good applicant is 4-5 hours of my teams time while they interview someone else The cost seems much higher to me. I have to interview dozens of people to find a single good applicant. Rejecting one good applicant costs me dozens of interviews, not one.
  - mjevans 10y ago
    Maybe actual apprenticeships are the answer. 3-6 months to get someone trained up, and a lot of their pay would be in /training/ them (you'd still pay at least a living wage for the area, but you might upfront plan and disclose to relocate them if hired). The benefit would be both in seeing if they're a good fit, and also enriching that employee as an employee. Both sides would have a much better perspective of if it's a good fit, if they want to restart the process with a different team, or if the employee can find better value in society elsewhere.
    - kagamine 10y ago
      When you think about it, college degrees in IT/CS are the wrong way to go about IT/CS learning. A 3 year apprenticeship like an electrician or plumber does would make a lot more sense. 60% of your time is spent at work, shadowing and helping an experienced professional who can show you the ropes and explain concepts in the real world. Remaining time spent in the classroom doing theory and learning new stuff. My degree attempted something like this, with a lot of guest companies providing projects that amounted to coursework. For example, one coursework was to make a front and back end in asp.net with a predefined set of features for a company. The problem with apprenticeships is that educators are handing over a large part of your training to a company with unknown factors, like mental people with random hangups. Still, I'm sure many of us when we got our first job felt hopelessly unprepared for working in a real company.
    - wyclif 10y ago
      My experience, when I ask decision-makers about training, is that there's a lot of resistance to the idea because of fear of poaching.
bostik 10y ago
> technical interviews skills are gained Oh yes, and that applies to both sides of the table. Interviewing skills are learned as well - and they can be taught. (A friend is proud of the fact that he's had actual interviewing training.) Interviewing is not that hard, but it sure as hell is a difficult thing to master. I'm reasonably good, but still nowhere near as good as I'd want to be. Nonetheless, it's still a skill that can be learned and improved. The irony is that it'll be easier to improve one's interviewer skills than those of being interviewed. The reason is that if you're conducting technical interviews, you'll be doing it as part of your job, and any reasonably good interviewer will have his or her calendar full of learning opportunities. Candidates will have less opportunities and due to the nature of the experience, are likely to be demoralising to boot. I recently wrote a post about things I've picked up and learned when doing technical interviews: https://smarketshq.com/notes-on-interviewing-engineers-a4fa4383968a https://smarketshq.com/notes-on-interviewing-engineers-a4fa4... ; when judging the experience from HN posts, I cannot help the feeling that most engineers are subjected to pretty horrible, even recurring interviewing experiences.

wpietri 10y ago

> these technical interviews are skills that you don't really gain on the job I believe that's definitely the case. That's why I shifted my interviews to be as much like the work as possible. First round was a pair programming interview plus a bit of technical discussion. Second round was kicking around a feature and its implementation with the team. My goal was also to see people at their best, so I did as much as possible to make them comfortable. E.g., for the programming portion they were welcome to use their own device, their favorite editor, and their strongest language. I was very happy with the results, and aim to keep moving in that "make it real" direction. I wrote more about my approach here: http://williampietri.com/writing/2015/slightly-less-awful-hiring/ http://williampietri.com/writing/2015/slightly-less-awful-hi...

Scea91 10y ago
> Second round was kicking around a feature and its implementation with the team. I suppose it was a toy feature. Isn't it detrimental to the teams performance if all of them have to be present at the interview?
- Declanomous 10y ago
  Wouldn't it be more detrimental to a team's performance to hire someone who isn't a cultural/productive fit? I think that would make the temporary performance hit when hiring worthwhile.
  - wpietri 10y ago
    Exactly. A good hire will add thousands of hours of productivity. A bad hire can be negatively productive, either personally, by harming team performance, or by driving off productive people. Trying to minimize team-minutes spent per candidate on late-stage interviews is a false economy. In practice, I don't try to get absolutely every team member involved, just a quorum. If everybody wants to have a say, that's fine by me, but often once you get past 3 participants somebody will say, "Oh, whatever you folks think is fine by me."

Scea91 10y ago

I've had 4 technical interviews in my life and passed all of them. I didn't practice for them, I just have strong foundations in CS. The most criticism of interviews comes from people who can't get past them.

divbit 10y ago
> I didn't practice for them, I just have strong foundations in CS. Perhaps my take on things is different since my degrees are in math, so I don't have a bunch of 'canned' algorithms stored in my head, and so in a whiteboard would come up with my own technique, even for possibly basic things like trees / sorting.
- Ar-Curunir 10y ago
  I'm sure that even in math you need to know some basic things; for instance every math major knows basic theorems about groups, fields, rings, about real analysis, and so on. It's the same for CS; basic knowledge of algorithms and data structures, and how these can be composed, is what a technical interview tests.
  - divbit 10y ago
    Maybe it is worth pushing 'pause' on my list of project ideas and just spend a month or so memorizing all the different sort algorithms etc.
    - Ar-Curunir 10y ago
      There's just three sorting algorithms anyone cares about, and they're not particularly complex. Someone with a math background should be able to pick them up in a few hours at most.
      - divbit 10y ago
        Probably useful to cut it down as much as possible.

gozur88 10y ago

Getting a job and actually performing the job are two entirely different skillsets. There are a whole lot of people who bounce from one three month gig to the next as the people who hire them realize it was a mistake.