Don’t do interviews, do discussions(thinkingthrough.substack.com)
thinkingthrough.substack.com
Don’t do interviews, do discussions
https://thinkingthrough.substack.com/p/dont-do-interviews-do-discussions
431 comments
> Life's too short to be stuck with mediocre employers.
Billboard worthy quote right there.
Billboard worthy quote right there.
At the risk of sounding cynical it sounds exactly like a slogan that would appear on billboards for one of those low-rent employment agencies.
I get what you mean, but I totally agree with the message itself.
> you're not going to advance your career at a place you don't do your best in
Hard disagree. I've worked at a lot of places where I was frustrated, didn't give a damn and felt like I was completely underperforming. And yet, my career has been advancing both in terms of title and earnings. So, unless you have a different metric for "advancing your career" I disagree.
That being said, I agree with your main point :)
Hard disagree. I've worked at a lot of places where I was frustrated, didn't give a damn and felt like I was completely underperforming. And yet, my career has been advancing both in terms of title and earnings. So, unless you have a different metric for "advancing your career" I disagree.
That being said, I agree with your main point :)
You can advance your title and earnings while also simultaneously not lose your will to live.
I've done the whole money+title things at places where my work barely made any impact. You'll pay for it later on; 40+ hours of weekly grind takes a toll on your mind and body.
I've done the whole money+title things at places where my work barely made any impact. You'll pay for it later on; 40+ hours of weekly grind takes a toll on your mind and body.
I dont disagree. The parent's only metric was "advancing your career". Not being happy or feeling fulfilled or anything else.
If the only thing you focus on is career advancement, you don't need to be at a great place that makes you the most productive.
If the only thing you focus on is career advancement, you don't need to be at a great place that makes you the most productive.
Agreed with this.
Oftentimes, you even _have_ to painfully grind out advancements in your career from unfulfilling, unhappy places, because amazing jobs aren't abundant and you have to eat (and also you have to have experience and a resume to apply for amazing jobs).
Oftentimes, you even _have_ to painfully grind out advancements in your career from unfulfilling, unhappy places, because amazing jobs aren't abundant and you have to eat (and also you have to have experience and a resume to apply for amazing jobs).
But how do you know you wouldn't have advanced more if you'd been doing better?
It seems sort of trivially true to me, excepting any workplaces that are simultaneously soul-sucking and growth-prospect-full, in such an outsized way that it's better to underperform there than overperform elsewhere...
It seems sort of trivially true to me, excepting any workplaces that are simultaneously soul-sucking and growth-prospect-full, in such an outsized way that it's better to underperform there than overperform elsewhere...
Irrelevant. The parent didn't say "optimally advance your career".
Not the main topic of the article, but in my opinion an interview/discussion also is supposed to answer another (third) question:
Does the company fulfill the expectations of the potential employee?
Not only the candidate has to sell their own service/skill during the interview/discussion, the company is being evaluated, too.
This so much. This would be on the syllabus of the missing Employment 101 course. Very few people I've seen try to evaluate the company as much as they're being evaluated.
We all grow up with the false, ingrained assumption that it's some sort of one-way privilege for you, the employee, to rent your time/body/mind to the employer.
We all grow up with the false, ingrained assumption that it's some sort of one-way privilege for you, the employee, to rent your time/body/mind to the employer.
That’s because in most interviews for most people the company holds far more power than the applicant.
For those who have done well in tech and don’t need to take the next job offered to pay for the next months food bill, because they have the savings, because they have 2 or 3 offers already, we may have the luxury of interviewing the company.
Most people aren’t in that situation, especially early in the career
For those who have done well in tech and don’t need to take the next job offered to pay for the next months food bill, because they have the savings, because they have 2 or 3 offers already, we may have the luxury of interviewing the company.
Most people aren’t in that situation, especially early in the career
I'm not sure why but it seems that most of my "interviews" end up with me asking lots of tough questions along with the reasoning behind my questions. I end up leading the discussion. I don't have numbers but it seems I get offers when I take the lead and ask tough questions about the business, what challenges exist, and how the interviewer deals with them. Anecdotally when I've been passive in the past I've not moved forward in the process.
On the flip side, when doing the interview and when I'm answering/explaining something to a candidate, I'm not really able to think ahead to the next tougher question in a chain of questions. I wonder how that impacts my assessments. I used to do 3-5 interviews per week, it is a shame I didn't take notice of this and compare to the group's consensus and outcome.
On the flip side, when doing the interview and when I'm answering/explaining something to a candidate, I'm not really able to think ahead to the next tougher question in a chain of questions. I wonder how that impacts my assessments. I used to do 3-5 interviews per week, it is a shame I didn't take notice of this and compare to the group's consensus and outcome.
Discussion will only be possible/advantageous if the interviewer decides to engage in a less strict and structured approach. I've had interviewers sticking to very specific questions and wanting very specific answers (not necessary what they needed to know me, but what they wanted to complete a form).
A discussion means an organic, constructive exchange. If anyone is too stuck-up, it way not work well.
Obviously getting to know the candidate through discussion is best.
A discussion means an organic, constructive exchange. If anyone is too stuck-up, it way not work well.
Obviously getting to know the candidate through discussion is best.
I've been involved in interviews for new hires a couple of years now. I'm pretty sure I could have the interviewee talk about cucumbers for 10 minutes and I could determine if its a good hire or not. It's all about getting insight about how the person thinks.
To be honest I sometimes get better signal from things like cucumbers than I do with technology. Tech has a real issue with biasing towards people who happen to have worked on a particular topic, and as we all know we get bounced to unfamiliar topics constantly.
If I'm kind of stiff in conversations with strangers but decent at programming, does that mean that your company doesn't have a place for me?
Are you stiff when talking about programming? Regardless what you're talking about, you're going to have to work with a team and communicate the problems at hand. I think that's really the crux of "having a conversational interview". Can you communicate technical things, both broadly and in depth, effectively.
Not the OP, but I have a similar experience. Being “stiff in conversations” is not really enough detail to answer the question. I don’t care about whether people are social butterflies. I care about whether they can accomplish the work as a part of a team. I know that sounds cliche but it’s the truth. I just want people who are accepting to feedback, don’t act unprofessionally, and can effectively work in a team.
Accepting feedback, but also providing feedback, also asking for it. So being able to initiate a conversation when needed is an important skill.
The problem with "decent at programming" is that it's often only a fraction of the job. You rarely get formal specifications and clear orders. Nearly everything involves discussion of the user's needs or eliciting the circumstances of a bug.
Real programming is very little like they teach in school and even less like coding competition. Being good at programming is great, and mandatory, but if you can't also have a conversation then you can't actually do most jobs.
Real programming is very little like they teach in school and even less like coding competition. Being good at programming is great, and mandatory, but if you can't also have a conversation then you can't actually do most jobs.
In my experience there's a big difference between an interview and talking/communicating/collaborating with coworkers. I don't think that you can use one as a reliable predictor of the other.
I think that's the point of TFA. You can never predict perfectly but it might be a closer approximation than a traditional interview.
At least you're talking about programming, something you should know about. In the actual job you'll have to talk about the subject domain, which you aren't always an expert in.
At least you're talking about programming, something you should know about. In the actual job you'll have to talk about the subject domain, which you aren't always an expert in.
> I don't think that you can use one as a reliable predictor of the other.
It's pretty hard to claim that there's no signal from this kind of interview.
Candidate A: was able to have a conversation with me, asked good questions, explained their thinking well, was easy to follow, etc.
Candidate B: seemed to not understand what I was saying/asking, his answers were rambling and incoherent, and unless I led the conversation he just sat there in awkward silence.
You can't make a prediction about which of these is more likely to communicate well at the office?
It's pretty hard to claim that there's no signal from this kind of interview.
Candidate A: was able to have a conversation with me, asked good questions, explained their thinking well, was easy to follow, etc.
Candidate B: seemed to not understand what I was saying/asking, his answers were rambling and incoherent, and unless I led the conversation he just sat there in awkward silence.
You can't make a prediction about which of these is more likely to communicate well at the office?
All else being equal on paper, the better their social skills the worse all their other skills will be since otherwise the guy with social skills would have had a way stronger career than the guy without and then they wouldn't be equal on paper.
The problem is the halo effect here. Candidate A has likely gotten preferential treatment throughout their entire life thanks to his social skills, possibly all the achievements they listed were just because they were good at talking and never had to perform in previous jobs? While if candidate B has similar achievements but acts like that then you know he earned them, since nobody would give such a guy a pass unless they knew their shit.
On average a new employer will rate the persons work the same as the persons old employers, since these are the same set. So if both the socially savy person and the socially inept person got the same rating at previous employers, then you should expect to rate these two the same as well. If in these cases your process prefers the first over the second then you will over select for social savviness and under select for technical acumen.
The problem is the halo effect here. Candidate A has likely gotten preferential treatment throughout their entire life thanks to his social skills, possibly all the achievements they listed were just because they were good at talking and never had to perform in previous jobs? While if candidate B has similar achievements but acts like that then you know he earned them, since nobody would give such a guy a pass unless they knew their shit.
On average a new employer will rate the persons work the same as the persons old employers, since these are the same set. So if both the socially savy person and the socially inept person got the same rating at previous employers, then you should expect to rate these two the same as well. If in these cases your process prefers the first over the second then you will over select for social savviness and under select for technical acumen.
> gotten preferential treatment throughout their entire life thanks to his social skills
First, I am talking about communication skills, the ability to receive and present information.
Second, this skills can be practiced and developed, it's not something you have or don't have. I assume that the person who is presenting well, does it because they put effort into it.
Third, I don't get this "all else equal" thing. I don't have access to their rankings from their old boss, nor do I have reason to expect their old jobs required the same thing my role does. Maybe their boss "did their talking" for them. Maybe someone gave them a spec and they just implemented it without any back and forth. But that wouldn't fly here.
First, I am talking about communication skills, the ability to receive and present information.
Second, this skills can be practiced and developed, it's not something you have or don't have. I assume that the person who is presenting well, does it because they put effort into it.
Third, I don't get this "all else equal" thing. I don't have access to their rankings from their old boss, nor do I have reason to expect their old jobs required the same thing my role does. Maybe their boss "did their talking" for them. Maybe someone gave them a spec and they just implemented it without any back and forth. But that wouldn't fly here.
This right here is the kind of company any self-respecting engineer shouldn't join unless they are transparent about the fact that they have issues with their processes/don't have people to deal with these issues that they need your help.
If they have a whole arsenal of project managers, architects, product managers, engineering managers, business/product analysts and still give this kind of lousy excuse, I'd probably stay away. Chances are they don't have any real expertise in the domain they are working in.
And btw, requirement gathering and writing technical specifications are taught in school.
If they have a whole arsenal of project managers, architects, product managers, engineering managers, business/product analysts and still give this kind of lousy excuse, I'd probably stay away. Chances are they don't have any real expertise in the domain they are working in.
And btw, requirement gathering and writing technical specifications are taught in school.
At least in SV, not having the support staff to fully insulate engineers from these kinds of conversations is the norm, not the exception. If you are a run of the mill senior engineer at the highest paying companies in the the area you're expected to be able to have these conversations. My experience is that exceptions are only made for people who are true technical wizards.
Project managers, product managers, etc. are still human beings. They can insulate you from the users themselves, but they still rarely turn everything into formally specified requirements. The job still involves a lot of discussions with co-workers, managers, etc. about exactly what it is that needs to be done.
It even shows up in the code. Code will one day be read by another human being, for maintenance, and maintainable code is often more important than mere correctness.
It even shows up in the code. Code will one day be read by another human being, for maintenance, and maintainable code is often more important than mere correctness.
To the contrary, I avoid any company that has an arsenal of project managers insulating me from the problems I'm solving. I don't want to be trapped in a cubicle churning out code. We all have preferences about the types of teams we like to work with.
In all likelihood, you've rejected phenomenal candidates and you didn't even realize it.
This is why I have candidates do a take home. We’ll (speaking across entire career not just current employer) have people who do mediocre in the video interviews but then turn in a great take home submission. Not everyone performs their best on the spot. I’ve hired so many talented people just by trying alternative formats to the traditional “today you’re gonna interview with 6 people hope you did your leet code.”
But did they hire any terrible ones?
This is the thing I most hate about being an experienced interviewer. I've interviewed hundreds of people. Am I getting better? Who knows! I get no feedback. I can find out whether other interviewers come to the same conclusions that I do, so I can learn to conform, but I will never find out if the person I rejected would've been fine, and I won't even find out if the person we hired did well.
How can ANYONE confidently proclaim that they're great at interviewing without some way of measuring the people they reject?
How can ANYONE confidently proclaim that they're great at interviewing without some way of measuring the people they reject?
Google still hires people even if one interviewer rejects them, so at least the people doing statistics there knows the difference between having 1 rejection, no rejections and how well each interviewer performs.
But I agree, I interviewed some at Google and we can see the stuff that happened in every other interview. And I was really surprised many times, ultimately I realized that I can't really make good judgements based on an hours worth of data and stopped caring.
But I agree, I interviewed some at Google and we can see the stuff that happened in every other interview. And I was really surprised many times, ultimately I realized that I can't really make good judgements based on an hours worth of data and stopped caring.
I'm sure you believe that, but I'd bet you don't have data. That's a fantastic way to introduce unconscious bias into the process.
I do the discussion approach, but my goal is to make sure I 'give candidates enough rope to hang themselves'. I also make extremely clear that it's ok to tell me that they don't know or aren't sure. A lot of times, I never ask the question that makes someone look bad, I just let them talk.
No interview system is good, but after cycling through many interview styles, this is the one I have found to be the least bad.
On a side note, I also can't believe tools like hackerrank report if a candidate has alt-tabbed out of the browser. I'm nearly 20 years in and I still have to look up basic syntax.
In my company we use hackerrank for the coding interviews, but more as a whiteboard, since we are not doing in-person interviews anymore. We say that syntax is not the most important thing, we are not going to run the code, and that anything they would usually check on google/SO, they can just ask us.
I usually pick some topic to do a deep dive on; I want to hear someone say "I don't know." If they can't or won't do that and just try to fill in with BS - that's a really bad sign.
"Discussion interviews" can suck because they're a lie. You're still being examined, and now you have to pretend that you aren't being examined in addition to performing well.
Some of my best interviewing experiences have been when as part of the interview I ended up having a discussion about something. But the interview didn't explicitly start with that format in mind.
Some of the worst interviewing interviewing experiences that I've had is when they say that it will be a discussion, and it is, up to the point when they spring an algorithm question out of the blue... it feels so scummy and fake. Ask me about the algorithm if you want, but mixing your question into 40 minutes of discussing other things and pretending that you aren't examining me is a farce.
The intention seems to be to make the experience more authentic and it often ends up having the exact opposite effect.
If your criteria for hiring boil down to "did I like talking to this person", you're probably not hiring well and you're allowing all kinds of biases to influence your decision. If your criteria are specific but you're hiding them behind the pretense of "discussion", you're doing everyone involved a disservice.
Some of my best interviewing experiences have been when as part of the interview I ended up having a discussion about something. But the interview didn't explicitly start with that format in mind.
Some of the worst interviewing interviewing experiences that I've had is when they say that it will be a discussion, and it is, up to the point when they spring an algorithm question out of the blue... it feels so scummy and fake. Ask me about the algorithm if you want, but mixing your question into 40 minutes of discussing other things and pretending that you aren't examining me is a farce.
The intention seems to be to make the experience more authentic and it often ends up having the exact opposite effect.
If your criteria for hiring boil down to "did I like talking to this person", you're probably not hiring well and you're allowing all kinds of biases to influence your decision. If your criteria are specific but you're hiding them behind the pretense of "discussion", you're doing everyone involved a disservice.
Discussion style interviews aren't about pretending they're not interviewing you though.
The title is "Don't do interviews, do discussions". That's repeated in the main text. The author seems to be concerned about the feeling of "I am being evaluated". I think that's counterproductive because it's false - being evaluatated is the whole point of the conversation and it's better if both sides were honest about it instead of lying to each other and playing games.
The tone of an evaluation can change the experience and isn’t boolean.
Which is another way of saying "life isn't boolean" honestly.
In context, I take it to mean "don't do the normal format of interviewing, use discussions". No amount of phrasing is going to convince you that you aren't sitting in an interview. I wouldn't want to convince you you're not in an interview anyway, that seems pretty dishonest. There's just way more value in having a (albeit can be fairly technical) discussion rather than typical call/response style of interview that consists pretty much solely of "did you memorize what I'm looking for". Particularly because I don't expect the person I'm interviewing to be a master of everything, having a discussion can lead to some common ground where we can go in deep on some of your actual previous experience.
"Interview" is ambiguous here. No matter what you do, it's always true that you're interviewing the candidate in the "assessing a candidate" sense, but you don't have to do this by interviewing them in the sense of "question and answer format you'd see a journalist use".
Exactly, if you lead with some obscure or polarizing hobby thinking its a casual discussion its a big mistake
“Hiking, trips to the beach” those are the answers. Any behavioral interview training will say the same
Everyone is lying (or actually boring and unambitious)
“Hiking, trips to the beach” those are the answers. Any behavioral interview training will say the same
Everyone is lying (or actually boring and unambitious)
I interview quite a bit of people. I always do it in a laid back, conversational style. When I ask technical questions, somewhere towards the middle or end of the session, I do it because I just want to know that the person I talked with understands some fundamentals (it's never a tricky question; just something basic like creating some threads, etc).
I talk with them about their previous work, stuff they're proud of, their hobbies and other things. I've recruited teams that excelled compared to their peers, and were certainly more fun than others.
I talk with them about their previous work, stuff they're proud of, their hobbies and other things. I've recruited teams that excelled compared to their peers, and were certainly more fun than others.
threading is your basic question at the end of an interview?
Yes, but really simple. It can get progressively worse though. Like:
1. Make a loop which counts and prints up to N
2. Now make it run in a thread
3. Now make another thread which only prints once this var hits modulo X == 0
etc
Actual fizzbuzz-level questions! Kudos for keeping the tradition alive.
You’re being examined at an interview, but you’re also examining the person you may choose to work for. If you don’t need to take the job you’re in a much more powerful position and you can have an honest discussion to come to a mutually beneficial arrangement.
I’ve never had the benefit of not needing a job while doing interviews. Doing interviews while I’m at a job isn’t viable for me.
Ah! What you describe drives me bonkers!
I’ve had interviews which start very casually, “we just want to have a high-level conversation, no crazy whiteboard coding or anything”, then, absolutely randomly in the middle of said “high-level” discussion, I get
> “well we did prepare a question to test your quantitative reasoning skills; so assume we have a bug that is detected by an analyzer with a false-negative rate of 0.3% and the probability of a bug existing at all is 7% and <sea of numbers> what’s the probability that a given test will report blah blah blah”
Of course this is communicated purely verbally.
> “This looks like a typical Bayes rule problem. Is that what you want me to calculate?”
> “Maybe, maybe not. That could be an approach. We just want the final percentage. Feel free to pull out your phone and use the calculator.”
Then of course, on the spot, I’m fumbling around with whether you divide by P(A) or P(B) or … to find P(B|A), and mucking around on a 4-function calculator like a dweeb.
So much for the “high-level discussion.”
I’ve had interviews which start very casually, “we just want to have a high-level conversation, no crazy whiteboard coding or anything”, then, absolutely randomly in the middle of said “high-level” discussion, I get
> “well we did prepare a question to test your quantitative reasoning skills; so assume we have a bug that is detected by an analyzer with a false-negative rate of 0.3% and the probability of a bug existing at all is 7% and <sea of numbers> what’s the probability that a given test will report blah blah blah”
Of course this is communicated purely verbally.
> “This looks like a typical Bayes rule problem. Is that what you want me to calculate?”
> “Maybe, maybe not. That could be an approach. We just want the final percentage. Feel free to pull out your phone and use the calculator.”
Then of course, on the spot, I’m fumbling around with whether you divide by P(A) or P(B) or … to find P(B|A), and mucking around on a 4-function calculator like a dweeb.
So much for the “high-level discussion.”
I interviewed a guy who had this approach. He seemed to think it was a great way to avoid answering actual questions, needless to say it wasn't a positive result.
There usually is not a table between us. I sometimes sit on a couch, or we both go to the balcony and talk facing the sea (balcony view:https://twitter.com/jugurthahadjar/status/145136819388953805...). If they smoke they'll have a cigarette there. We sometimes hack on a project together right there.
I use the term conversation or dialogue often to do away from discussion's root of 'breaking' or 'stomping'. I offer to make them coffee. We talk about pretty much everything. I ask questions. They ask questions.
We try to quickly get rid of the interview vibe by making them feel comfortable. We've refined this over the years.
I use the term conversation or dialogue often to do away from discussion's root of 'breaking' or 'stomping'. I offer to make them coffee. We talk about pretty much everything. I ask questions. They ask questions.
We try to quickly get rid of the interview vibe by making them feel comfortable. We've refined this over the years.
Depending on the interview I always try to make it light hearted and a discussion
One of the best times this happened is when I was being interviewed by the future manager and he said after 5 minutes you clearly know more than me and we started talking about the best places to go for a drink in the area.
I got the job and he was a fantastic manager and good friend
One of the best times this happened is when I was being interviewed by the future manager and he said after 5 minutes you clearly know more than me and we started talking about the best places to go for a drink in the area.
I got the job and he was a fantastic manager and good friend
Same! In a few situations I didn't ask a single technical question, it was just obvious they knew what they were doing and showed great insights.
> Here are some tips for converting interview into the discussion as an interviewer ...
Two ideas follow. I don't think they'll work very well.
Here's the #1 thing you can do as a candidate to turn the interview into a discussion: Come prepared with some interrogative-led questions. These usually begin with the words "who"; "where"; "what"; "when"; and "why". Then ask your questions at appropriate times. A good time might be, for example, right after you answer a question on a topic related to the question you're about to ask. Another good time might be when the interviewer asks "Do you have any questions for me?" Having been on the other side of the interviewing table a lot, it's quite surprising how few candidates have anything to ask about one of the biggest decisions they'll ever make.
The quality of your questions will determine what you get out of the interview. To prepare good question, you'll need to understand the following at more than just surface level:
- the position
- the company/group/pod
- the interviewer
Research these three things before the interview. The questions you bring to the interview should be designed to gather relevant and missing information on these points.
What's "relevant information"? You'll need some goals to figure that out. Don't set foot in the interview until you have some goals that make sense for you.
Reversing the above into a process for preparing for an interview:
1. figure out why you're interviewing at all, and interviewing at that company in particular
2. research the position, the company/group/pod, and your interviewers
3. draft questions you'll ask during the interview
4. ask your questions at appropriate times during the interview
Two ideas follow. I don't think they'll work very well.
Here's the #1 thing you can do as a candidate to turn the interview into a discussion: Come prepared with some interrogative-led questions. These usually begin with the words "who"; "where"; "what"; "when"; and "why". Then ask your questions at appropriate times. A good time might be, for example, right after you answer a question on a topic related to the question you're about to ask. Another good time might be when the interviewer asks "Do you have any questions for me?" Having been on the other side of the interviewing table a lot, it's quite surprising how few candidates have anything to ask about one of the biggest decisions they'll ever make.
The quality of your questions will determine what you get out of the interview. To prepare good question, you'll need to understand the following at more than just surface level:
- the position
- the company/group/pod
- the interviewer
Research these three things before the interview. The questions you bring to the interview should be designed to gather relevant and missing information on these points.
What's "relevant information"? You'll need some goals to figure that out. Don't set foot in the interview until you have some goals that make sense for you.
Reversing the above into a process for preparing for an interview:
1. figure out why you're interviewing at all, and interviewing at that company in particular
2. research the position, the company/group/pod, and your interviewers
3. draft questions you'll ask during the interview
4. ask your questions at appropriate times during the interview
> ere's the #1 thing you can do as a candidate to turn the interview into a discussion: Come prepared with some interrogative-led questions.
Yes, the candidate should come prepared to (1) resolve Leetcode Medium/Hard problems with obscure data structures and algorithms, (2) have a Github profile and demonstrate their side projects and (3) have best instances of their past careers to answer behavioural questions in the STAR format. In the same time, we want to demonstrate how the candidate "thinks of their feet" and now we have interrogative style questions. The way I see it - we don't really require interviewers at all. I don't see any benefit of an interviewer. We can replace them with robots.
Yes, the candidate should come prepared to (1) resolve Leetcode Medium/Hard problems with obscure data structures and algorithms, (2) have a Github profile and demonstrate their side projects and (3) have best instances of their past careers to answer behavioural questions in the STAR format. In the same time, we want to demonstrate how the candidate "thinks of their feet" and now we have interrogative style questions. The way I see it - we don't really require interviewers at all. I don't see any benefit of an interviewer. We can replace them with robots.
I tried the discussion approach instinctively in most of the interviews I performed. I tried to look at it as if both the interviewee and I are evaluating each other to see if we're a match. Kept the conversation light hearted and mostly focused on general technology trends relevant to the job. Same as if you were at a meetup or something and had just met someone new.
The only difference is that I would drill into specifics in certain areas, but keeping it conversation-style so that it doesn't feel like a pointed question. Usually I found it to be pretty easy to see a persons level of knowledge because they tend to hit a certain depth where they aren't able to keep the conversation flowing, so you have to pull back up into their more familiar territory.
The only drawback with this approach is that I have to be really mindful about potentially being biased. Pointed questions aren't as much fun but they're easier to approach from an objective viewpoint.
The only difference is that I would drill into specifics in certain areas, but keeping it conversation-style so that it doesn't feel like a pointed question. Usually I found it to be pretty easy to see a persons level of knowledge because they tend to hit a certain depth where they aren't able to keep the conversation flowing, so you have to pull back up into their more familiar territory.
The only drawback with this approach is that I have to be really mindful about potentially being biased. Pointed questions aren't as much fun but they're easier to approach from an objective viewpoint.
This is exactly how I would approach interviews too. I say "would" because I mostly do contract work and sometimes sit in on interviews when other companies are trying to hire someone. I've always thought to myself almost exactly what you wrote. I think having a low pressure conversation with someone can get you almost everything you need to be comfortable hiring someone or at least trialing them out with contract work to begin with.
You can absolutely get a good sense of their tech skills from just chatting and you can also get a decent feel for how they communicate in general which IMO is more important than tech skills once you reach a certain point.
You can absolutely get a good sense of their tech skills from just chatting and you can also get a decent feel for how they communicate in general which IMO is more important than tech skills once you reach a certain point.
> Kept the conversation light hearted and mostly focused on general technology trends relevant to the job. Same as if you were at a meetup or something and had just met someone new.
I like your phrasing. I'm not in tech and don't interview folks for tech jobs, but do interview plenty of people for technical roles in financial services (for me: insurance industry). There are lots of ways to dig into their technical skills - white-boarding, take-homes, etc. but I am often digging instead for fit.
By fit I don't mean whether a candidate has the skills. I ask questions about interests. What does the person do with their free time? Is there something they are obsessed with? What would their friends tell me they talk about way too much? What topics eat at their brains at all hours regardless of time of day. What do they do to feed their interests?
Have had the most success with candidates who come alive (or more alive) answering those types of questions. They show their drive and passion with their hand motions, facial expressions, tone, and more. It's awesome, but importantly, it IS a discussion. It's no longer Q&A to me.
And if those folks fit my other needs (e.g. tech skills, requirements for job), I hire them.
I like your phrasing. I'm not in tech and don't interview folks for tech jobs, but do interview plenty of people for technical roles in financial services (for me: insurance industry). There are lots of ways to dig into their technical skills - white-boarding, take-homes, etc. but I am often digging instead for fit.
By fit I don't mean whether a candidate has the skills. I ask questions about interests. What does the person do with their free time? Is there something they are obsessed with? What would their friends tell me they talk about way too much? What topics eat at their brains at all hours regardless of time of day. What do they do to feed their interests?
Have had the most success with candidates who come alive (or more alive) answering those types of questions. They show their drive and passion with their hand motions, facial expressions, tone, and more. It's awesome, but importantly, it IS a discussion. It's no longer Q&A to me.
And if those folks fit my other needs (e.g. tech skills, requirements for job), I hire them.
I've lately been trying to get people to teach me something as an interview.
Interviewed a guy with a PhD in organic electronics and asked him how to make an organic transistor at home. It was a great conversation, not sure yet if it was a great interview.
Interviewed a guy with a PhD in organic electronics and asked him how to make an organic transistor at home. It was a great conversation, not sure yet if it was a great interview.
I once had an interviewer ask me an obscure C++ question. I didn't know the answer, so I reversed it and asked if he knew. He did, and it taught me something I didn't know before. No, I didn't get the job. I no longer even remember the interviewer's name, but I remember well the question and answer.
When I started doing interviews I also had some C++ questions (like what is the difference between const and define and some random stuff like that), that I was always unsure about: are these things actually telling me that the person is a good C++ programmer, or am I just asking some random stuff that I happen to know?
I've finally reached a point in my career where I have a great paying job and like it well enough, and really don't give a shit what interviewers think.
Paradoxically, I think I interview a lot better. I can steer conversation towards stuff I care about, and if they insist on being annoying, just thank them for their time and leave. Though this might just be a result of being pickier about who I interview with.
If nothing else, it's _amazing_ for negotiating. "honestly I'm really happy where I am, but every man has his price, what can you offer?" does wonders.
Paradoxically, I think I interview a lot better. I can steer conversation towards stuff I care about, and if they insist on being annoying, just thank them for their time and leave. Though this might just be a result of being pickier about who I interview with.
If nothing else, it's _amazing_ for negotiating. "honestly I'm really happy where I am, but every man has his price, what can you offer?" does wonders.
I wonder how much "interviewing" is really testing the kind of performance anxiety that people without other good offers yet have.
I experience this too as I not just as I progressed in my career, but even within one batch of interviewing. I've always tried to batch as many interviews as I can. By the third interview I am feeling much less anxious and just perform much better and by the fourth or fifth I am nailing them to the wall - performance seems to be inversely proportional to how much I am worried about doing well in this particular interview.
I experience this too as I not just as I progressed in my career, but even within one batch of interviewing. I've always tried to batch as many interviews as I can. By the third interview I am feeling much less anxious and just perform much better and by the fourth or fifth I am nailing them to the wall - performance seems to be inversely proportional to how much I am worried about doing well in this particular interview.
I interview and I explicitly adjust for this in my interviews. Anxiety is not too hard to pick up on, especially if you know family and friends who have it, and I’ll give people the benefit of the doubt in the case that I do notice it.
Many people with social anxiety are excellent writers and I make sure we always have a written portion of our evaluation to give them.
Many people with social anxiety are excellent writers and I make sure we always have a written portion of our evaluation to give them.
This is really interesting! What kind of questions do you ask in the written portion?
The written portion is part of our take-home coding test. We have the candidate do a short and simple coding exercise, and at the end, there's a couple open-ended questions about their approach, what they could have done better, etc.
I find it really insightful to give people a simple exercise to complete and then ask them to talk about it. The answers to the questions are almost more telling than the code itself. You can easily see who is struggling to understand the concepts, versus someone who just didn't have much time to complete it, just by reading their responses.
Even for the same exact code, someone might answer "I completed all of the requirements", and another person might answer "I wrote this in a hurry and it doesn't meet requirement [x] all of the time, but to handle circumstances like [y], I'd implement [z]". The latter person is always a better engineer.
I find it really insightful to give people a simple exercise to complete and then ask them to talk about it. The answers to the questions are almost more telling than the code itself. You can easily see who is struggling to understand the concepts, versus someone who just didn't have much time to complete it, just by reading their responses.
Even for the same exact code, someone might answer "I completed all of the requirements", and another person might answer "I wrote this in a hurry and it doesn't meet requirement [x] all of the time, but to handle circumstances like [y], I'd implement [z]". The latter person is always a better engineer.
Yes exactly! If you need to have a take home coding test, do something simple and then use that as you discussion starter! Your developer is making decisions everyday on problems they may not have experience with. They are never making decisions in isolation without any internet connection.
If you want a job, about the last thing you are going to want to say is that you were in a hurry (meaning "I didn't care about this job enough to pay proper attention to this"). This is going to be your calling card, so it has to look great! You make it appear as if you are penalizing people for going the extra mile to complete all the requirements.
The key phrase above is:
> for the same exact code
And I’m in no position to expect candidates to treat a take-home code test like a real job. These are all experienced engineers that already have good jobs. They don’t need my job.
I 1000% prefer someone who didn’t spend much time on my code test but knows what they’re talking about, to someone who spent a bunch of time and is a bad engineer. The time constraint will be resolved when they quit their existing full time job.
> for the same exact code
And I’m in no position to expect candidates to treat a take-home code test like a real job. These are all experienced engineers that already have good jobs. They don’t need my job.
I 1000% prefer someone who didn’t spend much time on my code test but knows what they’re talking about, to someone who spent a bunch of time and is a bad engineer. The time constraint will be resolved when they quit their existing full time job.
I also do interviews, but find it is really hard to adjust for this. If a person repeatedly locks up and you give them space to come down from their anxious position for example, you simply get less signal than the person who confidently talks through their thought process the whole time and arrives at the right answer.
Is the written portion the way to offset this in your experience? In addition to being hard to squeeze into typical 45 minute interview chunks, I’m not sure that would calm my anxiety personally. But I’m certainly willing to try.
Is the written portion the way to offset this in your experience? In addition to being hard to squeeze into typical 45 minute interview chunks, I’m not sure that would calm my anxiety personally. But I’m certainly willing to try.
I’ve had some candidates who were mediocre in the verbal portion who blew me out of the water with their writing. They were clearly smart and capable people but were just anxious. I recommend these people be hired.
I’ve also had people who did great in the verbal portion completely make a fool of themselves in the written portion. They have the confidence and social ability, but they often show they’re missing the skills. They’d probably make better sales people than engineers.
I haven’t yet had someone who totally bombed the verbal do a good job in the written portion. All of the ones I’ve had were just overall poor communicators. If you can’t communicate an idea verbally or written, it’s going to be tough to work with a team of people who like to self-organize.
I don’t put the written portion in any time-block, if that’s what you’re saying. I normally give it via email and give people a week to get back to me.
I’ve also had people who did great in the verbal portion completely make a fool of themselves in the written portion. They have the confidence and social ability, but they often show they’re missing the skills. They’d probably make better sales people than engineers.
I haven’t yet had someone who totally bombed the verbal do a good job in the written portion. All of the ones I’ve had were just overall poor communicators. If you can’t communicate an idea verbally or written, it’s going to be tough to work with a team of people who like to self-organize.
I don’t put the written portion in any time-block, if that’s what you’re saying. I normally give it via email and give people a week to get back to me.
Do you really want to work for any outfit that believes that's a tactic that brings out the best in someone?
Hard pass.
Hard pass.
I really don’t think it’s what is being intentionally tested. Evaluating people is a necessarily stressful process to some extent, and it just takes a lot to counteract how different people handle it.
Just like I wouldn’t want to be written off for a place for being nervous I wouldn’t write off a place for doing the standard tech interview day-of-45-min-white boarded-questions.
Just like I wouldn’t want to be written off for a place for being nervous I wouldn’t write off a place for doing the standard tech interview day-of-45-min-white boarded-questions.
This is a really important point. Many of the best programmers I've worked with are extremely conscientious people, and I think interview anxiety goes naturally with that.
When I'm interviewing people, I work very hard to put them at their ease and discount interview anxiety when I see it. Too many interview processes are tuned for confidence, not actual skill.
When I'm interviewing people, I work very hard to put them at their ease and discount interview anxiety when I see it. Too many interview processes are tuned for confidence, not actual skill.
Thanks for being empathetic. Not everyone is lucky enough to have empathetic interviewers, and it makes it a really tough experience for them.
For sure. The upside, though, is that an unempathetic interviewer is a hint that it's not a good place to work at. So if I ever walk out of an interview feeling it was awful or unfair, in some sense it's a blessing. Better to know in the interview than after you're hired.
That's a great approach. I try to do the same thing, maybe try to get them to laugh with a witty joke or light comment to lower the stress level. I don't think it helps anybody to put candidates through stress.
For sure. I'm also explicit that the goal of the process is to see them at their best. So they should ask for accommodations. Split it into two parts? Sure! Specific time or day? Sure! Video off or on? Whatever suits you. If they want to look something up, they can look it up. I also try to give them open-ended questions so they can steer toward their strengths.
And their strengths are what I care about. Everybody has weaknesses, so finding them in an interview is uninteresting to me unless it's something truly fatal. I want to see them shine, as a) that gives me an idea of their capacity for growth, and b) that's what I'm going to play to when pointing them at work.
And their strengths are what I care about. Everybody has weaknesses, so finding them in an interview is uninteresting to me unless it's something truly fatal. I want to see them shine, as a) that gives me an idea of their capacity for growth, and b) that's what I'm going to play to when pointing them at work.
Thank you for existing and for being what you are.
Agree with this. The way I start every interview is attempting to disarm the other person and making them feel at ease. I kick back and try and make the conversation as casual and amicable as possible, even if I notice that they aren’t a good fit along the way.
> extremely conscientious people, and I think interview anxiety goes naturally with that.
No, conscientiousness doesn't correlate that much with neuroticism. You can care about the results without getting cripplingly anxious, the anxiety isn't a good thing.
No, conscientiousness doesn't correlate that much with neuroticism. You can care about the results without getting cripplingly anxious, the anxiety isn't a good thing.
I agree one can care without getting "cripplingly anxious". But you're ignoring how being anxious can definitely make you conscientious, something very helpful in work where fussbudgetry is half the job.
If you have evidence that software developers and sysadmins are no more anxious that the average person, I'd be interested to see it. But my experience is definitely different.
If you have evidence that software developers and sysadmins are no more anxious that the average person, I'd be interested to see it. But my experience is definitely different.
I had a strategy for this that I frequently recommend to people. Back when I was "in the game" and living in NYC, I used to take 1-2 interviews per month despite being happy in my then current role. I was up front with current and prospective employers about this.
This strategy served me well on many fronts: confidence in my skills and my options, familiarity with evolving interview trends, and networking opportunities with team leaders in a tight knit industry. It also allowed me to chase roles/positions which I wasn't immediately qualified for without feeling stress and anxiety, and was immensely helpful later on as an engineer turned startup CEO to know what product/project management interviews should feel like.
This strategy served me well on many fronts: confidence in my skills and my options, familiarity with evolving interview trends, and networking opportunities with team leaders in a tight knit industry. It also allowed me to chase roles/positions which I wasn't immediately qualified for without feeling stress and anxiety, and was immensely helpful later on as an engineer turned startup CEO to know what product/project management interviews should feel like.
Fascinating; how did your "open with current employer" conversations go? How did you present it? How did they react?
YMMV, software engineers can usually get away with murder.
It really all depends on how you frame it. I probably used terminology like “taking meetings with” instead of “interviewing at”. Just make sure it’s not with competitive companies and maybe more importantly not with sister companies under shared VC funds.
Honesty goes a long way, and if your employer is going to fire you because you are keeping tabs on your market value then you need a new employer anyway.
It really all depends on how you frame it. I probably used terminology like “taking meetings with” instead of “interviewing at”. Just make sure it’s not with competitive companies and maybe more importantly not with sister companies under shared VC funds.
Honesty goes a long way, and if your employer is going to fire you because you are keeping tabs on your market value then you need a new employer anyway.
I did the same thing for a couple of years here in Boston. (I stopped when I found a job I really liked and developed deeper extracurricular hobbies.) Interviewing can be fun if you have the right kind of mindset for it and you meet all sorts of people. Multiple people I interviewed with, I've run into down the road.
[deleted]
You definitely want to have a couple of warmup interviews to get back into practice, into shape. So queue up your "practice" companies first and save the ones you really want for later.
You can keep this shape up to some extent by doing a lot of interviewing of candidates at your current job. It really helps you understand what interviewers are looking for, what they expect, how a good interview should feel and flow.
But there are just some things you don't practice until your own interviews. So you'll want to have your answers to questions, and stories, and narratives all planned out. And make sure you practice them out loud, multiple times, until it's flowing naturally and easily.
And I just accept ahead of time that I'll fail 60% of the interviews that I apply for that I'd be perfect for. Sometimes things click and sometimes things don't. So make sure you've got warm leads and schedule your first rounds at an appropriate number of companies.
You can keep this shape up to some extent by doing a lot of interviewing of candidates at your current job. It really helps you understand what interviewers are looking for, what they expect, how a good interview should feel and flow.
But there are just some things you don't practice until your own interviews. So you'll want to have your answers to questions, and stories, and narratives all planned out. And make sure you practice them out loud, multiple times, until it's flowing naturally and easily.
And I just accept ahead of time that I'll fail 60% of the interviews that I apply for that I'd be perfect for. Sometimes things click and sometimes things don't. So make sure you've got warm leads and schedule your first rounds at an appropriate number of companies.
I had similar experiences as well. When there are no stakes you can be very relaxed during the interview and have all the cards during negotiations.
This is the proper way to negotiate. Most people don't do it while they have a job, only when they want one, and it puts them at a serious disadvantage.
The flip side is it will often get you dropped out of most interview funnels since you're likely to be a waste of time.
Quite the opposite. Companies fight that much harder to get a candidate they know is valuable.
That's true, if you have something to show for your value. You do sometimes get candidates who are very full of themselves but whose record track is not impressive, trying to use their confidence to skip past the interviews.
Which is fine because you arent desparate
And that may be fine. If I (rarely) respond that I’m pretty happy where I am but happy to have a chat and you vanish, shows you’re not terribly interested either.
And knowing this, if you can internalize it can maintain the advantage. I once took an extended time off working. When I realized that my personal 'runway' was running out, I didn't really have too many weeks to go through interview cycles with lots of companies. I didn't change how I interviewed and it payed off.
> I can steer conversation towards stuff I care about, and if they insist on being annoying, just thank them for their time and leave.
I like this approach. Stops you from being painted into a corner, and if you are, you can still leave with your dignity. Some interviewers can be on such a power trip, which can make things feel pretty horrible for the interviewee.
I like this approach. Stops you from being painted into a corner, and if you are, you can still leave with your dignity. Some interviewers can be on such a power trip, which can make things feel pretty horrible for the interviewee.
> Stops you from being painted into a corner, and if you are, you can still leave with your dignity.
Talk about wasting time. You are bothering to do the interview because for one reason or another you're interested in the job.
It's weird to feel good leaving the interview where you somehow saved face for yourself by not answering any of the questions. You just guaranteed that you neither get the job nor learn anything useful for your next set of interviews.
Talk about wasting time. You are bothering to do the interview because for one reason or another you're interested in the job.
It's weird to feel good leaving the interview where you somehow saved face for yourself by not answering any of the questions. You just guaranteed that you neither get the job nor learn anything useful for your next set of interviews.
Not quite. Confidence is a big part of interviewing, and having someone turn the screw on you on some esoteric topic doesn't really help build your knowledge or your confidence.
That's totally subjective. What someone may perceive as "turning the screw" could simply mean "probing deeper" or "seeing how you handle tough questions". One can get self righteous about that but it may be costing you tens/hundreds of thousands of dollars in lost earnings.
I understand your point of view, but I'm the sort of person that responds poorly to someone asserting too much authority. I've had issues with bad interviews before, where I've been rejected by someone, but then got the same job at the same firm, when interviewed by a different person.
Also, the lost earnings argument doesn't matter much if it comes at the cost of your mental health.
A bit unrelated, but there's an old joke my boss once told me, highlighting how poor interview questions/criteria can be at assessing one's ability for a particular job:
A guy goes for an interview. The interviewer tells him "forget everything you learned in your degree, it won't be useful here". The guy says: "actually, I don't have a degree". The interviewer responds: "in that case, you're not qualified enough for this job"!
Also, the lost earnings argument doesn't matter much if it comes at the cost of your mental health.
A bit unrelated, but there's an old joke my boss once told me, highlighting how poor interview questions/criteria can be at assessing one's ability for a particular job:
A guy goes for an interview. The interviewer tells him "forget everything you learned in your degree, it won't be useful here". The guy says: "actually, I don't have a degree". The interviewer responds: "in that case, you're not qualified enough for this job"!
I hear your example and I have the counter :) I had an interviewer push deep on a failure. The entire interview, maybe 45 minutes, focused on something I failed to pull off at my old job. He kept pressing me for "what else I could have done" and I kept coming up dry for most of the interview.
Two magical things happened - during this interview, I realized that I missed a huge opportunity at my previous job (in that case, the step I fell short of was escalating to the CEO) but more importantly, I got the job.
I learned later that the company put a huge emphasis on their employees, especially managers, to be self reflective and not shy away from self examination or probing by others. The point of this interview wasn't whether I could come up with an answers but whether I had the stomach for looking critically at my own failure.
So, I got the job. It paid a lot because the company had to pay for people who could pass these kinds of tests. And it was great to work with people who knew that "their shit stinks too" because they had all passed this kind of self reflection bar.
If I walked out of the interview because the questions felt uncomfortable, I would have missed out on all that.
Two magical things happened - during this interview, I realized that I missed a huge opportunity at my previous job (in that case, the step I fell short of was escalating to the CEO) but more importantly, I got the job.
I learned later that the company put a huge emphasis on their employees, especially managers, to be self reflective and not shy away from self examination or probing by others. The point of this interview wasn't whether I could come up with an answers but whether I had the stomach for looking critically at my own failure.
So, I got the job. It paid a lot because the company had to pay for people who could pass these kinds of tests. And it was great to work with people who knew that "their shit stinks too" because they had all passed this kind of self reflection bar.
If I walked out of the interview because the questions felt uncomfortable, I would have missed out on all that.
Huh, that's a really interesting story.
I can only imagine how difficult that company finds it to hire though, as a lot of people I encounter in professional settings don't seem to have this ability when applied to ther own actions.
I can only imagine how difficult that company finds it to hire though, as a lot of people I encounter in professional settings don't seem to have this ability when applied to ther own actions.
Interviews can be a valuable information-gathering exercise even if you don't want the job.
I don't really agree with your point. In the example, the candidate did the interview for as long as he/she thought it could turn into something. As soon as he/she realized that they ask questions that are completely irrelevant to the job (in his/her eyes, at least), the candidate let the interviewers know that it's not the kind of job, team, priorities the candidate wanted. Nothing wrong with that.
Wasting their time would be to continue the interview process and answer questions you think are pointless for the position at hand. It's something you can do when you already have other offers or your current position is good enough (meaning it is better than what the interviewers can offer).
When you know you won't take the job, it's okay to cut the interview short.
Wasting their time would be to continue the interview process and answer questions you think are pointless for the position at hand. It's something you can do when you already have other offers or your current position is good enough (meaning it is better than what the interviewers can offer).
When you know you won't take the job, it's okay to cut the interview short.
"You are bothering to do the interview because for one reason or another you're interested in the job."
I'm interested in learning how other companies do things, what technologies people are looking for in the industry, what sorts of questions are being asked in interviews, and what kind of problems people feel are in the domain of a particular job title. I'm also interested in compensation trends in the industry.
I can get all that information from a decent interview even if I walk away. Politely, of course! It's a matter of respect for each others' time.
I'm interested in learning how other companies do things, what technologies people are looking for in the industry, what sorts of questions are being asked in interviews, and what kind of problems people feel are in the domain of a particular job title. I'm also interested in compensation trends in the industry.
I can get all that information from a decent interview even if I walk away. Politely, of course! It's a matter of respect for each others' time.
> If nothing else, it's _amazing_ for negotiating. "honestly I'm really happy where I am, but every man has his price, what can you offer?" does wonders
My cynical self is thinking whether this is (one of) the reason why young people are preferred in our industry.
Young = Less experience in negotiating = lower wage
My cynical self is thinking whether this is (one of) the reason why young people are preferred in our industry.
Young = Less experience in negotiating = lower wage
>> My cynical self is thinking ...
>> Young = Less experience in negotiating = lower wage
Your compensation formula is completely void of the value someone can bring to the table. Young = less experienced, period. In negotiation, sure, but also in the on-the-job skills/experience/maturity. So of course they make less.
If you're a kid out of college competing with thousands of equally green kids, what would be your negotiating leverage? If you are someone 20 years in the industry with unique and proven experience, you can negotiate because you have something to negotiate with - there isn't another you.
Your compensation formula is completely void of the value someone can bring to the table. Young = less experienced, period. In negotiation, sure, but also in the on-the-job skills/experience/maturity. So of course they make less.
If you're a kid out of college competing with thousands of equally green kids, what would be your negotiating leverage? If you are someone 20 years in the industry with unique and proven experience, you can negotiate because you have something to negotiate with - there isn't another you.
I think you're right, but I think it's also true that plenty of companies either can't spot value or don't really care.
It's important to remember that a lot of execs get measured not by results, but by the resources they control. I've done contract work on projects that I could have built for 10% of the total budget. But nobody cared, because actual results were like the 4th priority, with the top three being 1) make the blowhard in charge look good, 2) make the project look big and important, and 3) provide a dramatic finish with 80-hour-weeks so said blowhard could look like he was managing very hard.
So it's no surprise that plenty of companies want cheap bodies more than they want the value of experience. And that's before we even get to the companies whose whole business model is based on hiring a lot of newbs and renting them out as highly competent bright sparks (coughaccenturecough).
It's important to remember that a lot of execs get measured not by results, but by the resources they control. I've done contract work on projects that I could have built for 10% of the total budget. But nobody cared, because actual results were like the 4th priority, with the top three being 1) make the blowhard in charge look good, 2) make the project look big and important, and 3) provide a dramatic finish with 80-hour-weeks so said blowhard could look like he was managing very hard.
So it's no surprise that plenty of companies want cheap bodies more than they want the value of experience. And that's before we even get to the companies whose whole business model is based on hiring a lot of newbs and renting them out as highly competent bright sparks (coughaccenturecough).
>> "honestly I'm really happy where I am, but every man has his price, what can you offer?" does wonders.
I would be very surprised if you say literally this and get results. No self-respecting company or manager is going to invest in talking to you if you describe yourself so overtly mercenary.
Obviously, when you're happy where you are, money is part of the equation to get you to move, but making it seem like the only motivator is super gauche and culture-centric companies (which are the good ones) would hang up on this answer.
So curious - are you actually literally saying this and people aren't hanging up on you?
I would be very surprised if you say literally this and get results. No self-respecting company or manager is going to invest in talking to you if you describe yourself so overtly mercenary.
Obviously, when you're happy where you are, money is part of the equation to get you to move, but making it seem like the only motivator is super gauche and culture-centric companies (which are the good ones) would hang up on this answer.
So curious - are you actually literally saying this and people aren't hanging up on you?
> culture-centric companies (which are the good ones)
This depends on what you are looking for.
This depends on what you are looking for.
> This depends on what you are looking for.
I am open to learning other sides here because this is so foreign to me. What are the cases where you don't want to work in a place where people care about the mission and culture and want coworkers who do as well?
What are the cases where you're happy working for the company whose attitude is "we don't care who you are and what you value, as long as you have the basic skills and are willing to take what we pay, welcome aboard?" Do such companies become great places to work and if so how?
I am asking genuinely curious because I've always looked for high culture high mission companies because that's what I am like.
I am open to learning other sides here because this is so foreign to me. What are the cases where you don't want to work in a place where people care about the mission and culture and want coworkers who do as well?
What are the cases where you're happy working for the company whose attitude is "we don't care who you are and what you value, as long as you have the basic skills and are willing to take what we pay, welcome aboard?" Do such companies become great places to work and if so how?
I am asking genuinely curious because I've always looked for high culture high mission companies because that's what I am like.
> "we don't care who you are and what you value, as long as you have the basic skills and are willing to take what we pay, welcome aboard?"
Why just "basic" skills? How does that fit in with the rest?
Why just "basic" skills? How does that fit in with the rest?
[deleted]
I'm a very mission-oriented person, so I understand where you're coming from. But there are a lot of places where people don't care very much, and people who work in those circumstances long enough tend to pick up those values.
The most obviously mercenary industry is finance. I did that for a few years and then got the fuck out. But I've met plenty of mercenary people in tech, especially in startups and BigCos. For plenty of people programming is a job like any other; they're going to come in, do whatever the boss wants (however little sense it makes), and go home. I would die from that, but a lot of people either find their meaning elsewhere or just don't care much about meaning.
The most obviously mercenary industry is finance. I did that for a few years and then got the fuck out. But I've met plenty of mercenary people in tech, especially in startups and BigCos. For plenty of people programming is a job like any other; they're going to come in, do whatever the boss wants (however little sense it makes), and go home. I would die from that, but a lot of people either find their meaning elsewhere or just don't care much about meaning.
There are plenty of people in this boat 1 the so-called “dark matter” developers. There are lots of people who find their fulfillment via means other than work, and work is a necessary evil that pays the rent. I personally couldn’t stand that kind of place, but understand why others are fine with it.
> “dark matter” developers
I like that. I'm probably one.
A few years ago, my company finally wound up my team, and brought all their development over to The Old Country (I am in the US, and it was a Japanese company). The jury's out, on whether or not it was a good idea for that company.
For me, I had plenty of investments and savings, that I didn't need to work, if I didn't want to, but I wanted to work. I love working on teams; the more eclectic, the better. I have a fairly unusual confluence of skills, experience and character that I know is quite valuable, and quite rare. I was a manager for a long time ("discussion" interviews were the way I worked). That means that I’m quite aware of the value of my skills. I’m not God’s gift to SWE, but I’m no slouch.
I also have a very big portfolio, to prove what I say. I'm not blowing up my CV with padding and BS. In fact, I had to remove a great deal of stuff, in order to keep it to a couple of pages.
I know that not everyone has a portfolio like mine, but it's what I have. It's dozens and dozens of completed, ship-ready, ultra-high-quality projects that can easily be examined, installed, built, run, and, in some cases, submitted to the App Store. There’s at least a decade of commit history, across these codebases, and a ton of documentation. Anyone can look at it. I make it very easy to find.
Couple that with many, many blog postings, training modules, essays, tutorials, etc., and you have a pretty damn good idea of who I am, what drives me, and what I can bring to the table.
You really can't get more solid than that.
In my experience, this was completely ignored, when I was searching for work. I understand the excuses that many managers use for this, and, in some cases, I can't argue against them, but, in other cases, they really missed the boat. I could have actually made a significant difference to their bottom line; especially a couple of smaller companies.
In the end, I just gave up looking, and went to work on my own. I found some folks doing nonprofit work, that looked like they could use some help, and I've been working with them, for free. I'm also making that "significant difference" that I mentioned earlier.
I have absolutely no intention of looking for work in the corporate rat race anymore. I'm quite disappointed in the zeitgeist of the modern software development industry, and don't want to darken my spirit.
It took me a few years to realize just how bad it was for me, and how much better it is, now. It would be nice to have the extra money that a continued paid career would give, but I've become used to feeling good about my work, and I work a lot.
It's like the scales fell from my eyes.
I like that. I'm probably one.
A few years ago, my company finally wound up my team, and brought all their development over to The Old Country (I am in the US, and it was a Japanese company). The jury's out, on whether or not it was a good idea for that company.
For me, I had plenty of investments and savings, that I didn't need to work, if I didn't want to, but I wanted to work. I love working on teams; the more eclectic, the better. I have a fairly unusual confluence of skills, experience and character that I know is quite valuable, and quite rare. I was a manager for a long time ("discussion" interviews were the way I worked). That means that I’m quite aware of the value of my skills. I’m not God’s gift to SWE, but I’m no slouch.
I also have a very big portfolio, to prove what I say. I'm not blowing up my CV with padding and BS. In fact, I had to remove a great deal of stuff, in order to keep it to a couple of pages.
I know that not everyone has a portfolio like mine, but it's what I have. It's dozens and dozens of completed, ship-ready, ultra-high-quality projects that can easily be examined, installed, built, run, and, in some cases, submitted to the App Store. There’s at least a decade of commit history, across these codebases, and a ton of documentation. Anyone can look at it. I make it very easy to find.
Couple that with many, many blog postings, training modules, essays, tutorials, etc., and you have a pretty damn good idea of who I am, what drives me, and what I can bring to the table.
You really can't get more solid than that.
In my experience, this was completely ignored, when I was searching for work. I understand the excuses that many managers use for this, and, in some cases, I can't argue against them, but, in other cases, they really missed the boat. I could have actually made a significant difference to their bottom line; especially a couple of smaller companies.
In the end, I just gave up looking, and went to work on my own. I found some folks doing nonprofit work, that looked like they could use some help, and I've been working with them, for free. I'm also making that "significant difference" that I mentioned earlier.
I have absolutely no intention of looking for work in the corporate rat race anymore. I'm quite disappointed in the zeitgeist of the modern software development industry, and don't want to darken my spirit.
It took me a few years to realize just how bad it was for me, and how much better it is, now. It would be nice to have the extra money that a continued paid career would give, but I've become used to feeling good about my work, and I work a lot.
It's like the scales fell from my eyes.
Having worked on teams that super duper care about the mission it isn't always roses. Why are you leaving work at 5pm or taking a vacation? Don't you care about the mission? If you aren't drinking the coolaid you don't fit in. Also I have met a fair number of people who think the mission is so important that it gives them a license to be rude. After all what are a few hurt feelings compared to the MISSION.
Where as working at a bank or a retail company no one is there because they are super into banking or selling generic household items. They are there to do good work and leave at the end of the day. They are professionals.
Where as working at a bank or a retail company no one is there because they are super into banking or selling generic household items. They are there to do good work and leave at the end of the day. They are professionals.
This is total loserthink. Saying literally that will assuredly get results.
Mature managers and owners are well aware that hiring is a commercial act and that commercial acts are about money. Signaling that you’re willing to walk from the negotiation is key to getting good compensation. Strategically, you wait until they’ve already invested thousands of dollars in labor costs interviewing you first.
Mature managers and owners are well aware that hiring is a commercial act and that commercial acts are about money. Signaling that you’re willing to walk from the negotiation is key to getting good compensation. Strategically, you wait until they’ve already invested thousands of dollars in labor costs interviewing you first.
Strategically then, wait until you are 4 months in the job, when they’ve paid the commission to the recruiter (finding and contacting interesting people is a job, paid ~20% of the gross salary), and THEN you raise the price.
Expect to receive a flying chair. If you get out of it alive, you’ll get a better salary.
Expect to receive a flying chair. If you get out of it alive, you’ll get a better salary.
I assume you’re being sarcastic, but if you change 4 months to a year and play hardball in your first review it’s not a terrible plan. This is assuming you spent that first year creating big value.
Right, if you have a good BATNA then you will actually be negotiating and not just bluffing.
I think lots of people get hung up on thinking of business interactions as personal ones, just because they have been interacting with people. Small businesses may act in more personal ways but most larger companies will generally be pretty faceless and make decisions they think are good without bearing grudges because people treated them like a faceless corporation trying to make good business decisions.
I think lots of people get hung up on thinking of business interactions as personal ones, just because they have been interacting with people. Small businesses may act in more personal ways but most larger companies will generally be pretty faceless and make decisions they think are good without bearing grudges because people treated them like a faceless corporation trying to make good business decisions.
Companies don't have self-respect and competent managers are necesserarily hypocritical, but your point is right for another reason: someone who speaks truth to power like that won't fit a typical team of hypocrites. A hiring manager would think: "if this dude disrespects my authority now, why is he going to respect it later? better to hire that less stellar candidate who at least will be manageable."
I've said a variation of it, and it works exceptionally well if the other side is also mercenary.
A mercenary working for another mercenary can be a very educational experience, and I have found that it is far easier to work with other mercenaries because they can be focused and aligned quicker than people that need to be inspired.
Honestly, if I was a hiring manager, then I'd try to only hire mercenaries keeping things professional.
A mercenary working for another mercenary can be a very educational experience, and I have found that it is far easier to work with other mercenaries because they can be focused and aligned quicker than people that need to be inspired.
Honestly, if I was a hiring manager, then I'd try to only hire mercenaries keeping things professional.
Why wouldn't that get results? If you're happy where you are then there needs to be a good reason to move. It's the interviewer/company's job to convince you to move, it's their effort being wasted.
If you're comfortable in your existing job then you are ALWAYS in the commanding seat during negotiations. If they want you then they will need to make an offer good enough. Otherwise you walk straight out and nothing changes.
Also, this isn't something you'd say on the phone. It's what you'd say during the interview, when they can't just hang up on you. You've done the interview, they ask "So, what sort of compensation are you looking for?", then you hit them with that.
If you show a weakness (a job you are actively trying to leave) then you will get lowballed. Showing that you have nothing to lose is a wall they have to scale and puts you in the best position possible for negotiations.
If you're comfortable in your existing job then you are ALWAYS in the commanding seat during negotiations. If they want you then they will need to make an offer good enough. Otherwise you walk straight out and nothing changes.
Also, this isn't something you'd say on the phone. It's what you'd say during the interview, when they can't just hang up on you. You've done the interview, they ask "So, what sort of compensation are you looking for?", then you hit them with that.
If you show a weakness (a job you are actively trying to leave) then you will get lowballed. Showing that you have nothing to lose is a wall they have to scale and puts you in the best position possible for negotiations.
If you're afraid of telling a company you'd move for more money, you've subordinated yourself and abdicated your own economic agency before negotiations even begin.
I tell every recruiter my price right off the bat and get plenty of interview offers. Unconditional devotion is reserved for my wife, who actually deserves it.
I wouldn't respect a company that expects me to stick around at below-market pay for "the culture". Tech companies already appropriate your labor on the cheap and keep the (enormous) difference. No culture makes up for that. They should at least pay market rate. I'm not a dupe.
I tell every recruiter my price right off the bat and get plenty of interview offers. Unconditional devotion is reserved for my wife, who actually deserves it.
I wouldn't respect a company that expects me to stick around at below-market pay for "the culture". Tech companies already appropriate your labor on the cheap and keep the (enormous) difference. No culture makes up for that. They should at least pay market rate. I'm not a dupe.
>I would be very surprised if you say literally this and get results. No self-respecting company or manager is going to invest in talking to you if you describe yourself so overtly mercenary.
that depends entirely on how badly they need you
that depends entirely on how badly they need you
On LinkedIn, when approached, and I am approached very often:
My very first question is: "What is the compensation range for this position?"
And if it is below what I am seeking, I say "Thank you for making me aware of this opportunity. At the compensation range you stated it is a hard pass from me. If you can come back with a realistic number I might be open to a discussion. Good luck in your continuing candidate search."
Or if they ask me what I want, I say: "I'm currently making $230k base. Can you come up with a number higher than that which would convince me to move from a job I am happy with?"
It quickly removes the time wasters and the starry eyed dreamers and the cheap skates, and the people who are serious, then we have a conversation and see where it leads. And I have plenty of conversations every month. Yes, it's effective. It's a business negotiation, and the person on the other side of the conversation either understands that inherently or is trying to convince me that my labour is worth less.
And if it is below what I am seeking, I say "Thank you for making me aware of this opportunity. At the compensation range you stated it is a hard pass from me. If you can come back with a realistic number I might be open to a discussion. Good luck in your continuing candidate search."
Or if they ask me what I want, I say: "I'm currently making $230k base. Can you come up with a number higher than that which would convince me to move from a job I am happy with?"
It quickly removes the time wasters and the starry eyed dreamers and the cheap skates, and the people who are serious, then we have a conversation and see where it leads. And I have plenty of conversations every month. Yes, it's effective. It's a business negotiation, and the person on the other side of the conversation either understands that inherently or is trying to convince me that my labour is worth less.
I said this to recruiter at $currentjob and they pay me ~50% more than the last place.
this is the way.
This is my experience as well. I no longer interview for things, I interview people who want to hire me. At this point in my career, as an engineering IC, my initial conversations are with the VP/GMs of business units.
Younger me would have been very surprised how much i actually enjoy these conversations with manager types. In my experience, _most_ of the VP GM and CEO types are much broader and more interesting than most engineers tend to believe, at least younger me.
Younger me would have been very surprised how much i actually enjoy these conversations with manager types. In my experience, _most_ of the VP GM and CEO types are much broader and more interesting than most engineers tend to believe, at least younger me.
Above a certain level of expertise, ICs are far harder to hire than management-like positions.
This is definitely surprising to younger ICs in the industry - who seem to want to become engineering managers any way they can.
The ceiling of genius you can possibly spike to as an engineer is far higher. I’ve seen single engineers at smaller startups perform the work of entire teams at big companies. And these folks get paid maybe 3x-4x the standard engineer salary. Huge savings. But hard to hire these folks.
This is definitely surprising to younger ICs in the industry - who seem to want to become engineering managers any way they can.
The ceiling of genius you can possibly spike to as an engineer is far higher. I’ve seen single engineers at smaller startups perform the work of entire teams at big companies. And these folks get paid maybe 3x-4x the standard engineer salary. Huge savings. But hard to hire these folks.
LASR, you seem to be shadowbanned, but your history doesn’t show anything weird. I vouched for this post to make it visible to everyone, but I don’t know if vouching lifts the shadowban entirely or just makes visible this particular post. You might want to reach out to dang just in case to figure this out.
I am at the same point in my career. I don't interview. I have a conversation with the person who wants to hire me. I've had two formal job interviews in the past 14 years, both at a FANG. Did not enjoy the interview experience at all. Got offers for both, and turned down both offers.
If you’re not willing to walk away from the deal then you’re not actually negotiating.
>I've finally reached a point in my career where I have a great paying job and like it well enough, and really don't give a shit what interviewers think.
I've interviewed people who have resched this point. It makes for a chill interview. In some cases, the interviewee is overly "chill" and is bored with the challenges described in the job. I prefer to hire people who are EXCITED about the challenges they will face in the job.
I've interviewed people who have resched this point. It makes for a chill interview. In some cases, the interviewee is overly "chill" and is bored with the challenges described in the job. I prefer to hire people who are EXCITED about the challenges they will face in the job.
It is much better to face boring challenges with interesting people than interesting challenges with boring people. Maybe focusing on the team would excite these kind of persons.
>It is much better to face boring challenges with interesting people than interesting challenges with boring people.
I absolutely agree. I like to work with interesting people, too.
I absolutely agree. I like to work with interesting people, too.
I don't really understand why software engineers need to be EXCITED about their profession. I don't think the same would be expected from a lawyer or a doctor.
I also think that excitement =/= passion. For example, if you look at the top chess player - Magnus Carlsen - he always looks bored talking about chess, and yet that's what he does all the time and is the best at it.
I also think that excitement =/= passion. For example, if you look at the top chess player - Magnus Carlsen - he always looks bored talking about chess, and yet that's what he does all the time and is the best at it.
Yeah, I don't care about people being excited about their job, as long as they do it well. Why would I?
>For example, if you look at the top chess player - Magnus Carlsen - he always looks bored talking about chess, and yet that's what he does all the time and is the best at it.
Serious question: Does Magnus have a team of people that he works with? Do they enjoy working with him? Do they think he is boring? Is he the type of person you want to work along side?
Serious question: Does Magnus have a team of people that he works with? Do they enjoy working with him? Do they think he is boring? Is he the type of person you want to work along side?
Yes Magnus has a team (all top players do).
Whenever I've observed him seeming bored I've assumed it comes from him being mentally so many steps in front of the interviewer. He's already evaluated all the positions, variations ad nauseum prior to being asked about them. Even if he did have something interesting to say it's unlikely he could put it into words that would resonate with the audience. I assume if he actually didn't have passion for chess he would've retired by now as his record is already good enough to be one of the all time greats.
Take the above with a grain of salt though, as it's probably just me projecting from my own experience as an IC that spends a lot of time working in a fairly specialist/abstract role.
Whenever I've observed him seeming bored I've assumed it comes from him being mentally so many steps in front of the interviewer. He's already evaluated all the positions, variations ad nauseum prior to being asked about them. Even if he did have something interesting to say it's unlikely he could put it into words that would resonate with the audience. I assume if he actually didn't have passion for chess he would've retired by now as his record is already good enough to be one of the all time greats.
Take the above with a grain of salt though, as it's probably just me projecting from my own experience as an IC that spends a lot of time working in a fairly specialist/abstract role.
> I prefer to hire people who are EXCITED about the challenges they will face in the job.
In this case your pipeline is optimized for hiring great actors.
In this case your pipeline is optimized for hiring great actors.
Or highly-outwardly energetic types.
I’m outwardly very dull, but also very willing to have a thorough and deep conversation on just about anything.
It just happens that…well…I happen to sound like Ben Stein from that scene in Ferris Bueller when I talk.
I’m outwardly very dull, but also very willing to have a thorough and deep conversation on just about anything.
It just happens that…well…I happen to sound like Ben Stein from that scene in Ferris Bueller when I talk.
Please, stop. This EXCITEMENT you cannot apply as a Golden rule. You can use it for junior position, may be junior to senior transitions but there is no sane professional with EXPERIENCE and EXPERTISE that will communicate and show excitement in a natural way. It is not logical.
When you have 20+ career, filled with success and failures, from which you can learn how to see and seek BALANCE, the last thing on your mind is excitement. You tend to see the world with realistic and moderate lens. And this is not only good for companies, this is a golden opportunity.
Sadly, more and more I look at the startups as a kindergarten party with serious consequences. Some VC's are playing the game and some lucky kids are taking this as a validation for knowledge and expertise. Selecting teams with "cultural fit" and "excitement" to fulfill a hollow visions of "changing the world".
P.S. I don't feel excitement. I consider myself a craftsman with a passion and deep love for my work. And your way of thinking is positioning you in the group of "thank you for your time" crowd. Automatically.
When you have 20+ career, filled with success and failures, from which you can learn how to see and seek BALANCE, the last thing on your mind is excitement. You tend to see the world with realistic and moderate lens. And this is not only good for companies, this is a golden opportunity.
Sadly, more and more I look at the startups as a kindergarten party with serious consequences. Some VC's are playing the game and some lucky kids are taking this as a validation for knowledge and expertise. Selecting teams with "cultural fit" and "excitement" to fulfill a hollow visions of "changing the world".
P.S. I don't feel excitement. I consider myself a craftsman with a passion and deep love for my work. And your way of thinking is positioning you in the group of "thank you for your time" crowd. Automatically.
As I near the entry into my 30s, I begin to see this more and more clearly. I used to be EXCITED about my job, about a project, about a task. It also made me very stressed and made me take things personally when they didn’t go according to “my vision”. Back then, I’d have read this sentiment as “jaded” and “cynical”. But as I mature, I find the balance, and I find truth in these words.
Oh yes. Getting genuinely excited about a project is a recipe for burnout, especially when the project doesn’t go in a direction that continues to excite you. I’d argue that an employee who can work on a project despite his lack of excitement is better than one who needs this excitement to function.
What excites me are things like enjoying time with my family, the idea of making enough money to retire in my 50s instead of 70s, working on my hobbies, and so on. Not my JIRA tickets, sorry.
What excites me are things like enjoying time with my family, the idea of making enough money to retire in my 50s instead of 70s, working on my hobbies, and so on. Not my JIRA tickets, sorry.
Thanks for your perspective. I have been burning out job after job and could never tell why. It’s like my mind was excited but my body could not go on.
[deleted]
>>I prefer to hire people who are EXCITED about the challenges they will face in the job.
Anybody who looks excited about things they they have no stake in is just pretending and is likely a ace imposter.
I'd be very vary of hiring such a person.
Anybody who looks excited about things they they have no stake in is just pretending and is likely a ace imposter.
I'd be very vary of hiring such a person.
EXCITED may be a bit overdoing it. I'm a geek, have been all my life. I've been programming since I was 13 yo. I still love what I am doing. But I am not automatically EXCITED about everything. I like my job, I care about my craft, and without false modesty, I do my job quite well. But you can't expect me be jumping all over myself at the chance of doing what I've been doing for 30+ years. I'm not a puppy anymore. There may be once in a while things I'm really interested in, and sometimes a task comes around that gets me working until late hours just because I want to figure out something tough - but you can't maintain bubbling excitement over that long, it's just not happening.
Just cause your not excited about every single problem, doesnt mean you are not excited. I a few years under you but would describe myself the same but also as never working a day in my life cause its a passion I had b4 the exchange of money. making computers do sht is only bettered by growing older and seeing them do more sht then we ever thought possible.
In addition to the points made in sibling comments, I want to point out that "showing excitement" (particularly in an interview context) can be culturally conditional. You may in fact be selecting for candidates with a European American cultural background more than anything else.
Sounds like it's just as well, the interview is a useful filter for you. Conversely, I like to work with companies tackling meaningful problems.
If I might ask, what do you do to excite your candidates about the challenges involved?
If I might ask, what do you do to excite your candidates about the challenges involved?
It's because you're coming from a position of abundance. Works wonders in dating as well. The trick is realizing you don't actually need to have abundance to take a position of abundance.
Yeah it's a much better mindset to be in to interview when you aren't desperate to leave. At my last job which I was decently happy and comfortable I still interviewed once a year just to see what was out there.
Though I was often asked "So why are you leaving?". Who said I was leaving?
But interviewing every now and then has other benefits:
- it has actually helped me become better at interviewing candidates
- a competing offer helped me get a better salary at a job I liked, so I didn't have to leave
- it kept my interview skills sharp for the next time I decided to interview
Though I was often asked "So why are you leaving?". Who said I was leaving?
But interviewing every now and then has other benefits:
- it has actually helped me become better at interviewing candidates
- a competing offer helped me get a better salary at a job I liked, so I didn't have to leave
- it kept my interview skills sharp for the next time I decided to interview
If you have a great paying job you like, why do you interview? Is it when someone cold calls you?
I'm in a similar job and haven't interviewed for years but want to start and not sure how to go about it.
I'm in a similar job and haven't interviewed for years but want to start and not sure how to go about it.
I was in a similar position. I made a prioritized list of target companies and projects, and then ‘practiced’ interviewing from the bottom up.
One surprising thing I learned from the initial interviews with my lower priority targets was that my prioritization was wrong, in terms of challenges, interests and compensation.
One surprising thing I learned from the initial interviews with my lower priority targets was that my prioritization was wrong, in terms of challenges, interests and compensation.
Doesn't mean there isn't an even better option out there :-)
Also I'd like to work on something related to tackling climate breakdown, so I'll almost always chat to companies in that space. Sadly I need to pay off some debt before I can take a paycut to work on these problems (or risk a startup).
Also I'd like to work on something related to tackling climate breakdown, so I'll almost always chat to companies in that space. Sadly I need to pay off some debt before I can take a paycut to work on these problems (or risk a startup).
The best experience I've had while interviewing is when I did not care at all about getting the job. It allows you to be genuine. Not playing the game of trying to show what they want to see but just truly being yourself.
It didn't have anything to do with my career though. It was early, I had an okay position and just encountered something really interesting and exciting.
So perhaps the learning is more about how and when you choose to go explore something that excited you rather than other reasons to find a new job.
It didn't have anything to do with my career though. It was early, I had an okay position and just encountered something really interesting and exciting.
So perhaps the learning is more about how and when you choose to go explore something that excited you rather than other reasons to find a new job.
Depends on the role and the candidate. If I'm hiring for a lower skill position and the candidate has a strong resume I just might want to verify the resume and confirm they have a basic grasp of the relevant skills.
If I'm hiring for a high-output FANG job, you bet your ass we're going to the whiteboard. Sure, I hate it too(on either side of the table), but it's not too much to ask to prove that you can think on your feet and solve hard problems if that's what the job is.
I generally tend to have discussions because I'm not very confrontational and also because I hate the modern coding interview. After moving to a FANG though, I now understand why the process is so hard. I also get that a lot of folks are frustrated because they've been told their whole career that they're smart, and they probably are, but for some roles the bar is just set higher. My 30 year old self, who thought he was hot shit because of all the praise I got for doing basic work(shake and bake linux embedded work, deep dive bugfixing, mostly writing glue code), was in no way qualified to exist in the world I (barely manage to) work in now.
If I'm hiring for a high-output FANG job, you bet your ass we're going to the whiteboard. Sure, I hate it too(on either side of the table), but it's not too much to ask to prove that you can think on your feet and solve hard problems if that's what the job is.
I generally tend to have discussions because I'm not very confrontational and also because I hate the modern coding interview. After moving to a FANG though, I now understand why the process is so hard. I also get that a lot of folks are frustrated because they've been told their whole career that they're smart, and they probably are, but for some roles the bar is just set higher. My 30 year old self, who thought he was hot shit because of all the praise I got for doing basic work(shake and bake linux embedded work, deep dive bugfixing, mostly writing glue code), was in no way qualified to exist in the world I (barely manage to) work in now.
Typical FANG employee... Hates whiteboard interviews until they get into FANG, then thinks that anyone outside of FANG is actually delusional about their skills and must whiteboard to prove themselves worthy of handling the incredibly challenging world which is FANG-engineering.
More likely that you've drank the kool aid that you are somehow special and smarter for working at a FANG...
More likely that you've drank the kool aid that you are somehow special and smarter for working at a FANG...
hfjkdh790sn(2)
Why are you so upset that somebody considers themselves smarter than you? Serious question.
Interesting that you decided that the OP:
1. Is upset
2. Interpreted the parent comment as being smarter than OP
Serious question: where did you infer these things from?
1. Is upset
2. Interpreted the parent comment as being smarter than OP
Serious question: where did you infer these things from?
> Is upset
Nobody is going to write such a rant if they're not upset.
>> Typical FANG employee... Hates whiteboard interviews until they get into FANG, then thinks that anyone outside of FANG is actually delusional about their skills and must whiteboard to prove themselves worthy of handling the incredibly challenging world which is FANG- engineering.
> Interpreted the parent comment as being smarter than OP
>> More likely that you've drank the kool aid that you are somehow special and smarter for working at a FANG...
???
Nobody is going to write such a rant if they're not upset.
>> Typical FANG employee... Hates whiteboard interviews until they get into FANG, then thinks that anyone outside of FANG is actually delusional about their skills and must whiteboard to prove themselves worthy of handling the incredibly challenging world which is FANG- engineering.
> Interpreted the parent comment as being smarter than OP
>> More likely that you've drank the kool aid that you are somehow special and smarter for working at a FANG...
???
Nope, not upset. Just trying to make OP aware of their contradictory behavior.
OP might be smarter than me, who knows. I don't really care, I feel pretty good about my intelligence level even though I know there are plenty of folks smarter than me out there.
What I am is annoyed at the elitism that OP shows. I work at a FANG, have worked at a couple SV unicorns too. There is plenty of work happening here that is not as challenging as OP makes it out to be. I've seen a lot of people with the attitude OP has and I think it makes for a toxic and unwelcoming environment.
As someone who has used complex algorithms research in my work, I agree white boarding has some carryover to some FANG work. But my experience is that there is vastly more boring CRUD work to do and you must generally fight with others to get the interesting/challenging algorithmics work. No need to filter out a ton of qualified people because they can't perform a tiny fraction of the work happening here.
OP might be smarter than me, who knows. I don't really care, I feel pretty good about my intelligence level even though I know there are plenty of folks smarter than me out there.
What I am is annoyed at the elitism that OP shows. I work at a FANG, have worked at a couple SV unicorns too. There is plenty of work happening here that is not as challenging as OP makes it out to be. I've seen a lot of people with the attitude OP has and I think it makes for a toxic and unwelcoming environment.
As someone who has used complex algorithms research in my work, I agree white boarding has some carryover to some FANG work. But my experience is that there is vastly more boring CRUD work to do and you must generally fight with others to get the interesting/challenging algorithmics work. No need to filter out a ton of qualified people because they can't perform a tiny fraction of the work happening here.
I think your biases have caused you to misread my original comment and attribute to me some beliefs with which you disagree.
> vastly more boring CRUD work
I don't do CRUD work and no one even close to my group does that. Are you a web programmer by chance? We work on systems software. If you've dealt with that I think you might agree that there isn't a lot of grunt work involved. Maybe when it comes to writing some tests but even then it can be fairly technical and require a lot of systems-level knowledge.
FWIW, I'm not saying I'm personally smarter than anyone. I got lucky and got a job working with the smartest, most dedicated and focused people I have ever met in decades of work. They're smart, and working with them requires some combination of extreme personal sacrifice, intense focus, and a deep and wide knowledge of software, hardware, CS theory and language issues.
> vastly more boring CRUD work
I don't do CRUD work and no one even close to my group does that. Are you a web programmer by chance? We work on systems software. If you've dealt with that I think you might agree that there isn't a lot of grunt work involved. Maybe when it comes to writing some tests but even then it can be fairly technical and require a lot of systems-level knowledge.
FWIW, I'm not saying I'm personally smarter than anyone. I got lucky and got a job working with the smartest, most dedicated and focused people I have ever met in decades of work. They're smart, and working with them requires some combination of extreme personal sacrifice, intense focus, and a deep and wide knowledge of software, hardware, CS theory and language issues.
I'm honestly curious to know. Can you say more about what your current work entails?
HPC programming library. It has to be fast, correct, secure and has strong compatibility guarantees so design decisions can have never ending repercussions.
Previous to this job I laughed at the goofy CS questions asked in interviews. "I've been doing this 30 years and never needed A* or a graph algorithm." I have to retract that statement now. Not that the modern coding interview isn't a little overdone, but there is a point to it.
There's also the question of dedication. When you work on a very driven team you have to show a similar level of drive or you're just going to get burnt. I'm not saying the level of work/life balance is fair or the way it should be, but it's the way it is and it has taken me quite a bit to get used to. It's a toxic environment on many levels. That said, it's by far the most impactful job I've ever had. I'm immensely grateful for the opportunity to contribute 0.0000000001 pct to some amazing work.
Previous to this job I laughed at the goofy CS questions asked in interviews. "I've been doing this 30 years and never needed A* or a graph algorithm." I have to retract that statement now. Not that the modern coding interview isn't a little overdone, but there is a point to it.
There's also the question of dedication. When you work on a very driven team you have to show a similar level of drive or you're just going to get burnt. I'm not saying the level of work/life balance is fair or the way it should be, but it's the way it is and it has taken me quite a bit to get used to. It's a toxic environment on many levels. That said, it's by far the most impactful job I've ever had. I'm immensely grateful for the opportunity to contribute 0.0000000001 pct to some amazing work.
How did you transition between the previous state you describe and when you found success getting into your current role, in terms of prepping to do that sort of testing, as well as motivation?
I'm very close to 30 now, and have been burnt out enough times that it's a struggle to imagine how I could care about tech enough to attempt to re-transition into almost only caring about sort of climbing that ladder.
I'm very close to 30 now, and have been burnt out enough times that it's a struggle to imagine how I could care about tech enough to attempt to re-transition into almost only caring about sort of climbing that ladder.
I got divorced, lost almost everything, and had to do it or accept living on sustenance net pay for the rest of my life. I really didn't want to do this. I had a cozy gig in my past life, but I couldn't make it on the engineering salary in my town.
I don't come from a CS background. I'm a EE. I just happened to get an embedded job right out of college and kept getting more and more software work. The only algorithms I'd dealt with were linked lists, circular buffers, and synchronization.
Burn out is a constant worry. I still question if my chosen path is even worth it. If I didn't still have hope of having a child someday... I don't know. I don't think I could find the motivation to keep going.
I don't try to climb the ladder. I hit a level I'm more than happy with and now I just need to try to stay on. I find I'm much more compatible with my team because I'm not trying to make the next level. I can share advice freely with the younger folks because I'm not trying to block them. On the contrary, I want my teammates to go far and kick ass.
I don't come from a CS background. I'm a EE. I just happened to get an embedded job right out of college and kept getting more and more software work. The only algorithms I'd dealt with were linked lists, circular buffers, and synchronization.
Burn out is a constant worry. I still question if my chosen path is even worth it. If I didn't still have hope of having a child someday... I don't know. I don't think I could find the motivation to keep going.
I don't try to climb the ladder. I hit a level I'm more than happy with and now I just need to try to stay on. I find I'm much more compatible with my team because I'm not trying to make the next level. I can share advice freely with the younger folks because I'm not trying to block them. On the contrary, I want my teammates to go far and kick ass.
I'll also add that the first couple of years of my code reviews were a bloody mess. It's frustrating to have people who constantly out-think you and provide better ways of doing nearly everything you come up with. I was lucky to get my foot in the door and then built my skills up even more with a lot of pain and extra hours put it to get things right. I'm a better programmer now than I ever was, but I still have so, so much to learn and practice.
Thanks for your reply. I'm sorry you had to go through that, truly, divorce is a traumatic experience unlike any other, but it does bring some solace to know I'm not the only one who's either been in or is in some sticky situations. Unfortunately I haven't been as lucky in finding something early on to build on. I was about a year and a half into my first position after diploma, and was laid-off, then terminated from my next 3 months in, then again, then again, then again. The only light in that dark being a decent python oriented thing in a research department. Reflecting on that, I might have been in over my head, too cocky as well, with really nothing to base it on other than a passing capability with programming and intense motivation to produce good results. But I was also in the wrong places that I wasn't well-suited for; a constant learning process that has taught me a bit about myself. Looking at the future seems rather bleak, as I'm sure you've felt many times, and I'm pretty much just counting on getting lucky at some point.
I am curious though, what were the more mechanical aspects of how you made that transition? Did you have a plan to practice algorithms in a certain way and then wait till you were contacted by the right recruiter? How did you go about it? Did you more simply just try and do 1 problem a day and then build that up, or did you find useful projects to apply more obscure algorithms to, that might be more interesting and motivating?
I am curious though, what were the more mechanical aspects of how you made that transition? Did you have a plan to practice algorithms in a certain way and then wait till you were contacted by the right recruiter? How did you go about it? Did you more simply just try and do 1 problem a day and then build that up, or did you find useful projects to apply more obscure algorithms to, that might be more interesting and motivating?
Mechanical aspects... I grabbed Cracking the Coding Interview. I started doing online coding tests. I started studying modern C++. I was fortunate that I had a relatively easy, 40 hour day job at the time so the nights and weekends weren't too bad. It took a few months. I interviewed with Amazon and it opened my eyes to how much I didn't know(Also, I am so incredibly glad I didn't get that job). I kept studying. I kept interviewing. I tried to think of things I would be expected to know. As an older engineer with a lot of Linux driver experience I had to refresh my knowledge of the Linux kernel's various subsystems. It was a lot of work. It helped that I've been at this game a few decades though so it wasn't like this stuff was exactly new. The algorithm stuff was, but I'd done a fair amount of Linux stuff, C++(but C++ pre 11), lots of C and Python... I wish I could say I still remember a lot of what I learned.
As far as interviews go, I think I tend to interview pretty well when it comes to social skills. Problem solving is tough. I had to do a lot of whiteboard practicing. I probably over practiced this part because, in my experience, you're not really writing tons of code on the whiteboard. Yes, you need to write some, but it's typically short snippets or pseudocode.
I remember telling my interviewers that I didn't think I was a good fit for the job. It seemed more 'CS' than I could handle. I don't know why they went with me. I know the company was rapidly growing at the time so I probably just got lucky. Not what you want to hear, I know.
As far as interviews go, I think I tend to interview pretty well when it comes to social skills. Problem solving is tough. I had to do a lot of whiteboard practicing. I probably over practiced this part because, in my experience, you're not really writing tons of code on the whiteboard. Yes, you need to write some, but it's typically short snippets or pseudocode.
I remember telling my interviewers that I didn't think I was a good fit for the job. It seemed more 'CS' than I could handle. I don't know why they went with me. I know the company was rapidly growing at the time so I probably just got lucky. Not what you want to hear, I know.
Thank you! That is a very interesting world indeed.
But, just focusing on the algorithms part of it, I never could answer how exactly a specific algorithm worked, but I've had to use many algorithms in my "normal" job. I just know "oh this needs a modified DFS, or A*, with custom heuristics, or a priority based permutations generator". I cannot answer how any of this works in detail on the fly, but I know where to look. Isn't that sufficient? I certainly would fail a FANG interview, but have gone toe to toe or even better when pow-wowing on some real problems with googlers. Wouldn't consider myself any inferior because I don't know how a specific algorithm works in the interview. Just my two cents
But, just focusing on the algorithms part of it, I never could answer how exactly a specific algorithm worked, but I've had to use many algorithms in my "normal" job. I just know "oh this needs a modified DFS, or A*, with custom heuristics, or a priority based permutations generator". I cannot answer how any of this works in detail on the fly, but I know where to look. Isn't that sufficient? I certainly would fail a FANG interview, but have gone toe to toe or even better when pow-wowing on some real problems with googlers. Wouldn't consider myself any inferior because I don't know how a specific algorithm works in the interview. Just my two cents
Is it sufficient? Depends on your interviewer and other factors. I personally wouldn't fail anyone for not knowing absolute specifics(unless they claimed to know as much). I would expect some 'algorithmic thinking' and basic familiarity. The interview is also based on a fair bit of luck. In my case, I was asked about virtual memory, and I had literally just days before done a deep dive through the Linux VM subsystem. If they asked me a week before I wouldn't have gotten the job.
When I started interviewing, I couldn't even do tree traversal. It just wasn't something I was familiar with, and never directly used in decades of coding. I don't blame Amazon for passing on me then.
> gone toe to toe or even better when pow-wowing on some real problems with googlers
I don't think making blanket statements like this is a good idea. Sure, you might be able to code better then them, but can you think of a new solution which is better than the current best practice based on some practical consideration(behavior of your HW, caching behavior, some niche use case, etc)? I think a lot of people are great coders in many ways but that's not always the skill folks are looking for. We don't necessarily crank out a lot of code, but it has to be really good code. You also are expected to come up with self-driven innovations and ways to push the industry forward. It would be nice if there was just a set of problems someone handed me and had me solve, but that's really not what they're paying me for.
When I started interviewing, I couldn't even do tree traversal. It just wasn't something I was familiar with, and never directly used in decades of coding. I don't blame Amazon for passing on me then.
> gone toe to toe or even better when pow-wowing on some real problems with googlers
I don't think making blanket statements like this is a good idea. Sure, you might be able to code better then them, but can you think of a new solution which is better than the current best practice based on some practical consideration(behavior of your HW, caching behavior, some niche use case, etc)? I think a lot of people are great coders in many ways but that's not always the skill folks are looking for. We don't necessarily crank out a lot of code, but it has to be really good code. You also are expected to come up with self-driven innovations and ways to push the industry forward. It would be nice if there was just a set of problems someone handed me and had me solve, but that's really not what they're paying me for.
That's fair. I think we are saying the same thing, it is just about what you know at that moment, rather than your true capabilities.
Also, my statement was not blanket statement, nor that I wrote more code than others. I was referring to a very specific set of problems that I was working on and not generalizing that I'm better than all googlers. There are many people who are way smarter/better than I am. I'm just saying not being in FAANG does not mean one is not good enough.
I think the interview processes put a bar on if one willing to put in the amount of specific kind of work needed to get in or not. In its own way, it is a good filter (for them)
Also, my statement was not blanket statement, nor that I wrote more code than others. I was referring to a very specific set of problems that I was working on and not generalizing that I'm better than all googlers. There are many people who are way smarter/better than I am. I'm just saying not being in FAANG does not mean one is not good enough.
I think the interview processes put a bar on if one willing to put in the amount of specific kind of work needed to get in or not. In its own way, it is a good filter (for them)
Mostly reversing binary trees obviously
> Sure, I hate it too(on either side of the table), but it's not too much to ask to prove that you can think on your feet and solve hard problems if that's what the job is.
That's a big IF.
That's a big IF.
> think on your feet and solve hard problems
> if that's what the job is.
> That's a big IF.
My experience with FAANGS is that their bar is universal. Even if you're going to a team which somehow won't require solving hard problems collaboratively under pressure, ability to do so is the bar for working at the company.
As the person you're replying to says, they use the interview style that gives them signal about this. And in general, unless one work at a FAANG and understands the roles, how does one think they have the correct perspective on how FAANG ought to be hiring for their roles?
My experience with FAANGS is that their bar is universal. Even if you're going to a team which somehow won't require solving hard problems collaboratively under pressure, ability to do so is the bar for working at the company.
As the person you're replying to says, they use the interview style that gives them signal about this. And in general, unless one work at a FAANG and understands the roles, how does one think they have the correct perspective on how FAANG ought to be hiring for their roles?
so there is no glue code at FAANG? Or you have overqualified folks doing, and getting bored, and jumping ship between FAANG every 1.5 years...
It’s perfect code with 105% test coverage and there are amazing meetings and everyone is as smart as they think they are.
Sure there's some of it, but not in my group and it's not something I'd be tasked with hiring for. Occasionally there's some infrastructure related task but I'd prefer someone on the team who actually has to use that stuff be the one to work on it.
We don't have a lot of glue code because we don't glue things together. We write the things other people glue together. That's why this is fundamentally different than 90% of anything I've ever done.
I also don't mean to say that all FANG work is like this. I could see some roles at, say, Google working on Android where it very much would be the kind of gluey work I've done before.
We don't have a lot of glue code because we don't glue things together. We write the things other people glue together. That's why this is fundamentally different than 90% of anything I've ever done.
I also don't mean to say that all FANG work is like this. I could see some roles at, say, Google working on Android where it very much would be the kind of gluey work I've done before.
There is no "this engineer should only touch glue code" and "this engineer should work on the really hard cool stuff". For category A, if something is expected to be extremely tedious drudgery, usually vendors/contractors are used rather than full time employees.
There is a lot of glue code at FAANG, but there are a lot of cutting edge libraries and services that you need to understand before you know how to properly glue them together. That is very different from mostly gluing together well documented standard public libraries.
From an efficiency standpoint, it is probably a lot cheaper to hire smarter users of those libraries than to ensure all new libraries can be used by less smart engineers. Especially since many smart engineers who can write great libraries doesn't necessarily have the ability to document those libraries well, so by removing the need for great documentation they can get a ton of such engineers that other companies with lots of mediocre engineers cannot find a good use for.
From an efficiency standpoint, it is probably a lot cheaper to hire smarter users of those libraries than to ensure all new libraries can be used by less smart engineers. Especially since many smart engineers who can write great libraries doesn't necessarily have the ability to document those libraries well, so by removing the need for great documentation they can get a ton of such engineers that other companies with lots of mediocre engineers cannot find a good use for.
There are also a lot of developers working on the internal payroll, HR activity scheduler, communications apps, among others. I still remember an interview when someone was expounding about the wonderful opportunities to work on the site that Google employees use to book yoga classes and other offerings.
That said, I understand that in the interest of fairness and allowing equitable access to the highly lucrative RSUs, it's important to give interviews equally rigorous to candidates for the AdWords team as those who end up pushing protobufs all day.
That said, I understand that in the interest of fairness and allowing equitable access to the highly lucrative RSUs, it's important to give interviews equally rigorous to candidates for the AdWords team as those who end up pushing protobufs all day.
There's glue code, but nobody wants to work with people only capable of doing glue code.
For a long time I am considering anything coming out of F an anti-pattern and an example of bad engineering.
>but it's not too much to ask to prove that you can think on your feet and solve hard problems if that's what the job is.
Because the most common say to day issue is needing to think of an algorithm on the spot...
You hate it because you know that's not true. Yet you're using it.
Because the most common say to day issue is needing to think of an algorithm on the spot...
You hate it because you know that's not true. Yet you're using it.
Should companies set their hiring bar to match the average difficulty of problems they encounter, or should they try to find people who can solve their difficult challenges?
Is your view of programming that good programmers spend the majority of their time writing boilerplate code or doing grunt work?
Is your view of programming that good programmers spend the majority of their time writing boilerplate code or doing grunt work?
Your average software developer isn't going to be solving the most difficult problems.
My view isn't that good programmers spend the majority of their time writing boilerplate code. But my view also isn't that the average programmer _isn't_ doing that.
I'd expect way more demonstrated knowledge for an interview in a higher level role than an mid level developer role. But the higher you go the less you actually need to demonstrate that. Why?
My view isn't that good programmers spend the majority of their time writing boilerplate code. But my view also isn't that the average programmer _isn't_ doing that.
I'd expect way more demonstrated knowledge for an interview in a higher level role than an mid level developer role. But the higher you go the less you actually need to demonstrate that. Why?
> Because the most common say to day issue is needing to think of an algorithm on the spot...
Are you trolling? Everything that you do as an engineer is coming up with an algorithm.
Algorithm is how you solve a problem, how you think about constraints and requirements.
Are you trolling? Everything that you do as an engineer is coming up with an algorithm.
Algorithm is how you solve a problem, how you think about constraints and requirements.
You're being pedantic. You know what I mean.
There's plenty of algorithms I know and I can see relevant business contexts to use them in. Do I know all of their implementations off the top of my head to regurgitate onto a whiteboard? No, because I don't need to. When the time comes I will just look that up. The easy part is the implementation. This isn't a school exam testing your memory.
There's plenty of algorithms I know and I can see relevant business contexts to use them in. Do I know all of their implementations off the top of my head to regurgitate onto a whiteboard? No, because I don't need to. When the time comes I will just look that up. The easy part is the implementation. This isn't a school exam testing your memory.
When was the last time somebody asked you to implement some text book algorithm?
All the FAANG interviews I had were about some leetcode problem where you had to be familiar and use some algorithm, not write it from scratch.
All the FAANG interviews I had were about some leetcode problem where you had to be familiar and use some algorithm, not write it from scratch.
Not every day, but my experience is at least every month-quarter. And since you're not primed like in an interview context these ideas need to be inside your wheelhouse to spot them within a business context. I would not describe myself as particularly technical for my org and in the past year I've made use of the following at work:
-Depth first search
-Binary Search
-Topological Sort
-Dynamic programming in a graph context
-Union Find
-Merkle Trees
-Fenwick (binary indexed) trees
Maybe I'm in an unusually technical area but it doesn't feel that way talking to my colleagues.
-Depth first search
-Binary Search
-Topological Sort
-Dynamic programming in a graph context
-Union Find
-Merkle Trees
-Fenwick (binary indexed) trees
Maybe I'm in an unusually technical area but it doesn't feel that way talking to my colleagues.
Yes, and there's plenty of times in my work where I've put algorithms to good use.
But out of all those algorithms how many could you regurgitate onto a whiteboard given 5 minutes to do so?
Knowing the use of each algorithm is good enough. You don't need to know the implementation until you want to use it. And nowhere in your day to day work is this going to be with no internet access or reference.
So why do interviewers suggest this is the case? Why aren't they just happy with you describing how a Merkle Tree can solve a particular issue. Why do you need to write that down?
But out of all those algorithms how many could you regurgitate onto a whiteboard given 5 minutes to do so?
Knowing the use of each algorithm is good enough. You don't need to know the implementation until you want to use it. And nowhere in your day to day work is this going to be with no internet access or reference.
So why do interviewers suggest this is the case? Why aren't they just happy with you describing how a Merkle Tree can solve a particular issue. Why do you need to write that down?
A friend once told me that he is interviewing Google.
I found that mindset very powerful.
And the best part, he got an offer but didnt accept it.
I found that mindset very powerful.
And the best part, he got an offer but didnt accept it.
yes! 1000x this.
don't let the power asymmetry get to you, take that attitude and you wont easily made nervous or uneasy and instead projects confidence
prepare insightful and incisive questions about how decisions are made, tech stacks, even how executives think about dev process and the business etc etc
as it turns out, many companies really appreciate the thoughtfulness!
don't let the power asymmetry get to you, take that attitude and you wont easily made nervous or uneasy and instead projects confidence
prepare insightful and incisive questions about how decisions are made, tech stacks, even how executives think about dev process and the business etc etc
as it turns out, many companies really appreciate the thoughtfulness!
I'm not even sure what an interview that is not a discussion would look like and even less sure it would provide value, especially when it comes to technical talent. There's far too much time spent on validating "can this person do X that they claim they do." That can be easily tested or validated with reference checks. What is hard is knowing if an interviewee knows when to do X, when to do Y, and can they coordinate with teams A and B to get it done.
I do that on my own show, when I interview Noam Chomsky, former regulators etc. I don’t like to fawn over them and ask the same questions as everyone. I try to bridge what they talk about and modern technology, and see if we can have a meaningful DISCUSSION about freedom of speech or sociopolitics or economics or regulations. Here are some episodes:
Economics: Thomas Greco, community currency economist https://community.intercoin.org/t/interview-with-thomas-h-gr...
Regulations: Sara Hanks, former SEC regulator and author of Regulation S https://community.intercoin.org/t/interview-with-sara-hanks-...
Freedom of Speech: Noam Chomsky, sociopolitical commentator and linguist https://community.qbix.com/t/freedom-of-speech-and-capitalis...
I don’t hold back, in the Noam Chomsky discussion I accuse him for example of having a lot of social capital (followers and influence is a form of capital that is convertible to other forms) and he brushes it off. Overall the discussions tend to focus 99% on substance, and deal with the Web, Social Platforms, Blockchain and Cryptocurrency, how they can change the world and the issues surrounding them.
PS: I know that for now no one has heard of Intercoin or Qbix or my interviews and I am OK with that. Eventually it will be discovered once our products are more mainstream. I am looking forward to interviewing Edward Snowden and a few other people next.
Economics: Thomas Greco, community currency economist https://community.intercoin.org/t/interview-with-thomas-h-gr...
Regulations: Sara Hanks, former SEC regulator and author of Regulation S https://community.intercoin.org/t/interview-with-sara-hanks-...
Freedom of Speech: Noam Chomsky, sociopolitical commentator and linguist https://community.qbix.com/t/freedom-of-speech-and-capitalis...
I don’t hold back, in the Noam Chomsky discussion I accuse him for example of having a lot of social capital (followers and influence is a form of capital that is convertible to other forms) and he brushes it off. Overall the discussions tend to focus 99% on substance, and deal with the Web, Social Platforms, Blockchain and Cryptocurrency, how they can change the world and the issues surrounding them.
PS: I know that for now no one has heard of Intercoin or Qbix or my interviews and I am OK with that. Eventually it will be discovered once our products are more mainstream. I am looking forward to interviewing Edward Snowden and a few other people next.
The biggest challenge with software interviews is that you don’t know when to lie. The process is maximally biased and so you have maximum incentive to lie. The only reason to not lie is reputation damage in the highly unlikely case you are caught. In the end you are either hired for more money or you are just wasting your time as a candidate.
Most of us really want to be as honest as possible, not just because we are good people, but because went want to ensure maximum compatibility. This is incredibly deceptive in itself because employer compatibility doesn’t really matter. As an employee you do things the company way or you don’t work there.
So, just lie. I really hate that, but there is no reason not to and every reason to do so. It’s just the nature of conforming to system of inherent implicit bias.
Most of us really want to be as honest as possible, not just because we are good people, but because went want to ensure maximum compatibility. This is incredibly deceptive in itself because employer compatibility doesn’t really matter. As an employee you do things the company way or you don’t work there.
So, just lie. I really hate that, but there is no reason not to and every reason to do so. It’s just the nature of conforming to system of inherent implicit bias.
> So, just lie.
I think this is bad advice. I have never lied in an interview. I've also never had a job not offered to me if I made it to the in person interview part. This isn't to say that I have magical job-getting powers, but only that not lying has not hurt my chances.
In one job I applied for, I didn't have a lot of domain knowledge, but I had knowledge in an adjacent domain and wanted to to jump over to this one. I told this to the interviewer up front, and the interview was a bit rough but I managed to do OK. What I did was explained my thinking process and in many cases arrived at the right solution, or close to it. In others I didn't. The interviewer was sufficiently happy with my ability to solve problems on the spot that they hired me. It wasn't hard to acquire that new domain knowledge, but I had to work at it. I also took a level down in the new job, but they increased my pay over my old job, so I didn't care about the leveling. Long term, that helped me as my salary ended up being higher as a gained levels in the new place.
So being honest about not being the perfect fit has worked out for me. I think it can work out for you, too.
I think this is bad advice. I have never lied in an interview. I've also never had a job not offered to me if I made it to the in person interview part. This isn't to say that I have magical job-getting powers, but only that not lying has not hurt my chances.
In one job I applied for, I didn't have a lot of domain knowledge, but I had knowledge in an adjacent domain and wanted to to jump over to this one. I told this to the interviewer up front, and the interview was a bit rough but I managed to do OK. What I did was explained my thinking process and in many cases arrived at the right solution, or close to it. In others I didn't. The interviewer was sufficiently happy with my ability to solve problems on the spot that they hired me. It wasn't hard to acquire that new domain knowledge, but I had to work at it. I also took a level down in the new job, but they increased my pay over my old job, so I didn't care about the leveling. Long term, that helped me as my salary ended up being higher as a gained levels in the new place.
So being honest about not being the perfect fit has worked out for me. I think it can work out for you, too.
Think about it like this. The goals are attain employment and maximize compensation. That’s it.
That said you are probably best off training machine learning to do this for you. It won’t suffer the nonverbal faults associated with dishonesty, because truth to a machine is how effectively it completes the assigned goal.
That said you are probably best off training machine learning to do this for you. It won’t suffer the nonverbal faults associated with dishonesty, because truth to a machine is how effectively it completes the assigned goal.
> Think about it like this. The goals are attain employment and maximize compensation. That’s it.
Meh, I think devoting 30-40% of your life to something is more than just maximizing compensation. In tech, at least, you normally have quite a few options about where you will work and what you will do. If you feel you need to lie just to get into the door and are convinced that you wont get the job unless you do lie, then consider that this might not be the best job.
On the other hand, if you are too afraid to tell the truth even in the interview, it doesn't bode well for when you need to deal with other people in the corp bureaucracy (which is inevitable once you go past the junior engineer level).
Meh, I think devoting 30-40% of your life to something is more than just maximizing compensation. In tech, at least, you normally have quite a few options about where you will work and what you will do. If you feel you need to lie just to get into the door and are convinced that you wont get the job unless you do lie, then consider that this might not be the best job.
On the other hand, if you are too afraid to tell the truth even in the interview, it doesn't bode well for when you need to deal with other people in the corp bureaucracy (which is inevitable once you go past the junior engineer level).
The reality is that most people are not completely honest. Extreme honesty is shocking and casually associated with extreme personality types or behavior disorders.
I recently accepted a position with 20% lower pay, because the work is more interesting, challenging and rewarding.
I once failed an interview, and I think it was because the interviewer laid a trap for me. He asked if I would use such-and-so algorithm to solve a particular problem, and I said sure. I had never heard of such-and-so algorithm, but I figured that I could look it up once I had the job. When I didn't get the job, I realized that such-and-so was probably made up by the interviewer to see if I was trying to BS my way into the job. Being honest would have been a better approach.
Maybe this works in big companies, but many small companies that I’ve worked at, you’d be caught, even lying on silly little things. The people reading your resume are the same ones you’re going to be working beside, and they’ll absolutely ask you about things you said you knew.
And once they find out that you lied about your volunteering experience at your local little league team, your whole resume goes under the microscope. I’ve seen it happen.
And once they find out that you lied about your volunteering experience at your local little league team, your whole resume goes under the microscope. I’ve seen it happen.
There is a couple of problems with that. More than half the time I have interviewed nobody reads resumes. They know your name and kind of how long you have been employed.
Second, you control what appears on your resume. You can spin it how you want by the facts you include and omit. You list the great selling points about yourself and none of the bad. Don’t lie on a resume because its already under your control and it’s a document of record that can follow you from any point in the past.
This tread isn’t about resumes. It’s about interviewing, specifically as a discussion.
Second, you control what appears on your resume. You can spin it how you want by the facts you include and omit. You list the great selling points about yourself and none of the bad. Don’t lie on a resume because its already under your control and it’s a document of record that can follow you from any point in the past.
This tread isn’t about resumes. It’s about interviewing, specifically as a discussion.
When I interview, I don't spend much time reading the resume beforehand, but I'll ask a few specific questions about it during the interview.
If one assumes nobody reads their resume, however, then what benefit would they get from lying?
If one assumes nobody reads their resume, however, then what benefit would they get from lying?
A resume is not an interview.
I never said it was. It’s a reference that most interviewers will have on hand before/during the interview.
what is it with lying on resumes? is that a thing? i went through some interviews a while ago. everyone assumed i lied on my resume without any basis to do so.
Very frequent, sometimes it's straight up lying, more often it's overstating what they did on the CV. To give you an example, when recruiting for a devops positions recently, during phone screen easily 1 in 4 people with several years of AWS experience on their CV had no idea whatsoever about very basic IAM concepts (e.g. roles vs users, that explicit deny always takes precedence over explicit allow).
That being said being civil and ensuring positive experience even for poor candidates is one of the fundamentals of interviewing. In the cases I described I didn't call them liars, I simply stated that for this role we expect them to independently support development teams, and that we consider IAM to be part of the fundamentals (it was explcitly listed in the job posting), and sent them some resources for studying up.
That being said being civil and ensuring positive experience even for poor candidates is one of the fundamentals of interviewing. In the cases I described I didn't call them liars, I simply stated that for this role we expect them to independently support development teams, and that we consider IAM to be part of the fundamentals (it was explcitly listed in the job posting), and sent them some resources for studying up.
In the attempt of bias removal, interviewers now want to ask the same question to everyone and leave the effort to the interviewer. Take for example, the standard behavioural question which is expected to answer in a STAR format [0]. The question will go as "Tell me about a time you did .... ". Now, it all sounds fine and dandy but you are basically offloading everything to the poor interviewee. You want them to (1) think of an instance in their past and (2) think of a good, relevant instance in their career and (3) follow a format for your convenience. I'd say that's a lot of pressure. Even if you want to stick to the STAR format - you can still be consistent and ask the same question with a twist.
"Did you have any conflict at work? Tell me about such situations"
"What was the impact of the conflict?"
"What steps did you take to resolve it?"
"What changed after you took those steps?"
Well, it's the same line of questioning and addresses all needs of the interviewer. Yet, most of them wouldn't do that. It's still a discussion format and win-win.
[0] https://careercenter.lehigh.edu/node/145
"Did you have any conflict at work? Tell me about such situations"
"What was the impact of the conflict?"
"What steps did you take to resolve it?"
"What changed after you took those steps?"
Well, it's the same line of questioning and addresses all needs of the interviewer. Yet, most of them wouldn't do that. It's still a discussion format and win-win.
[0] https://careercenter.lehigh.edu/node/145
Don't experienced candidates know that behavioral questions is bs and just make things up on the fly? You ask them about a conflict in past, they invent a story about a small disagreement with coworkers that got resolved in a model textbook way, leaving everyone better and wiser? It's not a deposition under oath, after all.
You're probably right, but it pains me to admit it. I would never make up some BS just to get through an interview, it's not in my nature.
I think the author has not really interviewed in the past couple of months / years. Now-a-days I see interviewers skipping the pleasantries and straight jumping on to LC style questions. In fact, in a lot of companies, the first couple of rounds are online assessments where you try to pound on LC mediums or hards without even talking to anybody else
Do you think this is a response to tech salaries getting higher, and more unqualified people who interview well applying for jobs?
A couple years ago we were hiring data scientists, and started with a chat with the hiring manager, and then at some point a technical evaluation. We attracted business grads and others for the position (in addition to cs folks), and a lot of them talked a good game but couldn't do basic data science stuff. So we ended up switching the process to have some kind of table stakes technical evaluation up front, and then do the interviews.
I don't think it's ideal, but the filter has to be somewhere, and companies want to optimize hiring to cut people as quickly as possible rather than do a bunch of interviews and drop them later.
A couple years ago we were hiring data scientists, and started with a chat with the hiring manager, and then at some point a technical evaluation. We attracted business grads and others for the position (in addition to cs folks), and a lot of them talked a good game but couldn't do basic data science stuff. So we ended up switching the process to have some kind of table stakes technical evaluation up front, and then do the interviews.
I don't think it's ideal, but the filter has to be somewhere, and companies want to optimize hiring to cut people as quickly as possible rather than do a bunch of interviews and drop them later.
I think it's a result of the cost of technical testing reducing to a negligible amount, and then as you say, an unhealthy relationship with risk aversion. If any company can open a funnel to the entire timezone or world and put everyone through a HackerRank test they bought off the shelf, they have sunk no real cost by the time they interview someone and potentially no shortage of people who'll go through with it. This is proven out by how little of a signal these cost-of-entry tests apparently provide, because they go on to do other tests anyway, and inevitably reject candidates who passed all of them for any reason they can come up with.
> I think it's a result of the cost of technical testing reducing to a negligible amount
This is a good point that I overlooked and definitely agree is also present. The same thing is happening with other types of interviews - I have seen companies hiring now where the candidate is asked to record video answers to prompted question, that from what I remember are evaluated by some kind of machine learning. They can open up the funnel without having to do anything (except forgo candidates that either have some self respect or are not desperate for work)
This is a good point that I overlooked and definitely agree is also present. The same thing is happening with other types of interviews - I have seen companies hiring now where the candidate is asked to record video answers to prompted question, that from what I remember are evaluated by some kind of machine learning. They can open up the funnel without having to do anything (except forgo candidates that either have some self respect or are not desperate for work)
Yes, absolutely. I've bumped into literally random people out in the world, outside of tech, who have experienced and complained (unprompted) about those creepy AI interviews and they find it dystopian.
I've been asked at least 3 times to do a similar thing, and every time I've just refused, it's a few steps too far for me to even participate in, even though I am almost completely out of options at this point.
I've been asked at least 3 times to do a similar thing, and every time I've just refused, it's a few steps too far for me to even participate in, even though I am almost completely out of options at this point.
>Now-a-days I see interviewers skipping the pleasantries and straight jumping on to LC style questions
lmao software houses in Eastern EU jump straight into day-to-day stuff, 99% of the stuff was normal development, that 1% was just for lulz, to check whether you heard about stuff.
0 algo questions.
lmao software houses in Eastern EU jump straight into day-to-day stuff, 99% of the stuff was normal development, that 1% was just for lulz, to check whether you heard about stuff.
0 algo questions.
> This makes me (and I guess most of us) nervous.
It doesn't me nervous. It makes me wonder if they know what year it is. :)
Ultimately, it's a relationship. Yes, it has to work for them. But it has to work for me as well. Fit matters.
If they're doing all the asking and I'm doing all the answering that's a red flag. If we get to the end and they say "We have a couple minutes left...do you have any questions?" That's another red flag.
Put another way, as I've said before:
How you hire is who you hire.
So if you're hiring ppl that can't see your red flags...well...um...that's a red flag ;)
It doesn't me nervous. It makes me wonder if they know what year it is. :)
Ultimately, it's a relationship. Yes, it has to work for them. But it has to work for me as well. Fit matters.
If they're doing all the asking and I'm doing all the answering that's a red flag. If we get to the end and they say "We have a couple minutes left...do you have any questions?" That's another red flag.
Put another way, as I've said before:
How you hire is who you hire.
So if you're hiring ppl that can't see your red flags...well...um...that's a red flag ;)
[deleted]
I love this thread and the comments in it.
I just had a useless interview with a company that pops up here from time to time. The only thing I liked about the experience was that the itinerary at least tried to make it clear what the key values seemed to be: listening to customers, outcomes, evolving vision. I tried to "map" my experience with their potential customers and how they could think about the "box" and listen and solve.
There's a 10 billion dollar problem in this particular industry and if you take the time to understand customers, it's pretty obvious. I watched first-hand the biggest competitor of this org pivot for this after being around for decades.
The "discussions" I had were not discussions at all. They all seemed rushed. There was no "deep dive" into tech at all.
Next time I interview, I'm going to try a radically different approach: I am going to undershare rather than overshare.
As an interviewer, I'm going to start asking people about cucumbers rather than speak about particular tech or follow some form-based process.
I just had a useless interview with a company that pops up here from time to time. The only thing I liked about the experience was that the itinerary at least tried to make it clear what the key values seemed to be: listening to customers, outcomes, evolving vision. I tried to "map" my experience with their potential customers and how they could think about the "box" and listen and solve.
There's a 10 billion dollar problem in this particular industry and if you take the time to understand customers, it's pretty obvious. I watched first-hand the biggest competitor of this org pivot for this after being around for decades.
The "discussions" I had were not discussions at all. They all seemed rushed. There was no "deep dive" into tech at all.
Next time I interview, I'm going to try a radically different approach: I am going to undershare rather than overshare.
As an interviewer, I'm going to start asking people about cucumbers rather than speak about particular tech or follow some form-based process.
> Use "We" instead of "you" because it feels more inclusive and it is. For example, ask a question as "Suppose we have this problem to solve. How would we go about doing that?"
Oh god how much I hate this! It’s misused by (some) managers so much these days, it’s infuriating. For me it has the very opposite effect than the intended inclusivity.
Oh god how much I hate this! It’s misused by (some) managers so much these days, it’s infuriating. For me it has the very opposite effect than the intended inclusivity.
On a tangent - to this day I can't stomach when Windows talks about itself in plural ("We are setting things up"). It started around Windows 10 and I hate it.
Ugh...
Ugh...
Well windows is plural…
Every few weeks someone comes back with the one true way of interviewing, or the X things wrong with how interviews are led. I have conducted a few hundred of these by now, and the most I know about it is that there's no good way, because you try to figure someone out in just a few hours based on stuff they tell you. The format that seems to work the least worse for me is when you get them to tell you about actual stuff from their experience, which tends to prevent getting completely pointless people. I have been forced to do coding exercises for a while but I replaced by a general discussion on some tech they have been using recently, just to get a feeling of whether they understand what they're doing.
Recently I have been looking for another team internally to my company. An interesting fit is that I went through 3 interviews. I'm an engineering manager. Two interviews were focused on system design, one was coding. The only non coding question I received was around how I coach people. The three persons who interviewed me I asked: "what does the team need to do better", and they all answered a variation of "it takes a while to get stuff to prod once it's built. We need someone who can help get better at that". Yet not a single question for that. I guess the lesson learnt is that if you are looking for a particular skilk, maybe focus on that as well.
Recently I have been looking for another team internally to my company. An interesting fit is that I went through 3 interviews. I'm an engineering manager. Two interviews were focused on system design, one was coding. The only non coding question I received was around how I coach people. The three persons who interviewed me I asked: "what does the team need to do better", and they all answered a variation of "it takes a while to get stuff to prod once it's built. We need someone who can help get better at that". Yet not a single question for that. I guess the lesson learnt is that if you are looking for a particular skilk, maybe focus on that as well.
> they all answered a variation of "it takes a while to get stuff to prod once it's built. We need someone who can help get better at that". Yet not a single question for that. I guess the lesson learnt is that if you are looking for a particular skilk, maybe focus on that as well.
If they knew enough about the problem and its solutions for it to filter down to people doing interviews, they wouldn't need to hire someone to teach them how to do it, right?
If they knew enough about the problem and its solutions for it to filter down to people doing interviews, they wouldn't need to hire someone to teach them how to do it, right?
You don't have to be an expert to get an idea of whether the person in front of you is experienced on a topic ; as long as you remain in the realm of their experience rather than going philosophic/theoritical
- Can you tell me about a time when you had an issue delivering things to production quickly? What did you do to optimize? How did you know there was an issue? What alternatives did you consider? - Can you tell me about what you have done in the past to optimize they lead time to production? What strategies did you employ? How did you
While you won't be able to tell if what they did was optimal, that can at least tell you if the person in front of you has some concrete experience in the topic, and some depth in their understanding. While that's not perfect, it's certainly better than flying blind
- Can you tell me about a time when you had an issue delivering things to production quickly? What did you do to optimize? How did you know there was an issue? What alternatives did you consider? - Can you tell me about what you have done in the past to optimize they lead time to production? What strategies did you employ? How did you
While you won't be able to tell if what they did was optimal, that can at least tell you if the person in front of you has some concrete experience in the topic, and some depth in their understanding. While that's not perfect, it's certainly better than flying blind
Best interview questions are open ended general questions. What is your opinion on software security? How would you improve your efficiency?
This usually is a great discussion where everyone feels good at the end, but tell a lot about the sophistication of the person being interviewed.
After this, pass a small test to make sure the person can do some real work.
This usually is a great discussion where everyone feels good at the end, but tell a lot about the sophistication of the person being interviewed.
After this, pass a small test to make sure the person can do some real work.
Don't do interviews, do take home tests. Do what's representative of the work you will be doing. I highly doubt even at google that it's a life or death situation that you correctly code an obscure algorithm in 30 minutes. Folks think you "cheat" on take home, but all they are doing is selecting for folks who "cheat" by being able to memorize massive amount of leetcode questions, its still a poor signal. 6-8 400-500K interviewees, likely costs more than 2 folks reviewing a take home for 2 hours.
> all they are doing is selecting for folks who "cheat" by being able to memorize massive amount of leetcode questions
This takes an extremely high level of cognitive ability, which is a far, far better signal than a take-home test.
This takes an extremely high level of cognitive ability, which is a far, far better signal than a take-home test.
Slightly OT - on hiring, not interviewing - I recently realized what could improve hiring, and it's simultaneously a great and terrible idea.
How does hiring work today? First, the employer sets out a "careers" page (which varies quite a bit, even within the same company, even for the same job title!) which includes the following banal information: A job title, part-time/full-time/remote/location-based, a company values blurb, a paragraph about the general responsibilities of anyone with this job title, a tech stack, a list of prerequisites that nobody will ever meet "or relevant experience", and maybe the benefits and perks.
Nowhere does it describe the actual project they're working on, their timelines, what kind of situation you're walking into, what the specific team's culture is like, whether there's a strong team lead or everyone is just a genius, if they're culturally diverse, what their daily workflow is, whether their OKRs have sustainability or social responsibility goals, or feedback from team members. Is the project they're working on greenfield or brownfield? What's the architecture? Will you be on-call? Will you be supporting customers or working in a silo? What is the reporting structure like? Career advancement / lateral movement? Training? Do they go to happy hour on Fridays? Is there an LGBTQ ERG?
And from the other side, the company knows next to nothing about who's applying. After all the candidates have played tech buzzword bingo in their resumes, the company (or worse, recruiter) pulls out a divining rod and tries to pick up the one or two candidates who they imagine are a match culturally, technically, and professionally. If you don't know somebody inside the company, or a recruiter doesn't push you as one of the two candidates they've found locally, you might as well be a translucent blob of Arial 12-point font.
How can we connect employees and employers in a meaningful way that isn't an arbitrary screening process? Well it seems to me that somebody has already come up with an answer: dating sites.
Please, stop throwing things at me and hear me out! What are jobs? Relationships between an employee and an employer. Well, dating sites are masters at finding the intersections where people match, in order to find good relationship matches. You can create a curated list of multiple-choice weighted questions, and ask the other person to fill them out, with a small text blurb to elaborate on your answer. The most common/popular ones automatically bubble up for everybody as default questions.
This combination of quantitative and qualitative matching would allow people to quickly see which employees/employers are the best match. We may still need a way to ascertain technical skill or professional experience, but at least the people who come in the door would appear to be the closest matches to what we want. Will there be some catfishing? Sure, but there already is with today's hiring mess! Can somebody please make the OkCupid of hiring? I'm waiting to open my account.
How does hiring work today? First, the employer sets out a "careers" page (which varies quite a bit, even within the same company, even for the same job title!) which includes the following banal information: A job title, part-time/full-time/remote/location-based, a company values blurb, a paragraph about the general responsibilities of anyone with this job title, a tech stack, a list of prerequisites that nobody will ever meet "or relevant experience", and maybe the benefits and perks.
Nowhere does it describe the actual project they're working on, their timelines, what kind of situation you're walking into, what the specific team's culture is like, whether there's a strong team lead or everyone is just a genius, if they're culturally diverse, what their daily workflow is, whether their OKRs have sustainability or social responsibility goals, or feedback from team members. Is the project they're working on greenfield or brownfield? What's the architecture? Will you be on-call? Will you be supporting customers or working in a silo? What is the reporting structure like? Career advancement / lateral movement? Training? Do they go to happy hour on Fridays? Is there an LGBTQ ERG?
And from the other side, the company knows next to nothing about who's applying. After all the candidates have played tech buzzword bingo in their resumes, the company (or worse, recruiter) pulls out a divining rod and tries to pick up the one or two candidates who they imagine are a match culturally, technically, and professionally. If you don't know somebody inside the company, or a recruiter doesn't push you as one of the two candidates they've found locally, you might as well be a translucent blob of Arial 12-point font.
How can we connect employees and employers in a meaningful way that isn't an arbitrary screening process? Well it seems to me that somebody has already come up with an answer: dating sites.
Please, stop throwing things at me and hear me out! What are jobs? Relationships between an employee and an employer. Well, dating sites are masters at finding the intersections where people match, in order to find good relationship matches. You can create a curated list of multiple-choice weighted questions, and ask the other person to fill them out, with a small text blurb to elaborate on your answer. The most common/popular ones automatically bubble up for everybody as default questions.
This combination of quantitative and qualitative matching would allow people to quickly see which employees/employers are the best match. We may still need a way to ascertain technical skill or professional experience, but at least the people who come in the door would appear to be the closest matches to what we want. Will there be some catfishing? Sure, but there already is with today's hiring mess! Can somebody please make the OkCupid of hiring? I'm waiting to open my account.
It's a great insight, but anecdotally dating sites aren't a great way to find a mate.
I know two people who found their spouse through a dating site. The first was forced to get a divorce after his wife tried to kill him and nearly succeeded - she had some mental health issues that weren't captured by the dating site. The second found his 4th wife that way, and as far as I know they're still good but I haven't quizzed him on his personal life in a while.
I know two people who found their spouse through a dating site. The first was forced to get a divorce after his wife tried to kill him and nearly succeeded - she had some mental health issues that weren't captured by the dating site. The second found his 4th wife that way, and as far as I know they're still good but I haven't quizzed him on his personal life in a while.
I prefer a "real" interview. A discussion is nice, but is not as focused as a "normal" interview. I would like to be able to guess roughly how well I have done based on the answers I have given.
Lastly, I don't want to have to guess what we should talk about so that you can feel you know I can do the job.
Lastly, I don't want to have to guess what we should talk about so that you can feel you know I can do the job.
A discussion is fine, but I’m too easily fooled by people.
It matters where you are in your career in terms of the power dynamic of interviews. Early on while unproven your answers matter and how you answer matters while having good questions is super important.
As you establish yourself the power dynamic changes considerably as companies are really trying to convince you to come over. At this point it really should be a conversation to understand if you’re a fit and it’s worth your time. Do the people you’re speaking with impress you?
As you establish yourself the power dynamic changes considerably as companies are really trying to convince you to come over. At this point it really should be a conversation to understand if you’re a fit and it’s worth your time. Do the people you’re speaking with impress you?
Been on the hiring side for more than a decade. In addition to other advice in this thread, I would like to add -
I treat the interview as my chance to help the candidate pass the interview. This bent of thought may seem subtle, but makes all the difference in meeting the candidate in their terrain, and seeing the world from their point of view. Consequently, the case studies given explicitly state that if the candidate finds something else that intrigues them, I am happy to take that as a case study instead - gives them something to flaunt and for me to learn about.
Some candidates are shy to open up, or just not comfortable conversing with strangers, or misread the power asymmetry in the interview and get anxious - I spend a fair bit of time just conversing human to human.
For the really uncommunicative candidates, I make a slight of what they built (fake slight) and this gets the conversation going like a star. The good candidates exhibit a great amount of "Builder's Pride" and defend what they built. They really good ones admit to the possibility that there were other better ways to have built, or explain to me the constraints under which they made the choices they did.
I treat the interview as my chance to help the candidate pass the interview. This bent of thought may seem subtle, but makes all the difference in meeting the candidate in their terrain, and seeing the world from their point of view. Consequently, the case studies given explicitly state that if the candidate finds something else that intrigues them, I am happy to take that as a case study instead - gives them something to flaunt and for me to learn about.
Some candidates are shy to open up, or just not comfortable conversing with strangers, or misread the power asymmetry in the interview and get anxious - I spend a fair bit of time just conversing human to human.
For the really uncommunicative candidates, I make a slight of what they built (fake slight) and this gets the conversation going like a star. The good candidates exhibit a great amount of "Builder's Pride" and defend what they built. They really good ones admit to the possibility that there were other better ways to have built, or explain to me the constraints under which they made the choices they did.
> They really good ones admit to the possibility that there were other better ways to have built, or explain to me the constraints under which they made the choices they did.
Does anyone just clam up because you are making slights about something where you don't know the constraints and make inferences about you from that? Most of us have dealt with utterly terrible, opinionated, under-skilled, supercilious and rude interviewers. How do you avoid coming off at least a little bit like that? Generally speaking there's zero point picking fights with an interviewer no matter how wrong they are.
Does anyone just clam up because you are making slights about something where you don't know the constraints and make inferences about you from that? Most of us have dealt with utterly terrible, opinionated, under-skilled, supercilious and rude interviewers. How do you avoid coming off at least a little bit like that? Generally speaking there's zero point picking fights with an interviewer no matter how wrong they are.
Yes, what you said exactly happens, but not often enough to negate the value of opening up the otherwise clammed up candidate.
Hopefully, the first part where the human<>human chat happens, the candidate is able to see that the intent is to have a genuine conversation, albeit with a more senior person (aka older) person on the other side.
Where I differ from you is the zero-payoff framing. There have been cases where the candidate put me in my place, rightfully so, and ended up getting hired.
This is subjective territory, but I actually prefer a candidate that spars. It gives me a chance to explain my position as well as hear his/hers.
Hopefully, the first part where the human<>human chat happens, the candidate is able to see that the intent is to have a genuine conversation, albeit with a more senior person (aka older) person on the other side.
Where I differ from you is the zero-payoff framing. There have been cases where the candidate put me in my place, rightfully so, and ended up getting hired.
This is subjective territory, but I actually prefer a candidate that spars. It gives me a chance to explain my position as well as hear his/hers.
Yours looks like a classic "yes but I'm different" response. Maybe you really are different. I couldn't possibly say. Just be aware of it? Or maybe there's a way to have your cake and eat it too? Like put on a stupid hat and say "I'm going to play 'Joe Obnoxious the Arrogant' and be critical, this is not how we talk design around here in general but it cuts us the to the chase about something you know. Stand up to anything you don't like hearing. Back it." Hat on. "Why did you do something so sucky as ..." And just maybe there's like a big smile, but heavy content? Eh just a thought. The way you described it would have me thinking I don't want to be there in the room, let alone working with, beside, for, in charge of, you. But I can't and hear the tone of what you describe so who knows..?
This does not seems like a generous interpretation of what op said. The slight that op mentioned could have been surgical and precise, and just enough to kick off a conversation, and not enough to trample the interviewee.
Well you don't know the interviewee to make any assumption at all. I've given /my/ honest response to the description of it. Framed as a question, while noting some of the shortcomings of that. Then provided a suggestion of how OP might get what they want without causing the problem I suggested might, and OP confirmed actually does, occur.
So yeah I think that's pretty productive and positive as these conversations go. I don't see you adding anything of utility or value to it by suggesting bad faith or lack of generosity that I don't think exists on either side. "Surgical and precise" slights by definition can't be either from a position of ignorance, about the person you're slighting or the context and constraints of the work they've done. But you might get lucky. Even without luck it might not matter, maybe nobody else in the world would tell you to boil your head other than me? And nobody whose opinion or work you'd care about? YMMV.
So yeah I think that's pretty productive and positive as these conversations go. I don't see you adding anything of utility or value to it by suggesting bad faith or lack of generosity that I don't think exists on either side. "Surgical and precise" slights by definition can't be either from a position of ignorance, about the person you're slighting or the context and constraints of the work they've done. But you might get lucky. Even without luck it might not matter, maybe nobody else in the world would tell you to boil your head other than me? And nobody whose opinion or work you'd care about? YMMV.
It sounds like the OPs method not only allows people to shine by diving into what they've built, but it would also filter out people like yourself, who are so unbelievably sensitive that it would be a nightmare to work around all of your triggers.
Possibly so. But it's a hell of an assumption to make and not a very kind one. Maybe you were triggered yourself and so that's not entirely fair.
Clearly people don't like the fact that you're making a very valid point.
This site is almost as bad as Reddit, go with the status quo and polish each others ego or you're downvoted or flagged.
This site is almost as bad as Reddit, go with the status quo and polish each others ego or you're downvoted or flagged.
> I treat the interview as my chance to help the candidate pass the interview
Yes! This is exactly how I treat interviews as well (as the interviewer) and would make a good addition to this already solid article. It really opens candidates up when you treat them like you're in an actual scenario at work. Let them ask for help, google for ideas, ask about different solutions, and ask them what they think of your own solutions. How they deal with these things are the real markers of what they'll be like to work with, not how quickly they can remember how to reverse an array while you sit there staring at them.
Yes! This is exactly how I treat interviews as well (as the interviewer) and would make a good addition to this already solid article. It really opens candidates up when you treat them like you're in an actual scenario at work. Let them ask for help, google for ideas, ask about different solutions, and ask them what they think of your own solutions. How they deal with these things are the real markers of what they'll be like to work with, not how quickly they can remember how to reverse an array while you sit there staring at them.
This is the way.
I think this is pretty much the opposite of what the evidence suggests: that unstructured interviews are pretty much worthless.
Conversations gives both parties more fuzzy feelings, but are they actually better or just easier and less awkward?
Conversations gives both parties more fuzzy feelings, but are they actually better or just easier and less awkward?
Both interviews and discussions are conversations. I know lots of interviews are too formal in some ways. I think it might be useful to start formal, get informal but still stick to rules like not asking discriminatory questions, and then get formal again for the end of the interview. Sort of like a feedback sandwich.
> I know lots of interviews are too formal in some ways
How do you know that? Maybe those interviews are the right amount of formal. Do you have evidence that they are too formal?
How do you know that? Maybe those interviews are the right amount of formal. Do you have evidence that they are too formal?
Because I've been on both ends of the interviews and I've seen places where a handful of unplanned questions and comments have gotten useful information and other interviews where no on-the-fly questions were asked and I think it was a missed opportunity. If you were to apply no true Scotsman to what is considered informal you might not include this because it was useful but I'd rather not do that.
Good idea on paper, not practical in real. FAANG etc are whiteboard/leetcode-ing everyone, I believe it's one way to filter out the seniors. Be senior's definition it means people don't spend a few months on algorithms to pass interviews because they had no need to use them in the past 20+ years of their career. It's intentional, talking about 'dont do interviews, do discussions' is missing the point.
By the way, I do think whiteboard/leetcode is important, just not that important.
By the way, I do think whiteboard/leetcode is important, just not that important.
[deleted]
I hate leetcode-style interviewing, but I see no reason to believe that FAANG companies use then primarily because of ageism.
The reasons they're used are simpler. First, these companies need MANY programmers, so they're mostly hiring generalists without a regard for the specific work they'll be doing. Second, they need to conduct many thousands of interviews per week. These two fairly unusual conditions make for a situation where you want a controlled, quantifiable, and simple approach. A leetcode-style interview hits those marks much more easily than other styles. Plus, you can teach someone how to do it in an hour or two (not how to interview well, but how to ask a leetcode problem while not making any headaches for legal in the process).
While I agree that this is probably at least slightly biased against more senior devs, I think senior developers actually get an advantage here. In my experience, as you apply for loftier positions, the technical questions become much more of a conversation.
The reasons they're used are simpler. First, these companies need MANY programmers, so they're mostly hiring generalists without a regard for the specific work they'll be doing. Second, they need to conduct many thousands of interviews per week. These two fairly unusual conditions make for a situation where you want a controlled, quantifiable, and simple approach. A leetcode-style interview hits those marks much more easily than other styles. Plus, you can teach someone how to do it in an hour or two (not how to interview well, but how to ask a leetcode problem while not making any headaches for legal in the process).
While I agree that this is probably at least slightly biased against more senior devs, I think senior developers actually get an advantage here. In my experience, as you apply for loftier positions, the technical questions become much more of a conversation.
I love it, love the way principal engineers in google said that. I know how nervous some candidates are, also how nervous I am when I want to change jobs to big tech companies and being interviewed like that (man live coding sucks).
Wished more companies are implementing this way of interviews
Wished more companies are implementing this way of interviews
It is really hard to filter those "discussers" in this way. They often know tons of possibilities and not the practical solution or skills to carry out their proposed solution
> Do they ask clarifying questions when they don't feel judged
Sure, you can tell yourself fairytale stories, but you and the other person both know there will be generated a number right after the call ends that can only range from 1 to 4 and you will be assigned it.
Also if you treat this as a discussion you may come off as arrogant. After all everyone else is showing nervousness so the interviewer probably thinks "what's with this person who acts like they're already on my team?"
Sure, you can tell yourself fairytale stories, but you and the other person both know there will be generated a number right after the call ends that can only range from 1 to 4 and you will be assigned it.
Also if you treat this as a discussion you may come off as arrogant. After all everyone else is showing nervousness so the interviewer probably thinks "what's with this person who acts like they're already on my team?"
I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to showing any cool/hairy/insane code that got the job done. We can discuss those things and see how to improve them, or laugh at the crazy solutions.
Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with blah blah blah) okay already. I would much rather show you real world code that I've built, or passion projects I spend my free time on. I want to bring me to your company/projects, so get to know what I'm about holistically as an engineer. I think you can best understand that by looking at actual work done and judging whether or not the person is capable of contributing to your needs.
Whenever we face challenges, we learn from them. At scale, we learn everyday. So just hire people who are passionate about facing challenges and learning from them. Not someone who can spend 8 hours a day like a college student playing leet code instead of building something useful. It really isn't that hard to memorize a dozen essential data structures and algorithms. But then what? So cringe.
Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with blah blah blah) okay already. I would much rather show you real world code that I've built, or passion projects I spend my free time on. I want to bring me to your company/projects, so get to know what I'm about holistically as an engineer. I think you can best understand that by looking at actual work done and judging whether or not the person is capable of contributing to your needs.
Whenever we face challenges, we learn from them. At scale, we learn everyday. So just hire people who are passionate about facing challenges and learning from them. Not someone who can spend 8 hours a day like a college student playing leet code instead of building something useful. It really isn't that hard to memorize a dozen essential data structures and algorithms. But then what? So cringe.
This is almost exactly how I hold interviews, except they are usually < 1hr. I ask a person to tell me about a recent project and then keep asking more detailed questions about things until one of us hits our limit of understanding. No gotcha questions or random trivia. I only ask questions about something they claim to have done. Occasionally I'll ask a category question like, "Have you done any work with multi-threading?" And if they say yes, I ask about that project.
I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. Everyone I've recommended for hiring has been successful.
I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. Everyone I've recommended for hiring has been successful.
> I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive.
This is the impossible problem with hiring. Every interviewer wants to minimize false positives (they're expensive!), but every interviewee thinks they're a false negative.
This is the impossible problem with hiring. Every interviewer wants to minimize false positives (they're expensive!), but every interviewee thinks they're a false negative.
Which is funny since I bet most who thinks they are a "false negative" also would claim to have "impostor syndrome". Anyone with impostor syndrome would view themselves as a true negative.
> I bet most who thinks they are a "false negative" also would claim to have "impostor syndrome"
I don't think this could be true? If you think you don't belong/deserve the job (imposter)... why would you think you deserved the job (false negative).
I don't think this could be true? If you think you don't belong/deserve the job (imposter)... why would you think you deserved the job (false negative).
Everyone I've recommended for hiring has been successful.
It's possible you're good at spotting good people, and rejecting bad people, but it's also possible that hiring is just easier than you think it is, and most people are capable of doing the jobs you hire for. You have no way to tell if you'd have the same result just hiring people by picking random resumes. Maybe negatives are just rare.
It's possible you're good at spotting good people, and rejecting bad people, but it's also possible that hiring is just easier than you think it is, and most people are capable of doing the jobs you hire for. You have no way to tell if you'd have the same result just hiring people by picking random resumes. Maybe negatives are just rare.
It's unlikely that hiring is easier than I think it is, because I think it's pretty easy. The people who think it's hard are the HN consensus and the large corporations we keep reading about coming up with these convoluted interview standards/metrics.
Same here. I've never had a dud in terms of ability when doing a technical chat interview. People who don't know how things work will hit a wall in this format, it's not actually that easy to BS what your thoughts on the CPP memory model are.
The fear of BSers seems to be what holds people back from this approach though, and I can see that it wouldn't work for certain non technical fields.
The fear of BSers seems to be what holds people back from this approach though, and I can see that it wouldn't work for certain non technical fields.
> I've found this technique to be extremely successful.
That's just survivorship bias waiting to explode. Also, they're successful by some arbitrary metric that is applicable only to your company.
That's just survivorship bias waiting to explode. Also, they're successful by some arbitrary metric that is applicable only to your company.
It's entirely likely I will one day hit a false positive.
I've been on the hiring team for every employer I've had for the last 15 years and have hired dozens of people.
I've been on the hiring team for every employer I've had for the last 15 years and have hired dozens of people.
The challenge with this approach as that many very competent people are not allowed to discuss their prior work in that level of detail. More practical variants of this approach use a straw man software design problem to talk to that will exercise diverse areas of experience.
Yep, 100% this. Particularly if you've worked for big firms in the past, those NDAs do not mess around.
I do experience-based interviewing, and i have never encountered this problem. The great majority of the time, people are able to talk about anything. Sometimes, there are sensitive parts of prior work, but a candidate can just talk around those bits and focus on the rest. Even if someone had been working somewhere super-secret, if they aren't a junior, they have other experience to talk about.
If all your career experience so far has been at the NSA, yeah, you might want to do a side project before looking for work.
If all your career experience so far has been at the NSA, yeah, you might want to do a side project before looking for work.
I’ve worked at some large companies and would say this is wrong. I can’t talk about most of my best examples because they’re still roadmap items.
You can’t remove the identifying details and talk about the technical challenge and usage in a generic sense? Your system or software is that specific? Can you give a now public example?
I can, and that’s usually what I do, but there are identifying details about the very specific domain which AWS only has a single product in.
So I can talk about architecting a system, about customer feedback and redesigns, but I can’t talk about work I did that will span another three years.
I think at FAANG it’s usually fine — most people have good enough examples even without their full repertoire. But at mid enterprise or F500 companies I could see this being a bit impactful.
So I can talk about architecting a system, about customer feedback and redesigns, but I can’t talk about work I did that will span another three years.
I think at FAANG it’s usually fine — most people have good enough examples even without their full repertoire. But at mid enterprise or F500 companies I could see this being a bit impactful.
> I can, and that’s usually what I do, but there are identifying details about the very specific domain which AWS only has a single product in.
Sorry, to be clear, I mean can you give an example of something you couldn't use as an example, but is now public.
I've worked at GAMMA, and agree, it's very doable to turn my work generic and talk about it in-depth, compare it to alternatives, etc. so that was the main driver in asking for an example.
Sorry, to be clear, I mean can you give an example of something you couldn't use as an example, but is now public.
I've worked at GAMMA, and agree, it's very doable to turn my work generic and talk about it in-depth, compare it to alternatives, etc. so that was the main driver in asking for an example.
it is not less wrong than timed leetcode BS interviews
As someone who's done classified work, the general guidance we got is that we can speak in generalities.
So I can't say what the code specifically does or who it's for, but I can talk about how I worked on a c++ engine wrapped in a Java server that was responsible for coordinating a large group of non-homogeneous assets, as well as various architectural details (what libraries did we use, database, messaging setup, etc). So it's not like I have nothing to talk about in an interview, plus the fact that I can't get too specific adds mystique. It's kinda fun, because in my experience there's an assumption most engineers/engineering managers make about what I've worked on from that first statement, particularly if they know where I work, and it's actually not that. :)
So I can't say what the code specifically does or who it's for, but I can talk about how I worked on a c++ engine wrapped in a Java server that was responsible for coordinating a large group of non-homogeneous assets, as well as various architectural details (what libraries did we use, database, messaging setup, etc). So it's not like I have nothing to talk about in an interview, plus the fact that I can't get too specific adds mystique. It's kinda fun, because in my experience there's an assumption most engineers/engineering managers make about what I've worked on from that first statement, particularly if they know where I work, and it's actually not that. :)
Also, I would find it weird if a person never worked on any side projects or tinkering in the free time to discuss the things above.
yeah, and some very competent people have no time or interest in timed coding tests and know that great software is not built that way.
if you have been through a CS program you have worked on probably at least 10 projects. and then there are your personal projects. if you have any experience you can talk about at least some of these apart from the stuff under NDA.
so, this approach is much better than timed coding interviews and is a much more fair system as it rewards and takes into account experience.
if you have been through a CS program you have worked on probably at least 10 projects. and then there are your personal projects. if you have any experience you can talk about at least some of these apart from the stuff under NDA.
so, this approach is much better than timed coding interviews and is a much more fair system as it rewards and takes into account experience.
if you have been through a CS program you have worked on probably at least 10 projects
That's fine for a new graduate, but many of us are decades out of college. What we did then has almost zero relevance to jobs we might seek today.
That's fine for a new graduate, but many of us are decades out of college. What we did then has almost zero relevance to jobs we might seek today.
the same goes for leetcode interviews. the key difference is that you don’t need to prepare to talk about your own projects. or at least much less. and you are probably working on stuff after hours anyway.
This follows what I think of as the best technical interview I ever had. It was for a more junior role, but it was pretty good.
Here's a basic straw man rails controller. There are a few things wrong with it. Apply suggestions. It was nice.
Here's a basic straw man rails controller. There are a few things wrong with it. Apply suggestions. It was nice.
100% give me a convo with a dev like this anyday of the week over this crammer whiteboarding l33tcode problems.
As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of conversations is that people can plausibly BS quite a bit about projects, or their role in them.
Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved and all the hard technical challenges were overcome, how can you tell?
Or maybe the project did succeed but someone else came up with the idea and led the efforts. I was there for the technical discussions and grilled the lead on why he made the choices he did, so now I can answer your questions and sound like I know what I'm talking about.
Software engineers can make a lot of money, the incentives to game the interview process are high and people attempt it often...
Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved and all the hard technical challenges were overcome, how can you tell?
Or maybe the project did succeed but someone else came up with the idea and led the efforts. I was there for the technical discussions and grilled the lead on why he made the choices he did, so now I can answer your questions and sound like I know what I'm talking about.
Software engineers can make a lot of money, the incentives to game the interview process are high and people attempt it often...
Yeah, any member of a team that isn't completely clueless will be able to convincingly claim that all of the achievements done by the team was achieved by the person alone.
There is a hysteria that's plaguing the world of tech: The fear that incompetent people might "BS" their way to a position.
Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine.
And this is fought with setting up ridiculous 8-part technical interviews where you'll have to whiteboard some leetcode questions ("Given a problem, show us a working O(Log N), or preferably O(1) solution. You have 45 minutes") or design questions ("Show us how you would design slack / discord / zoom / etc.") that drags over 6 months.
For someone to be truly incompetent, or even not good enough to meet the company standards, the current system is overkill.
Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine.
And this is fought with setting up ridiculous 8-part technical interviews where you'll have to whiteboard some leetcode questions ("Given a problem, show us a working O(Log N), or preferably O(1) solution. You have 45 minutes") or design questions ("Show us how you would design slack / discord / zoom / etc.") that drags over 6 months.
For someone to be truly incompetent, or even not good enough to meet the company standards, the current system is overkill.
It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company. How empowered are new senior hires, and how expensive is the time of the team? At larger companies senior engineers are often phenomenally expensive and at smaller companies controls over potentially business ending operations are usually minimal.
A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in the 6 months the bad hire was there they cost the company maybe ~5 million between wasted engineer time and delayed release schedules after people kept having to put out their fires. On the other end of companies, I've heard of seniors corrupting the database and its backup and ending an entire startup.
This is not a defense of whiteboard interviews per se, just an observation on why companies desperately want to avoid bad hires.
A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in the 6 months the bad hire was there they cost the company maybe ~5 million between wasted engineer time and delayed release schedules after people kept having to put out their fires. On the other end of companies, I've heard of seniors corrupting the database and its backup and ending an entire startup.
This is not a defense of whiteboard interviews per se, just an observation on why companies desperately want to avoid bad hires.
In your examples, did they go through a coding challenge / whiteboard process?
Across all examples I can think of - some yes, some no.
It's not material to my point either way. I was only arguing that for some company's being very afraid of bad hires may be sensible and dismissing their concerns as hysteria does not seem obviously correct to me.
It's not material to my point either way. I was only arguing that for some company's being very afraid of bad hires may be sensible and dismissing their concerns as hysteria does not seem obviously correct to me.
>In your examples, did they go through a coding challenge / whiteboard process?
I think he was trying to point out that if some of the bad candidates had passed a whiteboard test, it brings in to the questions of the effectiveness of whiteboard tests to filter out bad candidates.
I remember a guy we hired years ago who answered all the tech questions we asked with flying colors. He was lazy and unmotivated and ended up dumping all his work on other people (me). I would have much rather had a motivated person who I had to teach some stuff to rather than him.
I think he was trying to point out that if some of the bad candidates had passed a whiteboard test, it brings in to the questions of the effectiveness of whiteboard tests to filter out bad candidates.
I remember a guy we hired years ago who answered all the tech questions we asked with flying colors. He was lazy and unmotivated and ended up dumping all his work on other people (me). I would have much rather had a motivated person who I had to teach some stuff to rather than him.
Saying this method of interview is not 100% effective so it's useless is not a great argument. Reality is that bad hires are really expensive (as argued above) and that current interview methods are somewhat - admittedly not 100% - effective at avoiding those while mostly - again not 100% - effective at admitting the great hires. Maybe this "convert to discussion" method is more effective (I have my doubts), and I'm sure there are more effective methods out there and we should look for them, but let's recognize the reasons for what we have while we look for something better.
>Saying this method of interview is not 100% effective so it's useless is not a great argument.
Who said that?
Who said that?
Honestly, one of the safest and most powerful tools is just to continually ask "why" questions as a result of whatever they say in regards to technical details, with a scattering of "how?" questions.
Others in the comments have expressed some legal concerns about "discussions" instead of Interviews, but I feel this is a hyperbolized fear based off a laypersons interpretation of US hiring law. The law requires you ask the same set of questions of all candidates, yes, but it reasonably understands that questions on past projects/work of course will never be the same, and these are legal and valid areas to go off-script.
So suppose in your situation you have a candidate and they talk about the project they worked on. To hear about their contribution, you ask (as you would all candidates):
"Tell me about a problem you encountered on this project that was particularly challenging from a technical perspective"
The candidate will tell you and likely their solution, and then you can start with the why's and how's.
"Why did you choose this approach? What are the benefits?"
"How did you arrive at this conclusion?" (you can further restate the question with "explain how you got to the idea that you needed to get here")
Make it a hard rule for yourself that you must be able to build the entire timeline and understand the candidate's role in that timeline. I find that even if it turns out they mostly were receiving orders from a more senior resource but could reasonably explain in their own words now why they ended up doing what they did, this is still a good candidate for me as they used available resources and took away a good lesson. If there is ambiguity, you can even just ask "why do you think your senior colleague had the right idea here?"
The idea of a discussion versus a checklist is you want to learn how a person thinks and how they approach issues. Even as a follow up to more factual check-list questions, "why" is very important as it helps you to understand the current state of the person. Just be honest with yourself that not everyone will have the same background and be honest on whether the "why" is relevant for the position. For example, some trivial linux kernel knowledge I would consider "nice to know", but it's by far not essential unless they're doing specific dev work on that field or claim to know it.
The other big catch you need to train yourself for is accepting that people will do things far differently than you do, even things that you consider wrong, but they work. The important part to focus on isn't about how close their answer is to yours, but to make sure you understand how and why someone reached that conclusion.
Why and how are very safe and legal questions as a follow up to a very straight-forward technical question.
Others in the comments have expressed some legal concerns about "discussions" instead of Interviews, but I feel this is a hyperbolized fear based off a laypersons interpretation of US hiring law. The law requires you ask the same set of questions of all candidates, yes, but it reasonably understands that questions on past projects/work of course will never be the same, and these are legal and valid areas to go off-script.
So suppose in your situation you have a candidate and they talk about the project they worked on. To hear about their contribution, you ask (as you would all candidates):
"Tell me about a problem you encountered on this project that was particularly challenging from a technical perspective"
The candidate will tell you and likely their solution, and then you can start with the why's and how's.
"Why did you choose this approach? What are the benefits?"
"How did you arrive at this conclusion?" (you can further restate the question with "explain how you got to the idea that you needed to get here")
Make it a hard rule for yourself that you must be able to build the entire timeline and understand the candidate's role in that timeline. I find that even if it turns out they mostly were receiving orders from a more senior resource but could reasonably explain in their own words now why they ended up doing what they did, this is still a good candidate for me as they used available resources and took away a good lesson. If there is ambiguity, you can even just ask "why do you think your senior colleague had the right idea here?"
The idea of a discussion versus a checklist is you want to learn how a person thinks and how they approach issues. Even as a follow up to more factual check-list questions, "why" is very important as it helps you to understand the current state of the person. Just be honest with yourself that not everyone will have the same background and be honest on whether the "why" is relevant for the position. For example, some trivial linux kernel knowledge I would consider "nice to know", but it's by far not essential unless they're doing specific dev work on that field or claim to know it.
The other big catch you need to train yourself for is accepting that people will do things far differently than you do, even things that you consider wrong, but they work. The important part to focus on isn't about how close their answer is to yours, but to make sure you understand how and why someone reached that conclusion.
Why and how are very safe and legal questions as a follow up to a very straight-forward technical question.
> but I feel this is a hyperbolized fear based off a laypersons interpretation of US hiring law
Making definitive statements about liability is not trivial. I can confirm that at some very large companies legal has banned this style of interview citing discrimination concerns. I'm not a lawyer, so I can't comment on whether they're call is more or less correct but it certainly doesn't seem settled.
Making definitive statements about liability is not trivial. I can confirm that at some very large companies legal has banned this style of interview citing discrimination concerns. I'm not a lawyer, so I can't comment on whether they're call is more or less correct but it certainly doesn't seem settled.
I believe you can see in my quote I even wrote "I feel" ;)
Also working for a "large" US company and discussing with peers from others, no such banning exists. There is very clear training and a heavy restriction on who can perform interviews, but this is not the same as outright banning it.
Also working for a "large" US company and discussing with peers from others, no such banning exists. There is very clear training and a heavy restriction on who can perform interviews, but this is not the same as outright banning it.
> The law requires you ask the same set of questions of all candidates
Does it? I have never heard of such a requirement in a law (though I’m not a lawyer). That might be an employer’s decision on policy they use to ensure compliance with the law, but I couldn’t quickly find any law requiring the questions to be uniform across candidates. (It’s also a difficult set of terms to quickly and confidently exclude the possibility that one exists.)
I guess that’s a longer (and hopefully more polite) way of saying “citation, please.”
Does it? I have never heard of such a requirement in a law (though I’m not a lawyer). That might be an employer’s decision on policy they use to ensure compliance with the law, but I couldn’t quickly find any law requiring the questions to be uniform across candidates. (It’s also a difficult set of terms to quickly and confidently exclude the possibility that one exists.)
I guess that’s a longer (and hopefully more polite) way of saying “citation, please.”
Sure:
https://www.eeoc.gov/employers/small-business/3-im-recruitin...
Screen applications consistently. Apply the same standards to everyone applying for the same position.
Effectively, you should have the exact same criterion for all candidates for the same position and avoid "on the fly" questions/too heavily customizing it.
The legal discussion on all of this has basically boiled down to that you must ensure you're going through the same process for each candidate with the expected variances based on their employment/personal history (as it's relevant to the position)
I may overstate the situation slightly with that statement, but the idea is that if you ask about a networking stack for candidate A, you should ask the same probing questions for candidate B also. (Consider maybe you know that candidate B doesn't know this stack and will look "negative" on a review to the hiring managers, but you really like candidate B for other reasons)
Ultimately the idea is less about the specific questions and more that Candidate A and B are both reasonably considered in the same fashion for all of the requirements of the position, and that you aren't adding/omitting elements that may influence the applicability of the candidate in any fashion.
So let me restate: It's not required you ask verbatim the same words for each candidate (this is the lay-person over-read).
But for a given position, it should be established in advance a series of competencies that are necessary for the position and that are to be asked of each candidate. How you go about investigating it may vary from candidate to candidate, but should two interviews be reviewed, it should be expected that both interviews cover the same topics to a reasonable degree. (e.g., it is reasonable that if you ask "have you ever worked with library X" and the candidate flat out says they cannot answer questions on library X, you have reasonably covered that topic with this candidate. If you ask another candidate and they do have experience with library X and you ask some additional questions, you have not violated the spirit or letter of the requirement in this case.)
https://www.eeoc.gov/employers/small-business/3-im-recruitin...
Screen applications consistently. Apply the same standards to everyone applying for the same position.
Effectively, you should have the exact same criterion for all candidates for the same position and avoid "on the fly" questions/too heavily customizing it.
The legal discussion on all of this has basically boiled down to that you must ensure you're going through the same process for each candidate with the expected variances based on their employment/personal history (as it's relevant to the position)
I may overstate the situation slightly with that statement, but the idea is that if you ask about a networking stack for candidate A, you should ask the same probing questions for candidate B also. (Consider maybe you know that candidate B doesn't know this stack and will look "negative" on a review to the hiring managers, but you really like candidate B for other reasons)
Ultimately the idea is less about the specific questions and more that Candidate A and B are both reasonably considered in the same fashion for all of the requirements of the position, and that you aren't adding/omitting elements that may influence the applicability of the candidate in any fashion.
So let me restate: It's not required you ask verbatim the same words for each candidate (this is the lay-person over-read).
But for a given position, it should be established in advance a series of competencies that are necessary for the position and that are to be asked of each candidate. How you go about investigating it may vary from candidate to candidate, but should two interviews be reviewed, it should be expected that both interviews cover the same topics to a reasonable degree. (e.g., it is reasonable that if you ask "have you ever worked with library X" and the candidate flat out says they cannot answer questions on library X, you have reasonably covered that topic with this candidate. If you ask another candidate and they do have experience with library X and you ask some additional questions, you have not violated the spirit or letter of the requirement in this case.)
This is dramatically more complicated than it actually is. It does come back to competencies and structures. For instance, at AWS, this boils down to wide technical competencies and leadership principles. Of the nearly 100 interviews I did at AWS, I probably never had two that were very close, just due to people’s resumes, prior experience, and breadth of interests.
But, if you wanted to ask the recruiting team to add an interview to get more feedback, this would be a clear no.
But, if you wanted to ask the recruiting team to add an interview to get more feedback, this would be a clear no.
I wonder how much of the last point is a high tolerance for false negatives? If a candidate is that close to a no-hire, maybe a rational choice is to say “No, you’re welcome to re-apply in N months.”
It was always cited as a legal risk.
Stripe handled this by having an extra interview baked in by default. People who were viewed as no risk hires didn’t have to do it, but the default was an extra interview to cover risks. Because it wasn’t an aberration, it wasn’t giving a candidate preferential treatment.
I honestly think it’s one of the smartest interview loops I’ve seen. I think they are one of the few large companies gambling a bit on the false positive side of things to shave off false negative points. And honestly, I was impressed with the people I interacted with at stripe more than AWS. They’re doing something right.
Stripe handled this by having an extra interview baked in by default. People who were viewed as no risk hires didn’t have to do it, but the default was an extra interview to cover risks. Because it wasn’t an aberration, it wasn’t giving a candidate preferential treatment.
I honestly think it’s one of the smartest interview loops I’ve seen. I think they are one of the few large companies gambling a bit on the false positive side of things to shave off false negative points. And honestly, I was impressed with the people I interacted with at stripe more than AWS. They’re doing something right.
Reading this again, it was more confrontational than I wanted it to be and lacked details about why I think super structured interviews are a bad idea.
Some of the best candidates I’ve been involved with hiring have been compelling for reasons you’d never get to in a very structured way.
For instance, a candidate who was just out of university. They were very shy about technical topics, and their tech depth wasn’t great. They went to a university in Africa that I knew taught people more stuff that was wrong than right, and they were starting at a disadvantage. To get him out of his shell I asked about things he’d done outside of academics. He told me that he had not done much because he was very busy. Busy with what?
Oh, just starting a real estate investing side business with his family where he’d been responsible for their international expansion into the UK. With no finance background, he’d spent his time understanding the financial, legal and tax implications of their expansion and successfully launched in his third year of university.
And I’d done a bit of finance so we talked about concepts there and he was able to walk me through complex topics in simple terms.
My job for that interview was judging bias for action, curiosity, and diving deep into metrics. He couldn’t show that for tech because he went to a horrible university and had been very busy with other extra circulars.
He apologized to me for spending so much time talking about non tech subjects. And here is the problem: people who are bad at interviewing are punished by rigid processes. There’s a lot of data to show that women and immigrants from certain backgrounds are more reserved on average. You have to be a much better interviewer to pull off a structured interview that lets these candidates shine.
Some of the best candidates I’ve been involved with hiring have been compelling for reasons you’d never get to in a very structured way.
For instance, a candidate who was just out of university. They were very shy about technical topics, and their tech depth wasn’t great. They went to a university in Africa that I knew taught people more stuff that was wrong than right, and they were starting at a disadvantage. To get him out of his shell I asked about things he’d done outside of academics. He told me that he had not done much because he was very busy. Busy with what?
Oh, just starting a real estate investing side business with his family where he’d been responsible for their international expansion into the UK. With no finance background, he’d spent his time understanding the financial, legal and tax implications of their expansion and successfully launched in his third year of university.
And I’d done a bit of finance so we talked about concepts there and he was able to walk me through complex topics in simple terms.
My job for that interview was judging bias for action, curiosity, and diving deep into metrics. He couldn’t show that for tech because he went to a horrible university and had been very busy with other extra circulars.
He apologized to me for spending so much time talking about non tech subjects. And here is the problem: people who are bad at interviewing are punished by rigid processes. There’s a lot of data to show that women and immigrants from certain backgrounds are more reserved on average. You have to be a much better interviewer to pull off a structured interview that lets these candidates shine.
> Their guess was that in the 6 months the bad hire was there they cost the company maybe ~5 million between wasted engineer time and delayed release schedules after people kept having to put out their fires.
I've worked with one or two of those, but I've also been on interview loops that rejected candidates who went on to massively successful careers at a different FAANG.
The cost of false positives is relatively easy to quantify, the cost of false negatives significantly harder. Which is higher?
I've worked with one or two of those, but I've also been on interview loops that rejected candidates who went on to massively successful careers at a different FAANG.
The cost of false positives is relatively easy to quantify, the cost of false negatives significantly harder. Which is higher?
There is also a cost to hiring folks via an interview process that does not clearly signal, “we have thought about it and decided you belong here.” It reduces their willingness to ask for help and admit ignorance.
companies think that during interviews it is cheaper to let a really good candidate go than hiring a bad one. that is a huge mistake. every now and then they will not hire a key unique candidate, so they miss out on billions of $ in value. they don’t understand that if you hire 100 people, only about 5 of them will be doing all the important work and creating all the value.
> It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company
I'm always curious how people interview doctors. As bad as getting a bad programmer might potentially be, getting a bad doctor must be exponentially worse, so you'd think they'd have vetting the unqualified folks down to a science by now.
I'm always curious how people interview doctors. As bad as getting a bad programmer might potentially be, getting a bad doctor must be exponentially worse, so you'd think they'd have vetting the unqualified folks down to a science by now.
In most countries doctors and other health professionals are registered and licensed, and must submit to strict examinations.
Mistakes can also be career-ending and potentially result in criminal prosecution.
It's way harder to get hired as a doctor than "do a bit of leetcode on a whiteboard".
Mistakes can also be career-ending and potentially result in criminal prosecution.
It's way harder to get hired as a doctor than "do a bit of leetcode on a whiteboard".
Exactly. Somehow there is this impression that software engineers are having it really hard and they face worst job requirements/interviews.
I'd imagine software/IT might be only place where people who have delivered a couple of toy sized, half-assed webapps are now experts commenting on 'engineering challenges' and 'industry trends' with profundity.
I'd imagine software/IT might be only place where people who have delivered a couple of toy sized, half-assed webapps are now experts commenting on 'engineering challenges' and 'industry trends' with profundity.
> "I'm always curious how people interview doctors."
They go through several years of medical residency under supervision before becoming a full fledged doctor and are burdened by expensive liability insurance and ongoing education requirements. That takes care of the competency beforehand.
They go through several years of medical residency under supervision before becoming a full fledged doctor and are burdened by expensive liability insurance and ongoing education requirements. That takes care of the competency beforehand.
I think about the time my manager dismissed an interviewee as not understanding map-reduce because he couldn’t solve some problem in 2 passes, but rather needed 3.
I asked him to explain how to do it in 2. And he was like, “what? It’s easy!” Then another person on the team who over heard it also asked.
Eventually the whole team was there, asking him to prove it, and he spent over an half an hour trying to explain it, and none of us were getting it. The consensus from everyone (except the manager) that it was an unfair question that relied on a a very subtle assumption about the data that wasn’t obvious at all, and that 3 passes was the minimum required Without the that assumption.
Of course the manager said everyone was stupid and it was a good question.
That manager remains my counter example of what a good manager is.
I asked him to explain how to do it in 2. And he was like, “what? It’s easy!” Then another person on the team who over heard it also asked.
Eventually the whole team was there, asking him to prove it, and he spent over an half an hour trying to explain it, and none of us were getting it. The consensus from everyone (except the manager) that it was an unfair question that relied on a a very subtle assumption about the data that wasn’t obvious at all, and that 3 passes was the minimum required Without the that assumption.
Of course the manager said everyone was stupid and it was a good question.
That manager remains my counter example of what a good manager is.
this example display the advantage of leetcode. if your recruiters just can not work, leetcode style still can offer some useful data for decision.
An awful lot of the datastructure-style questions rely on specific knowledge of the optimal approach. I dislike asking questsions because they are more a test of whether you took a particular style of datastructure course than a test of problem solving
Sadly this isn't some sort of mass hysteria but based on practical experience. Yes, it's hard to believe. New interviewers are routinely shocked the first few times they are asked to take a candidate through a coding test. That's why everyone should just ignore the advice in the article - it's wrong. If you want to hire competent programmers, you need to test them rigorously by watching them code, in front of you. Every time I have been tempted to stray from this path the results have been bad. The world is full of people who are very good at seeming affable, friendly and competent but who then fall to pieces the moment you ask them to write a program. Any program. That does anything at all.
Then why ask candidates to solve a leetcode hard or two mediums in 45 mins? If you're afraid of people who can't code any program then ask for leetcode easy.
Sure but the article isn't about difficulty of coding challenges, or where you get them from, but about doing them at all.
It's a vicious cycle.
As companies ask 'Leetcode easy' questions, there came to be thousands of online blogs, youtube channels etc.. which trained even the n00bs who can't write good code otherwise. If they train very well they can solve 2sum or write binary tree level order traversal without understanding much. Of course not all interviews can use novel exclusive questions, and these have a non-negligible chance of passing.
Now if you are hiring, you would think, "If these n00bs can solve Leetcode easy with practice, the good ones are solving Leetcode medium with same level of practice. So let's raise the level of questions so that we don't end up hiring these rote-learning noobs". And it continues.
I don't think there's an obvious solution to this, if you don't want to lose the statistically good heuristic of problem solving skills, in order to weed out candidates.
As companies ask 'Leetcode easy' questions, there came to be thousands of online blogs, youtube channels etc.. which trained even the n00bs who can't write good code otherwise. If they train very well they can solve 2sum or write binary tree level order traversal without understanding much. Of course not all interviews can use novel exclusive questions, and these have a non-negligible chance of passing.
Now if you are hiring, you would think, "If these n00bs can solve Leetcode easy with practice, the good ones are solving Leetcode medium with same level of practice. So let's raise the level of questions so that we don't end up hiring these rote-learning noobs". And it continues.
I don't think there's an obvious solution to this, if you don't want to lose the statistically good heuristic of problem solving skills, in order to weed out candidates.
I haven't actually seen that cycle in practice when I've been hiring. Maybe a small number of people practice a lot on leetcode, but it seems most don't. And I think it's hard to get better at those sorts of problems and not get even a bit better at programming in general. Remember the problem here is people who can't code their way out of a paper bag, not people who just struggle with exotic algorithms questions.
The glaring problem (IMO) with throwing hard LC-style questions at interviewees, is that it's a fundamentally stressful and high-stakes situation - which is so far removed from the actual working environment.
What are you actually inferring from the situation - how well the candidate can write software? How well they tackle stress and anxiety? How much spare-time they have to grind these types of questions? etc.
Probably a mix of them all, but there's a lot of irrelevant noise - if you're just looking for one thing.
What are you actually inferring from the situation - how well the candidate can write software? How well they tackle stress and anxiety? How much spare-time they have to grind these types of questions? etc.
Probably a mix of them all, but there's a lot of irrelevant noise - if you're just looking for one thing.
I am an interviewer for C++ job candidates in the automotive industry.
I do a coding task first and a Q&A afterwards — because these are the requirements.
I did many interviews. My experience is: I could skip the Q&A completely. Most candidates could answer the questions just fine after reading the Wikipedia article for 10 minutes. In the interview I can see if they already read it or not. But I don't think it matters.
What matters are the coding skills. The coding task is quite simple and half of the candidates (with master degrees and 'years of industry experience') fail. But these candidates are often good talkers when they are chatting about the benefits of agile methodology and so on.
I totally agree with you that a candidate should just write any program. I believe I know after 15 minutes if they are developers or not.
But I also agree with the idea that we interviews must calm down the interviewee and remove the nervousness. I don't want to see if they stay cool in an exam situation because daily work is not an exam situation. I want to see if they can code when they are relaxed.
I do a coding task first and a Q&A afterwards — because these are the requirements.
I did many interviews. My experience is: I could skip the Q&A completely. Most candidates could answer the questions just fine after reading the Wikipedia article for 10 minutes. In the interview I can see if they already read it or not. But I don't think it matters.
What matters are the coding skills. The coding task is quite simple and half of the candidates (with master degrees and 'years of industry experience') fail. But these candidates are often good talkers when they are chatting about the benefits of agile methodology and so on.
I totally agree with you that a candidate should just write any program. I believe I know after 15 minutes if they are developers or not.
But I also agree with the idea that we interviews must calm down the interviewee and remove the nervousness. I don't want to see if they stay cool in an exam situation because daily work is not an exam situation. I want to see if they can code when they are relaxed.
>half of the candidates (with master degrees and 'years of industry experience') fail.
If half the candidates with a master's degree in CS are failing your test, that should be a pretty huge red flag to you that your test might have an issue. What question are they failing?
If half the candidates with a master's degree in CS are failing your test, that should be a pretty huge red flag to you that your test might have an issue. What question are they failing?
They don't have problems with the questions. They are not able to write a simple C++. And they are applying for a C++ dev job.
I would think that could get filtered out on the resume check with no relevant experience. Are they lying on the resume?
I honestly don't know. I asked myself the same question.
These guys are applying for C++ dev jobs but are completely unable to write a program. Most of these fake programmers have studied electronics (not CS) or have studied in a country where you can buy a degree.
These guys are applying for C++ dev jobs but are completely unable to write a program. Most of these fake programmers have studied electronics (not CS) or have studied in a country where you can buy a degree.
It's extremely common for people to not only advertise that they have specific skills, but even to have been using those skills for years, yet be entirely unable to demonstrate those skills when requested.
C++ is a particularly badly affected language for some reason. I think there are a lot of people who learned C++ once, a long time ago, then moved to Java as quickly as they could when it came out. But nobody likes to admit that maybe they lost a skill they once had, so they keep putting it down on the CV regardless. And then when asked to write something like hello world, they don't remember how to use std::cout or whatever.
C++ is a particularly badly affected language for some reason. I think there are a lot of people who learned C++ once, a long time ago, then moved to Java as quickly as they could when it came out. But nobody likes to admit that maybe they lost a skill they once had, so they keep putting it down on the CV regardless. And then when asked to write something like hello world, they don't remember how to use std::cout or whatever.
The vast majority of people you actually work with are competent, sure. But the problem with interviewing is that it adversely selects for incompetent people, because competent people are more likely to have jobs and not be currently interviewing.
Other fields seem to do just fine with this approach.
If you interview for an R&D position at (e.g.,) a biotech company, in academia, or one of the National Labs, you're usually asked to prepare a 30-45 minute presentation about your past work. New grads usually use their MS/PhD thesis defense slides; other folks often have a conference talk they can expand. Some places also do "chalk talks" where you describe how you'd approach a new problem of your or their choosing.
This presentation is the jumping-off point for the rest of your interviews. If you talked about building a compiler, someone is going to ask for details about the lexer, maybe have you do implement a very simple tokenizer on a white board. Another person will ask how you measured its correctness/performance. Yet another may dig into how you organized the team doing the work, etc.
Maybe, as you propose, someone else helped with parts of the work. This wouldn't necessarily weed that out. Nevertheless, I'd argue that being able to justify the decisions that were made--and cogently explain when/why they might be different--isn't actually BS; it's understanding.
If you interview for an R&D position at (e.g.,) a biotech company, in academia, or one of the National Labs, you're usually asked to prepare a 30-45 minute presentation about your past work. New grads usually use their MS/PhD thesis defense slides; other folks often have a conference talk they can expand. Some places also do "chalk talks" where you describe how you'd approach a new problem of your or their choosing.
This presentation is the jumping-off point for the rest of your interviews. If you talked about building a compiler, someone is going to ask for details about the lexer, maybe have you do implement a very simple tokenizer on a white board. Another person will ask how you measured its correctness/performance. Yet another may dig into how you organized the team doing the work, etc.
Maybe, as you propose, someone else helped with parts of the work. This wouldn't necessarily weed that out. Nevertheless, I'd argue that being able to justify the decisions that were made--and cogently explain when/why they might be different--isn't actually BS; it's understanding.
What happened to references? That’s an easy way to verify if someone is bullshitting. It is possible to bullshit your way through interviews (there’s a whole industry to help you do just that) and not know good software engineering patterns.
Most companies won't do references beyond verifying employment. Then you relying on professional references, and are they lying?
This is pretty pretty much what I tried to achieve here
https://github.com/philbert/take-home-tech-test
The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to.
Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the readme. During the interview we get the candidate to demo the project and any questions that came up in our code review we ask at the stage of execution in the project demo. The interview lasts for 2 hours and we’ve had several rounds of candidates put through this process.
Both we as interviewers and the feedback from candidates has been very positive. The interview ends up being a day-to-day normal experience within the team and this really helps us to gauge the team fit. I think this helps to hire people that compliment and expand our skill set rather than hire people who are basically ourselves.
The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to.
Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the readme. During the interview we get the candidate to demo the project and any questions that came up in our code review we ask at the stage of execution in the project demo. The interview lasts for 2 hours and we’ve had several rounds of candidates put through this process.
Both we as interviewers and the feedback from candidates has been very positive. The interview ends up being a day-to-day normal experience within the team and this really helps us to gauge the team fit. I think this helps to hire people that compliment and expand our skill set rather than hire people who are basically ourselves.
I feel like this is a pretty big ask to do for an interview, unless you happen to have it lying around already.
Yep, agree. 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws. The 5% that isn't, has no place in an interview. It's a bunch of brittle glue code automating and backing up data between my devices.
"Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest...
Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the interview. If i'm lucky I get a problem i've not seen before and actually have to use my brain during the interview.
"Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest...
Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the interview. If i'm lucky I get a problem i've not seen before and actually have to use my brain during the interview.
Isn’t the time spent memorizing leetcode similar to the time spent building a side-project?
I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.
I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.
No, it’s not, because take home assignments are not typically reusable. Learn leetcode and it is valuable at most companies you will apply to. It’s more respectful of your time.
I was comparing leetcode to sideprojects, not take home assignments. The parent company was also talking about side projects.
Side projects will help you learn useful skills and it is the suggestion of OP that it should be used by more companies in place of leetcode interviews.
Btw, a lot of companies don’t use leetcode for hiring. In my last job hunting season, I would guess than less than 20% of processes used leetcode. Pretty far from “most” companies.
Side projects will help you learn useful skills and it is the suggestion of OP that it should be used by more companies in place of leetcode interviews.
Btw, a lot of companies don’t use leetcode for hiring. In my last job hunting season, I would guess than less than 20% of processes used leetcode. Pretty far from “most” companies.
Completely agree re the value of having side projects. I wish I had the luxury of time right now, maybe in a few years once the kids are older.
The leetcode dance is, at least for me at this point, much lower effort than starting a side project on the understanding the code I produce will be reviewed during interviews. It's like Sudoku, once you've done a "few", you get to the point where you're able to solve them quickly.
The leetcode dance is, at least for me at this point, much lower effort than starting a side project on the understanding the code I produce will be reviewed during interviews. It's like Sudoku, once you've done a "few", you get to the point where you're able to solve them quickly.
> Isn’t the time spent memorizing leetcode similar to the time spent building a side-project?
The nice thing about leetcode it is easy to bound the time to what you can handle. I do one puzzle a week and set a timer for 20 minutes. Then I get the answer and browse the forum. It's basically the equivalent of solving the Sunday crossword for me, and it keeps my algorithm skills sharp. Probably no worse than burning a lunch hour on HN.
The nice thing about leetcode it is easy to bound the time to what you can handle. I do one puzzle a week and set a timer for 20 minutes. Then I get the answer and browse the forum. It's basically the equivalent of solving the Sunday crossword for me, and it keeps my algorithm skills sharp. Probably no worse than burning a lunch hour on HN.
I do my side projects the same way
> 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws.
True, but would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP (like util functions, and an integration syncing records from your backend the Salesforce, or something tangential to the business outside the core product)
May technically be breaking your employment agreement, but I can’t imagine it would be too hard to pluck out a decent amount of code, and re-write portions of it if necessary to “anonymize” it for interviewing purposes.
Or if you happen to be interviewed by someone like me, my approach is simply “if you can’t show me the code, show me the UI and explain how the backend / frontend works, and a discussion ensues.
True, but would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP (like util functions, and an integration syncing records from your backend the Salesforce, or something tangential to the business outside the core product)
May technically be breaking your employment agreement, but I can’t imagine it would be too hard to pluck out a decent amount of code, and re-write portions of it if necessary to “anonymize” it for interviewing purposes.
Or if you happen to be interviewed by someone like me, my approach is simply “if you can’t show me the code, show me the UI and explain how the backend / frontend works, and a discussion ensues.
> True, but would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP
What? Yes. I expect I'd be in prison for a few years. Your interview approach selects for people who don't follow their NDAs
Sergey Aleynikov went to prison over copying GPL code.
What? Yes. I expect I'd be in prison for a few years. Your interview approach selects for people who don't follow their NDAs
Sergey Aleynikov went to prison over copying GPL code.
As mentioned in my original comment, if someone isn’t comfortable showing me the source code I simply ask for them to describe how it works, challenges in building it, how they built it, etc.
I could do this and would welcome this type of interview experience. I'd be able to talk in general terms about the problems I work on and their solutions but not the low level specifics.
To add some context, my work is in Financial Services, trading systems and whatnot.
To add some context, my work is in Financial Services, trading systems and whatnot.
> would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP
Who decides what is "critical IP" and what is not?
This is a terrible advice, and no, you should never copy code from a work project without being pre-authorized to do it.
It's not just common sense, but you also might trip up over unexpected legal issues (licences etc) that you may not even be aware of.
Who decides what is "critical IP" and what is not?
This is a terrible advice, and no, you should never copy code from a work project without being pre-authorized to do it.
It's not just common sense, but you also might trip up over unexpected legal issues (licences etc) that you may not even be aware of.
I would immediately end my interest in a company if I was asked to do this. This is far too general a problem, which will harm the interviewer as much as it will harm the interviewee.
Contrast it to giving a candidate some slightly broken code in a framework related to the role and then asking them to a)fix it and b)implement a new feature of their choosing and document it.
The advantages of the latter approach:
* The interviewer doesn't need to prep beforehand as they already know both the problem and the codebase. This means they can ask much more interesting questions and don't have to invest significant time in reviewing a project that might be in a field in which they have no experience. This in turn leads to better discussions which in turn leads to better interviews.
* The candidate is given a much tighter problem definition and isn't required to come up with something a)novel, b)not covered by their current employer's NDAs.
* The candidate's time is respected because they can be told how long it should take them up front.
* Each candidate gets a standardised problem and so it's easier to compare between them.
When I give take-home assignments, I'm just looking to quickly confirm that someone has a working home dev environment (i.e. they don't just code inside environments that other people give to them) and that they can understand a small codebase and write clean code and document it. Everything beyond that I can find out by talking to them during the interview.
When I actually used this technique in interviews it was interesting to see how many supposed senior engineers would reply with things like "I'm getting a %JAVA_HOME NOT FOUND error, please can you fix the repo and let me know when it's ready for me to work on?".
Contrast it to giving a candidate some slightly broken code in a framework related to the role and then asking them to a)fix it and b)implement a new feature of their choosing and document it.
The advantages of the latter approach:
* The interviewer doesn't need to prep beforehand as they already know both the problem and the codebase. This means they can ask much more interesting questions and don't have to invest significant time in reviewing a project that might be in a field in which they have no experience. This in turn leads to better discussions which in turn leads to better interviews.
* The candidate is given a much tighter problem definition and isn't required to come up with something a)novel, b)not covered by their current employer's NDAs.
* The candidate's time is respected because they can be told how long it should take them up front.
* Each candidate gets a standardised problem and so it's easier to compare between them.
When I give take-home assignments, I'm just looking to quickly confirm that someone has a working home dev environment (i.e. they don't just code inside environments that other people give to them) and that they can understand a small codebase and write clean code and document it. Everything beyond that I can find out by talking to them during the interview.
When I actually used this technique in interviews it was interesting to see how many supposed senior engineers would reply with things like "I'm getting a %JAVA_HOME NOT FOUND error, please can you fix the repo and let me know when it's ready for me to work on?".
We've been using it for DevOps roles which are not highly specialised in any particular technologies and require ability to solve problems at a general level.
The test is intentionally designed to filter out candidates who cannot meet or do not want to meet the technical requirements.
The test is intentionally designed to filter out candidates who cannot meet or do not want to meet the technical requirements.
Fair enough, maybe that works better in devops, but it seems like it will filter out candidates who have a good work/life balance.
> You do not have to start a new project from scratch. It’s perfectly fine to submit something you have previously created yourself. Maybe it’s something you work on in your spare time, just for yourself!
Yeah, no, nobody is or should be giving you their own personal work. It's offensive and probably illegal that you'd even ask.
> The novelty and creativity of your submission
Yeah, no.
Yeah, no, nobody is or should be giving you their own personal work. It's offensive and probably illegal that you'd even ask.
> The novelty and creativity of your submission
Yeah, no.
This is a really bad take-home exercise, because it is way too vague. This vagueness makes it very hard for me to decide how much time to devote to it, and what task is complex enough so that you will consider it, but not too small so that you don't throw it away. Instead of giving me a bar to jump over, you make the bar invisible, then expect me to jump just above it. So I hope you do have a default project for those who are not "creative"... at least not for the purposes of a job interview...
Red flag test. Vague, no guidance around how much time to spend, no guidance around where to focus from a technical perspective (i.e. build anything/everything), bias towards someone who already has some related code completed. Given the lack of clarity, accurately assessing one candidate vs another would be difficult. It also comes off as lazy.
I don't think that style of interview provides as much signal as you think it does. I would probably say that watching someone work through a problem provides more signal than having someone explain a problem they have already solved. That's why I feel that all of the companies I've been at, eventually ended up shifting the interview process to do less "explain a project" and converging more on "talk us though these different types of problems". And then the past experience is what is being demonstrated when they show off how deeply and quickly they can think through the different types and bring their experience to bear.
I also just generally do not think that most people can even put together a 2-3 hour presentation of their past work that goes over well. Most of the time people can't really talk more than 30 minutes about past projects. That requires a whole different set of skills, which there are certain contexts where I'd value that more highly. But my initial impression is that if we set up our interviews this way, we'd also end up filtering out a lot of people who'd be great, since not picking the perfect project to demo basically dooms the entire interview to be a flop. With multiple interview types, you increase the chance that there's an interview they really shine in.
I also just generally do not think that most people can even put together a 2-3 hour presentation of their past work that goes over well. Most of the time people can't really talk more than 30 minutes about past projects. That requires a whole different set of skills, which there are certain contexts where I'd value that more highly. But my initial impression is that if we set up our interviews this way, we'd also end up filtering out a lot of people who'd be great, since not picking the perfect project to demo basically dooms the entire interview to be a flop. With multiple interview types, you increase the chance that there's an interview they really shine in.
This is how I interview.
Show me something you've done that you're proud of. Take me through it in depth. Answer some questions on it.
Doesn't have to be a free-time project. If you don't have a free-time project and you're too NDA'd to discuss previous work, then present some language feature or something.
Show me something you've done that you're proud of. Take me through it in depth. Answer some questions on it.
Doesn't have to be a free-time project. If you don't have a free-time project and you're too NDA'd to discuss previous work, then present some language feature or something.
I often administer a 45 minute version of this (talking about any/all past work, not necessarily side projects), as part of a half-day of interviews. We'd never be able to get into the depth you could in two hours, but we can get somewhere.
My experience has been that a lot of candidates can't even fill 45 minutes. I ask "what was the most interesting part?", "what was most technically complex?", "what would you do differently if you did it again?", and they just don't have nontrivial answers.
My experience has been that a lot of candidates can't even fill 45 minutes. I ask "what was the most interesting part?", "what was most technically complex?", "what would you do differently if you did it again?", and they just don't have nontrivial answers.
>and they just don't have nontrivial answers.
Yeah, because you can have a career where you're just gluing stuff together to make business apps for, usually, simple business problems. You're looking for craftsmen but you're interviewing plumbers.
Yeah, because you can have a career where you're just gluing stuff together to make business apps for, usually, simple business problems. You're looking for craftsmen but you're interviewing plumbers.
To extend the plumber analogy, prospective employers will frequently look for plumbers with specific experience in copper pipe, rigid PVC pipe, or flexible PEX pipe, as though fragmenting the plumbing space in this fashion has any bearing on whether or not the result will conform to building codes, ensure that all the drains and faucets work as expected, and generally solve any fluids transport problems that may come up without having to push the calendar to the right.
Most people look up the local business listings, pick anyone advertised as "plumber", and call to make a service appointment. Or they use a general contractor that already has a list of approved subs. Master plumbers don't have to answer little trick questions about brazing copper or about finding lead pipes in an old building. People somehow trust them to know what their job is, and do it.
Rarely, one might encounter an unreliable plumber. They might not get paid, and any other plumber is usually able to fix their botched jobs without hurting the budget much. Review sites exist to track building-trades business reputations.
But the analogy breaks, because no one trusts software and IT folks to do their jobs competently. The default assumption is that we are all know-nothing hacks who could destroy the company with one keystroke. All our knowledge is assumed to be tightly siloed, and does not transfer between similar technologies. C++ people can't do Rust or Go. Java people can't do C#. Desktop people can't do the cloud. Back-end people can't do UI. CMMI people can't be Agile.
It's madness.
Most people look up the local business listings, pick anyone advertised as "plumber", and call to make a service appointment. Or they use a general contractor that already has a list of approved subs. Master plumbers don't have to answer little trick questions about brazing copper or about finding lead pipes in an old building. People somehow trust them to know what their job is, and do it.
Rarely, one might encounter an unreliable plumber. They might not get paid, and any other plumber is usually able to fix their botched jobs without hurting the budget much. Review sites exist to track building-trades business reputations.
But the analogy breaks, because no one trusts software and IT folks to do their jobs competently. The default assumption is that we are all know-nothing hacks who could destroy the company with one keystroke. All our knowledge is assumed to be tightly siloed, and does not transfer between similar technologies. C++ people can't do Rust or Go. Java people can't do C#. Desktop people can't do the cloud. Back-end people can't do UI. CMMI people can't be Agile.
It's madness.
Quite often, though, you hire tradesmen and they're bloody terrible. More often than not. So i'm not sure this is a very motivating analogy.
I don't like it, but I get it. You can train for the algos, so just do what needs to be done and train for it. Maybe you don't like to do what needs to be done? Well, that filter worked.
Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular ;-)
Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular ;-)
> Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular
It's also hard to scale it, make it objective, and keep the efficiency high (most developers prefer not spending their time on either side of the interview table)
There is another advantage to the "algos". If you can learn algorithms then perhaps you can learn other things as well.
Every new job I've had involved quite a lot of learning in a very short period of time.
Learning whatever language, and whatever standard library is almost always trivial. They're usually not all that different, well documented, some with textbooks even.
Learning to navigate and reason about the huge number of undocumented, often arbitrary, system architecture decisions, design decisions, code layout, etc. etc. that make up real code bases.
That's hard. Really hard.
It's also hard to scale it, make it objective, and keep the efficiency high (most developers prefer not spending their time on either side of the interview table)
There is another advantage to the "algos". If you can learn algorithms then perhaps you can learn other things as well.
Every new job I've had involved quite a lot of learning in a very short period of time.
Learning whatever language, and whatever standard library is almost always trivial. They're usually not all that different, well documented, some with textbooks even.
Learning to navigate and reason about the huge number of undocumented, often arbitrary, system architecture decisions, design decisions, code layout, etc. etc. that make up real code bases.
That's hard. Really hard.
You can make it even more generic than that. A rather simple at first glance, but discussion provoking question: "What do you like and what do you dislike about the Technology X?". A good candidate who has experience with the said Technology X would not shut up on this subject. A bad one however will struggle. This is of course provided that you are hiring for some specific stack.
> experience with the said Technology X would not shut up on this subject
I've learned the hard way to be very reserved when giving opinions about technology X because interviewers sometimes get really defensive about the thing they like about technology X.
I've learned the hard way to be very reserved when giving opinions about technology X because interviewers sometimes get really defensive about the thing they like about technology X.
The bias in this approach is obvious. In your mind, you think a candidate "not shutting up" is a green flag, but the reality is you are trying to hire someone who thinks like you.
There are a million reasons why this approach doesn't work. Maybe they just don't like talking that much. Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it.
None of the above are good reasons to pass on a candidate.
There are a million reasons why this approach doesn't work. Maybe they just don't like talking that much. Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it.
None of the above are good reasons to pass on a candidate.
> but the reality is you are trying to hire someone who thinks like you.
Not really. If someone can present solid reasoning and argue their point well, they don't have to think like me. Three's more than one way to skin a cat.
> Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it.
You mean the technology they are being hired for? Yeah, hating, not caring about it is probably not a good motivator to go for the job then, wouldn't you agree?
> None of the above are good reasons to pass on a candidate.
Beats the whiteboarding. I was hired like that in my last 3 jobs and I have used the same approach myself with rather consistently good results.
Not really. If someone can present solid reasoning and argue their point well, they don't have to think like me. Three's more than one way to skin a cat.
> Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it.
You mean the technology they are being hired for? Yeah, hating, not caring about it is probably not a good motivator to go for the job then, wouldn't you agree?
> None of the above are good reasons to pass on a candidate.
Beats the whiteboarding. I was hired like that in my last 3 jobs and I have used the same approach myself with rather consistently good results.
Oh, well it sounds like you're doing everything right. This also probably scales really well.
Thanks for sharing - hopefully a lot of people will use your anecdotal evidence to impact the way they hire people too!
Thanks for sharing - hopefully a lot of people will use your anecdotal evidence to impact the way they hire people too!
You can sometimes. This is literally one of the interview questions I ask - tell me about a complex project.
In my experience I have seen some candidates that work very hard and mainly do boiler plate code in their projects, they struggle in the Algos/data structures but at the end of the day they get the job done. Others perform very good in Algos/data structures but produce very little at work, and also people that do good and perform above expectations. Is hard for me to actually filter good candidates, and at the end of the day, I value output and some quality.
Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews.
Even though this advice sounds awesome, I will be cautious of putting it into practice without thinking through the bias problem.
I do remember reading multiple research papers on this, but unable to find them at the moment. From anecdote - In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought. Most of it was comprised of "tech-bros".
Scripted interviews do not mean you ask through a basket of questions. It just means that you stay within the guardrails of a set of topics and you go through all the topics. With in a topic, you have fair amount of flexibility. For example if you are hiring for a mid level Java programmer your topics may include - Java 8, Testing pyramid, Functional programming, type safety, developer safety(CI/CD/Rollbacks/Code reviews/Pair programming etc), some domain specific knowledge and so on.
Even though this advice sounds awesome, I will be cautious of putting it into practice without thinking through the bias problem.
I do remember reading multiple research papers on this, but unable to find them at the moment. From anecdote - In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought. Most of it was comprised of "tech-bros".
Scripted interviews do not mean you ask through a basket of questions. It just means that you stay within the guardrails of a set of topics and you go through all the topics. With in a topic, you have fair amount of flexibility. For example if you are hiring for a mid level Java programmer your topics may include - Java 8, Testing pyramid, Functional programming, type safety, developer safety(CI/CD/Rollbacks/Code reviews/Pair programming etc), some domain specific knowledge and so on.
> In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought.
Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse?
As an interviewer I’ve always felt very constrained by scripted interviews and “approved question lists”. I always struggle to really evaluate a candidate when I’m asking pre-selected questions without knowing why I’m asking those questions.
Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse?
As an interviewer I’ve always felt very constrained by scripted interviews and “approved question lists”. I always struggle to really evaluate a candidate when I’m asking pre-selected questions without knowing why I’m asking those questions.
> Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse?
It did. And even if it had not in this particular case, it will hurt the company in the long run. There is not even a shred of doubt in my mind that diversity (of thought) is the best investment that leads to success.
I have been using scripted interviews, the same method I mentioned in original comment, for more than 5 years now, hiring more than 200 engineers in three continent and I am super happy with my results.
It did. And even if it had not in this particular case, it will hurt the company in the long run. There is not even a shred of doubt in my mind that diversity (of thought) is the best investment that leads to success.
I have been using scripted interviews, the same method I mentioned in original comment, for more than 5 years now, hiring more than 200 engineers in three continent and I am super happy with my results.
> It did. And even if it had not in this particular case, it will hurt the company in the long run.
Honestly, having been on plenty of interview panels for a decade now for DevOps and SRE roles, I'm not sure structured interviews, no matter how awesome they are, can solve the recruitment diversity problem. The war was already lost the moment the job description was published, IMO.
Honestly, having been on plenty of interview panels for a decade now for DevOps and SRE roles, I'm not sure structured interviews, no matter how awesome they are, can solve the recruitment diversity problem. The war was already lost the moment the job description was published, IMO.
I think it's also important to keep in mind that at minimum it would take a generation to truly solve in a root-cause way (one that won't just come back the minute you focus on something else). Many of these biases get built during childhood when your brain is so so much more plastic.
I'm not sure anyone in Kindergarten knows anything about having a job, let alone DevOps. =)
I have seen the same thing happening in recruitment for marketing roles. Totally unscripted interviews often leads to suboptimal results in terms of the quality of the candidate and their fit for the role. Made this mistake firsthand before devising my own process of hiring.
And the process I follow is based on having an exhaustive list of questions covering all areas of the role but during the interview if something else comes up, I don’t mind pursuing that and going unscripted. It often helps me add more questions to my list so my list of questions keeps improving.
I’ve been following this process for last couple of years and the structured process has helped me hire some of the best people I had the privilege of working with. Also, I feel more confident that I’m hiring the right candidate. But of course, there could be an element of bias in there.
Side point - I’ve just finished a SEO hiring guide that covers my whole process of hiring an SEO person (both junior and senior roles). Will be publishing that in the next 4-5 days. If anyone is interested in purchasing a copy, my email is in the bio.
And the process I follow is based on having an exhaustive list of questions covering all areas of the role but during the interview if something else comes up, I don’t mind pursuing that and going unscripted. It often helps me add more questions to my list so my list of questions keeps improving.
I’ve been following this process for last couple of years and the structured process has helped me hire some of the best people I had the privilege of working with. Also, I feel more confident that I’m hiring the right candidate. But of course, there could be an element of bias in there.
Side point - I’ve just finished a SEO hiring guide that covers my whole process of hiring an SEO person (both junior and senior roles). Will be publishing that in the next 4-5 days. If anyone is interested in purchasing a copy, my email is in the bio.
Research shows more diverse teams deliver better results. You’re asking something that can’t be proven though: is this thing that is occurring better than the thing that didn’t occur. We can’t know the answer to that.
> Research shows more diverse teams deliver better results.
FYI, there's plenty of nuance in the research that people like to gloss over. My understanding is that diversity of background / experience improves team performance. But having a diversity of values amongst your team decreases performance.
For example, if you form a diverse team where some people care about profits above all else, and other people care more about doing good in the world, the team will become less effective. Its really hard to use this research when hiring because a lot of values questions (like "who did you vote for?") are somewhere between creepy and illegal to ask.
Source: I used to work with someone who had a PhD in psychometric assessment. People saying "diversity=good" was one of her bug bears. I haven't read the research myself.
FYI, there's plenty of nuance in the research that people like to gloss over. My understanding is that diversity of background / experience improves team performance. But having a diversity of values amongst your team decreases performance.
For example, if you form a diverse team where some people care about profits above all else, and other people care more about doing good in the world, the team will become less effective. Its really hard to use this research when hiring because a lot of values questions (like "who did you vote for?") are somewhere between creepy and illegal to ask.
Source: I used to work with someone who had a PhD in psychometric assessment. People saying "diversity=good" was one of her bug bears. I haven't read the research myself.
Would it be illegal/creepy to ask then to sort a list of propositions or something like that?
I would ask if there was any published studies showing that "diversity of values" was bad, because searching Google for "diversity of values bad" does not yield any relevant results.
Then I would ask what her political leanings were next.
Studies seem to show that diversity initiatives fail mostly because of a lack of comprehensive diversity and inclusivity effort, e.g. companies talking big about it, but not backing it up with action, money, people, etc.
Then I would ask what her political leanings were next.
Studies seem to show that diversity initiatives fail mostly because of a lack of comprehensive diversity and inclusivity effort, e.g. companies talking big about it, but not backing it up with action, money, people, etc.
So which one is it? Is it"already shown by research" or "something that cannot be proven". You can't have it both ways.
What I said was:
> Research shows more diverse teams deliver better results. You’re asking something that can’t be proven though: is this thing that is occurring better than the thing that didn’t occur. We can’t know the answer to that.
Research is based on the cumulative results of many recorded events, in which we try to garner a pattern of relationship.
A singular event might have two inputs: we either do the thing or we do not. We can observe the results of what we do, but we cannot observe the results of what we do not. With the aforementioned research, we can _estimate_ the results, and, in some cases, we should make decisions with those estimates in mind, but these are two entirely different concepts. Macro and micro.
> Research shows more diverse teams deliver better results. You’re asking something that can’t be proven though: is this thing that is occurring better than the thing that didn’t occur. We can’t know the answer to that.
Research is based on the cumulative results of many recorded events, in which we try to garner a pattern of relationship.
A singular event might have two inputs: we either do the thing or we do not. We can observe the results of what we do, but we cannot observe the results of what we do not. With the aforementioned research, we can _estimate_ the results, and, in some cases, we should make decisions with those estimates in mind, but these are two entirely different concepts. Macro and micro.
> Research shows more diverse teams deliver better results
Seems like a bit of a sacred cow - how much better? Better enough to sacrifice, say, experience, contacts, or unique business knowledge for? How much, exactly?
Seems like a bit of a sacred cow - how much better? Better enough to sacrifice, say, experience, contacts, or unique business knowledge for? How much, exactly?
Odd comment. We hate the tech interview because it doesn't fairly evaluate on the job performance of candidates, but apparently it's ok to reject them because they don't fit the interviewer's tribe.
I wonder when will diversity require to also be skill-wise: like it is required to have someone on your team who cannot code at all, just for the sake of bringing "different perspective".
Aren't most teams already fairly multi-disciplinary comprised of product managers, UI/UX, and other skill sets?
It also means you have definitive qualifications for correctness. It’s harder to say “I’m not sure about this person,” when they quantitatively answered every question correctly. If you “have a conversation,” it’s a lot easier to have those itches, which might be primarily driven by bias, make your hiring immediately become problematic.
How is diversity of thought measured?
Standard precog manual, page 46.
Lack of diversity of thought is easy to spot IMO. Bigger point is - you should ensure your processes are setup to at least try to achieve the kind of diversity you would like to achieve. Those processes may still fail, just like anything else.
I honestly don’t comprehend this answer. You mentioned unconscious bias in interviews:
> Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews.
Yet, lack of diversity of thought is “easy to spot”. Without being swayed by unconscious biases?
> Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews.
Yet, lack of diversity of thought is “easy to spot”. Without being swayed by unconscious biases?
You are taking diversity of thought comment, which I mentioned as an attribute of a team and trying to apply to an interview, which is not what I intended. Your interview processes need to ensure that you do not hire based on biases, so that you will have a diverse team.
Also interview processes are not just interviewer protecting against his/her bias, but also against bias of interviewee which seems to be somehow lost in these discussions.
Also interview processes are not just interviewer protecting against his/her bias, but also against bias of interviewee which seems to be somehow lost in these discussions.
If someone answered every question the way the interviewer thought it should be answered that is probably an indicator of lack of diversity of thought, but I think it would actually be hard to spot because they would really look like the perfect candidate - unless the interviewer thought of themselves as a bad candidate / unoriginal thinker - which is unlikely.
On the other hand someone answers in a way that you have decided before hand is just the misguided answers of a particular tribe can be lack of diversity of thought, because you happen to be right about the preconceived ideas of said tribe, but pretty hard not to see that as the result of bias.
If on the other hand someone says some things you don't understand, espouses ideas completely alien - insane!
on edit: clarification
On the other hand someone answers in a way that you have decided before hand is just the misguided answers of a particular tribe can be lack of diversity of thought, because you happen to be right about the preconceived ideas of said tribe, but pretty hard not to see that as the result of bias.
If on the other hand someone says some things you don't understand, espouses ideas completely alien - insane!
on edit: clarification
By asking questions and comparing the answers.
I'm going to go out on a limb here and say I think most candidates don't hate scripter interviews, they hate robotic interviewers that go mindlessly through a checklist.
When I train interviewers my advice is: have a script, but be happy to go off it. If interviewers keep an authentically engaged conversation, the questions will blend into the background.
Scripts helps in several fronts. They help to reduce bias, standardise calibration and practices between teams, and provide a fallback to get the interview on track. However good interviewers should keep a living conversation with candidates, and take interesting cues off script.
When I train interviewers my advice is: have a script, but be happy to go off it. If interviewers keep an authentically engaged conversation, the questions will blend into the background.
Scripts helps in several fronts. They help to reduce bias, standardise calibration and practices between teams, and provide a fallback to get the interview on track. However good interviewers should keep a living conversation with candidates, and take interesting cues off script.
> I do remember reading multiple research papers on this, but unable to find them at the moment.
That’s too bad, because the obvious followup question is whether those papers survived the replication crisis.
That’s too bad, because the obvious followup question is whether those papers survived the replication crisis.
Some of these are great tips and I agree wholeheartedly.
However, in personal experience, I've found that this works much better with more experienced developers rather than with junior engineers. Why? Because for some reason, a lot of junior engineers have been pavlov-ed into thinking every interview is for something at Google/Facebook scale (no matter where they are interviewing) and they start describing extremely convoluted designs using tech that they are also not completely familiar with just because they want to come across as knowledgeable.
Something that I struggle with in these cases is reining in the dev back to the "what" rather than the "how", because I've seen even good engineers go into this "let's add a system-bus for everything" way of thinking. Constraining problems explicitly tends to devolve into the "Interviewer-Interviewee information asymmetry" which is the same with most DSA problems (At least with DSA, most constraints are known by both parties).
On the other hand, almost every time I've picked an actual problem we have with a system, be it a bug or a new product or something else, as an interview question with an experienced interviewee, I feel like I've come out understanding the problem space AND solution space better just through the process of discussion and in multiple cases, actually ended up using a lot of ideas from these discussions, so interviewing feels much more "natural" and a "dominant strategy" in game theoretic sense.
However, in personal experience, I've found that this works much better with more experienced developers rather than with junior engineers. Why? Because for some reason, a lot of junior engineers have been pavlov-ed into thinking every interview is for something at Google/Facebook scale (no matter where they are interviewing) and they start describing extremely convoluted designs using tech that they are also not completely familiar with just because they want to come across as knowledgeable.
Something that I struggle with in these cases is reining in the dev back to the "what" rather than the "how", because I've seen even good engineers go into this "let's add a system-bus for everything" way of thinking. Constraining problems explicitly tends to devolve into the "Interviewer-Interviewee information asymmetry" which is the same with most DSA problems (At least with DSA, most constraints are known by both parties).
On the other hand, almost every time I've picked an actual problem we have with a system, be it a bug or a new product or something else, as an interview question with an experienced interviewee, I feel like I've come out understanding the problem space AND solution space better just through the process of discussion and in multiple cases, actually ended up using a lot of ideas from these discussions, so interviewing feels much more "natural" and a "dominant strategy" in game theoretic sense.
Interviews can be made much more useful and pleasant simply by making a subtle change - instead of finding out/exposing what the interviewee does not know, find out what they do know.
I recently had the best interview experience of my life from an interviewer who had this philosophy. He's a professional interviewer who's done thousands of interviews over the past few years. He feels that the best way to gauge a candidate is not by their knowledge of minutia, but by whether you can trust the things they claim about themselves.
He's so passionate about the subject that he created a Youtube channel. It's aimed at both interviewers who want to do a better job and interviewees who want to influence their chances of success. https://www.youtube.com/playlist?list=PLhCnsRMXhadbiHsTcxMCg...
He's so passionate about the subject that he created a Youtube channel. It's aimed at both interviewers who want to do a better job and interviewees who want to influence their chances of success. https://www.youtube.com/playlist?list=PLhCnsRMXhadbiHsTcxMCg...
This works for me.
I usually would do three things. One show me or tell me about some code you are proud off, some code you are not proud off and what your learned from it and finally teach me something interesting that can be code or something else.
I’m looking for confidence, ability to accept making mistakes and improving and finally the ability to convey information in a teachable fashion.
I’m looking for confidence, ability to accept making mistakes and improving and finally the ability to convey information in a teachable fashion.
Sorry. Countless articles have been written about how interviews should be conducted. But nothing changes. There are thousands of engineers vying for FAANG/MAMAA and they’ll do backflips to get a job there; leetcode is nothing for them. Some do it to get better salaries as your compensation drops after the 4 yr cliff, some for prestige. So unless you can influence these companies to change nothing will change.
Interviews have the benefit of appearing equal at least - everyone is asked exactly the same questions.
Discussions might run the risk of appearing to give some people an easier ride than others.
I can interview any developer and by asking the right questions prove they are an incompetent fraud.
It’s a simple matter of asking the right questions.
Who’s wrong and who’s right?
The interviewer is always right.
If you don’t know what I think you should know then you’re incompetent.
It’s a simple matter of asking the right questions.
Who’s wrong and who’s right?
The interviewer is always right.
If you don’t know what I think you should know then you’re incompetent.
Any interview should be simple. You just have to not be a jerk:
-threat the guy as a human being, showing respect and kindness
-try to understand his mental processes
-try to asses his knowledge level by meaningful discussions, no "tricky questions" or "leetcode"
-ask to explain what he work on, what decisions he took and why
-explain some of your actual work issues and ask how he would address them
-do not try to make yourself look smart while trying to make your interlocutor look stupid
-threat the guy as a human being, showing respect and kindness
-try to understand his mental processes
-try to asses his knowledge level by meaningful discussions, no "tricky questions" or "leetcode"
-ask to explain what he work on, what decisions he took and why
-explain some of your actual work issues and ask how he would address them
-do not try to make yourself look smart while trying to make your interlocutor look stupid
As a person who used to take interviews, I thought discussions were the best way to figure out if someone is competent.
I mean, when I ended up in a discussion with someone, I felt like I did great. I had a good time and it frequently led to an offer.
As someone who's now interviewing a person or more every week (during a hiring surge), I still don't know of a better way to interview someone, but I'm not convinced this is great. A lot of people, who are unquestionably smart, coming into the interview after long careers in big companies, have a lot of trouble expressing themselves (especially if it's not in their native language), let alone selling themselves. They come in trying to find the correct answer for each question, even if it's open ended questions to trigger discussion. And when asked for a concrete answer to something, they will instead fumble around, only touch upon the answer, and talk about something that distracted them.
We still frequently hire people who interview like that, but it takes a lot of thinking and extrapolating.
I'm still not sure what to do.
As someone who's now interviewing a person or more every week (during a hiring surge), I still don't know of a better way to interview someone, but I'm not convinced this is great. A lot of people, who are unquestionably smart, coming into the interview after long careers in big companies, have a lot of trouble expressing themselves (especially if it's not in their native language), let alone selling themselves. They come in trying to find the correct answer for each question, even if it's open ended questions to trigger discussion. And when asked for a concrete answer to something, they will instead fumble around, only touch upon the answer, and talk about something that distracted them.
We still frequently hire people who interview like that, but it takes a lot of thinking and extrapolating.
I'm still not sure what to do.
The problem is that "Summarise a project you have worked on in a few minutes" isn't a task you normally do at your job either, software engineers job is to care about the full picture and ensure it all works together without missing any details, making quick explanations that are fit for small talk has nothing to do with it. If the engineer is expected to talk to a lot of non-engineers then that might be a good signal, but for other more technical roles it isn't needed at all.
So your process will select for people who love to smalltalk about stuff, they will look great. But many great engineers doesn't love to smalltalk about stuff, it isn't a part of being good at the job.
So your process will select for people who love to smalltalk about stuff, they will look great. But many great engineers doesn't love to smalltalk about stuff, it isn't a part of being good at the job.
I read a lot of anti-diplomas ideology, especially from US culture. Over the years I've realized that the multi-years selection people go through in academia is a decent and most importantly long process to select people.
A lot of the conversation is on interviews these days, on the idea that anyone can be a genius programmer after a bootcamp. While I don't deny it's possible, I think traditional selection based on the school people went to, and building a relationship between companies and school is a good thing.
Trying to holistically evaluate a worker in a few hours is not nice. It's very intense for candidates to have such opportunities to unlock in such a short time. People prepare for interviews intensely, and can live rejections as a deep traumas as a result. Having this process happen over years in academia seems healthier, and more accurate.
Companies would benefit from having their HR spend time studying curriculums of some schools, and build relationships. That guarantees a steady flow of qualified workers.
I see this where I live here in Japan, and I'm quite found of the work culture / society it produces.
A lot of the conversation is on interviews these days, on the idea that anyone can be a genius programmer after a bootcamp. While I don't deny it's possible, I think traditional selection based on the school people went to, and building a relationship between companies and school is a good thing.
Trying to holistically evaluate a worker in a few hours is not nice. It's very intense for candidates to have such opportunities to unlock in such a short time. People prepare for interviews intensely, and can live rejections as a deep traumas as a result. Having this process happen over years in academia seems healthier, and more accurate.
Companies would benefit from having their HR spend time studying curriculums of some schools, and build relationships. That guarantees a steady flow of qualified workers.
I see this where I live here in Japan, and I'm quite found of the work culture / society it produces.
That's good except, as you point out, in the US where schools are paid by the individual. At least some of the anti-diploma sentiment here in the US is because we understand that it would just result in "people born rich are the only ones who can get hired for good jobs".
I don't think there is anything you can do to prevent rich kids from having an easy life.
They are not numerous though, but definition. So the concern shouldn't be too large as well. In France where i'm from, and also here in Japan, i see the education system as mostly working. People get educated and the people more designed for more study can pursue while other go working before them. This seems to work enough to me. I wouldn't know how to improve it without regressing more on other fronts, for instance
They are not numerous though, but definition. So the concern shouldn't be too large as well. In France where i'm from, and also here in Japan, i see the education system as mostly working. People get educated and the people more designed for more study can pursue while other go working before them. This seems to work enough to me. I wouldn't know how to improve it without regressing more on other fronts, for instance
Some of these comments, like attending to relative position in space, remind me of Phil Agre's fantastic "How to Help Someone Use a Computer" (1996) – https://pages.gseis.ucla.edu/faculty/agre/how-to-help.html
Phil's instructions mix some good influences and can be used when working with people in other mediated spot environments like interviews/discussions too.
Phil's instructions mix some good influences and can be used when working with people in other mediated spot environments like interviews/discussions too.
This is a way to go for me. It would be great to brainstorm and discuss things relevant to the industry or in the real world.
I just got a development job where there was no whiteboarding, no linked list implementing, no balancing a red-black tree, etc. They just asked me to talk about some of my previous projects that interested them. Maybe things are changing. Or maybe it's as the CTO said to me "it's hard to hire people right now". At any rate, I was pretty happy with this kind of interview.
The problem with this piece is that it spends more time discussing a word change that how to make interviews more like actual discussions.
The word "boss" was original chosen because it avoided implications of a power dynamic between the boss and the worker. Centuries later, it has re-acquired the same connotation.
The word "boss" was original chosen because it avoided implications of a power dynamic between the boss and the worker. Centuries later, it has re-acquired the same connotation.
Life's too short to be stuck with mediocre employers.