8 ms·

What I learned about interviewing

75 points by luu 5y ago

oriettaxx 5y ago
some job screenings are really ridiculous: coding is not rocket science, come on (yes, I understand the need of filtering in case you have a lot of application, but how many have a lot of applicants?)
lkrubner 5y ago
I'm currently writing a book on the subject of bad hiring practices, and other management mistakes. Allow me to share some of what I wrote: --------------------- Homework assignments and personality quizzes won’t give you excellence This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program. Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned. "Wow, I didn't expect things to move this fast!" she exclaimed. Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!" Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.” At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?” What an empty ritual; reading words that are not understood.
- lkrubner 5y ago
  And a bit more from my book: ---------- Homework assignments and personality quizzes won’t give you excellence This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program. Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned. "Wow, I didn't expect things to move this fast!" she exclaimed. Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!" Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.” At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?” What an empty ritual; reading words that are not understood. If you are lost at sea, don’t drink the brine Stories abound of people lost at sea, perhaps because their ship engine died, or their ship sank and they escaped in a life raft. Once the clean drinking water runs out, the temptation to drink the sea water is strong. But of course, that is a fatal step: the sea has more salt than than the human body can tolerate; drinking makes you more thirsty, not less so. And yet the sea is vast. What a paradox, to die of thirst amid such an abundance. “Water, water, everywhere, and not a drop to drink,” as Coleridge said. I’ve had this conversation with tech team leads: Me: Where are you looking for candidates? Them: I’ve put a job posting up at LinkedIn and Indeed and StackOverflow. Me: Did you get any candidates that you like? Them: Well, the problem is, I’ve gotten several thousand. The problem is trying to narrow down the pile. I cannot possibly look through all of them. I’ve decided to post the job a second time, but this time I created quiz that people have to take. Me: What is the quiz about? Them: It’s 100 questions about the technologies we use, plus some algorithm questions that should help cut down the number of applicants who get through. Me: You created the questions yourself? Them: No, I copy-and-pasted them from various online sources. Most of them are about standard stuff. I put in a few trick questions to help filter out the weak candidates. Me: Are you sure you want the candidates who get your trick questions? Them: Well, if they get the trick questions, then they must know some fairly obscure stuff. Me: Is that what you need right now, people who happen to know some fairly obscure stuff? Them: Well, not really, our work here is fairly standard, but I need some way to screen the applicants because the first time I posted the job we got way too many responses. Me: Are you sure the people who get your most obscure questions are the candidates who will work out the best once you hire them? Them: No, but I’m not sure what else to do. You never really know about a person until you’ve seen them actually work. Me: How many people do you need to hire? Them: I need 3 developers for the frontend, and 2 more for the backend. Me: That seems like a manageable number. Have you tried to find some good candidates from friends of friends? Them: Oh, I don’t have time for that. We need to move quickly with these hires. Me: Is that any slower than making up quizzes for Indeed? Them: Well, I’m not sure how I would even start. Me: Something simple. You could go through your email contacts and make a special list with the email addresses of those who you know work in tech. Software developers, project managers, designers, anyone who might be able to give a meaningful recommendation. Send out an email explaining what you’re looking for. Them: Hmm, well, some people might feel that I’m trying to poach talent from their team. Me: They don’t have to respond. They can simply remain silent. Them: I worry it would feel like I’m asking for a favor. Me: That’s exactly what you are doing, you are asking for a favor. And then later on, when they are hiring, you could potentially pay them back by recommending someone, if at that later time you know of a good software developer who is looking for a job, when you yourself are not hiring. Them: Yeah, but, if they don’t know of anyone, then it’s just a big waste of time. Me: But it sounds like your original effort with Indeed was a waste of time. Them: Sure, but now that I’ve got a quiz in place, I’m hoping to filter out more of the applicants, so I’ll get a smaller number. Me: But the process does take time, right? No matter what you do, you have to invest some time in this? Them: Yeah, it really sucks. I’ve got a lot of work to do, but instead I have to waste time hiring. Me: But hiring is work. This is the work that you are doing right now. This is important. Them: Sure, I guess that’s true, but I’ve also got a lot of software that I’m supposed to write. Me: But as your team grows, you’ll need to spend less time writing code and more time focused on management tasks, such as hiring people. Them: I’m afraid so. Me: Is that something to be afraid of? Your team is growing, it sounds like things are going well. Them: Yes, I guess that’s true, but I’m worried, once I’m no longer writing code every day, and reading everyone else’s code, how can I be sure the quality of the work will still be strong? Me: You could hire excellent people and then expect excellent results from them. Them: Yeah, but that’s a lot easier said than done. You should see some of the resumes that I got from the applicants. Full of typos, obvious exaggerations, mistakes about dates, or dates that overlap, stuff that makes no sense. Some of these resumes are so bad it’s funny. I’ve started sharing them with the team so we can all have a laugh about it. Me: It sounds like Indeed isn’t really giving you what you want. Them: That’s true, Indeed sucks. The applicants we’re getting from these online sites, most of them are really awful. Me: Are you sure you don’t want to reach out to your acquaintances and ask them for recommendations? Them: Oh, gosh, no. Like I said, that would take too much time. For many categories of job applicants, job sites like Monster or LinkedIn or Indeed or StackOverflow are basically like drinking the brine: they offer such a abundance of material that you are tricked into thinking “Surely we can drink an endless amount from this source.” And yet, they waste so much of your time that they are effectively a kind of poison.
