
Tell candidates what to expect from your job interviews - zdw
https://jvns.ca/blog/2020/06/30/tell-candidates-what-to-expect-from-your-job-interviews/
======
jrockway
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.

~~~
pdimitar
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.)_

~~~
claudeganon
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!

~~~
freedomben
That's an interesting idea, tho I expect it would have the unintended
consequence of making it really hard to get an interview.

~~~
Teever
That's one way of looking at it. Another way of looking at it is that
prospective employers would stop wasting the time of applicants.

------
_hardwaregeek
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.

~~~
jrockway
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.

~~~
fogetti
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.

~~~
sokoloff
Unless you somehow require proof that the applicant meets the requirements, I
don’t see how that prevents the spray-and-pray applications.

~~~
viraptor
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.

------
denzil_correa
> 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.

~~~
barbegal
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.

~~~
brailsafe
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.

~~~
sokoloff
I wonder how much of that is like-me bias with the risk that 3 short
interviews might get us (even) more homogenous employee populations?

~~~
bradlys
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.

~~~
sokoloff
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.

~~~
bradlys
Team size is going to be important to note. The teams I'm talking about are
frequently near 10 or more members.

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

------
swarnie_
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.

~~~
tumetab1
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.

------
dilyevsky
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.

~~~
greggyb
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.

~~~
dilyevsky
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

~~~
greggyb
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 poor interviewer might let me go on
for a long time, so that we can't finish in time. I would blow my chance by
spending too much time in the weeds to get through everything they wanted to.

Even if I have a good interviewer who gets me back on track, if I've focused
on grinding leetcode for this interview, I don't have systems architecture on
my mind. I'm flailing around trying to refocus. Even if I get back on track,
I'll have a much poorer showing than if I answer the questions appropriately
(note, appropriate <> correct) to start with.

Separately from the examples given, there is another question of how well the
interview topics fit the job. I am opposed to algorithmically-focused coding
interviews for positions where it is not expected that the person in the role
will have to implement algorithms as part of their day-to-day
responsibilities. That said, if you are applying for a role where deep
algorithmic experience is required as part of the day-to-day, then I would
expect any decent candidates to not _need_ to grind leetcode. If you're
already doing this stuff regularly, then it should be a matter of brushing up,
rather than grinding.

------
incognito_limey
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.

~~~
michaelt
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.

~~~
twic
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.

------
kevsim
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.

------
andrewstuart
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.

~~~
robjan
I usually ask for feedback on the interview process from the candidate. Not
sure how common this is.

~~~
andrewstuart
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.

------
davidhyde
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.

------
azhenley
A recent research paper looked at traditional coding interviews versus
"private" interviews. One of the authors summarized the paper in a blog post
[1].

[1] The case for the private technical interview.
[https://medium.com/@gameweld/the-case-for-the-private-
techni...](https://medium.com/@gameweld/the-case-for-the-private-technical-
interview-4a92947e1692)

------
raghava
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.

~~~
XargonEnder
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.

~~~
raghava
> I never leave a job unless I have a job.

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?

------
anjc
> 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.

------
axegon_
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.

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

~~~
axegon_
> 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".

~~~
Dayshine
> 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!

~~~
artfulhippo
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.

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

~~~
vinaysshenoy
We ([https://obvious.in](https://obvious.in)) documented our entire hiring
process on our Playbook ([https://playbook.obvious.in/hiring/hiring-
process/engineerin...](https://playbook.obvious.in/hiring/hiring-
process/engineering-hiring)).

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.

~~~
gozzoo
> 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.

~~~
lnsru
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.

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

~~~
milesvp
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.

------
pm24601
How about telling candidates why they were rejected?

~~~
stronglikedan
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.

~~~
pm24601
That is not true. GDPR specifically requires that interview notes be available
to the candidate

