Live data from Hacker News

Tell candidates what to expect from your job interviews

jvns.ca

31–40 of 161 posts

Re: Tell candidates what to expect from your job interviews

#31
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.

Re: Tell candidates what to expect from your job interviews

#32

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,…

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 think we could do better, and I do appreciate people that I've emailed and wrote back "the process is over". But even that is hard to scale.

Internships seem super valuable to me. When I was at Google I had an intern every summer, and I basically dedicated my summer to teaching them everything they needed to know to be successful at Google or another big software company. Obviously, Google was 100% happy about this; I would go to weekly team meetings, say "all I did last week was spend days with $INTERN figuring out how to adjust build options for this new target" and the response was not "wow, you're lazy, get back to work" but "great!". Not every company can support that, though, which is why they're looking for people with experience. They want to pay money for getting work done, not pay money to have a senior engineer do no work for 3 months with the hope of someday having someone who can get things done by themselves. Again, it sucks, but that's how it is. Job training is EXPENSIVE. You can't always expect to get it for free. (That's why colleges exist, not that I think they do a great job.)

TL;DR: Practicing those coding challenges and how to write A* on the whiteboard is going to send a strong signal to companies that you're worth their time. It shouldn't be that way, but it is. "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." You have to ask yourself, do you want a job, or do you want to change the world. Changing the world is going to be a lot harder. Kind of sucks, but that's life.

Re: Tell candidates what to expect from your job interviews

#33

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?

We ( https://obvious.in ) documented our entire hiring process on our Playbook ( https://playbook.obvious.in/hiring/hiring-process/engineerin... ). Took us about a week to write everything down the first time and then we continuously updated it until it reached the current state. We had the advantage of being a "public by default" company, so there was no need for approvals of any sort.

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?

Re: Tell candidates what to expect from your job interviews

#34

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…

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.

Re: Tell candidates what to expect from your job interviews

#35
post #10

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 a…

> 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?

Re: Tell candidates what to expect from your job interviews

#36
post #13

Earlier quoted context omitted.

> 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 s…

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.

Re: Tell candidates what to expect from your job interviews

#37

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…

> not total package, but actual base salary ranges

Why base salary rather than total comp?

Re: Tell candidates what to expect from your job interviews

#38

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…

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 wan…

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.

Re: Tell candidates what to expect from your job interviews

#39

> 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 energ…

>"If you can't go without breaks in a 7h day, you are not good enough to work here" even worse when you think it's really saying "if you can't go without breaks in a 7h day of meetings"

It is even worse when it is legally required for employer to allow for an hour break after every 4 working hours.

Edit: It is at least where I live. (EU)

Re: Tell candidates what to expect from your job interviews

#40
post #25

Earlier quoted context omitted.

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.

You expect candidates to spend 20-30 hours on a task, and you don't even guarantee an interview? Talk about exploitative. Hell, that's incredibly biased. Can you imagine a young parent being able to do that?

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.

Post reply on HN