i_hate_pigeons 5y ago
For technical interviews I've settled down and just ask the candidate questions about things _they_ are familiar with, so things they've done recently and then try to gather how much they really understand about that, if enough seniority then also how much they contributed towards decision making. After all I'm trying to find, do they have initiative? do they care? do they make informed choices? do they think by themselves?
- iKevinShah 5y ago
  I was recently appearing for an interview and a fintech org did this. Wow that interview was so pleasant. I did not have to worry about forgetting where algorithm X is O(N^2) or O(2^N). and since they asked all about my experiences and what was written, I was able to articulate more than I would in usual tech rounds. Although we couldn't agree on location for personal reasons, that is an org which I would recommend specially as they really wanted to know the candidate's behavior and not whether he could remember some implementations which they're mostly never going to use.
  - feoren 5y ago
    > Forgetting where algorithm X is O(N^2) or O(2^N) I find it absolutely shocking that you would consider it trivial knowledge whether an algorithm is low-degree polynomial or exponential. The pendulum is swinging way too far to the other end. If you can't remember/figure out whether the code you're writing is O(N^2) or O(2^N) you should not be writing code professionally.
    - putsjoe 5y ago
      I haven't got a clue what your onabout yet I write code professionally
bmon 5y ago
In technical interviews I conduct I also include a system design challenge. I present a large scale architecture problem our company has had to solve and ask the candidate to take us through their process of designing a solution. Excellent candidates are not the same as the ones who arrive at a similar solution to ours. The best candidates are able to ask important questions about the requirements, and when asked can provide rationale for choosing specific components, as well as other potential options they considered. More often than not this kind of question is assessing your process, not the outcome you produce.
- ssharp 5y ago
  This is still a big flaw in the hiring process. Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews. The exact same pattern happens with product managers. There are very specific types of interviews and there is an entire industry built around preparing candidates for these types of interviews. At that point, is the interview process still effective? I'm certain there is a pool of fully-capable people out there being left behind in sub-optimal careers for no other reason than they've underestimated or are ignorant of the need to prepare for an interview exercise that is, at best, loosely related to the work they'd actually do. I suppose the counter-argument would be that good candidates should be able to figure out what they need to do to successfully complete a task, and properly understanding and gaming the interview process showcases that skill.
  - wreath 5y ago
    > Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews. But those who prepare for system design interviews are most likely better equipped to design systems in real life too, because they had to go through the different problems and types of systems and their requirements. Now that doesn't mean they can implement it end-to-end, but you could probably tell those who are over-engineering it from those who actually either have experience or solid foundation to make good decisions.
