5 ms·

I have a few as well: - You will face rejection (likely a lot). Don't take this personally and don't let it affect your confidence. - Unless you are an outst

by zebnyc 5y ago

I have a few as well: - You will face rejection (likely a lot). Don't take this personally and don't let it affect your confidence. - Unless you are an outstanding interviewee, this is like a skill/muscle which you need to develop and practice. Hence ensure that you don't schedule your "dream job/company" early in the process. Keep practicing. - Always have a beginner / practice mindset. Otherwise, you will accept the first (suboptimal) offer that you get as you will hate the interview rigmarole. Interviewing is annoying / painful. Accept it and work through it. - Keep applying and talking to companies even after you have started negotiations. There have been companies which have told me that another candidate accepted before me( and hence the position is no longer available) even when they have "granted me time" to make my decision. Similarly companies rescind offers. - Blowing hot(too many interviews in a short while) and cold (no interviews / interviews for a while) can be debilitating to your confidence. Hence ensure that you have a pipeline of interviews so you are talking to at least 1 company a week. - Take notes and reflect on your performance in each interview and how you can do better.

tanayagrawal19 5y ago
This is super valuable! Thank you for sharing :)
jbluepolarbear 5y ago
I’ve interviewed many candidates and I’ve interviewed many times myself. Having good conversation skills is the single biggest influence on whether a candidate proceeds or not. Talking is a skill and that really stands out against other candidates. When I’m interviewing, I’ll usually choose a stronger communicator over a stronger engineer.
- colmvp 5y ago
  Isn't that kind of odd? I've worked with software engineers who are good talkers but their code and problem solving skills leave something to be desired. Meanwhile, I've worked with guys who took a while to get comfortable with in terms of having conversations and yet they were some of the most productive members of the team both in code output and skill. Ultimately, most of the time I 'talk' with my team members, we're actually writing which is very different from talking due to the async nature of the former.
  - google234123 5y ago
    It might be reflecting the fact that it's easier to talk about something if you know it well.
    - Jensson 5y ago
      And the other side is that people who don't know what they are doing are very bad at talking once you try to solve problems. They might still be great at free form chit chat about technical things, like you'd get in an unstructured interview, but they lack the skills to actually apply the words they use and work through problems. So they will take a lot of space in meetings and chats and make everyone else less productive since they use so many words to say so little. These are basically "brilliant jerks" on the soft skill side. They take so much of the space that the people who knows anything don't get much airtime. But if the soft brilliant jerk would just stop talking for a bit the other people would start talking and actually improve communication in the team.
  - misterbwong 5y ago
    You're right to point out the difference between conversational and writing skills. However, generally engineers tend to overvalue technical skills and undervalue soft skills. IMO engineering orgs tend to set the bar really high for tech skills and really low for communication skills. Tech skills are easier to test and they feel more "objective" so they get more focus.
  - jrockway 5y ago
    You will want to adjust the knob depending on the specific role. You might look for different things in a candidate that will be person #1 on a one person project version person #49 on a 50 person project. Remember that most of us that are self-taught are pretty good at being person #1 on a one person project. That's what self-teaching teaches us, after all. But, a successful business might not be possible built around one programmer, so as you progress in your career you'll be working on developing the skills to form a cohesive team around you. A lot of this is going to be talking to people, not memorizing some algorithm. (But, many jobs are going to require both, so don't forget all the algorithms while you're in those meetings. At least brush up on them before your interview. A day of prep here can equal hundreds of thousands of dollars over the course of your career.)
- stavros 5y ago
  I'm fairly sure the reason I've gotten many of the jobs I've had is that I smile a lot.
  - phibz 5y ago
    Getting the interviewer to like you is most of what you need to land the position.
- B-Con 5y ago
  Engineering skills are easier to teach, particularly if you have an established culture and some senior personal who can spare a couple cycles to onboard new hires. If you don't, that's a sign the engineering culture needs some TLC. And now that I think of it, in that case good communication may still be a priority factor.
- Jansen312 5y ago
  The correct metrics are 1. Strong skillset, and 2. Able to follow instruction (obedient). Every other hot metrics now are pretty much misalign with company goal of earning profit. Purely on your criteria alone "strong communicator" are way down the list while "strong engineer" will be easily top 3 criteria. In a company you only need 1 or 2 strong communicator, usually they will be the head of departments or more likely C leaders. Too many chief and less foot soldiers will be like what happen to Enron where everybody just hop from departments to departments unable to deliver useful productivity. Talk is cheap. Actions speaks louder. Those strong communicators are also the most likely to jump ship and change job for the better within a short time. It will be very detrimental to company having this group of employees. Speaking from over 3 decades of experience in HR.
