Tell candidates what to expect from your job interviews
jvns.ca
jvns.ca
In general, I haven't been disappointed on this front, but I fear that many people are. If you want to be super transparent about the interview process, you should probably define what compensation range you're going to offer and realize that some candidates will simply never contact you. Saves everyone time.
A lot of interviewing processes are kind of like fishing. They hope that if they wasted you 6-10 hours of your time before an actual offer then you'd make a decision based on the sunk cost fallacy ("not sure how much time the other companies will waste me, let's take this one on their offer, it's not so bad").
I am glad that your experience has been positive but as you correctly intuited yourself, many others' experiences are very far from it.
(To clarify, the employer I started onboarding with is nothing like that; I am talking about all the others that I talked with before I stumbled upon them.)
Suddenly, managers, hiring committees, and recruiters will stop wasting people’s time and everyone will know what to expect to get paid!
A compromising variant I found is to make public the GitHub repos where I did homework assignments, with the company name removed and with the README enriched to clearly explain what was the task and how was it successfully done (although I do that preliminarily regardless).
At one point 4 companies told me that they actually went through my accumulated interview assignments in GitHub and liked them and wanted a HR/manager interview without the tech interview before, which was a pleasant surprise.
It is essentially a counterpart of the joke abuse of the current system of building software by giving out pieces as "code interview questions" and never hiring anybody. Actually being able to devise and intergrate such a thing would probably be cheaper and less effort to do the work yourself.
Lessons learned though. I quickly started putting very steep conditions on the table in response to employers whose conditions I had reservations about. It worked. 99% bailed out, only 2 agreed with my conditions. But by then I had much better offers overall so it didn't help them.
You might be overthinking this. I doubt many companies really have this viewpoint for the simple fact that falling for this is a trait of a bad employee. You don't want to actively select your employees based on their flawed decision making process.
But there are bad employers out there, be sure of it. Some of them definitely do employ that tactic. Might be unconsciously but they do.
They definitely lack the self-awareness to know what does it mean to hire a bad employee. They kind of just go through the motions.
One skill I never wanted to have but gradually developed pretty well was to recognize early such employers and bail out.
I don't know how exactly people in HR are rewarded, but I have noticed a few situations where the company had a generous salary range in mind, but HR fought against mentioning it. It didn't make sense from the company perspective, because the company wanted the people, and the salary was above market average so the potential candidates would have liked it too. The resistence of HR makes me suspect that their incentives didn't align with the company interest, but I have no idea how specifically.
Believe me, interviewing is a huge cost for the company and nobody wants to organize interview to "fish" for the candidates.
We have screening process to remove candidates that don't have chance passing next stage so that we can spend more time with candidates that pass screening.
It is really difficult to figure out if you want to work with somebody after 1.5-2h discussion.
For 2 hour interview I must fit following things:
* Spend 5 minutes getting everything to order, bringing water, solving connection problems etc.
* Spend couple minutes introducing myself, who we are and what we are doing
* Spend couple more minutes trying to calm the candidate, break the tension. People react very differently to stressful situation and we would really want to get the candidate little bit more calm to level the field (we don't want just the people that deal well with stress).
* Ask couple technical questions from various areas. I can understate how difficult is to gauge candidates knowledge and experience from 30m of technical questions
* Give a coding task. I can't tell how many time we had a candidate that was able to answer questions quite well but was unable to organize process to write simple piece of code. It is when the candidate is solving the task when we learn for example if the candidate can react to hints or how it feels to have a discussion on a technical problem. This typically takes 0,5h to 1h
* Have a discussion on the candidate experience, past projects, what was his/her involvement, etc.
* Let the candidate ask his/her own question about our project.
* Spend couple of minutes to close the discussion on a good tone regardless of how the candidate fared.
Our HR does not like us to extend the discussion over 2h supposedly because it "scares" candidates but you have to understand, it is very difficult to do all of this and get to know the candidate in such a short time. I can totally understand somebody wanting to spend couple more hours with a candidate that shows really good promise.
Hiring a bad employee is a huge cost and totally worth spending couple more hours trying to ensure this person does not have "dealbreaking" faults.
You would not believe what kind of things I met in my past. Candidates who passed technical questions really well just to start googling solution to our coding task? Candidates we give the same critical hint 5 times and each time he/she tells me that's not right and dismissed to go continue with his/her faulty line of reasoning?
The problem with these HN discussions is that they attract the good apples from both sides while the bad apples won't ever read and correct their practices by participating in these threads. We kind of put ourselves in a rather positive filter bubble here and that can skew our reality a bit.
I wish I've met more interviewers like you during my nightmarish 4 months of job hunting that just finished 1-2 weeks ago.
I'm actually a little shocked that this person whose job it is to interview and hire people seems to say that all these basic things like setting up for the interview, reading over the person's resume, and so on are /chores/. I mean, maybe they're not the most fun things I agree, but the approach seems way off, as if they're just trying to get it over with and check the boxes. Then they talk about defusing stressful situations multiple times, why? I get the feeling that they're creating a stressful environment for both sides.
Then the coding while watching part. That sounds just awful, I'm sorry. While this is part of your job within normal hours, the candidate is likely taking time off or doing it after hours (unless they're unemployed, but still). I don't know how you're actually "giving hints", but this just sounds really uptight and stressful. I'd wager you're really taking people out of their environment and setting them up for failure by doing this. Why is it a problem that they google the answer to your question? That doesn't strike me as wrong at all. Sounds like a good developer and I could see this going into a very healthy discussion about how they'd solve problems perhaps that weren't so obvious from googling.
I don't mean anything against the parent. Just adding my $0.02.
I just said it is difficult to do all of these well within 2h limit. This was to contrast with other people balking at longer interviews.
Also, if I ask the candidate a question or give a coding problem to solve I expect them to be intelligent enough to understand I don't want them to google the solution. Everybody knows what the interview is and what it is for.
If I wanted them to google the solution I would ask to perform the task at home EXCEPT I find giving the task to be done in own time unfair and unethical practice.
It is unethical because by spending no effort at all I am motivating potential candidates to spend huge amount of their own time to polish the solution as much as possible.
It is unfair because it does not let me to get to know the candidate at all. It promotes candidates who are willing to waste huge amount of their time.
I'd love to do away with coding screens in general. I glanced at the doc for Stripe and it looks great. I'd have loved to read this doc, but the last time I applied to Stripe I got a HackerRank followed by an auto-rejection. I get why coding screens exist, but it's so annoying to be batted away because I failed blind automated tests.
tl;dr candidates are happy to give feedback whether or not you provide any yourself.
EDIT: I agree with you though. An interviewer should be ready and willing to provide feedback if the candidate signals that it would be welcome.
And at which point would this happen, I wonder? All the interviews I went through during the last 4 months didn't have one person sound inviting along the lines of "we won't take you but if you think we can improve our process do let us know". Not one even hinted at that. It's all very... impersonal, cold and often feels like copy-pasted emails are being to sent to the candidate.
You are kind of assuming -- way too generously -- that the process and the interviewers are actually open to feedback. Most people, including in tech companies, are happy to tick boxes and check in / check out at given times of the day, and do nothing else more creative or requiring special attention (like recruiting).
---
EDIT: I tried giving feedback -- unsolicited -- after the rejection in my first 5-6 interviews. Didn't go well. You could tell people got offended by very simple points like "would have helped if you told me you will measure me with one extremely specific test while I am looking for a generalist role" or "what was the value of imposing a hard deadline on a homework while the candidate is going through several interview processes in parallel? does that tell you anything about their real productivity?", and a few others like "I am not sure that teling me 'I am not like the others in the team' is a valid point in remote working conditions where comms are mostly async and people don't chat that much". Etc.
In the end you get tired hitting a brick wall. People are generally not receptive to feedback and even react in a hostile fashion when it is given to them. Plus when you want to go through 35-50 interviews, at some point you really start counting the hours that each company is taking away from you before rejection and you figure it's not worth it to try and present feedback where it's clearly not wanted.
I think there's some miscommunication happening here. The line you quoted is specifically regarding the person conducting the interview looking for signals to provide feedback to the person being interviewed, not the other way around.
I would not recommend providing feedback to your interviewer unless they explicitly ask for it. It's likely to just become a clash of egos, and if the company is larger then it's likely the interviewer doesn't even have much power over the process anyway. If you're being interviewed and hate their process and/or the way they communicate, the best thing you can do is politely inform them it is not a good fit, remove them from your list, and move on.
I also agree that the interviewer shouldn't just give feedback without asking because I know many interviewees will react badly.
It's just that in my case no feedback was wanted in either direction. And job-hunting is a game of numbers and evolution (okay, most of the time, definitely not always): you seek to adapt to the current conditions and see what you can improve upon for the next interview. Some feedback would have made your time and effort worth it. Giving you zero feedback wastes your time entirely though.
Perhaps if it were a third party.
Anyway, I wrote up a req and posted it to the usual career sites, and within a day, I had 500 resumes to review. About 490 of these had no real-world programming experience. They were all candidates from "boot camps", that, as far as I can tell, copied some example code into their GitHub and called it a day. (They listed each example project as "work experience", and many of the candidates had bit-for-bit identical repositories in their GitHub.) I would have been fooled if I had only seen one of these, but when you see hundreds of them all on the same day, you realize that investing in each candidate isn't possible. Even a 30 minute phone call to each candidate would have cost me an entire month of 8 hour workdays. Even a cursory review ("maybe this person actually did something other than the boot camp, let's look through GitHub") was excessively time-consuming. Even an email along the lines of, "sorry, we're looking for 5 years of experience for this senior position", is expensive.
So at that point, you have to somehow shift the cost onto candidates. It costs nothing to spam your resume to hundreds of companies, and I have no doubts that the bootcamps automate this process to some extent. That is why online coding tests exist. You have so many candidates in the pipeline that missing one good person is a cost that's acceptable for having to spend 30 minutes with someone that probably can't actually program. Is it impersonal? Yes. Does it suck for someone to be in limbo for forever because you are too lazy to write them an email saying "we're not moving forward with the process." Yes. But the submitting-resumes process scaled and was automated much more efficiently than the reviewing process. It's kind of like spam filtering now. (I get a ton of emails in my spam folder from people from HN that are email-blasting everyone on HN their projects. I get a ton of emails in my spam folder from people in open-source Slack channels that I read along the same lines. Is it unfortunate that I can't read and respond to every one of these emails? Yes. Does it suck that their "hustle" got detected by some machine-learning algorithm that has permanently blacklisted their company. Yes. But that is life -- attention is limited, a for loop that sends email isn't. So something has to give.)
I realize that it's confusing to say "we can't hire any engineers!" and at the same time throw 500 resumes into the trash can. But a resume is not equal to a hirable engineer. Anyone can make a resume. And, attracted to the high salaries of the software engineering field, many people do!
Anyway, I don't know what other fields are like, but I feel like the programming world is unique. You don't need extensive background -- university, internships, prior work experience. You can buy yourself a Python book and teach yourself everything you need to work at Google all by yourself. As a result, there are a lot of people that think they've taught themselves everything they need to work at Google all by themselves, but in fact can't actually do the job. As a hiring manager, your job is to filter the wheat from the chaff, and there is one grain of wheat in every ton of chaff. It's hard, and you're going to miss something. But, that is the world we built for ourselves. In other fields, there are other bodies in place that handle the filtering ("what's your Professional Engineer license number?"), but not in ours. As a result, the hiring process isn't as good.
I think we could do better, and I do appreciate people that I've emailed and wrote back "the process is over". But even that is hard to scale.
Internships seem super valuable to me. When I was at Google I had an intern every summer, and I basically dedicated my summer to teaching them everything they needed to know to be successful at Google or another big software company. Obviously, Google was 100% happy about this; I would go to weekly team meetings, say "all I did last week was spend days with $INTERN figuring out how to adjust build options for this new target" and the response was not "wow, you're lazy, get back to work" but "great!". Not every company can support that, though, which is why they're looking for people with experience. They want to pay money for getting work done, not pay money to have a senior engineer do no work for 3 months with the hope of someday having someone who can get things done by themselves. Again, it sucks, but that's how it is. Job training is EXPENSIVE. You can't always expect to get it for free. (That's why colleges exist, not that I think they do a great job.)
TL;DR: Practicing those coding challenges and how to write A* on the whiteboard is going to send a strong signal to companies that you're worth their time. It shouldn't be that way, but it is. "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." You have to ask yourself, do you want a job, or do you want to change the world. Changing the world is going to be a lot harder. Kind of sucks, but that's life.
If you have written your job description tailored to the ideal candidate you would have had a smaller candidate pool and a better match to the actual job.
"How to Apply to All Jobs on AngelList (Script)"
https://alejandrorioja.com/how-to-apply-to-a-lot-of-jobs-on-...
VERY debatable. I've chatted with dozens of HR and CTO people during the last 4 months of interviewing and looking for a job. They all complain "there are no good candidates". Without exception. (And I know you addressed that one paragraph below this quote.)
You're not wrong that selecting good candidates is extremely hard. I know it is. But the companies have to find a way to do better. I know many examples of world-class programmers being passed on by employers who, if they actually paid attention, would kill for them (and often times they contacted them anywhere from 6 to 18 months later, only to be predictably laughed out by the now-happily-employed person).
Actually, it's why other high-salary professions have professional licensing and advanced degree requirements.
Now that I'm older and I've interviewed a lot of people too, I realize sometimes life is un-fun and kinda sucks but you gotta do what you gotta do. There's a strong co-relation between people who spend two hours a night for three months studying algorithm questions and people who are willing to spend 8 hours a day debugging un-fun code. Which, more often than not, is what I need my team mates to do.
I work in AdTech. It's not particularly sexy. We don't have particularly sexy projects but we do have a large (millions of users per day) scale. A lot of our projects just require a engineer who has base level of experience plus a positive attitude and a slightly above average level of responsibility because we have to avoid outages. I need people to do work that is oftentimes not particularly fun but particularly important and revenue driving. My best filter, apart from actually having worked with the person for years beforehand, is asking a low-ball JavaScript "can you debug this asynchronous JavaScript" question.
So while the current system is frustrating, until we can figure out a best solution, unfortunately you just gotta play the game how the rules are laid out now.
I've practically [re-]invented Redis back in 2008 while working for a company, and wrote something very akin to the Google crawler bot in 2009 yet at some point 2 months ago I "fail" an interview because I didn't do the best possible optimization of a basic stock storage system that has packages at different weights (and valued in different currencies) and since I had to fit a whole mini web project in 2h I of course didn't pursue perfect optimization. But the thing was working pretty well and ticked all boxes that were required -- and perfect optimization wasn't mentioned otherwise I'd probably skip 1-2 features to achieve it and fit in the [arbitrary] schedule of the homework assignment.
And then boom, you are no good because of a hidden requirement and unclear communication which aren't my fault.
I do get your point. Really. But people put too much value on some pretty random questions / assignments as well.
I've gotten my last few jobs and oppertunities by following co-workers from job to job. AKA doing good work and building good relationships with the people I worked with. I've been able to leverage these relationships to skip the phone screen at some of the big tech companies but still freeze up on the the white board interviews unfortunately in real life.
At the end of the day though I know what I have to do: Either study for 3 more months, stay where I'm at with my current pay, or switch careers entirely. Right now I'm leaning towards switching careers entirely.
At the end of the day though, if you've never worked with a person before, and your company doesn't do a good job firing people who aren't performing, I'm not sure of a better way to screen people in 45 minutes :(. And this is coming from the guy who's screened out himself.
There's _plenty_ of engineers out there. We're not special.
One person who wrote a Python book was spot on in their conclusion: "At one point you should stop working as a programmer. You'll get no respect and your pay will be mercilessly negotiated down. Better to start another business and utilize programming as a secret weapon."
(Grossly inaccurate rephrasing but that was the gist of the paragraph.)
Still though, maybe you are too shy for the brutal game of numbers and chance that job hunting is even for seasoned programmers. That's fine. But you should know -- there are a ton of really mature and interesting people out there who know how to recruit. But it's a fact of life that you rarely find them; more often than not, they find you. And that's not happening to everyone who needs such an approach (sadly).
If you feel you want to switch careers and can't bear the thought of working programming anymore then do it. But if you just kind of feel giving up because of bad interviews -- don't give up just yet.
And I absolutely agree: we like to think we're special but there are a lot of very talented people out there. Very few are actually standing above the crowd. I am fine being one of many though; we each bring our own flavour to the company and some of these flavours do bring serious competitive advantages. :)
I wonder if companies like TripleByte are actually successful in solving this issue. I've avoided them because I'm skeptical of recruiting companies, but it might be a good idea to have people take one coding screen and have it apply to multiple companies.
I have seen this w/o breaks 5-7 interviews a day, too often. Some candidates suffer from low energy at the (n-1)th interview. The interviewer is baffled and gives a slightly negative feedback. The reason for the interviewee's interaction is not the skill of the interviewer.
So, in short - please keep breaks. You should have a 1h (min.) dedicated lunch break if you have a long 1-day interview. In additional, you should schedule 15m breaks in the morning and afternoon session to let the candidate recuperate. Finally, please ask your interviewers to look through the candidate schedule. Take into account that they have had many interviews, do your bit to make them comfortable. Also, please do not spin this as "If you can't go without breaks in a 7h day, you are not good enough to work here". Kindness, empathy helps and makes you a better employer.
I love it!
I am just crawling out of 4 months of hell of interviews and homeworks. And I can tell you: probably 90% of it. :(
If I have 16 teams of 4 people each, I should probably expect to find an all female team and an all male team, if we assume that gender has no bearing on individual performance or on team selection and that gender bias was entirely removed, leaving the gender of each team member to a coin flip?
Similarly, I’d expect to find a fair number of teams who all had O+ blood type today, as I think we do not discriminate on that basis.
As your point becomes more important as the size gets smaller. If it were all teams of 1 then each time would have incredible bias...
Without even seeing a single like of code from the candidate? That definitely doesn't translate to tech interviewing. It takes at least 30 minutes to get enough code out of the candidate to form even a first impression.
Yeah, gonna stop you there. It takes less than 30 seconds to get a first impression. That's the whole point of first impressions. As soon as you see a person, you have a first impression.
I've talked to many interviewers - they all agree that they basically have an impression formed within the first few minutes and then use the interview to solidify that impression. It is wildly uncommon for them to come in, have a very negative first impression, and then have it completely turned around by the end.
> research suggests that interviewers know after 20 seconds whether they'll hire someone.
That’s not first impression, that’s a meaningful ability to see if I hire someone. I can tell you that without seeing code/discussing some previous experience there is zero chance I can form hiring decision for most reasonable candidate (the only 30 second hiring impression I can form is perhaps a negative one).
Thirty minutes is usually enough to form an opinion, but the purpose of the other thirty is to gather supporting evidence, so that I can justify my hire/no hire decision.
If you are letting your interview candidates bomb their interview in less than 15 minutes, your expectations for them are highly unrealistic.
Which shows that bias is 99% of that thought process.
7?
There are companies that do this plus a bar raiser round. Some times two bar raiser rounds.
9 rounds is quite common in FAANGs.
There is also this condition that even single negative feed back after 9 hours of interviews. Like a 10 minute bad session in a 9 hour game disqualifies you. Like 8:50 of blazingly awesome performance is considered a waste even if the feed back was slightly negative in a 10 minute section.
This is basically a circus performance.
First was a quick call with a recruiter to make sure the role was a good fit. Then a prep call where I was told exactly what my interviews would be, then a 3 hour session with 10 minute breaks between each of three interviews.
The second was a similar quick call with a recruiter, then a 1 hour phone call technical screen. Then a prep call and ample prep material shared by the recruiter. Then a 5 hour session of 45 minute interviews with 15 minute breaks each hour.
These were both for technical roles, but not 100% engineering roles. Both processes were fully remote. I was struck by how well prepared I was, and how few surprises there were.
I had a chance to discuss the interview process with both companies, and they talked about changes in the process to support remote interviewing. The first indicated that there was no difference other than being remote. The second indicated that their typical interviews were full hours, rather than 45 minutes, but otherwise the number of interviews was the same.
even worse when you think it's really saying "if you can't go without breaks in a 7h day of meetings"
Edit: It is at least where I live. (EU)
While still being expected to produce 10+ hours/day worth of software development.
I actually don't think they did this on purpose. When i mentioned to someone at the end of the day that there was no lunch break, they were surprised. I think it's just that they're such a constitutionally incompetent organisation that things like this will just happen from time to time.
That is accurate based on the 10 people I've known that have worked there.
Make sure your interview process isn't stacking too many in a row, or the signal from the last few is going to be pretty bad.
To all potential employers and recruiters: When a candidate asks you for the agenda or some indication to the structure a meeting will take its because they want to be prepared. They aren't trying to "cheat", they want to be as productive as possible. Unless your company operates some insane work methodology where preparation for any task is strictly forbidden i don't understand why you wouldn't give them this info.
Twice in my last round of interviewing additional people where added to the call with short or no notice. These people where obviously experts in their technical niches so expecting me to preform well in a 30 minute grilling unprepared seemed unreasonable.
If they scheduled an interview without an agenda is because it's the norm to do that within the company when talking with outsiders. If someone jumps in to a call, it's their practice to have surprise guests within meetings. If someone ask you subject matter expert questions, it's how the company sees developers, as subject matter experts.
So, you were interviewing to a company which views, my guess, developers as subject matter experts, has people jump in into calls and doesn't prepare specific calls.
Obviously if you’re google or whatever your process is going to leak anyway so better to tell candidate upfront what to expect (and they do). If you’re smaller/unknown co may as well get genuine reaction rather than choreographed dance. Ofc that doesn’t mean you should expect candidates to have their env already setup that’s just silly.
Based on my experience, the best interviews have been the ones with the most detail shared up-front. When I say best, I don't just mean my own performance has been best, but I also feel that the interviewer has been most satisfied and that they have learned what they meant to learn.
The reasons for this are several-fold. In order to prepare a candidate well, there must be a well-structured interview process. This means that each interview should have some explicit goals - information about the candidate which the interviewer intends to elicit.
It is painful for everyone and a waste of time for the goal of an interview to be unclear to one party (and many times so if the goal is unclear to both). My favorite interviews have been at several FAANGs, which were highly structured. I knew up front what the interviewers would be looking for in broad strokes, and how the interviews would be structured to elicit that information. I knew how technical acumen would be ascertained.
I much prefer this over walking into a room with no idea what will happen. I do very well in those interviews as well, as I have spent much of my career in professional services, where part of my job description is to be always ready to project competence and to rapidly build rapport with new clients and potential clients. I also have much experience in interviewing to lean upon. Nevertheless, this is still a worse interview process, as I have to spend time figuring out what the interviewer needs to learn.
You may object that a good interviewer should be able to guide the interviewee. This is correct on the face of things. However, any people are bad interviewers, because there is rarely much training or prep for them. I have had plenty of successful interviews where I have had to lead the interviewer, rather than the other way around.
Additionally, there are very few jobs where job requirements include being quick on your feet and being able to rapidly (aka within an hour or so) ascertain what someone needs and how to give it to them. If you are looking to fill such a position, no-prep "genuine reaction" interviews might be a good fit. If, on the other hand, the position requires analytical thought and deliberation over periods of time greater than an hour (or whatever the length of your interview is), then such a no-prep interview seems a poor method to learn whether the interviewee has the skills you are looking for.
All this said, I do not like interview processes that have large homework requirements. It is one thing to inform the candidate of the structure and broad content of the interview, but another thing entirely to request that they do extensive work. My most extensive interview prep (excluding homework assignments) has never been more than a few hours, even for FAANG interviews with much structure and lots of prep materials shared by the company. If you can't find a few hours to prep for interviews, you're probably not taking them very seriously. And if you can't fit two or three hours of prep into a period of one to two weeks, then you've got bigger problems in your life.
[0] Note I haven't changed jobs this frequently, but I've always kept an eye out for interesting opportunities. I would interview companies to see if I like them or their job offer. I would frequently bail out early if it didn't seem like a good fit. Some I went for offers and used that to negotiate. Some I went for offers just to learn what comp packages look like. Some I went for offers to get the job.
Example 1:
"This interview is for your cultural fit. The interviewer will ask a series of 'tell me about a time when' questions. The core values of the company are x, y, and z."
So I spent a few hours reviewing those core values, and making sure I had anecdotes to cover each that represent me and my experience well. I rehearsed these answers, and made sure that I could articulate how my answer aligned with a specific value. I didn't have to flail around on the spot with no understanding of what the interview would be about. I didn't waste time in my answers talking about technical details that aren't relevant to an interview that is focused on personality and experiences outside of the technical.
If I did not know what the point of the interview was, I could easily respond to, "Tell me about a time you had a disagreement with a teammate and how you resolved it," by focusing on a technical challenge, and giving background on the technical details. If the interviewer weren't too good, or was just having an off day, they might not press to get details about the soft skills involved in solving disagreements that was really the point. This could easily become a failed interview question where they consider me obtuse and focused on the technical details at the expense of interpersonal ones.
With expectations firmly set and my own prep to make sure I had that story and that focus locked and loaded, I can make sure to focus on how I made sure all parties were heard, and that how I helped to foster a productive conversation, and how I made sure that I could back my side up with facts and figures, and how we had a reasoned discussion, and how we made a good decision in the end.
Then the interviewer doesn't have to keep digging when I gave an answer all about technical domain challenges. Then I don't have to feel defensive because the interviewer is digging. So we both have a better time in the interview. And I avoid being marked as "do not hire" for answering the question wrong without knowing.
Example 2:
"This interview is a high level technical interview, focusing more on systems architecture than code. You will be expected to whiteboard but not write code. Our interviewers will have several scenarios to choose from that focus on the following topics: a, b, and c."
So, I looked at that company's product offerings (this was for a customer-facing engineer role), in order that I might be conversant in their technologies. I looked for any whitepapers or blog posts about the topics, and made sure I was familiar with the architectural challenges of the topics provided. I made sure I understood how their products could fit together in a larger architecture, or where integration with third party systems was viable. These are not topic areas unfamiliar to me, so I'm not embarking on a full curriculum to understand these, but focusing my time on the topics I know will be covered.
I didn't waste time grinding leetcode, or even reviewing anything algorithmic for this interview.
When the interviewer presents a scenario, I don't waste time in answers that include fine technical details, such as how to configure the various services involved, or how one might program a solution to the scenario presented. I know I'm expected to whiteboard, so I make sure to illustrate as I am talking.
Again, my prep makes sure I'm on topic, so I don't depend on my interviewer guiding me to the right level of answer. A poor interviewer might let me go on for a long time, so that we can't finish in time. I would blow my chance by spending too much time in the weeds to get through everything they wanted to.
Even if I have a good interviewer who gets me back on track, if I've focused on grinding leetcode for this interview, I don't have systems architecture on my mind. I'm flailing around trying to refocus. Even if I get back on track, I'll have a much poorer showing than if I answer the questions appropriately (note, appropriate <> correct) to start with.
Separately from the examples given, there is another question of how well the interview topics fit the job. I am opposed to algorithmically-focused coding interviews for positions where it is not expected that the person in the role will have to implement algorithms as part of their day-to-day responsibilities. That said, if you are applying for a role where deep algorithmic experience is required as part of the day-to-day, then I would expect any decent candidates to not need to grind leetcode. If you're already doing this stuff regularly, then it should be a matter of brushing up, rather than grinding.
Wish I could just outright refuse those but between 4 months of looking for a job (I was looking in a rather niche zone) plus the pandemic draining my savings 5-7 months before they were supposed to run out, I really had to work a lot for free...
Lessons learned, and I completely agree with your post.
I just went through an interview process with AWS that wasted a lot of time for both sides due to them not being up front about the potential package. I had to push a fair bit to get any info, and finally had to politely tell them if the it's less the X I don't think it makes sense to move forward.
Edit: -----
Additionally, they were unable to explain how after two interviews, what an additional 7 interviews in an onsite capacity would add/build on top of the first two.
It felt like they were just putting me through a gauntlet without really understanding why.
It saves both sides effort if you can make sure you are in general alignment before going too far into the process.
After all, I know $X is what it will take for me to move enthusiastically and see it as good for my career trajectory, so if $X is over their salary range being coy about what I want just wastes my time.
Why base salary rather than total comp?
When I was new to the FAANG world I pretty much valued the stock at $0. I quickly learned that that was not correct; stock ended up being half my pay. (Probably more than half as you move further up the ladder!) The base salary is good, but another 100% on top of that was also pretty okay. I guess until you've seen it, it all seems mysterious. But I can assure it's almost as good as cash, minus whatever you pay someone to fill out all the tax forms.
As for why these companies give you stock instead of bumping up your base salary to be what you'd get by selling the stock right when it vests... apparently it's cheaper for them. It's not quite the same as printing money, but I guess it's close.
I find the NHS I have today is slighty worse than the Spanish equivalent I left a decade ago. Maybe because of the austerity policy of the Conservative government during the last decade, I don't know. In any case is not too bad.
Funny enough the private health insurances in Spain, which have to compete with a better public system, are WAAAAAAAAAAAAY better than ANY available in the UK.
At first I used the UK private insurance from my employer thinking "if they are being paid let's at least use them, saving resources to the NHS for people without an alternative". But not anymore...
- It's more complicated
- I have an uncomfortable relationship with my doctor when there are financial incentives involved (specially after one specific case)
I actually need to pay a 40% of the price of the insurance in income tax. The only reason I have not asked my employer to stop it is because the NHS cancer treatment times are getting longer than they should. That's the only benefit I see in them: a potentially shorter time to treatment in cases where time may make the difference between life and death.
I've been on both ends of terrible recruiting processes. Processes which have gone so slow that good candidates get away, processes with slow follow ups after interviews, processes where candidates are asked to come back in with short notice.
I think documenting and sharing how the process is going to run might cause it to actually run that way. That may be wishful thinking.
I'm tempted to run the job interview myself and instruct them on how to properly assess and interview developers, and then go ahead and interview myself for the role with them watching on.
But of course the outcome of that would be a rejection for insubordination - "not a team player".
You can't win so you just have to shut up and hope that some random series of events will get you a job.
I'm yet to encounter a company that thinks their interview process is anything but awesome. Companies really aren't interested in feedback. This is human nature - pretty much anyone, when given "feedback", it is taken as criticism and the status quo is defended and the feedback disregarded.
Companies who say they want feedback I think like the idea of asking for feedback but not acting on it or internalising it.
If a candidate was not good enough for a job with a company, why would they be qualified to advise that company on how to improve?
Don't believe me? Run an experiment - next time a candidate is rejected, ask them to give feedback to other members of your team, and in the unlikely event you get considered feedback, observe what happens to that feedback - don't intervene - just do the experiment to see whether the above assertions are correct or not.
[1] The case for the private technical interview. https://medium.com/@gameweld/the-case-for-the-private-techni...
It's too easy to fake "expertise" and "culture fit" over a 2/3/4/5 round interview each lasting an hour or so.
Most companies who deem this mode as not an option, simply aren't looking for great experts or engineers, but rather a cog in the grand system of wheels to keep the show running - or what HRs end up calling - a resource!
Solution: What can engineers do for this problem?
1. Propose this option (1 week PAID work trial) to HRs 2. Keep a backlog of technically engaging, but smaller work-items which could be taken up with least amount of background-knowledge , or something that has an easy-ramp-up-path for a newbie in the realm 3. Iterate and improve
This is just an extremely condensed internship of sorts. And many firms understand the value of intern-to-hire path.
This is actually solved by this approach. Nobody needs to quit, a week's leave/vacation is good enough for the trial period. Or, am I missing anything?
Also the most valuable question you can ask as a part of the non-technical interview: "So do you have any questions for us"? If the answer is "no", you are not looking at a good candidate.
> you can take that into account
I seriously doubt you can do this in a consistent and fair way.
Whether someone does well in a completely unfamiliar stack is fairly random, so you're almost certainly filtering out excellent candidates who just got unlucky with understanding the IDE.
But why? The odds of them facing unexpected tasks on the job aren't that high, they have their job description, they have their set of skills, you delegate tasks based on that. It's not like there are curveballs coming every week where they have to upend their knowledge and strategies. It might be good to see how they act under pressure but seeing the person comfortable and putting in their best work helps evaluate how beneficial they will be to the company.
I have never heard a better description of the majority of jobs out there.
I agree that you want to see someone thinking on their feet and tackling a new problem. But you can get that without making the whole interview a mystery. I can tell you "we will be giving you some C# code with concurrency bugs and asking you to find them", and it's still going to be a challenge when i do.
I have recently been doing interviews where we talk to candidates about past projects they've worked on, and ask them to go through some of the technical decisions they made. We don't warn them ahead of time that we're going to do this. Often, candidates have interesting projects they did a few years ago, and they just don't remember them in enough detail to go through them with us. This tells us nothing useful about the candidate. I think the interview would be far more useful if we had prompted them to revise their old projects, and i don't think this would generate false positives, because we can still distinguish bullshit from actual understanding (although of course i think that!).
> Also the most valuable question you can ask as a part of the non-technical interview: "So do you have any questions for us"? If the answer is "no", you are not looking at a good candidate.
I've heard people say this, but i don't see why it would be true. Is there reasoning behind this, or does it just feel smart?
Not at all. The lack of questions shows a lack of interest. In every test I've ever prepared I've deliberately left one or two questions which are near impossible to answer and no one has ever been able to correctly answer them so far. The least you can do is ask about those. Or what does the release cycle look like or how is the development being tracked - literally anything, just to indicate that you genuinely are interested and not "I simply want this job".
What if I'm so interested in the job that I simply don't care about those things? If you're doing amazing work, who gives a crap about the small details!
Also, if you are unaware of the norm that asking questions indicates interest, you are likely to have social/cultural deficits relative to an ideal employee; the likelihood of you being unaware of other workplace norms is increased.
If a senior engineer, at no part of the process, asks questions about the company, I would question that. To be clear, my experience is exclusively startups, but everyone I know would be very discerning about where they're going to be working for the next x years (x ≥ 2) and that's a long time with great opportunity cost. I'd be using every part of the interview that I can to extract information about how the company is run, who makes what decisions, and how long it takes to get a trivial feature out (mean-time-to-copy-change haha).
If they don't ask, then they either already know (which can only mean they're familiar with someone on the inside or someone who left on good terms, both of which are worth mentioning) or they don't know at all and don't care.
I recently got told by the VP of Engineering of the company I am now undergoing onboarding with, that if a senior programmer asks no questions about how the company['s teams] work and doesn't have any requirements, that to him sends the message they are desperate and don't know their value.
Other people told me that not asking anything means that the interviewee is not proactive.
If other people find thay have this problem have a couple of canned questions ready. Ask how much of a mess their code base is on a scale of 1 - 10.
I share your unpopular opinion, because the truth is generally told between the lines. At my last job I was the only one excluded from interviewing new candidates, because I am silly enough to throw ad-hoc technical questions into the discussion. My colleges managed to hire really nice people lacking basic technical skills, e.g. data analyst with 17 years of experience not knowing how to make a left join or a sub-select or PHDs not knowing what python or even a "programming language" is. We had some "fun", I can tell.
And this goes both ways. I remember as an "unprepared" candidate facing the ad-hoc question "how would you deal with time series data". Through well placed questions I figured out that they have - after removing the obvious seasonal effects - only 5 data point. After my answer "I wouldn't even fit a regression line on it" the interviewer said "no one here does time series analysis, not even I" and left the room with some made up excuse. Or when the interviewer was bragging about "valuing work-life balance and having a lower churn rate than the industry average" and I figured out he is with the company since 9 months. He was just smiling and left the room with some made up excuse.
Basic rule for hiring: don't let fool yourself AND don't try to fool others.
I'd love if this requirement were explicable and quantifiable. Two people can each be nice and kind, but not get along for whatever reason. When a hiring process can include face to face meetings with 10+ people, the chances of a suitable candidate being excluded for an arbitrary 'personal' reason seem high.
What's the point in many stringent evaluation criteria if, at the end of it, all interviewers then have to agree that they can be besties with a random person. It's too fuzzy.
Took us about a week to write everything down the first time and then we continuously updated it until it reached the current state.
We had the advantage of being a "public by default" company, so there was no need for approvals of any sort.
This seems a little bit odd to me.
How long do you expect people to work on their home assigments in order for them to commit often? Is it days, or weeks? I don't imagine multiple commits for a 3 hour poject.
For a new project there aren't any well defined states of the code that make sense to be persisted. This means the commits will be arbitrary and their messeages not very meaningful.
If you implement a piece of logic with passing tests, then commit. It takes seconds to do but makes reviewing so much easier.
As I said - I don't see a reason for multiple commits for a few hours project. It is not how people start a new project. This is an exploratory phase, you check this, test that. Very often it becomes a mess. Eventually your idea of the project gets clearer, then you clean the code, or start again from scratch. I don't see why these steps need to be persisted.
This has been my experience each time I've started a new project, unless it is something very trivial, where you just follow the steps from the tutorial. If that's the case though I don't see the value of such assignment.
Conversely, if it is a few days or a week project you shouldn't expect experienced developers to take you seriously. This has been discussed multiple times here on HN and most poeple don't like it. People have lives, they probably have applied to multiple companies and it's just not possible for them to invest that much time.
In both cases the company misses the chance to meet potentially bright and hard-working people, which should be the purpose of the whole thing.
There is something else - what commit messages should look like is a very controversial topic. Introducing a chance for a strong disagreement on such an early stage of getting to know a candidate is not very wise.
I have had interview projects that were much more open-ended and exploratory, and there, i would not expect to be cranking out neat atomic commits. But i don't think that's what they are doing here.
Unless it is something completely new to me and I am basically "playing with the tech" (which this does not seem to be) this is exactly how I would start the project. I find it easier to be organised from the start. Especially if, when I do take a wrong turn, I can revert easily to a previous commit.
Agreeing with how one should work when employed is very different from agreeing with some nonsense during the application process. And in my opinion test assignment which take days to be done is definitely nonsense.
Expecting applicants to follow a process that has been adopted in a company, which took possibly years to get established is very naive. Of course if they get hired they should comply with the company policies and make their best to fit in with the culture, but how can some arbitrary requirement help evaluate their abilities.
People involved in hiring sometimes forget that this process is a two-way street. Applicants can also have expectations, requirements and questions. They are also entitled to disagree. Being themselves in a process of selecting the best company to work for, they can have their own opinion about how this should happen. I'm not sure if is a good policy for a company to hire the most agreeable candidates, willing to follow without objection any rule or order.
Most good engineers I've worked with are not like that at all.
> For a new project there aren't any well defined states of the code that make sense to be persisted. This means the commits will be arbitrary and their messeages not very meaningful.
I didn't understand this? The problem is well scoped and defined. Regardless of whether it's a new project or old, we expect candidates to be able to split their work as atomically as possible.
One is to make disciplined incremental progress: write a test, make the test pass, do minimal cleanup, commit, see a refactoring opportunity, do it, commit, write another test, see a related bug, write the bug down but don't fix it, make the test pass, clean up, commit, tackle the bug, commit, etc.
The other is to flail about wildly until you have something which more or less works, and then commit it. Then make a few follow-up commits fixing bugs.
People who have only experienced the latter will find the idea of making numerous commits during the day absurd.
You're going to be judged on how well the end product works, so if we start with the following tasks, and you have 180 minutes.
1. 20 minutes: their stack's boilerplate/tooling
2. 10 minutes: unit testing boilerplate
3. 20 minutes: integrated testing boilerplate (browser automation is a fickle beast)
4. 20 minutes: basic database entity + database setup
5. 20 minutes: basic UI page + frontend setup
6. 20 minutes: replace default styling (their guide talks about UI "polish")
That's 110 minutes and nothing more than a pretty display from the database.
The task will almost certainly ask for more than one user action. I might be able to write an action in 20 minutes, but there is no way I can write good tests, seed test data for integrated testing, and keep each commit atomic and green.
So, do you choose to have a tidy commit history and complete test coverage, or do you choose to complete the task?
Estimates are almost always under.
As you point out the most basic project setup takes time. And I am working on a home laptop, not my work machine, so I don't have everything installed in the same way as I do for a work setup (that's usually at least a days work in itself on a new work machine).
Also it is not uncommon to find some strange issue that will take a couple of hours to fix if you are unfamiliar with it. Last technical test I had involved using Django's chache framework. I have used Django a lot, but not really used the cache in depth. I got everything working in the end and they failed me for the most trivial reasons.
Talk about exploitative. Hell, that's incredibly biased. Can you imagine a young parent being able to do that?
At least they are open about it. It is probably a fair indication of the companies values if they are oblivious to how unreasonable a 3 day take home assignment is.
Most cheapo shops which won't pay FAANG salaries but still want near-FAANG-quality-engineers end up using this as a bait.
Other ways are "your work has great purpose!" "You will advance humanity!" "You will bring great experiences to users" ... yeah yeah yeah, just an alias for "we are a glorified bodyshop. BigCos hire us for some piecemeal job. We get it done and get paid relatively well." But this isn't too appealing, is it!
It would most probably have a twisted answer as "you can post that solution of yours in your git repo and showcase it as a part of your portfolio"
Many shops out here are so adept at this stuff, it's no more funny!
> Why do you want to be at Obvious?
I never understood this. Unless you are Apple or Google or some other big brand, most likely people found your job through a job forum or even HN and never heard of you before. Then most likely the answer is money. So what is the point?
I just stopped filling up job applications that have this. Seems so counter productive. Heck, I was approached by a CTO of a Ycombinator company a while ago, he found my resume somewhere, asked me if I would be interested in the position, then redirected me to a form where 2-3 questions was about why I wanted to work with them, and what I would bring to their team. I want money, and in exchange I give you my time and knowledge. Is that so hard to understand?
I'm not saying that someone needs to be so desperate to work somewhere (that would probably be bad), but if a candidate can't express why they have an interest in a particular role then that's of note, especially if I'm comparing to someone who can. Pretty much everyone wants to exchange their time and knowledge for money, but they could do that anywhere, so why here?
From their website 'We help people create digital experiences their customers love.'
Has anyone been 6, day dreaming in school, 'when I grow up, I want to help people create digital experiences their customers love.'?
My interest in the role is it matches my experience and I want money. Again, if you are a FAANG, fine, if you are a startup no one really knows but pretend you are changing the world, you are making yourself a disservice by asking these questions. You can ask 'What are you looking in a new position/What excites you/etc', but to ask specifically why this company is tacky and I know I am not alone with this as I regularly talk with friends that feel the same.
Maybe I am jaded as a software developer with more than 20 years professional experience, but job=money so I can money=things/time I want. 99.9% of companies aren't changing the world. They are trying to make money for the owners/shareholders/investors, and employees should think exactly the same, and that is motivation enough.
If you paid a million dollars a month for people to dig holes for 8 hours a day, you would see the fastest shortage of shovels ever.
Beyond a threshold salary level, these intangible things matter much more than money since I am going to be spending every single day working on these things and with these people. I want to work with skilled technicians but I also want to be in alignment with my team.
I understand the "not changing the world" mindset but motivation is still a hugely important consideration when hiring and when choosing where to work. Every job has bad days/weeks/months and it takes motivation, beyond the paycheck, to hold myself and my team together through those moments.
Similar to your million dollar situation: If you paid high performing knowledge workers a million dollars a month to do soul-crushing stressful grind work in a bad environment, those people are still going to quit after a short period of time.
And you know this from a job post in a job board/website how?
This is what I mean. A no-name company can't say 'we want people to be motivated to work with us' when 99.99% of the world have no clue what they do/how they work.
If you are Uber, or Microsoft, 37 Signals, or even Doctors Without Borders you know in general their motives/how they work (from the 2389472309 blog posts). But 5 employee start ups? Or a consulting firm that does client work for companies you never heard from? Really?
> If you paid high performing knowledge workers a million dollars a month to do soul-crushing stressful grind work in a bad environment, those people are still going to quit after a short period of time
Maybe being from different country shows my bias, but even with a lot of friends in the USA, most don't change jobs for lower paid positions. There is even a term for it: 'Golden Handcuffs'
I don't need to know it from a job board or website because I don't apply to companies that I'm not already familiar with. When I apply to those listings, I already know how I will answer this question, because that's why I'm applying to the company.
> Has anyone been 6, day dreaming in school, 'when I grow up, I want to help people create digital experiences their customers love.'?
No but that's a strawman and I'd be surprised if you don't recognise that.
> My interest in the role is it matches my experience
I doubt that's the only reason. You could have experience doing a billion things but you probably enjoy what you do a lot more than that, and when we break it down, there are almost certainly subsections within what you do now that you enjoy and hope that the company aligns with that. When a listing asks "why are you interested in working here", you hopefully already know and can express that.
There are a large number of ways from location, culture, processes, technical decisions, people, problem domain, etc that you can discover about a company before applying.
> My interest in the role is it matches my experience
This is a great reason to want to work at a company.
"I specialize in X technology and I see that you use X technology as well and I believe my expertise in it can help your company solve problem Y, and in particular I'm looking to join a company of Z size because blahblahblah"
Yea you have to stretch it a little bit sometimes, but that's life. You don't get paid to write code, you get paid to solve human business problems using code, which comes with the baggage of dealing with humans.
One was at a 40,000-employee global tech professional services firm. I got feedback from each interviewer filtered through the recruiter at each step along the way, sharing both positive and negative. This process ended in an offer I didn't accept.
Another recent interview process at a FAANG ended in a rejection. The recruiter followed up with me and informed me which interviews were considered a pass and which were a fail. Each interview had several components, and the recruiter was able to tell me which components were the cause of failure in the one interview, and what to focus on in any future applications to the company.