Jensson 5y ago
> By this I mean that it should be obvious that they’re also screening for how pleasant you are of a person to work with on technical problems. In what way should this be obvious? Do they insult you and see if you react poorly? Normally you do this by just working through a problem, and then after the interview you evaluate whether the person was unpleasant to work with. There is no unnatural process required, you get that for free.
gwbas1c 5y ago
> If you can, schedule your interviews in the order of importance for what job you think you might want an offer for. This isn’t to say that you should in any way not prepare for those earlier interviews; I don't understand. Does this means that I should schedule interviews for jobs I want sooner or later? The wording "order of importance" is ambiguous which order I should follow.
- pc86 5y ago
  "In the order of importance" means ascending. Basically if you're applying to 5-6 jobs, try to schedule the one you want the most last, so that when (not if) you bomb some aspect of an earlier interview, it doesn't a) completely depress you for the rest of the interviews, and b) can be a learning experience for later interviews that you ideally would like to get offers from more.
- oumua_don17 5y ago
  >> This isn’t to say that you should in any way not prepare for those earlier interviews Implies ascending order so that you are well prepared for the later more important ones by rectifying the mistakes you made in the previous ones.
  - gwbas1c 5y ago
    You shouldn't have to think that hard in order to understand what someone wrote. As someone who spent many years with my writings misinterpreted, simple word choice is always better than relying on context.
- 71a54xd 5y ago
  Yeah, this was definitely lazy writing. I think the author meant to say that you should schedule real interviews you care less about prior to those you actually want. That way, you have a few warm ups with real skin in the game, but if you bomb it's not going to take away a serious opportunity. I usually do this with interviews at Amazon since it's fun to waste their time.
71a54xd 5y ago
I think a lesser mentioned topic about interviewing is that the expectations / rigor of the interview vary parabolically based on the tenure of the position and how many years of experience you have. For instance, even if the interview prompt doesn't change - an interview for a mid to senior position expects far better communication and execution than that of a NCG interview etc etc. This is sort of a self-fulfilling prophecy for people with more than 2-3 years of experience who don't perform well or haven't grown.
sys_64738 5y ago
What I learned about interviewing: 1) the questions asked in a technical interview often are what the interviewer is actually working on and so you're doing their job. 2) send a billing invoice for any time they interview you for and you don't get hired. Your time isn't free. 3) you generally don't get hired to work on the project they say they'll hire you for. Expect disappointment.
- lelandfe 5y ago
  > send a billing invoice for any time they interview you for and you don't get hired Do you do this? Have you actually gotten paid?
  - sys_64738 5y ago
    Not yet.
jononomo 5y ago
Shouldn't candidates have portfolios -- i.e., examples of software that they have built, with a complete git history, etc? That seems to me to do away with the need for a coding challenge as well as demonstrating a lot about their approach and interests. On the whole, I'm surprised by the number of people who think both coding challenges and whiteboard interviews are a waste of everyone's time. Is the employer not supposed to assess the candidate in any respect?
- Viliam1234 5y ago
  > Shouldn't candidates have portfolios -- i.e., examples of software that they have built, with a complete git history, etc? Would you be okay if your former employees provided the software they built for you, with a complete git history, at their next job interviews? If no, do you have a reason to assume that the former employers of your current job candidates would be okay with the same thing?
- Jemaclus 5y ago
  > Shouldn't candidates have portfolios -- i.e., examples of software that they have built, with a complete git history, etc? Most career engineers (including myself) have worked on proprietary systems. I can't show you any production-level code that I've written in the last 10 years, because it's all proprietary and owned by the companies I've worked for. I don't even have access to my previous employers' code! So what exactly would I put in my "portfolio"? If the answer is "open-source," then that presumes that the only engineers worth hiring are those who contribute to open-source -- which leaves out a ton of great engineers -- and those who have the extra time to contribute to open-source outside of their day jobs -- which can be a bias against those with life obligations (e.g., caring for dependents). So the answer to your first question is: no, they shouldn't. If you have one, FANTASTIC. But it shouldn't be a requirement. To your second question... Employers need to evaluate candidates _somehow_, so yeah, I'm baffled by that as well.