- kitsunesoba 5y ago
  Conversely, the interviews that have gone most well for me were those that were largely just technical conversations. That’s not to say that they were nothing but fluff — the bits of conversation were usually accompanied with plenty of skill testing. The worst were the ones where the interviewer clearly didn’t want to be there and mostly acted as a cold stone statue firing questions of from a sheet of paper. Incidentally those interviews were usually also the ones with the highest number of hackerrank sorts of questions.
nemo44x 5y ago
> You will face rejection (likely a lot). It's very important to realize this. Maybe you feel you nailed it and everyone really liked you but you still didn't get the job. Well, there's other candidates in the pool too and there's a chance one of them was amazing too and you lost the proverbial "coin toss". There's also a chance you were always the backup option - it happens. Lastly, don't give up on the role. I've seen numerous instances where an offer went out and was accepted and then a week later the person backed out because their existing employer gave them a huge package to stay on. It happens. You might get the call then after being rejected.
xivzgrev 5y ago
"Keep applying and talking to companies even after you have started negotiations" YES. Do not stop until your first day (half kidding). One time I stopped interviewing after accepting an offer...only to find out there were rounds of reference checks (and one of them didn't go well). It was 2-3 weeks of anxious bullshit, but only because I already turned down everything else that was in motion. Who knows maybe a second company will come through with a better offer.
victoro 5y ago
"Always have a beginner / practice mindset." Just wanted to highlight this because it is a fantastic piece of advice to keep in mind for interviews (and honestly for your career and even crafts or hobbies too). There's a reason doctors and lawyers (for whom the stakes of failure are sometimes measured in lives or years of freedom lost) call what they do "a practice".
strikelaserclaw 5y ago
Some additional points since i'm currently interviewing a lot -Practice leetcode since it will make up 50-60% of the interview process -Study your resume inside and out, know the whys of what you did not just the whats -Don't talk too much, sometimes nervousness and anxiety can make itself with a candidate talking too much or too little, both are bad, be concise with your answers but don't ramble on, the more you ramble the more surface area you give the interviewer to poke holes at what you said. Being concise can lead the interviewer towards areas where you are most comfortable answering questions. -Realize you might be an amazing developer but you only have a couple of hours to show prospective employer what you got, don't be too harsh on yourself if you get rejected, it is impossible to know a person in 3 hours, they are merely going based on their best judgement of you (which is mixed in with actual performance considerations and bias many times) and not the "reality" of you.
- greatwave1 5y ago
  "-Practice leetcode since it will make up 50-60% of the interview process" I know we're on HackerNews, but this is still a very bold assumption lol
  - strikelaserclaw 5y ago
    it is a solid assumption if you want to work for a big tech company.
    - redisman 5y ago
      At least in big tech cities it is in no way a ridiculous thing to say. I interviewed with about 20+ companies based in SF, NYC, Seattle and only one loop didn’t have leetcode equivalent steps
    - greatwave1 5y ago
      >if you want to work for a big tech company. There's the bold assumption haha. I'm certain that less than 5% of all job interviews use leetcode. Even in big tech, I'd imagine the majority of interviewees (such as the product manager who wrote the original article) won't need it.

by zebnyc 5y ago

tanayagrawal19 5y ago

This is super valuable! Thank you for sharing :)

jbluepolarbear 5y ago

I’ve interviewed many candidates and I’ve interviewed many times myself. Having good conversation skills is the single biggest influence on whether a candidate proceeds or not. Talking is a skill and that really stands out against other candidates. When I’m interviewing, I’ll usually choose a stronger communicator over a stronger engineer.

colmvp 5y ago
Isn't that kind of odd? I've worked with software engineers who are good talkers but their code and problem solving skills leave something to be desired. Meanwhile, I've worked with guys who took a while to get comfortable with in terms of having conversations and yet they were some of the most productive members of the team both in code output and skill. Ultimately, most of the time I 'talk' with my team members, we're actually writing which is very different from talking due to the async nature of the former.
- google234123 5y ago
  It might be reflecting the fact that it's easier to talk about something if you know it well.
  - Jensson 5y ago
    And the other side is that people who don't know what they are doing are very bad at talking once you try to solve problems. They might still be great at free form chit chat about technical things, like you'd get in an unstructured interview, but they lack the skills to actually apply the words they use and work through problems. So they will take a lot of space in meetings and chats and make everyone else less productive since they use so many words to say so little. These are basically "brilliant jerks" on the soft skill side. They take so much of the space that the people who knows anything don't get much airtime. But if the soft brilliant jerk would just stop talking for a bit the other people would start talking and actually improve communication in the team.
- misterbwong 5y ago
  You're right to point out the difference between conversational and writing skills. However, generally engineers tend to overvalue technical skills and undervalue soft skills. IMO engineering orgs tend to set the bar really high for tech skills and really low for communication skills. Tech skills are easier to test and they feel more "objective" so they get more focus.
