111–120 of 372 posts
Earlier quoted context omitted.
You usually have to be the first mover and be willing to give them a number you’re looking for.
Never give the first number https://news.ycombinator.com/item?id=24588379
Earlier quoted context omitted.
Never give the first number https://news.ycombinator.com/item?id=24588379
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.
There is no objective measure and you likely underestimate what you are "worth" to some companies.
As a consultant it might be different because roles are different and you aren't really talking to HR at that point, e.g salary negotiation
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 che…
> Job Title and Salary "Compensation will depend on your experience"
Earlier quoted context omitted.
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.
> 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.
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.
> 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 interac…
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 Amaz…
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.
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.
Earlier quoted context omitted.
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…
>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 seem…
Earlier quoted context omitted.
> 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.
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.
"Did their solution to FizzBuzz coded within 20 minutes produce the correct output?" has far fewer mines than "did they communicate clearly throughout?"
Earlier quoted context omitted.
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.
> 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.
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…
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.