75 points by luu 5y ago

some job screenings are really ridiculous: coding is not rocket science, come on (yes, I understand the need of filtering in case you have a lot of application, but how many have a lot of applicants?)

lkrubner 5y ago

I'm currently writing a book on the subject of bad hiring practices, and other management mistakes. Allow me to share some of what I wrote: --------------------- Homework assignments and personality quizzes won’t give you excellence This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program. Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned. "Wow, I didn't expect things to move this fast!" she exclaimed. Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!" Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.” At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?” What an empty ritual; reading words that are not understood.

lkrubner 5y ago
And a bit more from my book: ---------- Homework assignments and personality quizzes won’t give you excellence This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program. Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned. "Wow, I didn't expect things to move this fast!" she exclaimed. Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!" Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.” At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?” What an empty ritual; reading words that are not understood. If you are lost at sea, don’t drink the brine Stories abound of people lost at sea, perhaps because their ship engine died, or their ship sank and they escaped in a life raft. Once the clean drinking water runs out, the temptation to drink the sea water is strong. But of course, that is a fatal step: the sea has more salt than than the human body can tolerate; drinking makes you more thirsty, not less so. And yet the sea is vast. What a paradox, to die of thirst amid such an abundance. “Water, water, everywhere, and not a drop to drink,” as Coleridge said. I’ve had this conversation with tech team leads: Me: Where are you looking for candidates? Them: I’ve put a job posting up at LinkedIn and Indeed and StackOverflow. Me: Did you get any candidates that you like? Them: Well, the problem is, I’ve gotten several thousand. The problem is trying to narrow down the pile. I cannot possibly look through all of them. I’ve decided to post the job a second time, but this time I created quiz that people have to take. Me: What is the quiz about? Them: It’s 100 questions about the technologies we use, plus some algorithm questions that should help cut down the number of applicants who get through. Me: You created the questions yourself? Them: No, I copy-and-pasted them from various online sources. Most of them are about standard stuff. I put in a few trick questions to help filter out the weak candidates. Me: Are you sure you want the candidates who get your trick questions? Them: Well, if they get the trick questions, then they must know some fairly obscure stuff. Me: Is that what you need right now, people who happen to know some fairly obscure stuff? Them: Well, not really, our work here is fairly standard, but I need some way to screen the applicants because the first time I posted the job we got way too many responses. Me: Are you sure the people who get your most obscure questions are the candidates who will work out the best once you hire them? Them: No, but I’m not sure what else to do. You never really know about a person until you’ve seen them actually work. Me: How many people do you need to hire? Them: I need 3 developers for the frontend, and 2 more for the backend. Me: That seems like a manageable number. Have you tried to find some good candidates from friends of friends? Them: Oh, I don’t have time for that. We need to move quickly with these hires. Me: Is that any slower than making up quizzes for Indeed? Them: Well, I’m not sure how I would even start. Me: Something simple. You could go through your email contacts and make a special list with the email addresses of those who you know work in tech. Software developers, project managers, designers, anyone who might be able to give a meaningful recommendation. Send out an email explaining what you’re looking for. Them: Hmm, well, some people might feel that I’m trying to poach talent from their team. Me: They don’t have to respond. They can simply remain silent. Them: I worry it would feel like I’m asking for a favor. Me: That’s exactly what you are doing, you are asking for a favor. And then later on, when they are hiring, you could potentially pay them back by recommending someone, if at that later time you know of a good software developer who is looking for a job, when you yourself are not hiring. Them: Yeah, but, if they don’t know of anyone, then it’s just a big waste of time. Me: But it sounds like your original effort with Indeed was a waste of time. Them: Sure, but now that I’ve got a quiz in place, I’m hoping to filter out more of the applicants, so I’ll get a smaller number. Me: But the process does take time, right? No matter what you do, you have to invest some time in this? Them: Yeah, it really sucks. I’ve got a lot of work to do, but instead I have to waste time hiring. Me: But hiring is work. This is the work that you are doing right now. This is important. Them: Sure, I guess that’s true, but I’ve also got a lot of software that I’m supposed to write. Me: But as your team grows, you’ll need to spend less time writing code and more time focused on management tasks, such as hiring people. Them: I’m afraid so. Me: Is that something to be afraid of? Your team is growing, it sounds like things are going well. Them: Yes, I guess that’s true, but I’m worried, once I’m no longer writing code every day, and reading everyone else’s code, how can I be sure the quality of the work will still be strong? Me: You could hire excellent people and then expect excellent results from them. Them: Yeah, but that’s a lot easier said than done. You should see some of the resumes that I got from the applicants. Full of typos, obvious exaggerations, mistakes about dates, or dates that overlap, stuff that makes no sense. Some of these resumes are so bad it’s funny. I’ve started sharing them with the team so we can all have a laugh about it. Me: It sounds like Indeed isn’t really giving you what you want. Them: That’s true, Indeed sucks. The applicants we’re getting from these online sites, most of them are really awful. Me: Are you sure you don’t want to reach out to your acquaintances and ask them for recommendations? Them: Oh, gosh, no. Like I said, that would take too much time. For many categories of job applicants, job sites like Monster or LinkedIn or Indeed or StackOverflow are basically like drinking the brine: they offer such a abundance of material that you are tricked into thinking “Surely we can drink an endless amount from this source.” And yet, they waste so much of your time that they are effectively a kind of poison.