- jrockway 5y ago
  You will want to adjust the knob depending on the specific role. You might look for different things in a candidate that will be person #1 on a one person project version person #49 on a 50 person project. Remember that most of us that are self-taught are pretty good at being person #1 on a one person project. That's what self-teaching teaches us, after all. But, a successful business might not be possible built around one programmer, so as you progress in your career you'll be working on developing the skills to form a cohesive team around you. A lot of this is going to be talking to people, not memorizing some algorithm. (But, many jobs are going to require both, so don't forget all the algorithms while you're in those meetings. At least brush up on them before your interview. A day of prep here can equal hundreds of thousands of dollars over the course of your career.)
stavros 5y ago
I'm fairly sure the reason I've gotten many of the jobs I've had is that I smile a lot.
- phibz 5y ago
  Getting the interviewer to like you is most of what you need to land the position.
B-Con 5y ago
Engineering skills are easier to teach, particularly if you have an established culture and some senior personal who can spare a couple cycles to onboard new hires. If you don't, that's a sign the engineering culture needs some TLC. And now that I think of it, in that case good communication may still be a priority factor.
Jansen312 5y ago
The correct metrics are 1. Strong skillset, and 2. Able to follow instruction (obedient). Every other hot metrics now are pretty much misalign with company goal of earning profit. Purely on your criteria alone "strong communicator" are way down the list while "strong engineer" will be easily top 3 criteria. In a company you only need 1 or 2 strong communicator, usually they will be the head of departments or more likely C leaders. Too many chief and less foot soldiers will be like what happen to Enron where everybody just hop from departments to departments unable to deliver useful productivity. Talk is cheap. Actions speaks louder. Those strong communicators are also the most likely to jump ship and change job for the better within a short time. It will be very detrimental to company having this group of employees. Speaking from over 3 decades of experience in HR.
kitsunesoba 5y ago
Conversely, the interviews that have gone most well for me were those that were largely just technical conversations. That’s not to say that they were nothing but fluff — the bits of conversation were usually accompanied with plenty of skill testing. The worst were the ones where the interviewer clearly didn’t want to be there and mostly acted as a cold stone statue firing questions of from a sheet of paper. Incidentally those interviews were usually also the ones with the highest number of hackerrank sorts of questions.

nemo44x 5y ago

> You will face rejection (likely a lot). It's very important to realize this. Maybe you feel you nailed it and everyone really liked you but you still didn't get the job. Well, there's other candidates in the pool too and there's a chance one of them was amazing too and you lost the proverbial "coin toss". There's also a chance you were always the backup option - it happens. Lastly, don't give up on the role. I've seen numerous instances where an offer went out and was accepted and then a week later the person backed out because their existing employer gave them a huge package to stay on. It happens. You might get the call then after being rejected.

xivzgrev 5y ago

"Keep applying and talking to companies even after you have started negotiations" YES. Do not stop until your first day (half kidding). One time I stopped interviewing after accepting an offer...only to find out there were rounds of reference checks (and one of them didn't go well). It was 2-3 weeks of anxious bullshit, but only because I already turned down everything else that was in motion. Who knows maybe a second company will come through with a better offer.

victoro 5y ago

"Always have a beginner / practice mindset." Just wanted to highlight this because it is a fantastic piece of advice to keep in mind for interviews (and honestly for your career and even crafts or hobbies too). There's a reason doctors and lawyers (for whom the stakes of failure are sometimes measured in lives or years of freedom lost) call what they do "a practice".

strikelaserclaw 5y ago

Some additional points since i'm currently interviewing a lot -Practice leetcode since it will make up 50-60% of the interview process -Study your resume inside and out, know the whys of what you did not just the whats -Don't talk too much, sometimes nervousness and anxiety can make itself with a candidate talking too much or too little, both are bad, be concise with your answers but don't ramble on, the more you ramble the more surface area you give the interviewer to poke holes at what you said. Being concise can lead the interviewer towards areas where you are most comfortable answering questions. -Realize you might be an amazing developer but you only have a couple of hours to show prospective employer what you got, don't be too harsh on yourself if you get rejected, it is impossible to know a person in 3 hours, they are merely going based on their best judgement of you (which is mixed in with actual performance considerations and bias many times) and not the "reality" of you.

greatwave1 5y ago
"-Practice leetcode since it will make up 50-60% of the interview process" I know we're on HackerNews, but this is still a very bold assumption lol
- strikelaserclaw 5y ago
  it is a solid assumption if you want to work for a big tech company.
  - redisman 5y ago
    At least in big tech cities it is in no way a ridiculous thing to say. I interviewed with about 20+ companies based in SF, NYC, Seattle and only one loop didn’t have leetcode equivalent steps
  - greatwave1 5y ago
    >if you want to work for a big tech company. There's the bold assumption haha. I'm certain that less than 5% of all job interviews use leetcode. Even in big tech, I'd imagine the majority of interviewees (such as the product manager who wrote the original article) won't need it.