Just curious, thought of doing something like this for my company too, how long did this take and who did you have to go to to get this approved for public consumption?
Oh nice, you know it does have an interesting effect on me of making Obvious a more enticing place to apply... Has this improved the quality of interviews and/or applicants?
> We expect you to use git, commit code as you go along, and build the app iteratively -- just as you would during a normal workday.
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.
I think you've just failed that part of the test. If you've got more than an extremely simple project there are multiple point s where you should commit.
If you implement a piece of logic with passing tests, then commit. It takes seconds to do but makes reviewing so much easier.
Or the company failed to attract the most suitable people for the job.
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 get the impression that the project here is not one that calls for exploration - "a simple note-taking app with a couple of screens". You can use a tech stack you already know well, the entity model is pretty obvious, you should be able to sit down and mostly just smash it out. You can make lots of little commits while doing that.
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.
By specifically mentioning this, I would imagine it is something that is important to them. Therefore, somebody who doesn't agree with this way of working is not "suitable". In my experience, hiring people (however good) who do not agree with the company's core practices doesn't end well for either of them.
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.
> Therefore, somebody who doesn't agree with this way of working is not "suitable"
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.
The exercise itself is a simple note-taking app with a couple of screens. We don't impose a time limit on candidates interviewing to complete this stage.
> 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.
Sure, but I'm not sure how much progress you're going to make in the 2-3 hours one would spend on a speculative take-home task (they've stated there is no guaranteed interview).
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)
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?
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.
It is not expected to be 3 hours project. Target easily 3 days for it. Requirement to get more points for this assignment from that page: “Detailed documentation with setup, screenshots, configuration instructions, etc.” This alone might take couple hours.
We did allow concessions for people who were not able to find time to do the exercise. We merged it with the pair programming exercise and asked them to build it with us in office.
Young parent here. Not a chance in hell I'd be taking part in that exercise. The only possible way would be to take a weeks holiday and that's just not going happen.
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.
Yeah, no kidding. If you’re not going to pay an hourly rate for a homework assignment, you are not getting particularly good applicants. No quality engineer will spend more than a couple hours at a chance to maybe have someone look at their code, to maybe offer them a job.
As I have said in a comment below, it sorta became a way to signal being hip-n-cool, while actually being totally otherwise.
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!
Can I honestly ask what is the point of this question:
> 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?
No, it's not hard to understand, but that doesn't do you any favours.
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?
I'm not sure what to reply. I was going to be snarky but prefer not to.
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.
This is one approach and way that people feel about work and job hunting but (anecdotally) many others, including myself, do care about things like culture fit and company vision.
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.
> do care about things like culture fit and company vision.
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'
> And you know this from a job post in a job board/website how?
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.
Honestly, it's just part of the game. If you want a job at a company, you have to play the game of interviewing.
> 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.
Also get feedback from candidates, especially rejected ones. The people who get offers will assume that the process works, since it validates their self-worth. Even if the process is very stupid. I've had processes that were so so bad from top companies. Like "here's a repo, clone it, write a program that will be judged by automated tests that you can't see". I had to basically guess what the tests were going to do, which turns the coding challenge into a game of luck.
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.
I think it can only be fair to ask for feedback from a rejected candidate if you (the potential employer) are willing to give feedback yourself, which is rarely the case, especially from larger companies.
This might be what you'd think intuitively. I've conducted ~500 technical interviews, and in my experience candidates who are obvious DNP (do not pursue) often times really do not want your feedback or do not care about it, either because they think they're smarter than the whole process, or they're too busy turning inward to deal with an emotional breakdown. But those very candidates are the ones who are likely to leave the feedback!
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.
> 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.
Sorry to hear about your experiences. It sounds frustrating.
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.
Oops, I guess I misread indeed. And you are quite right on your last paragraph -- found it the hard way.
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.
It would feel a little awkward for me to ask for someone to do work for me after I've determined that they're not a good fit for the company. And if it's post-interview pre-result then the problem is that they'll feel pressured to be positive.
Agreed that it's tricky, but there needs to be some feedback loop. Otherwise you end up with seriously broken processes that never get fixed. Companies tend to care about false positives more than false negatives, but there's a decent possibility that some companies have an extremely high false negative rate.
I am hardly a fan of excessive language policing, but this phrase "a good fit" bugs me. Is it common currency? To keep asking among yourselves "is this person a good fit?" seems unlikely to encourage the sort of objective assessment of a person's usefulness and talent that you'd want for your company's sake and also to stay within the law.
I think it's instructive to look at this from the other side to see why these processes exist. At my last job, I wanted to hire a frontend engineer with some experience beyond tweaking HTML and CSS (we used gRPC/Web and Typescript, so some actual programming experience was going to make them pretty productive, and that's what I was looking for).
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 am sorry but this tells me exactly one thing: that you don't know how to write a job description.
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.
Writing a nice description will help but only slightly. It was written here the other day: GitLab used to receive 15,000 resumes per month. I think their job descriptions are pretty good and precise. People use scripts to apply to hundreds of jobs blindly.
This is not from an IT position, but my wife uses "mention word XYZ in the email subject" in the requirements. This filters out a few people who just spam their CV regardless of job description. It also filters out people who are applying to a job that really requires attention to details in written communication.
> 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.
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).
I 100% agree. I used to be in the boat of "I shouldn't have to study to pass a job interview" when I was younger.
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.
This is all true, I just wish people didn't put that much weight on some pretty random and oddly specific tech interview questions.
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.
pdimitar I totally feel you. For full context: I have never passed a leetcode style phone screen in my entire life. Even after studying for 6 weeks, every night for 2 hours and buying a couple of courses on how to pass coding interviews.
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.
> 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.
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 agree and sympathize with what you're saying. Coding screens are a necessary evil. But perhaps they can be omitted in certain situations. I know I completed the Google foobar challenge far enough to alert a recruiter, only for the recruiter to send me a snapshot test. Like c'mon, I just solved a whole slew of harder problems than this.
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.
> We will do our best to provide a 15 minute break and/or lunch/coffee break during your interviews, especially if you'll be interviewing for more than 3 hours. That said, we are happy to accommodate additional breaks or fewer breaks, depending on your preferences, just let your recruiter or recruiting coordinator know!
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.
Is there any evidence to suggest that more than 3 hours of interviews is actually beneficial? 7 hours of interview seems like overkill. I've never had more than a couple of hours of interview: an hour with the department head and another hour with my future line manager and/or another senior employee.
Afaik, research suggests that interviewers know after 20 seconds whether they'll hire someone. I don't have references and don't know if this would translate well to tech interviewing, but I'd wager that the vast majority of a 7h interview day is totally pointless.
I rarely have encountered an employer that is truly - actively - trying to avoid like-me bias. If they were even remotely successful, your interviews wouldn't almost always be constructed of 3 races... and various teams at orgs wouldn't have such wildly lopsided demographics.
Wouldn’t entire elimination of irrelevant bias mean that teams would have wildly varying demographics?
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.
> "...interviewers know after 20 seconds whether they'll hire someone..."
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.
> 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).
I meant to be less specific than "hire someone", but I'd wager that once a subconscious impression is formed, you'd be more likely to bias your interpretation of whatever else they say.
Right, I am sure I have a first impression, which could be good or bad, and that impression does inform my later views. However, just objectively I know for a fact that I declined some candidates I initially liked and I hired a few people who initially was super shy/not communicative.
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.
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.
Recently had a couple of interviews with members of FAANG.
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.
I live in Germany and it seems like I am incorrect (I looked it up), it is actually 30 minutes, for 9 hours of work. But my contract states it is 1 hour per day, which I assumed was the law. Sorry about the confusion!
Typical US state laws are 15 minute paid break for every 4 hours and an unpaid 30 minute meal break for every 8 hours. The assumption is that these breaks must be scheduled for hourly workers but that “white collar, non-overtime” workers have enough flexibility to self schedule.
When Amazon interviewed me, it was something like 10:00 - 17:00 with no breaks. They didn't tell me that in advance, so i hadn't had a big breakfast.
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.
I think the problem is that even with breaks, you can still be mentally exhausted by the last interview or two. For a normal work day, I wouldn't expect people to switch between writing completely different algorithms and problems so often. In a day of interviews, switching to a new problem five or six times can be exhausting.
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.
Perhaps a bit of an unpopular opinion but as far as interviews go, I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect. You see their ability to adapt and improvise, which is far more valuable then being picky about a particular library or technology. Yes, the quality of their tests will be lower, but that's fine and you can take that into account when you are checking them and you can check the test along with the candidates and ask additional questions which will steer them in the right direction, which ultimately will give you more insights about their thought process. Imo, their thought process is arguably the most valuable factor.
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.
That only works if your task is equally unexpected/unusual for all candidates. If it isn't then either you punish them for being familiar with your stack (as you don't get that valuable knowledge) or you punish them for not being familiar (as you reward a good result).
> 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.
> I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect
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.
Imo, most of most jobs come down to how well you can tolerate doing what is basically intellectual grunt work while people interrupt your attention. As an IC, things are much more boring than ridiculous interview processes would have you believe.
> Perhaps a bit of an unpopular opinion but as far as interviews go, I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect. You see their ability to adapt and improvise, which is far more valuable then being picky about a particular library or technology.
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?
> 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".
> 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!
If you're maximally interested in doing the job, you would ask questions to learn details that will accelerate your onboarding into your productive role and culture of the firm.
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.
> 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?
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'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?
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.
The main thing "did the candidate have any questions for us yes/no?" tells you is "has the candidate read the usual 'how to prepare for interviews' guides where this is noted as a very common question for which the candidate should spend a little time in advance thinking of one or two good questions to ask". I guess that's a little bit of signal about their ability to prep for interviews but you probably are getting enough "does candidate know how to play the job-interview game" signal already...
I am not sure I agree on the have you got any questions for us. Interviewing is a strange process. I find it quite difficult from being sociable friendly, coming up with decent answers then jumping into some kind of coding question, as it engages different parts of your brain. After you have done that coming up with questions for the interviewers is something different again. I can see why many people wouldn't have anything unless it was prepared. The interview process should be fairly two way anyway, so I ask as I am being interviewed, so often any questions I have are answered already.
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 think that seeing how someone reacts unprepared is a lot more valuable
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.
All of that sounds like you’re just going to favor people who are slacking at their current work, unemployed or have a ton of free time outside of work to prepare. How is that “leveling the playing field”?
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.
I disagree. I've interviewed an abnormal amount: roughly every 8 months since getting my first job, and for more than one job at a time.[0]
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.
I don’t really understand how few hours of prep work can correct for crappy interviewer. Also not talking about few hours - people spend months grinding leetcode and if you don’t you’ll be at disadvantage
Below are two examples of recent preparatory information given to me before interviews with two different companies. These are samples. I did not spend a few hours on each of these examples, but a few hours in total for each company. I probably spent <45 minutes of prep specifically on the examples below. I hope these are helpful to illuminate my point, that prep info can be acted on usefully in some amount of time measured in low-single-digit hours and can improve the interview experience for everyone.
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 ...
> All this said, I do not like interview processes that have large homework requirements.
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 think an additional piece to this, is to tell candidates what level they are interviewing for and the possible salary ranges, not total package, but actual base salary ranges.
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.
A lot of people say "never be the first to give a number" (which might be wise if you aren't confident you have a good idea of your market value) but I've always found it useful to just give recruiters a salary requirement figure upfront.
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.
I think that "never be the first to give a number" advice is good if you want to maximise your income. If you want to minimise your drudgery, name a number as soon as possible.
I agree. I am at the higher end of the payscale where I live (Spain so overall pretty poor salaries). Most jobs will be offering around average salaries, so it's saves me time to state up front what i expect.
Because I've experienced a lot of number fiddling to describe total comp. For example we offer you X equity at Y valuation, when the valuation is something they have made up internally etc. I want to know how much cash in hand I can expect. Also, offering private health insurance, when you live in a country with a decent public health care system is not much of benefit and generally not worth what the company says its worth. If it was the US, I could see how that would be valuable, but in most of Europe, it is not.
Startups are going to be like that, but you said you were interviewing at AWS. You can buy and sell their equity on the open market, so it's not really a mystery what you're getting. If they say they give you 50 shares a year, that's $137,941 a year in cash money. Probably more next year. You can sell it or hold it, but turning it into cash is very easy. Sure, Amazon could go out of business while you're holding stock grants and then you get $0... but that's exceedingly unlikely. A lot would have to go wrong for Amazon to lose all its value.
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.
Instead of worrying about base salary vs. equity, I'd rather know roughly how much "guaranteed" compensation to expect. Guaranteed would include cash salary, immediately-sellable stock, and the amount of bonus that is not contingent on personal or company performance. The rest is "speculative" compensation: stock options, potential gains from holding stock, illiquid stock, and bonuses that might not materialize for various reasons.
This. Bonuses based on company performance are going to be extremely rare this year. My employer was up front about it, telling me in April that bonuses were suspended. That’s fine, because I treat it as a bonus, but if one was counting on it to make mortgage or student loan payments...
I never got offered private health insurance in Spain by an employer. I have it in the UK. When I was a kid I had access to private health insurance in Spain, so I know it a bit.
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.
My general thought is that your compensation scale should be proportional to the complexity of the interview process. If you're going to be copying the FAANG interview process, then the candidate should expect an offer similar to what they'd get from FAANG.
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.
This is strongly misaligned with many companies' incentives so it will never happen, I am afraid.
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.)
The solution is to make companies pay people for their time during interviews, at an hourly rate equivalent to compensation for the position. Everyone else in the interview is getting paid by the company, after all.
Suddenly, managers, hiring committees, and recruiters will stop wasting people’s time and everyone will know what to expect to get paid!
I'd love that but I am pretty sure it won't ever happen.
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.
That brings to mind a funny hypothetical niche of "interview tricksters" who lack qualifications but can land an interview sustainably. Probably not sustainable and they would be incentivized to bullshit their way into a full time job (like normal status quo really) but still pretty funny.
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.
Goes both ways. I make a point of working at well-funded tech companies and if a recruiter neglects to raise salary from the get-go I use it to my advantage to make them and the hiring manager squirm as they re-arrange the department budget to pay me an extra 20%+ over the initial offer. As you mentioned, time is money :) and interviewing sucks even more after you find the right candidate.
True true, and I mostly did the same this time around. But the pandemic thinned my savings much earlier than I anticipated (I should have been able to coast on them all the way to Christmas) so at one point I was forced to play the numbers game -- while ignoring obvious bad signs -- much more than I wanted.
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.
>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
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.
I totally agree with you that some employers are downright bad and that how a company runs an interview process is indicative of how they run everything. I have turned down multiple interviews and a job offer before because I was soured by how a company operated that process. I just don't think the reason for those bad processes is necessarily nefarious. Hanlon's razor and all.
Technically, company is not a single mind that could have a viewpoint on something. It is a group of people, who sometimes have different incentives. Maybe someone's incentives make this a good strategy, even if it is harmful for the company as a whole in long term.
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.
I conduct interviews with candidates almost every other day.
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?
I can't find a single point of disagreement with you. :)
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 feel like chiming in because the way the parent described things makes me sad about the state of interviewing and I personally would be very turned off by this kind of interview.
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 did not say it is a chore. I wouldn't be doing interviews if I didn't like it.
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.
This is a big reason why I talk compensation up front during initial conversations. I'm not sinking hours of time into an interview process only to find out they're only offering less than half of what I'm expecting. Plenty of recruiters say no they don't discuss this up front at which point I'm fine not continuing the conversation.
I’ve actually found that there’s an inverse correlation: companies with worse comp seem to have more rounds, more take home and harder questions. The confounding variable is that the lower comp companies tend to be startups.
Also confounding is that start ups usually offer equity which is an unknown variable.
Financial planning-wise it is geneally best to assume it is worth nothing but there is a small chance that it will utterly outstrip the certain compensation.
Usually there is some sort of VC funding and usually there is a valuation and ergo a price per share. I find that startups are usually at part with public companies or slightly worse with the promise that there's tons of growth right over the horizon.
I don't think many companies will be able to come to terms with not being able to hire FAANG-level engineers if they can't offer FAANG-level compensation. I can't remember where I once read the quip, "we only hire the best, and so does everybody else".
I've just finished this maddening process for the 4th time in my "career" and it was as frustrating as i remember.
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.
My experience is that when obvious experts in niches are added late to an interview loop, that’s almost always a positive sign for the candidate. Those people are generally busy and aren’t on the “everyday candidate” loop typically.
For some reason developers seem to assume that the recruiting process is immune to the regular company dysfunctions.
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.
It's a pity job interviews aren't generally better run.
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.
The psychology of recruiting is that once a candidate is rejected, the interviewers and company have lost any sense that the potential employee is competent and their opinions at that point are of little value.
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.
Great article but I also really liked the website. Fast and simple but still aesthetically pleasing. It's got that charm of being hand written. Love it.
> We used to apply a ‘Sunday Test’: “If this person were alone at the office on a Sunday, would that
make us want to come in just to hang out with them?”. However, this was the wrong phrasing for
the idea we really cared about (we don’t encourage people to work Sundays, and we want people
who would make excellent coworkers rather than be our personal friends). Instead, we now ask: “Is this someone we’d actively seek to work with”
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.
What I'd like to see is the process documented and actually stuck to. Not the content of the interviews, but the actual composition of the process - how many interviews, timelines, etc.
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.
A recent research paper looked at traditional coding interviews versus "private" interviews. One of the authors summarized the paper in a blog post [1].
I presume it's a liability thing. It only takes one candidate to "spin" an otherwise valid reason into something they can sue for. Same reason why companies don't tell employees what they're being let go for in at-will states.
I've had some surprisingly good feedback experiences in recent interviews.
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.
IMO, if a company is very serious about hiring for the role, they must offer a 1 week trial period (PAID!). The candidates get a fair idea about the kinda muck they might be getting themselves into. The team(s) get an idea as to what kinda schmuck they get to deal with over next months.
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.
I like it except for one problem. I never leave a job unless I have a job. Seems too risky to jump ship from a good job where you're under paid to get a chance at a little more money.
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?
160 comments
[ 2.2 ms ] story [ 178 ms ] threadTook 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.
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,...
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.
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.
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 ...
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.
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.
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.
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.
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.
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.
[1] The case for the private technical interview. https://medium.com/@gameweld/the-case-for-the-private-techni...
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.
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?