i_hate_pigeons 5y ago

For technical interviews I've settled down and just ask the candidate questions about things _they_ are familiar with, so things they've done recently and then try to gather how much they really understand about that, if enough seniority then also how much they contributed towards decision making. After all I'm trying to find, do they have initiative? do they care? do they make informed choices? do they think by themselves?

iKevinShah 5y ago
I was recently appearing for an interview and a fintech org did this. Wow that interview was so pleasant. I did not have to worry about forgetting where algorithm X is O(N^2) or O(2^N). and since they asked all about my experiences and what was written, I was able to articulate more than I would in usual tech rounds. Although we couldn't agree on location for personal reasons, that is an org which I would recommend specially as they really wanted to know the candidate's behavior and not whether he could remember some implementations which they're mostly never going to use.
- feoren 5y ago
  > Forgetting where algorithm X is O(N^2) or O(2^N) I find it absolutely shocking that you would consider it trivial knowledge whether an algorithm is low-degree polynomial or exponential. The pendulum is swinging way too far to the other end. If you can't remember/figure out whether the code you're writing is O(N^2) or O(2^N) you should not be writing code professionally.
  - putsjoe 5y ago
    I haven't got a clue what your onabout yet I write code professionally

bmon 5y ago

In technical interviews I conduct I also include a system design challenge. I present a large scale architecture problem our company has had to solve and ask the candidate to take us through their process of designing a solution. Excellent candidates are not the same as the ones who arrive at a similar solution to ours. The best candidates are able to ask important questions about the requirements, and when asked can provide rationale for choosing specific components, as well as other potential options they considered. More often than not this kind of question is assessing your process, not the outcome you produce.

ssharp 5y ago
This is still a big flaw in the hiring process. Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews. The exact same pattern happens with product managers. There are very specific types of interviews and there is an entire industry built around preparing candidates for these types of interviews. At that point, is the interview process still effective? I'm certain there is a pool of fully-capable people out there being left behind in sub-optimal careers for no other reason than they've underestimated or are ignorant of the need to prepare for an interview exercise that is, at best, loosely related to the work they'd actually do. I suppose the counter-argument would be that good candidates should be able to figure out what they need to do to successfully complete a task, and properly understanding and gaming the interview process showcases that skill.
- wreath 5y ago
  > Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews. But those who prepare for system design interviews are most likely better equipped to design systems in real life too, because they had to go through the different problems and types of systems and their requirements. Now that doesn't mean they can implement it end-to-end, but you could probably tell those who are over-engineering it from those who actually either have experience or solid foundation to make good decisions.

Jensson 5y ago

