This is something I have never done before my most recent job search but it has been a huge help. Previously all my interview prep was on tech and I pretty much winged it for the behavioral stuff since interview prep guides seem to always focus on the tech side. Plus it always feels worse and more obvious when you struggle with or fail to properly answer the tech questions.
What I did is I prepared 10 different stories about my career experience and then tagged them with a bunch of prompts. For example I have a story about one project that had dual PMs that experienced a lot of scope creep and eventually fizzled on release. I can now use that story to answer a broad range of questions from failure to various project management approaches. Overall I now have prepared stories to answer probably 50-75 different questions immediately.
Another benefit is that I have also told these stories multiple times in interviews now and I get better telling them each time. Even if the answer isn't 100% relevant, I feel more confident and likely come off better launching immediately into a detailed story about my experience rather than trying to awkwardly come up with an answer on the fly. It is also easy to drop irrelevant parts or expand on specific details when the basic framework of the story is already something that feels natural.
I will even have the document with all the prompts and story bullet points open whenever I am doing phone or remote interviews. I could probably even create a cheat sheet to use for in person interviews since I usually would bring an executive style notepad with me anyway to interviews to jot down notes about the company.
Maybe this is obvious advice, but I think I am relatively smart and never done it previously or even seen this approach recommend so I am guessing there are other people who could use this tip.
A single memorable event you went though tends to highlight many different skills, so having a few stories down well will let you answer most of those questions
And what if it doesn't answer the interviewer's question perfectly?
Their real goal was to try to get to know you better. The question was just a prompt to get a better signal about you, and you delivered above and beyond what was asked.
>And what if it doesn't answer the interviewer's question perfectly?
Exactly. You only need to avoid the extreme of looking like a politician in a debate completely dodging a question. And even if you do get too far away from the question, you can always close it out with a joke about how off topic you got which gives you a chance to connect with the interviewer on a human level.
I love when candidates go on sort of relevant tangents. It shows they've actually done the work and formed opinions about it. Pros and cons, maintenance and growth, missteps and how they've been burned, competing or preferred solutions, etc. It means they are capable of more than: I can code in X and help clear your backlog.
Yes. Behavioral interviews tend to ask you the same types of questions over and over. Have a canned response for each. Whenever you hear a new question create a canned response. I've been telling the same story about a conflict with a coworker (that has a nice resolution) for the past 5 years whenever someone asks me, "Tell me about a time you have had difficulties working with someone on your team".
I had to do a bunch of interviews recently and did something similar, multiple pages of notes with bullet points in a big font just out of view. Was very helpful for those moments where your brain just freezes up and you can't remember the perfect anecdote or systems architecture point you wanted to bring up.
I do think it would work for actual on-site interviews as well, as it's common for a candidate to bring in their own notes of questions to ask, etc.
This is something I think Amazon does well: their behavioral questions have a known format and prompt, and their recruiters tell you that and that you should practice.
At Amazon, the behavioral questions should be a STAR format response to prompts about Amazon leadership principles.
If you write down two STAR format stories to each principle, you’ll always have something to say for the behavioral questions. (Most stories hit several LPs, depending on what you emphasize. So it’s only a handful, total.)
I made flash cards for each story, so I could practice hitting the key points.
One additional tip on recruiters: have a cheat sheet ready (web page or public Google doc) that answers the basic questions they'll have for you and makes clear your expectations.
Here's the info I ask them to provide:
- Job Title and Salary
- Job Description
- Company Overview and Location
- Steps in Hiring Process
Whenever I'm emailed by a recruiter, I politely thank them for reaching out, paste the link to the cheat sheet, and invite them to review it and write back if they still think I'm a good match. It quickly separates the professionals from the wannabes. (You usually don't hear back from the wannabes.) The ones who do write back often thank me for it.
I'm pretty cynical when it comes to recruiters. So I find it interesting that 3 of my last 4 jobs have come through one.
There are a lot of recruiters on the market. But it's really no different than the market for lawyers; the median lawyer is a very poor man but the average lawyer is rich.
If they can't put a number on the table, they are probably one of those that tries to run a volume game, which I think is a bad approach for engineering. Basically spamming and not giving any info until they get their quotas.
The good ones want you to get hired at a good price because they are often paid a commission on your salary. And the great ones want to keep in touch so they can cash out again once you get bored with your current job. But the spammy one will have moved on to selling used cars at this point.
How do you end up with a network of the good ones? I have gotten my last job through a recruiter but the process sucked. He took me and my boss for a ride financially. This was in part me not getting many callbacks from any decent companies(Im in the NJ/NYC area) so I was desperate to accept and part my current manager not knowing what he should be paying for this and that type of developer. While I love my job and my team, they won't last forever and I have wanted to escape the dreaded cycle of dealing with these terrible recruiters. Can it really be done with just getting really good in your craft or do you really have to be the well known developer that has worked at a million top tier companies? How do you find these recruiters?
> How do you end up with a network of the good ones?
> I have wanted to escape the dreaded cycle of dealing with these terrible recruiters
Focus on yourself. When you are in a good place yourself you will find non-terrible recruiters. And when recruiters reach out, have a copy/paste response to say thanks for reaching out. +1 bonus points if you have a friend looking for a job and you can share their LinkedIn profile in your copy/paste response.
And don't run away (escape), run towards something.
Its not like I don't focus on improving myself. Who doesn't focus on improving themselves in this industry? You have to keep improving or else you are finished at some point. Imagine a circle of the stimulating inspiring well paid jobs and another circle filled with the painful, boring non noteworthy jobs. The circles don't overlap. Somehow through connections, impressing that one higher up or being in the right place at the right time, some can jump into the good circle and never have to look back while everyone else is stuck. That does not mean all the people in the bad circle are bad developers. I have seen with my own two eyes a lot of brilliance(I know its just my word so you'll just have to believe me) but they are still stuck in that bad circle.
I love this inspiring response but someone who is on the outside trying to claw their way in cannot see the light at the end of the tunnel. I guess its a self fulfilling prophecy, don't run away and there is a chance in the distant future you jump into that other circle but if you don't try you have exhausted any chance. But what if you spend all that effort trying never do? What have you sacrificed in order to end up failing to get into that other circle?
I meant something slightly different (and I did not write it very well at all), but to give an example I spent the first 15+ years of my career chasing success, upskilling, focusing on self improvement. And my identity became tightly coupled to my work and each little win felt good for a day or two, then felt empty pretty quickly after that. When I let all that go and found a stronger sense of self worth, I found much more career success than I ever had before without really trying so hard for it. It came more naturally. Therapy helped me with this journey.
What do you mean? Either you got a bad deal being underpaid which means your boss got a good deal, or you’re getting paid a lot and your boss got a bad deal but you got a good one.
You can reach out to companies that interest you directly, using their career page, finding people who work there and contacting them (LinkedIn, or via Twitter but preferably through an introduction), or some combination of both. You'll usually get a message back if your online presence shows some sort of proof of skills.
Have you found a job using this approach? I just think that if I were on the receiving end, i'd be a bit creeped out if there wasn't an introduction. How would I get an introduction? Thanks for the unique tip though.
I got most of my jobs this way. It becomes easier later as your network grows and can vouch for you. If you don't have an existing network to help introduce you, find some people working where you're interested, contribute helpful stuff to their GH projects and ask them a referral. Takes more upfront work but it creates an internal ally who will be interested in helping you get in.
It's fairly easy to get someone to push your resume forward internally, if that person has some sort of (even benign) reason to think you'd be a good hire. Everyone wants to hire good people and often we're compensated for referrals who pan out.
I know my manager has had people reach out cold on LinkedIn. His profile makes it pretty clear he’s hiring so he doesn’t mind at all. If he gets a good vibe he’ll setup a call between me and the potential candidate. If that all goes well we’ll kick off the formal recruitment process.
Fellow NJ programmer here - have you had much luck finding stuff in Central Jersey? Red Bank to Toms River sorta area.
I'm currently working in Red Bank and have been having a hell of a time finding places that don't seem miserable or just short contract work that I'm not interested in lol
Sorry I've been off the market for 2 years now. Holding onto my job and super easygoing boss for dear life. I found by it pure luck and its at a boring company that does nothing innovative but the pay is good and there is no stress. I wish you luck in your search.
Yes. My cheat sheet includes a "Minimum base salary" bullet point that is much higher than my walk-away number. This anchors the discussion.
I find the recruiters who get back to me are pretty open and transparent. If not, that's a sign they're probably not well connected with the company and may even simply be front-running a listing they found on a job site.
On preview: what @kortilla said. I don't find it limiting since it's a number I would be happy accepting (all other things being acceptable). I'm not out to maximize my salary. I want to maximize my well-being.
I generally want to understand what someone's ask is first.
After that I'm usually very upfront (ie, immediate verbal feedback) on how that falls into the position vs their apparent skill set etc.
If they have come in low (not uncommon for non bay area folks) I'll let them know that there are opportunities for growth beyond where they would start at. If they are someone we want we'll generally beat their ask as well to get them where they should reasonably be. Then usually there are two years of substantial pay increases. My own experience, these tend to be great folks to have on team if you can give them 3 years of nice growth.
If they are too high I'm usually upfront that at that rate they'd be flat compensation wise for a number of years or that the amount is simply too high relative to skill for position and our needs.
It used to be market was so tight, that if you found a great person you could go 2x what the planned budget was. Not sure if all orgs have that flex so that makes it a bit unusual.
"If they are too high I'm usually upfront that at that rate they'd be flat compensation wise for a number of years"
I've heard that once before and it always puzzled me. Basically you're telling the candidate that you want to underpay them now, so you can eventually pay them what they are worth. The math is in their favor even if they don't get a raise next year. And of course, next year they will be worth more anyway because they will have another year's experience plus additional domain knowledge.
I'm curious if anyone has ever fallen for that line.
I didn't fall the for the line, but I had that used on me. Raise time came up and I was told that after review my salary was still inline with what they wanted to pay for my experience, because I had negotiated up from their initial offer on initial here. I was gone several months later. Such a stupid thing to do.
I’m unable to parse the sentence you quoted and get the same meaning.
The quote is saying that the employee will be at the top of the budgeted pay range for that position, so their salary won’t grow much at all year over year.
I’m unclear on where you’re getting “underpay” from. Perhaps you’re assuming that the budgeted salary is below fair market value, and there’s a vague promise to increase the budget/salary in the future? Not sure why anyone would take the position in that case.
Because the sooner you get to the top of your budgeted salary the more years you spend collecting it. Collecting a higher salary for longer makes you more money.
Ah I see! The assumption is that the candidate is already worth the top of the pay range for the position. In that case, should they be aiming for a higher position? Should there be room to grow in the position?
Nothing about being "worth" it if you ask me. It's about collecting the money (and not getting layed off coz you're the guy that makes the most). This will depend on the company. Some companies do stack ranking and you can tell me whatever you want but I bet being at the top of your salary bracket gets you out more easily. But if you have a company that values you, doesn't do that sort of stack ranking and you're fine with only getting the standard inflationary increase, then collecting the extra money for multiple years is worth it if you ask me.
That said it feels kinda nice if the company gives you a raise without you even asking but it does mean you were basically underpayed vs. what you might have gotten.
The original poster said if they negotiate too high, they tell them they simply won't give them pay raises. (With the implication that for some reason the potential employee would instead want to start low and get raises).
I'm not sure where "The assumption is that the candidate is already worth the top of the pay range for the position" comes into this. As a potential employee, i want to maximize my $$$. How much the employer thinks i'm worth is the employer's problem not mine. If the employer gives me a choice that i can either (a) make more money or (b) make less money, i am going to choose (a), and i don't know why anyone would chose (b), all other things being equal.
> If they are too high I'm usually upfront that at that rate they'd be flat compensation wise for a number of years
I think its good to communicate that they wont be getting raises. I've taken a few jobs where I've been paid well above average, it feels great then you dont get any pay rises for a few years which makes you feel like you're aren't doing a good job.
1. Bend policy at hiring. $250k. $250k. $250k. $250k. $250k. $250k (no raises)
2. Follow salary brackets. $200k. $210k. $220k. $230k. $240k. $250k (low initial salary, catch up over time)
Having been on both sides, it's nearly impossible to make the case for bending policy further at annual reviews. Over time, employees converge to pay brackets. If you were hired with a on-off exception, you're getting no raises for a long time.
No raises feels shitty to a lot of people. It also brings risks.
True story: I was hired by a not-for-profit doing good work. Pay was maybe 1/3 of Google, and I'd be the top tech person at the org (not by ladder, but by skills). Pay was about 85% of what I needed to cover cost-of-living. They stretched brackets to get up to covering my cost-of-living exactly, so I was almost 20% over the upper cap of my pay bracket. Come next re-org, what do you know, they re-jiggle salary brackets standardize things, and my salary comes down 20%.
Fortunately, in the meantime, my cost of living had come down, so it worked out okay. I'm doing important, fulfilling work, and it's fun. So long as I'm doing that and making ends meet, I'm not tempted to jump ship to FAANG.
And no, my employer wasn't simply f-ing me; I understand the organizational structure, psychology, and dynamics well enough to understand what happened, how, and why. These were dynamics well above anything my boss, their boss, or their boss has any influence over, and I'd rather spend the social capital of going to their boss on something more important (e.g. making sure everything I do is open source).
A common career mistake people make is to assign intentions to places where the other side has no control. If you're worth $350k on the free market, and you receive a $180k offer, odds are the other side isn't low-balling you or doing anything mean or improper. They're operating from their constraints. You're operating from yours.
If you need $350k, and they can spend up to $500k, you'll be hired, and how well each side negotiates sets at where you'll get paid. If you need $350k and they can spend up to $200k, you're not getting hired, period. It's good to discover that earlier rather than later, but in practice, that usually comes up after the interview. In the no-hire $200k/$350k case, although you might not get a job now, things might change in five or ten years, and it's good to leave without bad feelings, and I'm not just talking about expressing bad feelings, but about what you're actually feeling. If you come out thinking "low-ball exploitative !@#$%," that's not very healthy; if you come out feeling "good people; no fit; difference in expectations; maybe next time," that is healthy.
No raises are fine if they make it clear from their hiring that you're being paid above band. Also, raises aren't really the way to move up in tech, it's to jump ship as you say.
If you get recruiter emails for positions that are not interesting to you, just ask for the salary range. A lot of recruiters won't give it to you but some will.
If you can't articulate your own sense of your worth, it's very hard to engage with someone I've found.
Note - I've always given my number first (and all consultants tend to) and it's worked out fine.
Note, most people don't like dealing with places that are not upfront with the number to purchase the item / time etc. So if you are selling your labor, have some sense of its value /price.
> If you can't articulate your own sense of your worth,
The concept of your "worth" as the salary that you can manage to negotiate is so stupidly backwards that I cannot express how much it makes me want to burn everything to the ground.
Honestly I tried this every time I was interviewed. Never could get them to give the first number. I probably should have been firmer but usually the pressure of the situation led to me giving a number I would be happy with.
> I tried this every time I was interviewed. Never could get them to give the first number.
"I've actually done a few of these calls at this point and i know what the best practice / right move / way to play this is, so instead of me telling you what i'm looking for i'd like you to tell me the range on your hiring document:)" and just be totally silent.
Usually they ask me first. I give them the answer of wanting to know more about the position and the company. They push back and I throw in a number I am comfortable with.
Read the article: it mentions to ask back the recruiter with the same question.
Now I ask back with “what is the total compensation for this position/role?”. I almost always get an answer, often above my expectations. I used to give my range (mistake)
I assume this is something which is going to be very region/industry dependant.
I have done the exact same thing multiple times, never had an answer.
When they answer "no, we want you to give a number first", I'm at loss about what to do, so I usually give them a number. Answering "no, you" feels kinda puerile.
I assume you have to be the first to do the power play?
This is like a website that says "contact us" under the Pricing menu.
Do your homework. These days it's not that hard to determine what a competitive rate for a job is. Then ask for the top end of that, or even a bit more. It shows that you know what you are getting into, what you are worth, and quickly surfaces that there's been a misunderstanding about the job, if there has been one.
Sure maybe push back a little to see if they'll throw out the first number. But don't dance around it too much. Have your number in mind.
Never give a recruiter a number - there is 0 value you get out of it and it gives the company you interview for the power and you'll leave money on the table. Let them tell you.
I always just say stuff like "I assume that the compensation at amazing company xyz will be competitive enough to consider"
I’ve taken this strategy before, but now that I’m more senior I’ve found there are lots of positions that are not even in the right ball park that I’ll only find out after wasting a bunch of time.
Business relationships only work if both parties are happy; providing a number that makes you willing to work somewhere will avoid wasting time, and allow for them to adjust their expectations accordingly (i.e. fully appreciate how valuable you can be to them).
This is terrible, outdated advice for anyone with more than a couple years experience. The value you get out of it is not wasting everyone's time when the salary available isn't even close to high enough. Decide what your minimum compensation requirement is, increase this by some percentage that would make you happy, and give that to recruiters. You will get far more out of avoiding bullshit than you will potentially leave on the table.
Additionally, remember that most independent recruiters work on some form of commission. It's in their best interest to get you more money because then they also get more money.
I am an old guy who is a better-than-average negotiator (top 20%, not top 1%) and I’d like to hear more about that. In my view, it is never advantageous to come up with the first number in any kind of business negotiation and I have done tens of millions of dollars in negotiations for myself over the last couple of decades. But I haven’t interviewed for a job in 20 years. I would like to hear more about why that concept is outdated. Not arguing, just genuinely curious.
LinkedIn makes it pretty simple to get many recruiter contacts a day. These are not qualified leads, and many are dialing for dollars -- hoping to fill a vacancy with a warm body long enough to get the agency fee.
Most people ignore these contacts, so it does kinda work to match needy recruiters with underemployed IT pros. But when you're already at FAANG making 400k a year, it can take a recruiter phone call, two tech screens, and an onsite before compensation comes up, and you're now invested like 10 hours into a negotiation where your BATNA exceeds whatever budget they have written down. I've had one recruiter get a bit angry even over it, as if my number was unrealistic (I assume they were unprepared to make a competitive offer).
Since there are so many of these lowball recruiters, some people resort to screening them out up front with a salary negotiation.
The issue (I think) is that what one company and another might consider 'competitive' might vary wildly depending on the candidates they are used to and the space in which they work.
If you don't set some kind of expectations with a recruiter then you might end up in processes where the 'negotiation' happens at the back-end, when you've been through the hoops, and the company has no chance in meeting what you're looking for.
This can waste a large amount of your time. Which is probably valuable if this is a situation you're concerned about :-)
It's not so much that as a negotiation technique it's outdated, it's more that you need to pre-select positions in some manner so you don't waste your time. If you are being paid X and a company pays their best employee X/2, but think they are paying 'really well', you're never going to not be wasting your time.
Price anchoring is a pretty well researched/understood phenomenon though - as in, whoever comes up with the first number sets the tone for what's "acceptable". Someone who negotiates down from that number feels like they got a better deal than someone who was negotiated up to it.
I admit it's not exactly applicable to salary negotiation, but IMO leading with a high number can help cement the counterparty's perception of your value. I think it really depends on what type of company (and what level of its food chain) you're applying for.
> Additionally, remember that most independent recruiters work on some form of commission. It's in their best interest to get you more money because then they also get more money.
They may get more money total, but less money per unit time spent. Their ideal scenario is getting their commission instantly, even if it leaves some money on the table.
This limits options that are unwilling to meet your requirements; places you would have passed on due to insufficient salaries anyway. If you're willing to take lower salaries, lower your minimal salary requirements to receive more of them.
Dictating salary reqs up front does two things:
1. Reduces time wasted on folks or orgs that don't want to pay your rate.
2. Immediately moves discussion away from a dance around salary to salary _negotiation_. Any good HR org that can't meet your salary reqs and still wants you will try to compensate in other ways (stocks, RSUs, benefits, bonuses, etc).
It limits your options down. If you say you're looking for $100/hour, and the recruiter was planning on giving you $150/hour…guess what offer you're going to get?
I have never seen this in practice (but I'm sure it happens all the time). At the places I've worked/hired, if a candidate's ask was below the bottom of the range we paid that role, we just paid them the bottom of the range (regardless of their ask). It's a win/win from a hiring perspective. You hired a candidate for the minimum you possibly could (from a budget perspective) and the candidate is grateful you didn't hire them on their bad ask.
At some terrible companies even, it's harder to hire someone outside of their defined salary band. Even if you don't care about being nice or paying fairly, your life is just made easier by paying them the bottom of the range rather than dealing with HR about salary bands.
It also saves you huge amounts of time dealing with bullshit recruiters and companies. And if your ask is off by 50% then you did a shit job of understanding your actual market value in the first place and will hopefully do a better job in the future.
As if there would be an "actual market value". There isn't one number. Maybe there is a company out there that you perfectly match with and which is ready to pay you twice of what other would pay you.
I'd actually recommend the opposite. I want them to come in above my current salary — simply hitting my salary means their deal is basically the same as my current deal, plus a bunch of unknowns around the work, the environment, the company. If I'm going to switch companies, it should advantage me to do so. (And IME, if you give exactly the salary, they'll come in as little above it as possible. I am naming what I want, not what I already have.)
(I also agree with many of the parents: you don't really want to be the first mover — it isn't advantageous — but recruiters are very rarely going to give you that, and will force your hand in naming a number first.)
Well the thing is that if they name a number first they will assess whether you'd go for the 100 even if they would top out at 150 and then just offer you the 100 or say 110 or something. This will set the "tone" and the base number for negotiation. Your mind will be thinking "he said 110, so I guess they might go to 120" so you'll maybe ask for 130 and accept the 120 they offer you next.
Queue up yourself asking for 150 coz you make 100 right now and you did your research. The recruiter might just begrudgingly give you the 150 they were prepared to go to anyway coz you seem to know your stuff. Of maybe he's gonna haggle you down to 140. Big deal. But you set the tone of the conversation. This is not gonna work if you don't know your worth but either way either you are gonna lowball yourself and they will just accept or they are gonna lowball it.
To play Devil's Advocate, and I ask as someone not in the industry (I'm in academia) - is the difference between expectations really that large?
I would imagine (perhaps unreasonably) that a relatively seasoned person on the job market would have a reasonable understanding of their market value within a few percentage points - so the recruiter might be willing to pay up to $105/hour, while you low balled it at $100/hour.
I'm still early in my career, but the last two rounds of interviews I've done have yielded initial offers with a spread of $100k+/yr in total comp and $60k+/yr in base salary.
Just to have concrete numbers to work with, suppose initial offers exactly correspond to final pay and that you're currently making toward the lower end of that range (e.g. because raises haven't kept up with your increased skill and increased market demand).
If you're currently making $X/yr (total comp), you think you _might_ be worth $X+$50k to somebody, and you spit out $X+$50k as your target range, a prospective employer could generously offer $X+$60k and you'd be happy as a clam and none the wiser while missing out on a new Tesla per year in extra pay.
There's a separate argument that if you'd be happy with $X+$60k then you shouldn't try to squeeze your employer for more, but I'll let somebody else make it if they'd like. Regardless, that big of a spread really does exist, and I imagine it grows further into one's career.
I think my concern really is about the final 'negotiated' compensation & the parent's universal strategy to get there. I would imagine (correct me if I'm wrong) that regardless of the spread of the initial offers, you can reach a final negotiated compensation that is more or less in line with your market value. I would imagine that the more seasoned you are, the better you are at estimating your market value. You have a relatively clear eyed belief about what the final negotiated compensation would be, so why not just pad that as your starting bid? What's the downside? The parent's strategy of never revealing your number first doesn't make sense in that regard. For a seasoned worker, I don't see the payoffs at all.
I have over 10 years of experience and was recently on the job market. The highest paid job I was pitched by a recruiter paid more than double the lowest paid job I was pitched.
Specially in small/medium companies, a lot of the times businesses don’t know what they are looking for.
I know of a place that was looking for a “hardware engineer with 10y experience”. The average salary for this kind of job posting is not that high, they offered way more, but that’s because the actual position was “we’re looking for someone to become COO, and we need him to understand hardware development because the rest of the team doesn’t”.
I understand that this sort of situation might arise, especially in smaller companies that are still building institutional wisdom and are out of sync with the market. That said, is this really the case most of the time, to justify developing your entire strategy around it? As the sibling comments suggest, the greater the delta between expectations of the two parties, the less worthwhile the whole endeavor is. The parent comments suggest that the strategy to never disclose expectations pays off precisely because there could be a wide delta between the expectations, AND you're underselling yourself. I don't know enough about the industry to know how often these happen, to justify this approach.
That is surprising to me, but more pertinently, how often is this the case? Even if expectations don't match, how often do you actually undercut the recruiter's expectations? I would think most people would have a reasonable ballpark idea of what the recruiter has in mind - so just overshoot and then get negotiated down from there. The suggested tactic only really makes sense to me if you frequently expect to be undercutting what the recruiter's got in mind, and even then by a lot.
To my layman understanding, the larger the difference between expectations, the lower the value in this tactic of not revealing your expectations.
I agree (and expect) that people new to the job market would be poor estimators of their market value. They would also have the least room to negotiate.
The suggestion assumes most of the asymmetry between you and the company is not informational. You should strive to be well informed about what the salary range is. For well known tech companies, this is easy with sites like levels.fyi. Otherwise you can ask in your own network. It follows that you should also strive to be well networked.
Negotiation is an adversarial game played between humans. Therefore there can't be any simple advice except to get better at the things that make you more competitive at negotiation itself. Instead of subscribing to basic rules like, "never give the first number!", put yourself in a position of being well networked, well informed and experienced. Then you can decide how to negotiate well on the fly according to the context. You will probably earn vastly more by focusing on those areas than you will by diligently following simple rules of thumb.
For example: I received an offer from Stripe and got them to add a $100k sign on bonus to it even though I previously gave the first number. Which party gives the first number doesn't matter.
> If you're willing to take lower salaries, lower your minimal salary requirements to receive more of them.
To me that feels more complicated in Silicon Valley with equity. Once a minimum salary is met, I'll care about total compensation, not just the base salary. I'd be nervous that mentioning a low salary could lower an offer, and I don't a have reasonable number for salary I would accept if the company doesn't give much equity.
Well, of course they do. That gives them more information about you "for free", which would be useful to them if your salary ask is below what they had imagined you would want.
Asking for - what to me seems like basic - details is something I’ve been doing every time a recruiter reaches. And honestly, maybe only 5% replies with all the requested information.
If their response doesn’t come with the answers, or it’s just “let’s have a call to discuss”, I already give up and disregard them as spam.
We need to clarify: Sounds like you’re talking about the third party recruiters who play the numbers game and email anyone and everyone they can keyword match.
In the article, the author is referring to internal recruiters who are employed by the company itself.
Yes. While many internal recruiters are not great they are typically a bit better than the average third party external recruiter. Most third party recruiter are entry level sales people who got the job right out of college and will never make a placement before moving into another career.
There are very few high quality third party recruiters but the ones who are typically are very good but overworked and only serve a specific market. If you are not that market then you are a waste of time to them.
I have had very little luck getting a recruiter to supply a range. I've had a few, but they are few and far between. I've also had a few that I've gotten to name a range by first naming something comfortably above where I suspect their range is — to which the reply is then to talk me down to that number.
(And, in the cases where I've done this, I've found out the recruiter's range was well below my own BATNA…)
> Keeping those skills sharp even when you’re not job hunting.
Can I just add "Leetcoder" as a part time job on my resume? It is amusing how in this industry, your ability to interview will not at all be improved by spending time doing your job unless it is algo heavy. It is a separate job entirely.
The reality is that industrial psychology has consistently found that fluid intelligence is the best predictor of job performance. Even more so than experience.[0]
Whiteboard interviews are used, not because they have a lot of relevance to the job, but because they're a hard-to-fake indicator of high intelligence. Somebody who shows a lot of mental fluidity with complex data structures, almost assuredly can quickly master any specific tech stack. Even more so than a less intelligent person with years of experience in that specific tech stack.
It's the same reason that the military selects infantrymen based on word synonyms and fast mental arithmetic. What does that have to do with loading a rifle or marching in formation? Not a whole lot specifically, but whenever they've lower the intelligence standards, the results have been disastrous.[1]
There are other important qualities for certain. Honesty, resilience, hard work, enthusiasm, being a team player, reliability, etc. But almost all of those qualities are easy to fake and hard to assess in a 30 minute conversation. People who are hired on these qualities, are usually tapped from a pre-existing network, not selected from the recruiter funnel. If you've only got a half hour to choose a candidate, then pretty much your only reliable option is test their intelligence.
Doing well on whiteboard interviews can be a sign of high intelligence (a true positive result). But what signal does doing poorly on them give? Did you measure the candidate's intelligence (true negative), or preparedness maybe anxiety levels (false negative)? I guess the answer is that it does not matter as long as you have a large enough true positive candidate pool. And FAANG has this.
Sure it matters. Who doesn't do well due to stress? I think you'll find women, minorities and basically a lot of people outside of the cultural norm/majority do poorly.
That's not an argument that you can eliminate test anxiety, but certainly if we can reduce it without destructively eliminating the high value candidate pool we should do so.
What you are saying is an ethical/moral consideration and it is a valid one. When I said it doesn't matter, I meant that FAANG is commercially not incentivised to account for the anxiety factor. Even if they miss out on good candidates due to their anxiety, they can still choose from plenty of good candidates who don't suffer from anxiety. Given how many people are aspiring to join FAANG, I'd assume it's a buyer's market for these companies.
I'm not sure that's true. What you describe is the case for any individual candidate, but doesn't account for how those candidates interact with one another. Specifically, it has repeatedly been shown that more diverse teams will consistently outperform more homogeneous ones.
If your company only hires above the 95th percentile but their method for finding that quality cutoff is heavily skewed towards a certain demographic, in the long run that company may well perform worse than a company that hires at the 80th percentile but without the demographic skew.
The ratio that's important for those huge companies is the "true positive"/"false positive" one.
I guess if you make the test hard enough, always change it, and add some unhealthy dose of suspicion over the candidate's behavior, you can maximize that ratio. But I'm not confident FAANG even looks at it. It's much more likely that they just postulate that a hired employee is a competent one and go on with their day.
From the candidate point of view, of course, things are very different, and the negative results are much more important.
"Whiteboard interviews are used, not because they have a lot of relevance to the job, but because they're a hard-to-fake indicator of high intelligence."
By now it mostly correlates with effort spent preparing. There's dozens of web-sites, companies, consultants and message boards where one can train for those interviews. Whiteboarding is a skill like any other, it can be trained, faked, etc.
"But almost all of those qualities are easy to fake and hard to assess in a 30 minute conversation."
Perhaps it's not possible to assess somebody's future job performance in a 30m conversation.
Before taking algos/data structures I did terrible on whiteboards. After, I do well. From this experience, they seem reasonable indicators of a cs grads intelligence.
I doubt I am too much better of a software engineer in my day to day job, but I do think this toolkit does unlock a second disperate level of engineering ability, to code core algos for novel software.
I just have a problem suggesting learning this one set of skills really boosts my fluid intelligence. Im probably just as intelligent as I was before.
But I do get the cooralating signal as a cheap, low false positive approach to selecting good candidates.
Doesn’t that require a lot of interpretive skill on the part of the interviewer?
And for the interviewer to not arrive with the expectation that you will pass the same hazing ritual they passed to deserve that big paycheck?
It’s been a long time since I interviewed at a FAANG but I don’t think my whiteboard mojo played much of a role. It was more down to my personality fit with the interviewers, and the correctness of my algo answers. Which were still pretty softball way back then.
Everything I’ve read and heard since then makes me think it’s much more about those things now, and even less about general mental agility.
That infantryman comment is blatantly false. The literal bare minimum entry level job in the military is infantry. Like if you pass the ASVAB with the lowest score possible, you are infantry without a say in the matter. The army wants dumb people to get hit with bullets first. Then the laborer types, then the admins. Thats why those "better" jobs are harder to get.
That "lowest score possible" for the Army is a 31 percentile on the AFQT, which is a proxy for an IQ score. That means about 100 million Americans are too stupid to carry a rifle. My understanding is that the real score is actually higher than the advertised minimum.
I've taken the ASVAB and it is definitely not a meter of IQ. Middle school children who at least know simple algebra would have no problems scoring fairly well.
The ASVAB iirc was designed to determine critical thinking and mechanical skills. If you aced it, you either studied or shouldn't be in the army.
If fluid intelligence was truly perceived as the most important thing, then people would just skip the coding entirely and try to directly measure fluid intelligence. There are companies more than happy to run IQ tests and the like to screen candidates. Probably a lot cheaper than the current hiring processes.
The fact that they aren't trying that, and are instead attempting to get a measure of coding ability, suggests they don't really believe in the approach.
> “but because they're a hard-to-fake indicator of high intelligence”
Surely you realize large companies are full of people whose friends just told them what the questions were going to be? Memorizing 4 problems is still easier than cramming 40.
I'm sure many interviewers do cargo-cult whiteboard interviews, but the core intention of the archetypical whiteboard interview is to spring a complex question on the candidate that they have never seen before and observe how the candidate thinks. If the interviewer is asking questions that the candidate knows the answer to the interviewer is literally doing it wrong. It's not a trivia challenge, and the interviewer should only ask questions that they are confident the candidate hasn't ever seen before. That's not to say that Leetcode-style preparation doesn't work, but it works by tricking the interviewer into thinking that the candidate has solved the problem very quickly, when in fact the candidate actually already knew the solution.
Once you "memorize" a core set of data structures and algorithms, you can apply them to a variety of "novel" problems. The issue is those technique that are memorized, that become useful in solving these problems, aren't intuitive, despite their deceptive simplicity. In reality there's little memorization of solutions, and much memorization of useful techniques (data structures, algorithmic techniques) that are useful for these problems. And the more you do, the more you'll have at your disposal for "novel" problems. Further, many of these memorized techniques are not as intuitive as they seem. Quite a few resulted in publications when they were discovered.
5 years ago the fast/slow pointer technique for cycle detection could have been impossibly hard, now I see questions that just assume the candidate knows this. Every year the bar gets higher.
I've had this discussion during interviews as a disarming technique. Candidates will sometimes express nervousness at the beginning and say stuff like "I'm terrible at interviews" or "it's been a while since I've had to do this kind of programming," and I try to respond by making it clear that I understand that the whiteboard coding has very little in common with the actual job and that I'm not judging them, so when I dutifully proceed to ask them to invert a linked list, they hopefully don't feel as judged when they approach the problem. Seems to help at least a bit. Mind you, I'd prefer NOT asking those questions, but I'm not empowered to make that change at my workplace and I'm honestly not sure what I'd replace it with if I were.
Interviewing should normally have two results: the candidate was able to demonstrate the appropriate skills, or the candidate was not. Not being able to demonstrate the right skills in the interview does not mean that the candidate is a bad programmer or even a bad fit for the job. It just means that I was not able to verify their bona fides in that hour.
That's the difference between "that interview didn't go well" and "you are a bad programmer." One's a major blow to self confidence, and the other's a bummer. It's also a helpful mindset shift for both the interviewer and the interviewee: both of us are working together to achieve the goal of proving your capabilities. My job is to give you as many opportunities as possible to do so.
Why do you think that whenever we discuss interviews on HN, there's several highly upvoted comments complaining about how many incompetent people show up for interviews and how this basically makes coding interviews necessary?
I think it's because most interviewers consider people that failed their interview bad programmers.
You get classroom training, shadow hours, supervised hours, and certification on a particular type of interview. From that day forward any open slot on your calendar is fair game for Recruiting to schedule, up to 3 per week. You might get away with a "No" RSVP if you have a good excuse, but not in general. It's part of your job.
I think one of the biggest problems we have today is that we use the same word for estimating or evaluating a characteristic or ability of a person, as we do for evaluating the person themselves. I am evaluating your ability to perform this complex task in this situation, and it has nothing to do with my value for you as a person.
You may not care whether I value you as a person, but at that point, that's your problem and not mine.
I'm not even exaggerating, I believe this is a major source of strife in modern societies.
Trying to understand their thought process, is the candidate coachable, can the candidate accept feedback, does the candidate at least understand the underlying ideas, etc.
The more prestigious the employer then the less forgiving they are on your shortcomings.
The word "judging" has multiple variant meanings. It is being used to mean two different things in this subthread.
Judging whether a candidate is coachable, their thought processes relevant to the job, understands the ideas etc is what the interview is for, you're right.
But "I'm not judging" doesn't refer to that. It refers instead to the concept in the word "judgemental". Some definitions of that are "having or displaying an overly critical point of view" and "thinking, speaking, or behaving in a manner that reflects a critical and condemnatory point of view".
Apologies are due, sir. Two things happened. First, I hastily read through the question and rushed my response. Second, just a few minutes prior I finished a workout and was quite exasperated.
The use of the term "not judging" is a bit strange, without further context.
> I'm honestly not sure what I'd replace it with if I were.
Just to theorize: how about having the interviewee write a narrowly scoped toy project that's relevant to the position? (Edit: On site, as a replacement for white boarding.) A JS to-do app for a front-end engineer, for instance. Just a short thing you and the candidate can attack together in a couple hours. The candidate can write "normal" code, google things, clarify requirements, use their own architecture/patterns/style to reach the solution, etc. You could even add/change a requirement midway through the session, too. That would be realistic, and test for brittleness (and maybe be mean).
I don't interview people, so this might be hopelessly naive, or maybe untenable for some types of positions. But that interview process strikes me as a far more representative microcosm of an actual job than regurgitating LeetCode solutions or hardcore algo arcana.
I worked at a company that did this. This company always pair programmed. So the interview took place at a pairing station. We gave the candidate a choice of about 10 toy problems to solve, and then we coded for 2 hours. They could use Google, their preferred IDE, whatever they wanted.
Of all the companies I have worked at, this was by far my favorite interviewing technique. But, I think it works best when you pair with the candidate. So if pairing at your company is not done, it might not be a good fit.
> Just a short thing you and the candidate can attack together in a couple hours
Unless your hiring pipeline is absolutely perfect (you pretty much get great candidates all the time and almost no bad ones) this doesn't scale at all.
Because a candidate can grind leetcode and prepare for a huge number of companies.
On the other hand, something like a homework assignment is typically good for a single company, and if you fail, it's time and effort and emotional energy down the toilet.
Are extremely prestigious or have compensation clearly above market rates.
Candidates only have so much time to dedicate to homework so they will sort companies and work on homework assignments from top to bottom.
Homework are easy to grade (some of that can be automated!) and low commitment from the employer side. But that low commitment sends a signal that the candidate isn't really valued.
Having an on-site with engineers sends a much better signal as it tells the candidate he's worthy of discussing with a real engineer on company time rather than some gradings software.
Of course, if your recruiting pipeline is very poor (low signal to noise ratio, majority of applicants can't code) then sure, weed out with a homework assignment.
Agree 100%. I've decided to just reject any company that requires a homework assignment unless it's a FAANG or nearly FAANG level of prestige and/or comp. Otherwise, it really is a waste of time when there are many, many, companies that do not require homework.
I've done tons of interviews over the past 10 years. It was surprising to me the number of times the experience on a resume didn't line up with what the interviewee showed through conversation and small whiteboard exercises.
I get that it's not very real-world representative, and that's why homework is used instead by some companies.
Maybe the answer is to give the applicant a choice? Either be prepared to convince me you know what you claim, or demonstrate it with a take-home problem.
Personally, I'd prefer a day of in-person-pair programming as part of the interview. I'd get a better feel for the team and their workflows. If it's a total horror show, it's good to know up front :)
I think I misled you. I meant for the toy project idea to be an on-site, swap out replacement for a typical white board session. The time commitment should remain unchanged. Maybe I should edit the original comment. Sorry!
I prefer to have multiple short interviews with different engineers rather than a single multi-hour long one with only one engineer. You get better feedback and it helps against bias.
Not only that but a "toy JS app" implies the candidate knows JS at all. If it's college recruiting, you are better sticking with algorithms since you know that they know it.
To be clear, the goal is to watch the candidate build something using the prerequisite skills expected for the position. I'm not prescribing 3 hour sessions, or JavaScript. Target a 45 minute session. Target whatever tools, languages, etc are expected for the role. Maybe that means being language agnostic. Whatever is appropriate.
Watching folks make something -- for any significant duration -- is perhaps a better estimator of a candidate's genuine job ability than testing how well they approximate an algorithm textbook. Well...that's the assumption, anyway.
We need to band together and stop rewarding companies who pull this shit in interviews. Leetcode problems are not applicable to 99% of the actual work in most software engineering roles. There are other, gentler ways to find out if someone knows what binary trees, dynamic programming, sorting, and big O notation are.
Not being directly relevant to the role also has its benefits. It means that you can interview for a job without necessarily having experience in the company's exact problem domain or with the framework that they happen to be using this quarter.
True, but the algorithms challenges are not very representative of the actual work we do in our industry. They are a nice way to filter people who are not willing to spend a lot of time studying challenges to have job interviews though.
> They are a nice way to filter people who are not willing to spend a lot of time studying challenges to have job interviews though.
They filter for general problem solving skills. Whether you acquired those skills through a degree, self-study, a week of leetcode or 3 months of leetcode will be up to your individual background and aptitude. It's a hiring process - filtering for something is the whole point. Personally, I prefer being tested on more general stuff (like algorithm problems) over most of the alternatives.
They filter for memorization. Most leetcode problems you will not be able to solve in the allotted time without first being familiar with the problem or one very similar to it. Because most of those problems (and many CS algorithms) hinge on a certain "trick" to solving them.
The way to pass a leetcode interview is to know exactly what the interviewer is asking and then pretend like you've never seen this problem before. Then you amaze them by pulling a rabbit out of a hat. We are all a bit dumber for putting up with this charade.
Or they are just seeing how well your pattern recognition and subsequent application of an efficient solution. The problem is our industry is full of people who put their whole self worth on intelligence and then pick learned skills to judge anyone too harshly that hasn't worked through algo and data structures. You miss alot of smart and great engineers who don't have that skill set. But for hiring, its about reducing false positives. So you might as well ignore those who dont atleast have that algo/ds toolkit.
I think that you're misrepresenting the process of solving these problems. Recognising that you need to use a certain data structure or that a problem falls in a larger class of similar problems is a skill that you can develop. Just because you get better at it with practice, doesn't mean that it's the same as memorization or that there is some special trick to solving each problem.
Not necessarily saying you're wrong, at least not when it comes to general trends, but nonetheless this definitely needs a citation. Is there really that much of a correlation between 1) general intelligence and 2) happening to find the "trick" corresponding to a typical tech interview problem?
Speak for yourself. I love Leetcode. It's a standardized process that I can study for and basically be guaranteed to get a job in a sunset of companies that pay extremely highly.
I think the most valuable thing to know about interviewing is: go in to interviews already holding a job offer.
So to be clear I'm saying: interview at companies you don't like until you get an offer.
THEN rush the recruiters at companies you do like to get you scheduled quickly, because you are holding an offer and they don't want to miss out.
This lights recruiters and hiring managers on fire. It makes sure you have practiced enough to succeed. It destresses the interview for you since you have a backup.
It is the ultimate and most powerful interviewing technique.
Adding to this, schedule your interviews from least desired role to most desired. You will get a ton of practice interviewing and white boarding, and have offers in hand before you interview at your goal role. This is doubly true if your goal role ends up having an exploding offer.
Correct me if I'm wrong, but it seems like there would a substantial amount of luck involved in getting schedules and offers to line up just right like this.
IMO as a practical matter the way to manage this is to have an a active pipeline and manage your callendar to pull the B-grade opportunities earlier and push out the A-grade opportunities. Telling a recruiter “I am actively talking to a couple other companies” is usually an accelerant and seeds FOMO.
So, I agree with you that it takes some luck. But good strategy makes you ready for whatever luck happens. Play backgammon, not chess.
> good strategy makes you ready for whatever luck happens
Yes, I agree that attempting to schedule things in this manner is better than not, should you find yourself able to do so. But, I don't agree with the parent comment that it is "the ultimate and most powerful interviewing technique". Scheduling by preference is moot if (1) you don't have a resume/background that lands interviews in the first place and (2) you don't have the chops to be successful in technical rounds.
Apparently if you spend all your time either working or interviewing, even at places you don't want to wind up, it'll all just come together perfectly because that's all your schedule is.
I've done the opposite; I got an offer, but was still interviewing, and I let the recruiter know, and that I'd be willing to sign within 24 hours if they add on a signing bonus. You obviously have to do some math on the EV and consider how inconvenient interviewing is.
> This lights recruiters and hiring managers on fire.
Not always. Sometimes it has a repulsive effect. Like trying to score a first date when you're already flaunting the fact that you're engaged to someone else.
> Not always. Sometimes it has a repulsive effect. Like trying to score a first date when you're already flaunting the fact that you're engaged to someone else.
In what universe is this an acceptable analogy for anything?
> Your mad technical skills no longer matter to them. If anything, humility and an openness to learning will show you in the best light.
I've been interviewing for the last couple of weeks and I agree with this. Being a "good" human being, i.e. candid, humble, kind, friendly, seems to be valued a lot more than what I thought before.
At the end of the day is people working with people, and the more humans that interactions can be, as opposed to a rigid, dry act, the better.
At least, that gives an idea of the company and if it's a fit for me.
Can confirm as a senior engineer at a FAANG. I've rejected people for showing negative non-technical traits but being ok technically, and recommended people for hire with not the best technical skills but with excellent non-technical/leadership traits.
Life is too short to work with assholes if it can be helped.
Although this is welcome to hear, it's not something a candidate can count on reliably nor something they can really control. After all, a candidate can come off as likeable to one interviewer and unlikeable to another.
Versus just being able ace through leetcode problems - that's a more objective criteria a candidate has more control over.
Personal anecdote. I interviewed at a FAANG, got rejected. They actually offered feedback, and one of the key reasons I apparently got rejected was that "I asked too many (clarifying) questions" about the leetcode problem.
Fast forward a year, I retry. I take the above feedback to heart, and refrain from asking too many questions. I get rejected again, and given feedback. One of the reasons given? "I asked too few questions".
> candidate can come off as likeable to one interviewer and unlikeable to another.
> I apparently got rejected was that "I asked too many (clarifying) questions" about the leetcode problem.
> I get rejected again, and given feedback. One of the reasons given? "I asked too few questions".
It sounds like they didn't like you _personally_. If the rejection reason wasn't due to technical or behavioral mismatch but a fake reason like the ones above, it's the often the problematic "Airport test" (ie. They don't want to be stuck in an airport with you"reason).
And to be clear, I think it's wrong to reject candidates because you personally can't think of "being friends" with them. It's unfair to both the candidate, but also the company as it misses out on great engineers.
> I've rejected people for showing negative non-technical traits
I'm not an expert, but this can be a really slippery slope to implicit bias creeping in to your hiring decisions, especially if these traits are outside of your area of interview/expertise.
Not selecting or evaluating for soft skills is worse than potentially slightly increasing exposure to implicit bias.
Furthermore, I would bet that in the long run, selecting for soft skills helps drive down real observed implicit bias. (People with better soft skills are probably better at managing their own implicit biases.)
This assumes that your soft skills evaluations are more colored by implicit bias than your technical evaluations. Everything is colored by bias, it's just different kinds of bias. And stuff being inside your area of expertise is no defense against bias. You might subconsciously assume someone doesn't know certain technical things and simply not bother to ask the question.
Eh, seems to me some minefields have a lot more mines in than others.
"Did their solution to FizzBuzz coded within 20 minutes produce the correct output?" has far fewer mines than "did they communicate clearly throughout?"
I think reaching the correct solution is one of the least important parts of a technical interview.
I've interviewed candidates who will write the equivalent of enterprise level fizz buzz [0] and get to a correct solution, and candidates who will write much simpler code, but not quite solve the problem (it's a longer problem than fizzbuzz). I feel like I get better signal off the latter, as we can spend more time discussing their ideas, Vs writing boilerplate.
The "culture fit" interview which is standard in tech companies today is nothing but an avenue to introduce whatever bias the interviewer wants with no oversight, no explanation.
I can see how it can do just that, but I explain our "culture" as best I can before evaluating candidates against it.
Example: My workplace has a great deal of change, bordering on ambiguity. We need people who can deal with that and thrive in that environment. So, my interview questions aim to find out if the person is going to thrive in an environment where they might have to find their own way, or if they are the kind of person who likes to take directions and stay in a specified lane.
In this case, adaption to change is part of our culture - you're either a good fit or you aren't.
This isn't necessarily true. You can have rigor around your value/culture fit questions. In our process, we require strong reasons for both yes and no decisions (especially for culture fit). If an interviewer says no "because X" we look for similar signal to have shown up in other parts of the loop (performed by different people). If only one interviewer sees a signal, we are careful to analyze it for bias.
It's def a slippery slope, but all of hiring is bound by implicit bias. If random people are evaluating random people against a set of subjective metrics, you're always going to get _some amount_ of bias in your decision making.
In reality, I think a surprising amount of bias goes into "tech screening", maybe even moreso than evaluating "soft skills." If you're asking random engineers at your company to conduct tech screens, the odds that those engineers are emotionally and mentally reflective enough to be fair and bias-free in the questions they ask and the solutions to those questions are very low. This is why so many places struggle with tech interviews that feel like debates. Engineers dislike candidates that do well on the tech portion of the screen because those engineers feel it is a competition that they must "win". I've seen this time and time again at FAANG and non-FAANG. Random engineers from a team should not be assessing candidates, pretty much ever.
In some cases you are effectively screening out senior engineers that have pretty much reached their plateau. They won't learn anything new and they don't want to learn anything new.
There's a difference between 10 years of experience and 10x one year of experience.
What I meant is that I've met senior engineers who were senior by virtue of having spent a long time in the industry but not because they were any better than a fresh grad.
Also that some seniors simply stopped learning at some point, which is pretty bad for the majority of dev roles. They won't learn for the new role and push whatever they used at last N roles because that's all they know.
Not being an asshole, being able to help teams work together and not be assholes to each other, and having okay technical skills is my true value proposition.
I have had opposite experiences. Many of my interviews were straight evaluations on technical ability, many of which I failed.
Amazon in particular, I had told the interviewer that my day-to-day was in C#, but they continued to ask rigorous javascript questions, of which I could explain most of the answer, but failed to find the very specific javascript answer they were looking for. As a result, I was blocked by Amazon from any further interviews for one year. (And at the time, incredibly disheartening in my job search...)
The most scarring interview experience I've ever had was with Amazon, when I was very young, where they exhibited a similar amount of not listening to me at all and evaluating skills that I never claimed to have.
Ultimately Amazon is too big and too popular to listen or care to candidates. They're going to do whatever they're going to do, regardless of what you say, and that'll naturally filter out a ton of candidates.
Interesting thought. I had an interview experience a few months ago that went fairly poorly and it was in large part because the interviewer pressed me on topics that I forwardly stated I was not well versed on (microservices). I ejected from the interview process afterwards because of my displeasure with the interviewer. He was not someone I wanted to work with in the long term.
It happens all the time. The last time I was looking for a new job, I interviewed at a bigger tech company in my area (SF based though). In the first screen I was open about not having recent JVM experience and 0 experience with JVM optimization/tuning. The hiring manager said it was no big deal and they hire and train people that are new to that space all the time. I was then given a take home challenge that required Java. Then, during the technical assessment, all of the questions were around JVM optimization. I just kind of laughed and skipped a lot of questions until the interview ended, where I emailed the hiring manager withdrawing from further interviews.
With regards to the “block”- my understanding at most companies is that if you don’t pass the interview, but still had some positives, they’ll tell you to try again in a year.
I recently had a technical interview where I stumbled the whole way through, but I kept my attitude lighthearted, asked plenty of dumb questions, and am pretty sure I even said "Oh, geez, I'm an idiot" at one point. They acknowledged that I was a weak candidate, but they liked me enough to extend an offer amounting to a 33% salary increase over my current job--and with an additional 33% bump after 6 months if I can prove that I am actually not so much of an idiot. :)
Humility and earnestness can go a long way. A big ego never helps.
That doesn't seem to apply at FAANGs. I had some positive interviews where I went out of my way to build some rapport and it got a lot of smiles but no offer. It definitely worked at the completely not FAANG company that I work for now. I think I'm probably better off this way.
FAANGs are a different beast altogether. Especially at the IC level, it is 99% technical, given a normal-human-being-behavior. Then, technical the way they (individual interviewer and company) evaluate it and you don't know about, since I had a few interviews in which I was confident I did a very good job (I am not a junior...) and they got back with a rejection on technical grounds.
One striking example was when I solved the coding problems posed to me in 15 minutes out of the 45 available, the interviewer said "that's great, I don't have any more questions, please use this time for you to ask about the company" and then the recruiter told me I was rejected because I did not do the coding part well enough.
> One striking example was when I solved the coding problems posed to me in 15 minutes out of the 45 available, the interviewer said "that's great, I don't have any more questions, please use this time for you to ask about the company" and then the recruiter told me I was rejected because I did not do the coding part well enough.
That's terrible behavior from the interviewer. Did you try raising this with your recruiter?
The decision is already made, there is no point, nobody is going to backpedal on anything. I remember saying: "I don't get it", but she was clueless about the interview itself. It was a company in LA with a ghost.
If I liked other people I'd met well enough I'd give that feedback (politely and without assigning blame), not to change their mind but just to let them know.
The one moment I know went wrong was when I couldn't remember the name "trie" and the interviewer just wrapped up and left 15 minutes early. And I still had 3 more sessions that day.
It's because they thought you memorized the problems and solutions. Next time if you get something you know, feign ignorance and just stumble through it naturally.
It seems that it depends on the interviewer. I nailed 3 out of 4 of the rounds for a FAANG job earlier this year, but absolutely bombed the system design question. I was offered one more interview round to redeem myself (didn't know they did this). Did so-so on the extra round but ended up having a fun conversation about surfing after the interviewer pointed out my surfboard in the background. I have no way of knowing but I'd like to think that my personality got me the job considering my poor performance towards the end.
I would say it doesn't apply to most medium sized or larger tech companies, or even most medium sized or larger non-tech companies that have formalized leetcode-based hiring practices.
You can come off as the most awesome person to work with, but they'll typically reject you if you can't solve the leetcode problems to whatever minimum standard they're expecting.
The hardest part about interviewing is that there is no feedback loop; I once interviewed at 10 companies within 2 weeks and got rejected from all of them, but to this day I still don't know what part I need to improve upon.
Same. I interviewed with Amazon twice and it's like a 10-hour meat grinder. No offer either time and I have no idea what I did wrong.
I absolutely don't get those wide open questions like "How would you design 1-hour delivery?" (real question btw). As someone who has done a lot of consulting work, my instincts are never, ever try to answer such a ridiculously broad question on your own with no context. The answer to me is to budget for several weeks of planning with a broad range of stakeholders to prioritize features and come up with an initial technical approach that we can refine after an MVP launch, but I don't think that's what they wanted to hear.
>I absolutely don't get those wide open questions like "How would you design 1-hour delivery?"
Quick tip: interviewers often design that kind of question to be intentionally vague. If you get a question like that, they probably want a bunch of questions before you start on an answer. Like, "which part of the process are we designing? The software stack, interfacing with logistics companies, customer service?"
It seems frustrating, but they're looking for people who will drill down and make sure they fully understand a task before they run off to solve it. Asking for clarification is usually a good thing in an interview, especially since the interviewers don't always think the problems through completely.
The lack of feedback seems like a liability thing. A very small number of people will sue because they don't like the reason they were given, so the company decides not to give detailed feedback.
Your interviewers rarely have real world consulting experience, meeting with clients and solving real problems tied to real money. What they mean by that "1 hour delivery" is a system design question that must be answered along the standard system design template, which is completely detached from reality. You should lookup up those system design interviews on youtube, ala "design a tinyurl service".
There is no stock right or wrong answer for those kinds of questions.
You should ask questions to understand which area the interviewer wants you to concentrate on (if any). Some interviewers are happy if you choose an area where you can showcase your experience, others expect you to answer an area they have in mind. If you cover enough, with enough detail, they will be happy. Ask questions.
There is a correct answer actually, one which can be studied for. That question is a system design question, they wanted you to come up with some architecture for it, that you will know once you study system design. To do so, just search up "system design questions site:GitHub.com".
It sounds like a super fun question. I'm almost tempted to start thinking about it even though I'm not interviewing for anything.
Given how many features AWS alone ships every year, I'm sure Amazon is very familiar with prioritizing features and building MVPs. But you're interviewing for a software engineering position (I assume) and the question is explicitly about design, so project planning is off topic here. It's fine to mention it in passing, but the meat of the answer should be about the "initial technical approach" that you mention.
Your comment suggests that, due to your consulting experience, you flat out refused to draft an initial technical approach on the spot. That may be wise is other situations, but you aren't here as a consultant. Amazon isn't going to start implementing 1-hour delivery based on your plans. They're asking this question to see you think and work your way through a complex problem.
Additionally, your answer is so vague that it could apply to almost any question ("How to do X?" "Gather stakeholders and come up with an initial technical approach").
Interviewed at a FAANG last year, failed the onsite. I got called by the (internal) recruiter a few weeks ago asking if I wanted to retry, and he offered feedback he had from my previous attempt. I was shocked - both that he provided feedback, and because my own evaluation of how I did differed from the actual feedback (did better at a round I thought I bombed in). More on this later.
Interviewed at another FAANG, and got rejected there too. Here, the hiring manager immediately gave me feedback before sending me home. Again, surprising.
So are things changing in regards to giving feedback? Usually FAANG leads the charge, and other companies play copycat.
Getting back to the first FAANG, I wanted to punch myself because according to the recruiter, I might actually have been able to get in if I had asked to be considered for a lower level than what they had originally pegged me for. I would have hands down, no hesitation, jumped for joy to be brought in at a lower level. Sucked that no one told me at the time of the actual rejection.
Kind of related to the advice in the blog post, there are a couple things you can do (from an open-minded, kind, curious-and-hoping-to-learn approach and way of phrasing your questions).
- In an interview, if you feel it could have gone better, you can ask your interviewer about better solutions. I have literally done this in interviews that led to an offer - when they get to the point where you ask questions, one of yours can be "I don't feel like I got to a great solution here, can you explain what an efficient solutions would look like, or point me to a reference where I can read up on this"?
- You can ask your recruiter for feedback, or just suggestions for general areas that you can improve. More likely than not, they won't respond or will tell you the policy is not to share anything, but you've already lost out on this job, and one polite inquiry is not going to put a black mark on your record at this company.
If you aced the technical questions, then it must be the behavioral part. One big trap there is the question about conflict resolution. The naive answer "I avoid conflicts" is a mistake: according to the trendy big five personality traits system, avoiding conflicts is a sign of guess what? combative personality. You want to present yourself as a "agreeable" person. The person asking these questions is rarely a psychologist. Instead the interviewer is given a big spreadsheet with 50 or so canned questions and 5 or so columns with examples of answers and how those answers must be interpreted. Finally the interviewer crosschecks your answers with the spreadsheet and gives ratings to five personality traits. In your case, you must be said some keyword, the interviewers, who can't care less, matched that keyword with the spreadsheet and you got a bad rating. The HRs also can't care less, so they obviously don't bother to double-check the ratings (if anyone bothered to actually record your answer). Anyways, morale of the story is that behavioral questions are just like leetcode: you need to know the right answers before you start the interview.
If you get to later stages you can ask for feedback. Some give it some don’t. I had some really positive experiences with that, usually with smaller companies. Worst case you just get ghosted (hi datadog, dropbox).
This is not completely covering why they didn’t give any feedback, but something to ponder over. From the Recurse Center application process and why they don’t give feedback to rejected candidates: [1]
> People would reply and try to contest our decisions, get frustrated that our responses weren’t specific enough, or otherwise indicate that our feedback wasn’t very productive.
Depending on the company and its location, there could also be legal considerations in not giving feedback.
From time to time, I've gotten really good explanations. One was that the perfect candidate fell in their laps, and not to look at it as "I failed," but they the company got really lucky.
Another was that I did well and people liked me, but they realized they actually needed to focus on a different position. This meshed with things I learned during the interview.
Granted, these are the low-risk rejections where giving me the reason doesn't open up the company to anything legally, but it's still appreciated.
From the article:
If you think you flubbed an answer, ask during the interview for what they were looking for! Or, I've had success framing that up at the end of the interview as:
"Is there anything I didn't say today you hoped I would; anything that I said you hoped I wouldn't; anything I said that you've got questions about?"
Nothing can save you from getting ghosted, but you definitely should utilize the face time you have to ASK questions, too.
> The hardest part about interviewing is that there is no feedback loop;
I've had good results simply asking the recruiter for feedback. Typically they are able to give me some insight into the process that I wouldn't have been able to guess. In "no offer" situations, it's often "the hiring manager was looking for someone with more experience in X" or something like that. This works best over the phone, since they are apt to tell you more than they would be willing to put into writing.
For that matter, the recruiter is often an underutilized resource before the interview too. There's no rule that the nature of interview questions need be a complete surprise. The recruiter is often able to shed light on who will ask what sort of questions, which can be reassuring and narrow down what you might review before the interview.
I have given lots of interviews and only one company (bol.com) was kind enough to schedule a call and gave feedback that why exactly I am being rejected.
Everyone else, if they bother enough, only sends the standard template response.
I recently got interviewed by a FAANG company, and it was not a nice experience, it had like 4 hours of back to back interviews with 4 different people and couple of them didn't even bother.. on the technical side, I was asked questions that didn't even fit my profile :( .
although am waiting for their response, regardless of whether i have cleared their "tech" rounds, at this point I dont even care about that interview anymore or their offer (if it did happen) :|
so the fine print is, be attentive in the interviews and see whether "they" really care about you, and if you dont feel comfortable about other side, dont bother!
If you're not up for four to eight hours of interviews (with a break or two, depending on how long the day is), asking the standard bank of questions, it doesn't sound like you're a good fit for a big tech company.
But why did you bother applying?
None of what you describe seems like it should have been a surprise.
I’ve been on the other side, and hired people, which means you sit through 8 hours of interviews. Sometimes days in a row. I also work as an external examiner for CS students, which again, mean that I sit through long days of tedious technical tests.
I can’t imagine why you would ever want to subject candidates to that. It’s tiring enough when you’re not on the spot. I’ll typically spend the weekend or days leading up to such an ordeal in preparation, and when a day is over I’ll go home or to the hotel, do a few hours of prepping for the next round and then go straight to bed. Because you’re that spent. It would be ridiculous to expect a candidate to perform well, or show you anything about themselves, when the interviewer gets that busted. Because a candidate would have it much harder, especially if they are early in their careers.
I can’t imagine why anyone would want to subject themselves to those sort of ordeals either. I realise that I’m Scandinavian, and that our interviews and hiring processes are very different from Silicon Valley, but all my interviews have been as much about the company/organisation selling itself to me as me selling myself to it. Well not for my first two jobs, but since then.
my point was not about 4 hours, its more like , if i spend 4 hours for you, least you can do is to look interested and make me feel like they need me (just like i need them )
I work at a big corp and I interviewed for big corps and oh my it is awful. I remember leaving a google interview so mentally drained I couldn’t open my eyes anymore.
I wonder how many, if any, great software engineers simply let their careers stall out because they don't want to deal with the ceremony around tech hiring.
Same kind of person who never finds a partner because of the "ceremony around" dating, I guess?
In both situations, it's not like you're adding a commodity product to your Amazon shopping card. The matching is non-trivial and both parties have to recognize and commit to the effort-full process.
To abstract your comment all the way out - how many people live well below their potential because they are too lazy or afraid to work and get something they really way?
> Same kind of person who never finds a partner because of the "ceremony around" dating, I guess?
If dates were conducted like coding interviews — assuming the candidate is a liar and forcing them to prove in detail why they're not — you'd never get a second date. A job is supposed to be a voluntary, mutually advantageous relationship between two parties. So interviews ought to be kind of like dating, where you're trying to be as nice as possible and make a good impression. You don't give tests to a date, you just talk to them, get to know them.
Employers too often assume that interviews are a one-way street, where the candidate wants the job no matter what and will do anything to get it. On the contrary, the candidate can walk away at any time, and the employer needs to woo the candidate just as much as the candidate needs to woo the employer.
I kinda like this analogy. To take it a bit further, when there ought to be a two-way street, a toxic behavior would be for person A to use some kind of negging, to try to force the dynamic of person B feeling insecure, and seeking A's approval.
>> Employers too often assume that interviews are a one-way street, where the candidate wants the job no matter what and will do anything to get it. On the contrary, the candidate can walk away at any time, and the employer needs to woo the candidate just as much as the candidate needs to woo the employer.
I guess I am lucky but I never had (or gave) an interview of the former, so it DID feel like this: "On the contrary, the candidate can walk away at any time, and the employer needs to woo the candidate just as much as the candidate needs to woo the employer."
Hence my comment. It sounds like you've interviewed at some shitty places or maybe underappreciated how much power you actually have.
> Same kind of person who never finds a partner because of the "ceremony around" dating, I guess?
Surely its the person who gets married and doesn't have to deal with that any more. Its a good reason to stay in a company a long time, like the OP says.
Tip 3 is huge. I ask hard questions during interviews, and I don’t expect a perfect answer. What I do want is the interviewee to handle failure without being defensive, and to ask probing questions.
Same here. Some of my goto questions are questions I don't expect a solution to. I'll tell people that - I know some people use similar questions without telling candidates that, but I don't think the extra pressure is necessary. I also explicitly explain to people that what I want to see is how they think, more so than the final solution.
It tells me a lot about how a candidate will work within a team if they're capable to actually bounce ideas back and forth and explain their thinking, and I've often preferred someone who doesn't get as far but who can show me better communications skills and who seems eager to learn.
I've found you can somewhat mitigate it by asking questions yourself. For example in one tech screen once I had the algorithm pretty much done I asked if I should look to optimize and to add test cases/handle odd input and the interviewer said it's fine as is and let's talk more about other topics like architecture in the real world.
Absolutely, that's something I pointed out in my writing: if the interviewer doesn't explain their expectations, you can and should ask. Interviews work best when both parties are engaged heavily in the success of the interview.
On the other hand, I go through months where half my job is devising ways to extract requirements from users who just want me to "make this problem go away"! I consider it very reasonable to test someone's ability to work out what problem they're meant to be solving.
I like to ask open-ended questions. "I am trying to solve X problem, how should-I do it?". That reduces the rote bias and also checks if the candidate can communicate.
Heh, I once was introduced to a particular interview question. It has a solution that is hugely better than the best naive solution, but is basically a giant gotcha that seems obvious in retrospect. I couldn't find it myself even though I was stumbling around in its neighborhood. Obviously I gave this question informally to a ton of people as entertainment (Bay Area techies in various companies), and most couldn't find it either.
However, one guy told me he now uses the question as his actual interview question because he thinks the way people suffer thru a seemingly impossible problem reveals how good of an engineer they are :D
Sorry, I was offline for the break. You have a singly linked list with each node having a "random pointer", an extra field that points to another node in the list (including itself or null). You need to make a copy of the list, in such manner that random pointers in the copy correspond to the original list, e.g. if the 10th element of the original points to the 3rd element of the original, 10th element of the copy needs to point to the 3rd element of the copy.
Was it clear for the candidate what you were looking for, like "if it happens you don't know the answers or else, I'd like to know how you think about it"? Because that is what I do in the beginning of the interviews I lead, I dislike the approach "let's slap this guy and see if she calls her mother". It puts the interviewer on the throne and the candidate of their knees, it is an interview and not the "real" job, and the candidate may have studied for months and might be rightfully defensive when they see their months of work go up in smoke after your "slap".
I don’t go out of my way to encourage the behavior I’m hoping to see, but I do indicate that the question isn’t one I expect a complete answer for and that it’s more of a discussion than an interrogation.
These blogs are just for procasinators to feel productive. If you landed the interview then it is just about practicing through a lot of questions. The time you finished reading this comment and this blog, some people out there have already completed a mock interview or a leetcode question. I wonder who made greater gains.
I would add, these holier-than-thou FAANG interviewers writing blog posts about how to clear a FAANG interview are actually bullshitters. They want to feel good about themselves. So they write.
When push comes to shove, these same interviewers would clear the candidates who've pretty much memorized all the medium-level leetcode problems, but lie during the interview by claiming that they've never seen the problem before in their lives, but just happen to be "so good" they end up solving the whole thing in 30-35 minutes.
P.S.: The non-tech part is not that hard. Just don't be a dick.
>> P.S.: The non-tech part is not that hard. Just don't be a dick.
This is probably true for junior roles but gets much more important for senior roles or ones where they are testing out your potential to take on greater responsibility shortly after joining.
An answer to a vague behavioral question can make a ton of difference. EG:
Question: Have you ever managed people?
Answer A: Nope, always an individual contributor.
Answer B: No, but at my last job I took ownership of a project that involved coordinating work of 50+ developers, UX people, QA, etc to deliver.
Question A is technically correct and "not a dick" but if the person has it in them to figure out to provide answer B (assuming it's true) they are more likely to get a more senior job and make more money.
> When you're in a real interview the world changes: You're locked in a cage with a lion.
I got into interviewing this last year as an interviewer. I used to think (as most people do) that the interview is a confrontation between interviewer and candidate.
However my biggest breakthrough happened when I changed my perspective. Now I see interviewers as detectives, gathering evidence of whether the candidate would be a good hire.
So my advice to candidates is the following: don't think of the interviewer as the enemy. Usually they aren't trying to get you, but help you. And if that isn't the case, you don't want to work for that company anyway. Keep a friendly and relaxed conversation with the interviewer and you'll be surprise how far it can get you.
I like to view myself as an advocate for the candidate - work with them and help them to succeed in the interview. Through that process it's really easy to figure out if you are a good fit for each other or not.
I mentor interviewers at my job. Pretty much, every junior (< 3 years of experience) interviewer at first asks me what they should do if the candidate starts talking about something they know very little about.
The interviewers are people too. They get nervous too sometimes. They too don’t want to look stupid when they’re having a conversation with the candidate.
The first learning of interviewer training I try to solidify is that the interviewer is not intended to be the person who “knows the answers”. Candidates have specialized, deep knowledge in the specific areas they’ve worked on. How can an interviewer expect to know more than them?
Experienced interviewers will know that they are there simply to facilitate the candidate in arriving at solutions to the problem.
This doesn't really go against the Leetcode till you die advice. It's just assuming that you're baseline really good at Leetcode style questions so that you can focus on soft skills. I do not believe you can get a job in any top 100 company in this day and age without being able to regurgitate Leetcode mediums in your sleep.
So yeah be nice to people and all that, but you also must pass the tech screen and the 3-4 Leetcode sessions.
The same kind of articles over and over again with lots of text, but in reality everyone knows that in tech if you want a FAANG (and now extended to several other companies) job you better spend hours in Hackerrank/Leetcode. All the rest (except maybe Amazon with their "principles" thing) is a nice-to-have.
> (I wanted to learn the answer for future interviews!).
This is the only advice that has ever helped me.
Technical interviewers are unoriginal and looked up and use the top google result on "programming questions for X", especially for niche roles that the company is now just hiring for.
Nowadays leetcode platforms can provide a more randomized set of problems for companies, but many many many teams and individuals will still just recycle.
I recycle answers, which is ironically closer to what I would be expected to do for the company on a day to day basis than an original answer to any academic problems.
I interviewed with FAANG twice this year, and both of them were rejections with zero feedback. The first one I thought went well, I had a two-way conversation with the Engineering Manager, but sadly I didn't hear back from the recruiter, so I assumed it was a rejection. The second time I cleared the initial screen question, then I had a coding question with two engineers. They gave me a problem, and I solved it but using a sub-optimal algorithm. I thought I'd done well, because it was a hard problem and the solution was not very far from the optimal one. Unfortunately, after two weeks and chasing the recruiter, I got the rejection that they went with someone else.
> What hadn't occurred to me at the time is that C# is a very verbose language which Visual Studio beautifully automates away the tedious parts of. This online IDE automated nothing.
That's pretty much why I use Javascript in interviews
Writing on the board or in an online IDE
Its just the gaslighting is annoying, in most contexts that's called toxic. "We don't care which language you use .... ooooh you used Javascript we code in this other thing"
I think you're saying this to dismiss the wisdom of the author.
I think it's actually worth noting that you can be a very valuable developer and not remember minutiae.
For example, in the last few days I wrote in C++, Python and JS. Do you think my fingers always typed the right type of bracket to create an array as I jumped between the languages? Who cares.
I need to get a good software engineering job, BUT I'm tired of the take home projects, the 5 phase interviews just to drop you 1h before a final -not important just burecreacy-google meeting with the VP of Engineering, recuriter just tells you there's been some internal miss-communication on the roles they're hiring and they're not looking for frontend roles anymore, and they're sorry...
Nevermind I'm pretty good at backend too with node/python and devops chops...
I need to learn vue and nuxt for applying to a job now, It would take me 20% effort and time doing it in react/next but who cares... not the recuriters or companies..
I'm not talking about FAANG here though, and yes I prob am not good enough for the position/company.
Just saying that every interview I do / application I go through ends up with my noticing this little feeling that I maybe just am not wired to work for someone else...
I've found that if you are transparent as recruiters and treat them as partners , sharing the offers you've gotten at other companies, they will reciprocate. At one of the Big Tech companies where I interviewed and they ultimately decided not to give me an offer (it was a near thing and I had other offers), the recruiter gave me tips about what other companies she was aware of that were paying well in my area (that I wasn't aware of).
Your relationship with recruiters is more complicated and nuanced than the game-theory relationship would lead you to be believe. Maybe I could have gotten slightly better offers if I had used classic hardball negotiating tactics, but from colleagues, other recruiters, and other data sources, it looks like being transparent resulted in me getting top-of-market offers for my job role at the companies where I was interviewing and got offers.
My philosophy is to interact with everyone as if I'm planning to join their team from the beginning, almost as if I'm already a team member. That entails among other things that if you're going to join someone's team then you'll interact with them with transparency and vice versa.
During my recent round of interviews, I shared the ballpark details about all the offers I got and all the companies I was interviewing with with every company I was working with, and I was pleasantly surprised with the results. Recruiters would give me tips like "Competitor X's offer is likely to offer the highest compensation, but here are some reasons you should consider us", or "Offer Y from <other company> is a very good offer", all from recruiters at other companies. If I had been cagey I don't think I would have built relationships with recruiters where they'd share tips like that with me.
I think a no-bullshit approach is refreshing and worth considering. The trick is being high demand as talent -- having multiple offers and being a desirable candidate for employers to hire.
The recruiters that I recently worked with at all the big tech companies, pre-IPO tech companies, and startups were all very professional and I think I only benefited from treating them as partners in the profess of finding the best next job -- because the company and employee are looking for a mutual fit, after all. This resulted in me having a number of great offers (a few where I don't have details yet) that I'm currently in the process of deciding between.
There might be really good negotiators who could do even better, but simply showing that you're high demand in the market was enough for me to get good offers from the companies I was working with who made them.
I've had it happen multiple times where I tell a recruiter I'm looking for X but will go as low as Y, they simply told the company Y so it'd be easier to close the deal. Even if I specifically ask them not to say Y.
How many interviews do people do a year? I've been in my job 5 years and the one before that 8, I've had 4 interviews in the last 10 years. I kinda feel at a big advantage for not job hopping. It seems some people interview a dozen times a year just as normal.
Should I try to get 10 interviews just for practice before interviewing companies I really like?
From my experience job hopping usually pays off (at least financially). Bumping your salary in the next job by 50% is not uncommon while may be much harder to achieve when staying at the same firm for years.
As others have pointed out before, interviewing is a skill that can and should be practiced. The best way to prep (except grinding through leetcode problems) is to go to a real interview and practice telling real stories from experience and solving problems in real time under stress. So yeah, I would definitely recommend going to at least a few interviews for jobs that might not be your first choice before going for that “dream job” interview.
Has anyone here pivoted from software engineer to software engineering recruiter? Curious or yours (or anyones for that matter) thoughts on this topic.
It's a move I've considered just to keep my career interesting.
Closest I have come is managing a lot of recruiting (but still from the engineering side) and I know a few very senior folks who started their own headhunting firms - it's an obvious move given their vast network.
I don't know for sure but I suspect most recruiters make a LOT less than the roles they are recruiting for, since generally the skills to make a good recruiter are easier available than those that make an engineer. If you want to broaden your career while getting more into dealing with humans rather than code, the obvious progressions are engineering management and perhaps product management.
The ability to hire good junior engineers is one of the things that set a good senior engineer apart. So you might want to practise being an interviewer, even if you don't go into recruiting.
I personally know an engineer who started his own recruiting firm and is making much, much more money than he did as an IC engineer. He also has built a business that he can sell one day.
Extremely well written title, content so-so though.
It's simple: Make the funnel full that you don't feel any pressure, anxiety or whatever because you have options. No need for some voodoo advice from OP.
That's the general route that I took. As an applicant or hiring manager, I view the interview as a meeting between two equal sides looking for a mutually beneficial fit. If there isn't a fit, it's ok. Onto the next interview. It makes interviews a lot less stressful and more engaging to me. But to go down that route as an applicant, it helps a lot to think about what's needed to have those options.
Some smaller items as well, that I think are worth mentioning, given the post starts out that advice is woefully short - seems like an invitation to throw in my 2p/2c/2satoshi, etc.
Remember that it's really a conversation, and it goes both ways. They want to learn about you, but you need to learn about them as well. Are these people you really want to work with, and are you the kind of person they want to work with. This means you have to show your full self - honest and open, and expect the same from them.
Some tricks here include making sure to turn it into a conversation, and engage the interviewers - something like finishing up your answer with "and, have you faced that problem, and how did you solve it?" works well to make them think, and engage them. You can then have a discussion about the problem and really allow yourself to show how you think and engage with someone. It stops being an exam/quiz setting.
In a similar vein, you want to answer in a way that shows you've solved the problem, or something similar before, in a real setting. So, rather than just providing the book answer, you can say something like: "Well, that's a similar problem to one I had when I was at X, and we solved it by doing Y, and my responsibility there was Z.". This shows that you were genuinely part of the solution, and can work in a team, and have real practical experience that's worth hiring you for.
I find it helps as well, in both the above scenarios, to highlight the problems you had, and how you overcame them. Especially in a technical field, the majority of what you'll be doing is problem solving, so demonstrate that ability.
Use open ended questions to demonstrate what you're passionate about and know really well. Call it out and explain what in the exercise you really enjoy, then explain your most recent tips, techniques, and things you've been experimenting with. Passionate people come across really well, and it's much easier to talk about something you love, it removes some nerves and mental blocks. It also them demonstrates (again), your capacity to learn, grow, and improve.
All of the above help you bring your humanity, as well as you tech skills, and show you can be a great help and contributor to the team they're hiring you for, and get you away from having to just rote repeat book answers to standard questions.
Finally, some smaller items:
1. If you need a second to think, have a drink. I always try to make sure I've got at least a bottle of water, so take a sip, and it'll give you a minute to think, to breathe and to relax.
2. You can always just say, let me think about that, and ask for a whiteboard, notes, etc. So many candidates we interview don't, and it hurts them. In the past I've taken to pushing people to take notes and write things down to keep their thinking in order.
>In the past I've taken to pushing people to take notes and write things down to keep their thinking in order.
At analyst events, a former IBM exec who ran one of their major business units would always write on index cards during Q&A. Assuming he was actually writing something, it is a way to avoid the awkward "What was the second part of your question again?" But it also gives you some time to get your thoughts in order,
Great advice. Especially practice interviewing and keeping skills up. Alas, the interview barriers set up by many companies would leave them without staff if applied to their current employees.
Another thing I found quite common in these people who can easily get a lot of great offers is that they keep writing things down, so that they never forget what they have learnt. A blog for digestions and summarizations is very usefully and can help a lot.
“Keeping those skills sharp even when you’re not job hunting.”
It’s so tiring to continue to see this.
If the “skills” you need to keep sharp are not the same thing as the skills you exercise through your job, that’s a giant red flag that the hiring company should be avoided.
If you’re practicing leetcode or Kaggle in your spare time to pass interviews, you need to stop and realize you’ve set up your goals completely backward and you are actively helping companies to commoditize your labor product and short change you on poor job quality or experience building.
If you don’t reject companies when they try the algorithm hazing crap that has no bearing on the real day to day job of software engineering, you are setting yourself up to fail and burn out, with crappy resume experience and nothing but perpetual leetcode skill to show for it.
>Again the statement that most engineers are introverted is in no way defensible and its insulting to try and group us all together like that.
Of course its defensible. From the abstract: "Engineers scored higher on Tough-Mindedness and Intrinsic Motivation; but lower on Assertiveness, Conscientiousness, Customer Service Orientation, Emotional Stability, Extraversion, Image Management, Optimism, Visionary Style, and Work Drive."
The advice of going on interviews semi-regularly is one that I tell everyone soliciting advice (even my direct reports, though only once and only if conversation veers that way!).
I don’t mean the leetcode hoops (etc, though that is part of the game) but once you’re in the door.
It’s a unique skillset that degrades fast, not unlike dating skills.
> It’s a unique skillset that degrades fast, not unlike dating skills.
It's crucial to continue dating while you're in a relationship. Especially a long-term relationship, which can cause your dating skills to become very rusty.
Haha, the similarities are more than I thought at first: That's a thought process that you would think when you are young and naïve. Playing the "dating" game. But as time passes, you just stop bothering and the "dating game" becomes just natural interactions.
Same with job-seeking, as time passes by I find myself more and more reluctant to "play the game". To the point that I won't proceed with a job process if it requires me to jump those stupid hoops (my 2 last jobs, 3 and 7 years ago I got without a real technical interview, and they were both highly technical). This means that right now jobs that I get will be "limited" to people I know and people who knows me.
As a head of engineering, right now I am trying to convince a good friend of mine (and amazing technologist) to join my team. I wouldn't dream of putting him through the "normal" that other general candidates go through.
Well, actually I'm in a long-term polyamorous relationship and my partner keeps telling me to go do this because I haven't felt much like dating this year!
Imagine if a Brain Surgeon was quizzed on Liver anatomy every time they wanted to interviewed for a job. It makes no sense and is borderline irrelevant to their actual job of you know doing brain surgery.
> Imagine if a Brain Surgeon was quizzed on Liver anatomy every time they wanted to interviewed for a job.
If software developers had the kind of exams getting initially licensed, and the ongoing continuing education requirements imposed to maintain their licenses, that regulated professions tend to have (doctors, lawyers, nurses, even schoolteachers), then they probably wouldn’t have every hiring process trying to compensate for the absence of such prior screening.
I would however imagine them to need to be able to show good skills at communicating the things they actually do, and being good at communicating that is in itself a skill that they will not necessarily use on a daily basis.
>I would however imagine them to need to be able to show good skills at communicating
Yes, that's called an interview. No one is saying there is no need to interview... So you seem to agree that leetcode style questions are irrelevant and pointless?
Yes, I do, but the comment you replied to above also made the point that those kinds of questions are not the primary reason why you need to practice interview skills, so it's an odd thing to focus on.
Doctors routinely need to update their certification by taking a formal exam; which includes subjects that they never except when studying for said exam.
You don't need technical screenings when just getting through the front door involves passing a rigorous certification process.
> If the “skills” you need to keep sharp are not the same thing as the skills you exercise through your job, that’s a giant red flag that the hiring company should be avoided.
Lots of people want a job slightly different to or at a higher level than what they currently do, so they don't get to exercise the skills they will need at work and practice them at home instead.
I don't get why people here are so hostile to people investing their time to try to better themselves and achieve their goals.
If that can help you move up your annual salary significantly and make you better at handling arbitrary challenges, then it is exactly "Bettering oneself".
Before practicing you were worse, and afterwards have improved.
If Leetcode is all you can think of to do to learn and practice skills then you've got a poor imagination.
One side project I did in my spare time outside of work got me onto my PhD and has literally saved people's lives. People here probably think that's a waste of time and I should have just lazed about instead.
> If Leetcode is all you can think of to do to learn and practice skills then you've got a poor imagination.
I think the point is that real-world experience often doesn't translate into Leetcode skills, meaning that you have no choice but to devote time to the otherwise-useless[0] skill of solving Leetcode problems. If making a cool side project, etc. was what helped most software developers get better at interviews, "people here" wouldn't be complaining in the first place.
Sure, you are learning something by solving Leetcode problems, but not anything useful[1] except in the artificial world of software interviews.
[0] This is probably heavily dependent on the specific jobs in question—I'm only speaking from my personal experience.
The best paying tech jobs I’ve had did not ask leetcode style hazing questions. I earn more and feel more valued at a mid size e-commerce company than I ever did previously working for FAANG or quant finance forms.
I think the high wage allure of those companies only applies to very junior engineers. Once you have 4 years of experience, if you’re good, lots of places will pay FAANG levels of total comp, and most won’t put you through leetcode hazing or stick you at the back of a thousand-engineer wait line for interesting projects.
Are you in the US? There’s not many companies outside of FAANG (and the FAANG-alike like Uber and Snapchat) that pay software devs with 5-10 years of experience over $300k/year. Perhaps financial companies in NYC?
I am in the US. Most midrange ecommerce companies will meet that total comp. I’ve had total comp north of that working for not-name-brand stock photography companies, education tech companies, payment processors and online shop / storefront companies.
It's not just about "algorithm hazing" but about presentation and communication skills that are often not a big part of the job of especially lower level developers, or at least not assessed in the same way.
Keeping your communication and presentation skills sharp will not just benefit you in finding a new job, but also in advancing where you are, but you're rarely fired if you fail to improve at it.
If I was going to judge dev interviewees solely on presentation and communication I'd have hired FEWER people than I have using algorithm questions as well.
If you're junior, and you can't tell me anything interesting about the work you've done in the past, but can at least write some code quickly to solve some sample problems, you've at least shone something.
If you're pretty experienced, though... not having much you can talk in depth about is a bigger flag.
> Your mad technical skills no longer matter to them. If anything, humility and an openness to learning will show you in the best light.
Your technical skills no longer matter? So someone without technical skills, but the humility and willingness to learn is what they are looking for? Is that why these companies want CS graduates? Is that why they run interviewees through technical quizzes?
How about technical skills are just as important, but also are humility and willingness to learn? How about they were always important? Since when were humility and willingness to learn not important in the tech industry? The guy just rehashed industry interview talking points that have been around forever. The only thing new in the articl is "technical skills no longer matter. Which is nonsense.
Also, nothing more humble than bragging about getting offers from google, microsoft and stripe. That headline screams humility.
The most important interview skill, however, is being able to effectively communicate and present that wisdom, because otherwise the interviewer will not know you have it.
That is a skill a lot of developers practice way too little. It's also a skillset that is increasingly valuable if you want a promotion.
It's interesting how so many of the responses here assume that the skills people should keep sharp are narrow technical skills. I'd expect a developer to keep their technical skills sharp as part of their day to day job. That's not the most important reason to practice interviewing; the most important reason is to know how to sell those skills.
I know lots of techies dislike having to know to sell themselves, but the reality is that hiring managers can't read minds, so selling your skillset is part of the job, but one you don't use very often in many jobs.
I don’t believe in generalists. Everyone has interests and strengths that over time move them in a direction to specialization. To say one codes both the front end and back end of a web site is about as general as I’d accept.
Example, game developers and financial systems engineers have very little shared domain knowledge and would require a huge amount of context switching on the order of months.
Mobile engineers also rarely want to work on server code. The tooling, the languages, the UX, they don’t even intersect on a vin diagram. Tools like react-native try to work around this discrepancy, but it’s few and far between.
I prefer to be specialist in some areas and generalist in the periphery. e.g. I am excellent in distributed systems, Networking and FS, and have decent knowledge of web services, aws and kubernetes. I don't have any idea about embedded systems, mobile development and have no intention of acquiring that.
I can see this, and come to think of it, my hires have this shallow, gravity-well type of expertise. few strong areas, and large swath of general knowledge.
I interviewed a lot last year at FAANG, and my biggest takeaway was that the recruiter is your friend. Understand what they are looking for and make their job easier - and they will be your biggest advocate.
It helps to understand what their job is exactly (and their success metrics) depending on where you are in the process.
For example, early on you may be dealing with a sourcer whose job is to fill the funnel with qualified leads - while later in the process you may be dealing with someone whose job is to close the deal (get you to accept that offer).
Communication is key. Do not hesitate to ask for advice, for guidance every step of the way, and ask how you can make the process easier - and it will become easier for you.
One important thing I want to note for chronic "interview preppers":
The interviewer wants to get to know you, not the interview you! They want to understand what it would be like to work with you and how you tackle new problems. It is therefore of very little use to them if you just have boilerplate answers to throw back at behavioral questions and/or if you already know the answer to every technical problem off-hand. Assuming your job will involve creative problem solving struggle, displaying some of that in the interview is a bonus (although it's of course up to the interviewer to tailor the problems accordingly). You probably won't be rejected for doing too well on the technical part, but don't hide your personality and technical aptitude behind walls of preparation.
> "Remember, never let them see you sweat" Vince told me. But when the stakes are low and you’re having fun, who sweats?
This can backfire. It's great if you enjoy tackling the interview problems, and sincerity is great, but indifference is not a good look.
> And as an interviewer, I can attest: sincere interest is always a good sign.
It always surprises me that these articles do so well on HN. I would assume the people who want to be in the corporate giants are, and the rest of us... don't want to be? No offence to Google, but I just don't want everything that comes with being at Google. As for the advice, I think the better, more general advice really should be "If you want a job at Google, make the people at Google want to work with you" - it's not difficult to understand what that means, you need to be smart, you need to be someone people want to work with. That's all.
When people give the advice, oh well you need to be willing to learn? That's not advice for an interview - when you arrive on your first day you actually need to be willing to learn.
The success rate at Google has nothing to do with how many people on HN want to work there, and the artcile provides a pretty confounding factor - that 0.2% success rate includes people applying to interviews for practice. Personally I don't think that many people applying to Google are in that 99.8% because they don't know how to learn during an interivew, it's because their application got scrapped on review stage.
This is something I have never done before my most recent job search but it has been a huge help. Previously all my interview prep was on tech and I pretty much winged it for the behavioral stuff since interview prep guides seem to always focus on the tech side. Plus it always feels worse and more obvious when you struggle with or fail to properly answer the tech questions.
What I did is I prepared 10 different stories about my career experience and then tagged them with a bunch of prompts. For example I have a story about one project that had dual PMs that experienced a lot of scope creep and eventually fizzled on release. I can now use that story to answer a broad range of questions from failure to various project management approaches. Overall I now have prepared stories to answer probably 50-75 different questions immediately.
Another benefit is that I have also told these stories multiple times in interviews now and I get better telling them each time. Even if the answer isn't 100% relevant, I feel more confident and likely come off better launching immediately into a detailed story about my experience rather than trying to awkwardly come up with an answer on the fly. It is also easy to drop irrelevant parts or expand on specific details when the basic framework of the story is already something that feels natural.
I will even have the document with all the prompts and story bullet points open whenever I am doing phone or remote interviews. I could probably even create a cheat sheet to use for in person interviews since I usually would bring an executive style notepad with me anyway to interviews to jot down notes about the company.
Maybe this is obvious advice, but I think I am relatively smart and never done it previously or even seen this approach recommend so I am guessing there are other people who could use this tip.