> By this I mean that it should be obvious that they’re also screening for how pleasant you are of a person to work with on technical problems. In what way should this be obvious? Do they insult you and see if you react poorly? Normally you do this by just working through a problem, and then after the interview you evaluate whether the person was unpleasant to work with. There is no unnatural process required, you get that for free.

gwbas1c 5y ago

> If you can, schedule your interviews in the order of importance for what job you think you might want an offer for. This isn’t to say that you should in any way not prepare for those earlier interviews; I don't understand. Does this means that I should schedule interviews for jobs I want sooner or later? The wording "order of importance" is ambiguous which order I should follow.

pc86 5y ago
"In the order of importance" means ascending. Basically if you're applying to 5-6 jobs, try to schedule the one you want the most last, so that when (not if) you bomb some aspect of an earlier interview, it doesn't a) completely depress you for the rest of the interviews, and b) can be a learning experience for later interviews that you ideally would like to get offers from more.
oumua_don17 5y ago
>> This isn’t to say that you should in any way not prepare for those earlier interviews Implies ascending order so that you are well prepared for the later more important ones by rectifying the mistakes you made in the previous ones.
- gwbas1c 5y ago
  You shouldn't have to think that hard in order to understand what someone wrote. As someone who spent many years with my writings misinterpreted, simple word choice is always better than relying on context.
71a54xd 5y ago
Yeah, this was definitely lazy writing. I think the author meant to say that you should schedule real interviews you care less about prior to those you actually want. That way, you have a few warm ups with real skin in the game, but if you bomb it's not going to take away a serious opportunity. I usually do this with interviews at Amazon since it's fun to waste their time.

71a54xd 5y ago

I think a lesser mentioned topic about interviewing is that the expectations / rigor of the interview vary parabolically based on the tenure of the position and how many years of experience you have. For instance, even if the interview prompt doesn't change - an interview for a mid to senior position expects far better communication and execution than that of a NCG interview etc etc. This is sort of a self-fulfilling prophecy for people with more than 2-3 years of experience who don't perform well or haven't grown.

sys_64738 5y ago

What I learned about interviewing: 1) the questions asked in a technical interview often are what the interviewer is actually working on and so you're doing their job. 2) send a billing invoice for any time they interview you for and you don't get hired. Your time isn't free. 3) you generally don't get hired to work on the project they say they'll hire you for. Expect disappointment.

lelandfe 5y ago
> send a billing invoice for any time they interview you for and you don't get hired Do you do this? Have you actually gotten paid?
- sys_64738 5y ago
  Not yet.

jononomo 5y ago

Shouldn't candidates have portfolios -- i.e., examples of software that they have built, with a complete git history, etc? That seems to me to do away with the need for a coding challenge as well as demonstrating a lot about their approach and interests. On the whole, I'm surprised by the number of people who think both coding challenges and whiteboard interviews are a waste of everyone's time. Is the employer not supposed to assess the candidate in any respect?

Viliam1234 5y ago
> Shouldn't candidates have portfolios -- i.e., examples of software that they have built, with a complete git history, etc? Would you be okay if your former employees provided the software they built for you, with a complete git history, at their next job interviews? If no, do you have a reason to assume that the former employers of your current job candidates would be okay with the same thing?
Jemaclus 5y ago
> Shouldn't candidates have portfolios -- i.e., examples of software that they have built, with a complete git history, etc? Most career engineers (including myself) have worked on proprietary systems. I can't show you any production-level code that I've written in the last 10 years, because it's all proprietary and owned by the companies I've worked for. I don't even have access to my previous employers' code! So what exactly would I put in my "portfolio"? If the answer is "open-source," then that presumes that the only engineers worth hiring are those who contribute to open-source -- which leaves out a ton of great engineers -- and those who have the extra time to contribute to open-source outside of their day jobs -- which can be a bias against those with life obligations (e.g., caring for dependents). So the answer to your first question is: no, they shouldn't. If you have one, FANTASTIC. But it shouldn't be a requirement. To your second question... Employers need to evaluate candidates _somehow_, so yeah, I'm baffled by that as well.