Hacker News Reader

Comment by indymike | Hacker News Reader

We use this process, and it has helped us hire some great developers without having to use third party staffing and headhunters:

1. Post well written job post on major job boards.

2. Immediately reply via text to every applicant (yes, we have opt in on the application)

3. Initial screening including several knock-out questions via text. Immediately let candidate know if they are not selected and why.

4. 30 minute can you write a working function from requirements code test. Allow one re-try. Immediately let candidate know if they are not selected and why.

5. Interview and code review session. Bring a side project, show us how it works.

6. Offers out.

7. Background checks start in parallel with on-boarding. First week is spent with business unit teams to learn what the company actually, really does.

8. End of first week, we occasionally have to let someone go on background issues. Otherwise, week 2 is first week coding, expect a working pull request by end of week. All candidates informed position is filled, ask if they would like to be alerted if similar job opens.

Works like a champ. Helps we write software that does this.

Average developer tenure is two years, company is three years old. We write telecom software that does texting, voice and video interviews.

View on HN

> 7. Background checks start in parallel with on-boarding. First week is spent with business unit teams to learn what the company actually, really does.

Yikes!!! I’ve never heard of a potential employer giving offers before background check. Do you tell candidates this before they quit their current jobs?

Exactly. A lot can unexpectedly go wrong during a background check, some companies ask employees for (very old) W2's they may not have, etc. There was a time when I worked at <redacted> and a new co-worker suddenly disappeared without a trace, and I was told in confidence by a VP they "were not who they said they were" which I presume means they failed a background check. This was during growing pains, they were probably doing checks after hiring.

> "were not who they said they were"

I worked with a guy who it later came out that he was convicted of conspiracy to commit murder when he convinced a buddy of his to kill his ex-wife and her new boyfriend. Probably should have had better background checks at that company.

…why would you need an old W2?

People lie about job history

So you reference check with the company’s HR department, no? There is way too much info on a W2 that no future employer should have.

There's a school of thought around comp where what someone's made in the past should inform what you offer in the future. Some use comp history as an indicator of quality. Some use it as guidance for making sure they don't offer too much.

If an employer ever asked for an old W-2 I'd refuse, and if it was enough of a problem I'd recuse myself. That's private, sorry. Not that it would matter for me personally, I've been self employed for 15 years. But still there has to be some self respect.

Unfortunately these types of requests come after you have presumably accepted the offer and declined alternative offers...

All “high-horse” claims work better when yo have cash in the bank and don’t need to get that job right here right now.

I also decline signing NDA, providing data they should not request. Asking to cross off anything that encroaches intellectual property I might create after hours.

But if I would need that paycheck ASAP all of it goes to trash and I would comply to most of shenanigans, maybe not all but still.

> Asking to cross off anything that encroaches intellectual property I might create after hours.

We're pretty big on making sure that our contract allows this as we encourage developers to do side projects - open source, etc. We do have an anti-double dipping clause.

Your example seems like something that the employee likely knew of though.

If it’s fully communicated that the background check happens in parallel and the new hire doesn’t expect anything to pop up, it seems like a good option (provided the employer is reasonable about trying to solve unexpected inaccuracies that may arise).

In my last two positions, I’m pretty sure my employment contract included a section indicting that at any time they can do a new check on me. And I believe my most recent one explicitly asked if I expected anything to come up.

> Your example seems like something that the employee likely knew of though.

That's true, but consider this: by running these checks in parallel you are exposing your employees to whatever risks the new element brings in. Perhaps they were convicted of SA etc. and decide to stalk someone at your co.

It just doesn't seem like the best idea.

We're not doing a salary verification so we don't make the new hire provide a bunch of data, aside answering questions about where you lived, when. We are doing a court record and criminal background check. When we have a problem 100% of the time the new hire has misrepresented themselves. We tell people exactly what the background check will discover, and we've even hired people who have disclosed issues prior to the check (nothing serious).

As someone not familiarized with background checks, why is it weird to do bg checks after handing the offer?

If the employer does the bg check before handing the offer, that means the candidate hasn't resigned yet from their current job. So wouldn't the bg check expose the candidate? (E.g., my boss would know I'm thinking about leaving)

Doing the background check after the offer is fine, it's insane that they do it after the candidate already starts the new job. So what, I leave my current job to come work for you, and in the first week you tell me "sorry you failed our background check" and let me go? Who the F would ever agree to this kind of risk?

>>8. End of first week, we occasionally have to let someone go on background issues

Yeah, that's bonkers.

This is normal for non-tech employers. It is novel in tech, but not something that is bonkers in other sectors. We're able to have developers on the payroll three-four weeks before offers are out by competitors.

I wonder where you find developers desperate enough to accept such conditions - I'm not sure I'd want to work with them.

This has never been a problem, except when someone is currently employed and is leaving a job to take one at our company. Right now, there's a lot of really good talent that does not have this issue.

>>except when someone is currently employed and is leaving a job to take one at our company.

And in that case you do the check before they start with you, yes?

Of course.

In that case it seems like all of the criticism in this thread is moot.

We're not talking like government security clearance here. If you have some major legal or financial issue in your life then maybe it depends what exactly the BGC turns up or how it's adjudicated. If not, there's basically zero chance it's going to affect anything. Just a formality from the candidate's perspective.

If it's just a formality, why not do it before you start the job then?

If it’s just a formality, why would you delay the new hire’s start by several weeks while it’s pending?

As an employer you wouldn't - but I don't understand how any employee agrees to starting before it's complete.

You already know whether you have a criminal record or financial catastrophe. If you do, maybe you need to wait and see what they think of it. If you don’t, there is no chance of a problem.

Background checks don't call your old boss. How would they even know who that is?

Have you ever done a background check with HireRight? They ask you for all of your previous companies and contact them to verify. I think there is an option not to call your current employer.

How far can you legally go with those in the US?

Here in the EU at most you can ask if they worked there, nothing else.

Oftentimes, in practice it's the same.

Aside from things that may lead to accusations of violating equal opportunity employment laws, you can ask just about anything. Many previous employers won't do more than confirm employment though, as a negative review may open them up to liability. As a result, the norm in many industries is to only ask (and receive) confirmation of employment.

Nearly the same. “Did BigJ1211 work at your company? Would you hire them again?”

But that signals to their current employer that they’re applying for other jobs. Unlike the EU, employers in the US can be retaliatory about that.

There's a huge background check fetish here in the US, and it's facilitated by a massive lack of privacy and an equally big fetish for everlasting punishment.

Want a job or rent a place? Background check, baby!

Not just prior employment but even civil court cases and criminal history are all a part of it, and it doesn't help that even something as small as a traffic ticket shows up on your records.

Have you ever sued a landlord to get your deposit back? There's a good chance your new landlord doesn't want you.

Were you convicted of petty theft years ago? That might cost you your prospective job.

In most of the EU, much of this information isn't public, and in many countries, criminal records are inaccessible.

Often, in the latter, you can get a declaration of “good behavior” from the government if your prospective job has some sensitive elements. The government will then issue one or decline based on the specific job and its risks with your record in mind.

Were you caught committing a DUI? You won't get one for a job as a cab driver, but you can safely get one for working at a bank.

Have you got caught embezzling money? Then you can't get one working at a bank, but you're welcome to become a cab driver.

In the US? Well, you're SOOL. Enjoy being marked for life as your options to get an income legally have significantly shrunk.

> So wouldn't the bg check expose the candidate? (E.g., my boss would know I'm thinking about leaving)

HR at the orgs I've worked for call that a reference check and it is usually concurrent with the other background check processes before the offer. The background check I'm thinking of is more like criminal history, work eligibility status etc., potentially drug screening etc. I know I have no criminal record but I'd really like to know that whatever service HR is using to screen agrees with this before I quit my job.

Yeah this sounds like it should be illegal, although it's probably allowed in the US. There's no way it is clearly communicated to candidates, I don't think most people would agree to a contract that says "FYI we might fire you after a week if HireRight doesn't like you, no we can't check beforehand you'll just have to hope you meet our standards."

Yes, I agree that the company should be clear about this upfront.

I would think that people affected by this are probably used to this coming up and are up-front with what happened before the accepting the offer. "Hey, so great to hear about the verbal offer. So about white collar crimes..."

Unless the company is somehow getting expunged records or something like that, it's likely that the person is lying about something they shouldn't have and got caught.

On one hand it sounds off putting, on other hand it can be very awkward that you have hired a mole from competition who is there to understand your secret sauce and get out or that you have hired somebody who was in prison for computer crimes.

A week -1 background check would find anything a week 1 background check would find.

Yes we disclose. We have to. Incentive is on the candidate to be honest.

I work for a large, well known tech company and can confirm I had a formal offer before doing any background check.

I can bring my kids in but I don't think I could tell you how they work. I've been in this industry for almost 20 years, but I don't have side projects, because, well, see above.

Agreed not everyone has side projects. But being asked to build something of your own interest in about half a day seems like a good alternative.

I don't know what I could do in half a day that would impress anyone. Especially if other candidates are bringing in their serious side projects.

Freelancers can quickly build out some side projects for you to use on your resume if you wish. It shouldn’t be a big deal.

That seems super dishonest and the kind of thing that would get you in big trouble if discovered. Hell if you're going to lie like that might as well lie on your whole resume.

There is zero chance of being discovered. You pay your freelancer, own the project, throw it up on your GitHub, no one will ever know.

Meanwhile, you get to spend more time with your kids.

Which is why this is a dog whistle for ageism.

My go to side project right now is training a neural net to operate a bio-mechanical process to automate waste management for consumers.

By which I mean I'm potty training my 3 year old.

You’ve never written a utility at work to help that isn’t part of your core work? You’ve never had a side project in 20 years ?

Maybe your view would change if you were actively looking for work? Spend a week on some fun project while taking a break from resume writing.

I've never heard side projects should be recent or ongoing. How do you not have any side projects? Have you only ever programmed professionally?

I doubt they would want to be judged on code they wrote 10 years ago, though

I doubt they would want to be judged on code they wrote 10 years ago, though.

>5. Interview and code review session. Bring a side project, show us how it works.

So you are filtering out candidates that have families or lives outside of work that do not spend their free time coding?

Yes that is precisely what happens here. It's intentional.

It also doesn't scale up high enough, because the pool of candidates is smaller. It's a big part of why you won't see large companies hiring this way, typically. The other big part is that big companies have lawyers who see potential for lawsuits due to discrimination.

Same thing leetcode does tbh

It's great that you quickly notify candidates if they aren't a fit! Wish more people did that.

But....

>Bring a side project, show us how it works.

What do you do if someone doesn't have a side project (or want their side project to be reviewed by someone they don't know)?

Some people code to live, not live to code.

I'm not defending the practice of requiring that a side project be presented. I think that's over the top and wouldn't do it -- however, if a candidate volunteers one, that does give a huge advantage to that candidate.

> Some people code to live, not live to code.

Totally fair. But there are lots of companies who prefer people who code because they love coding over those that do it just for the paycheck, and that's also totally fair.

I don’t think this was intentional, but you missed the third category: people who love to write code but only have time to do it for the paycheck.

Oh, I think it is very intentional, and the whole point is to not say it out loud.

If you don't have time to code for "love", you won't have time to jump at unreasonable requests and pull tons of crunch time overtime either.

Given the choice, companies would love to hire someone with no responsibilities outside of work, this is just a legal way of filtering out parents, people with dependents etc

> If you don't have time to code for "love", you won't have time to jump at unreasonable requests and pull tons of crunch time overtime either.

As opposed to doing leetcode? when you also have to spend time outside of work to practice and memorize them?

If you are looking for a new job, you have to invest time and effort. One way or another. Unless you are a known quality.

Can you suggest a fair way to evaluate a candidate?

I love to code, hell, I do it almost 40 hours per week. And I get paid to do it, isn't that cool?

Sometimes a side project catches my eye. But I have more than a singular interest. And kids. And to be honest, when a side project catches my eye, work suffers a bit because those tiny moments I have to fill with thoughts are spent on my side projects rather than work projects.

>Some people code to live, not live to code.

That doesn't mean not loving coding.

It means that you might have other hobbies that you want to spend time on, or other obligations you have to spend time on, etc.

I like what I do at my job. I would even go as far to say as I love it. I also don't do it for an extra 20 hours a week (beyond the 40 hours I already do for work) because I have other things I love to do too (sometimes more!); quality time with friends, family, my other hobbies, etc.

Then those people get ranked lower (for good reason).

I can sympathize, but keep in mind most professions expect you to commit to a certain number of hours of continuing education. Often you can convince your employer to let you do this during work hours (or even pay for it!), but not always.

Continuing education credits is pretty far from "bring in a hobby project for code review for this interview".

Is there even a CE credit available for coding up a hobby project (and who from)? Completion of a course, attending a lecture, attending a lunch & learn, etc. are the CE credits I am familiar with (spanning a few different professional bodies).

Sometimes you can declare "self-learning", depending on the order.

But anyways, that's not really my point: My point is just that in professions it's not uncommon to be expected to perform some kind of extracurricular activities related to your job. Often software "engineers" aren't members of a professional order, but I'd argue that the idea still applies. Tbh learning by working on a hobby project is way more appealing to me than watching some PowerPoint presentation...

>My point is just that in professions it's not uncommon to be expected to perform some kind of extracurricular activities related to your job.

If my employer _expects_ me to do something related to my job, I get paid for it. I really wish we'd all stop normalizing working for free.

I don’t understand your view. How do you improve your skill in the craft ? Or learn new technologies ? You wait for your employer to tell you to learn something ? That’s a sure fire way to always be behind the curve.

I don't understand how you reached that conclusion.

If it is a personal interest or hobby, I do it on my own time. If it is something required for work, I do it on company time. If there is a lot of overlap, I do it whenever.

Other than that, I learn and improve like any other person does.

Continuing education credits, which is what started this subthread, is something required by the professional body that my company wants me to be a member of. So they happen on company time and dime.

Employers don't require their employees to be members of a professional order because they think professional orders are nifty- It's because certain jobs are only legally allowed to be performed by a member of said order. If you were a dentist and ran your own clinic, you'd still need to be a member of a professional order (at least in Canada and the US afaik) to practice dentistry legally, which would come with obligations outside of your usual working hours.

Software engineering exists in a sort of gray area where you can often be a professional software engineer without having to be a member of any order, which is great in many ways. But I feel like one could argue that the informal expectation of software engineers to care about software outside of their work is similar to what is expected in other professions with more rigid governing bodies.

>Employers don't require their employees to be members of a professional order because they think professional orders are nifty

I didn't say they do it for nifty-ness. At risk of repeating myself again: if it is a requirement of my position, I get my employer to pay for it. Why it is a requirement doesn't matter to me.

If you want to pay for and do continuing education things on your own time and dollar, I'm not going to stop you.

>But I feel like one could argue that the informal expectation of software engineers to care about software

I didn't say I don't care. I just have plenty of other things that I care about that take priority when I am not working (spending time with my family, friends, doing other hobbies, etc.).

Here is a dark side of side projects (pun unintended). I went to an interview which was a nodejs shop. I was excited as they wanted to see a side project. Most of mine are just things I do for fun. Anyway it was in golang (with lots of control plane like features for a "fun" saas offering). Cto wasnt happy that I had chosen go and wanted to know why I hadn't chosen Node instead. (Never mind my Fe was in typescript). He wasnt happy with any of my explanations and came back with retorts like "well you have async/await so you don't really need goroutines).

First of all nobody should be forced to be judged on side projects alone. There are several talented "family folks" out there. And even if not there are enough "recharge on my time " folks which is totally fair.

Secondly just like in leetcoding interview all it takes is an inexperienced interviewer with a script to degrade the experience!

Yeah, I provided a side project once during an interview process and the only feedback I got related to my use of the 'static' keyword and how that could introduce an undesirable side effect when deploying into a web server (or something like that.) Not sure where they got the idea that the side project would ever be used in that way, unless they were trying to do that themselves.

Yeesh, sounds like you dodged a huge bullet. What an insanely narrow minded individual.

I want to see good engineering practices, I might be curious about your language decision, but I'd never tear you apart for your choice.

right, and i even explained that node was for single-language simpletons, but he didn't like that either

> Bring a side project, show us how it works.

"As you can see, it's based on a I-IV-V chord progression..."

"Usually I try to take advantage of the negative space, but it's not cheating to add a little white gouache in spots like this..."

"...and here you can see that I did more than 12 reps, so next time I'll up the weight."

"When she makes that face she might be pooping. If you ask her and she says 'HHHNNNNNO!' she's trying to hold it in, so bring her knees up like so..."

So you have someone start before you've decided to hire them. This sounds incredibly sleezy.

Sounds incredibly like a non-starter for people who aren't completely desperate. Then again, maybe that's who they're looking for.

It's bizarre to do with background checking specifically. Like WTF, you're gonna have someone come in and then fire them because of their past.

I thought it was bad enough these people trying to get you to start as soon as you clear HR.

I'd never even thought about the idea of starting before getting the greenlight... this is insanity.

In the U.S. you'd get title IX'd eventually. All feedback will be used against the company. This is why leetcode was spawned, to weed out the 99% in a way where nobody can claim discrimination. The last 1% can be picked with discrimination by failing the undesired candidates, the "not a culture fit".

> we occasionally have to let someone go on background issues

What kind of issue would that be?

Undisclosed felonies is a popular one.

Had they disclosed the felony would they have made it that far?

I have heard of employers allowing you to explain them, yes. Example: Felony DUI: explain your remediation steps, AA, etc.

Maybe. But they definitely should have brought it up before accepting the offer.

Embezzlement or something? Probably a no-go, especially if you are anywhere near money.

There's a whole host of crimes out there that you could have committed and be hired after. But the opportunity to explain yourself looks much better if you do it before accepting the offer.

Not having a side project going on in the background.

I fail at #5.

Most all the coding I do is for the firm I work for, occasionally some of it escapes to the open source world if I can convince some manager to let it.

At the end of the day, if I've wrung out all I got, that's all there is. It is best to recharge and get ready for the next day.

I've written some pretty cool stuff. But often the code isn't 1/4 of what is interesting about what got written :)

Man, I forgot how much people on hacker news absolutely hate the idea of side projects, a.k.a. passion for engineering and an interest in creating new things.

Somehow the implication is that if you build even one little side project for fun that means that you spend every single hour of your time coding. It's such a reductio ad absurdum argument.

If I was hiring an architect, I'd expect to see samples of their work.

If I was hiring an artist, I'd expect them to have a portfolio on Behance or Artstation.

etc. etc.

It sounds like you have the mentality that everybody must be a front end developer.

I work in a domain that's very much not front end development, I've participated in interview rounds for at least 100 different candidates, I don't think I've seen "side projects" ever be a factor in someone getting hired, not even once.

The one thing that did put an applicant way ahead of the pack was contributing to open source projects relevant to our domain. It didn't have to be anything super duper impressive, we just liked to see a history of submitting meaningful PRs and getting them through code review.

AI could do code review better than coding.

90% of code review is BS - and AI excels at BS.

Are you hiring now? :)

"Bring a side project, show us how it works." Can people in the industry stop this please? You have to be mentally sick to ask people to code review their side projects. It doesn't make any sense.

"Average developer tenure is two years, company is three years old." Got it. I don't think this statement says what you think it does.

Agree. Interviews taken into account side projects are biased towards:

- people who have free time to work on side projects (usually young people have more free time than people with families)

- people who don't mind sharing their code with others

- people who work on interesting side projects. If your side project is boring, that will probably bore your interviewers -> no offer

- people who work on side projects on regular basis. If I get to work on one side project every year, well, chances are I may have forgotten the hell I did on that project (depending when the interview takes place). If I work on side projects constantly, I have no trouble picking up a fresh one to talk about

> people who work on interesting side projects. If your side project is boring, that will probably bore your interviewers -> no offer

This hasn't been my experience at all. The interviewer doesn't care how "interesting" the side project is. What they want to see is what your actual working code is like, that you demonstrate a good grasp of programming concepts, etc.

I wouldn't be worried about boring my interviewer and getting rejected because they consciously recognized that they were bored, I'd be worried about there not being a level playing field between projects when the hiring committee is discussing it later. The guy who built the fun video game will probably be remembered more fondly than the guy who built the CLI tool for tracking the weather.

> people who have free time to work on side projects (usually young people have more free time than people with families)

That's the whole point. Companies would always prefer someone with no responsibility who can be guilted and pressured into doing overtime over someone who can point to actual needs outside of work that they need to attend to. It's a great way of filtering out people who will have boundaries.

> You have to be mentally sick to ask people to code review their side projects.

Could you expand why? We allow people to substitute a tech interview round with side project showcase. Don't see why it doesn't make sense in your view.

> "Average developer tenure is two years, company is three years old." Got it. I don't think this statement says what you think it does.

So what does it say?

> Could you expand why? We allow people to substitute a tech interview round with side project showcase. Don't see why it doesn't make sense in your view.

As an option to replace a different interview segment I think that's quite fair. But both choices have to be clearly presented to the interviewee, and they should understand that either option is treated as equally good. OP's interview format seems to assume that everyone does the side project and the tech interview round isn't an option.

> So what does it say?

It depends on the definition of tenure... if tenure is defined as a closed interval (i.e. defined only for developers who've joined and then left) then it means that, of the developers who have departed, none had wanted to grow with the company, or the company had let them go. For a startup company this might not be a good sign.

If tenure is defined as the length of time the developer had worked, OR, has worked so far, then it means they have a core group of developers and aren't growing the development team particularly quickly. Again, this might not be a good sign for a startup.

> then it means that, of the developers who have departed, none had wanted to grow with the company, or the company had let them go. For a startup company this might not be a good sign.

What. Of course that "of the developers who have departed" all have left/been fired, that's a tautology. How is it "not a good sign"? Or is it supposed to be a bad sign that there even is a person who is not working there anymore?

I think parent meant:

Assuming tenure is defined ONLY for those who have already left, 2 years is a bad sign. For a 3 year old company, if that definition is used, it is indeed pretty bad. It means that _of the people who are leaving_, people stay a couple of years, then bounce. This means people stick around long enough to get past the warmup of new employment, get used to your stack and tech, then bounce for greener pastures.

The very important metric this leaves out though is what percentage of the company actually left. If there's 7 people in this 3 year old company and only one person left last year . . . that says almost nothing. Any single person can leave for a great variety of reasons. You'd need a decent sample for this to matter.

The flip side definition of "tenure" is worth considering though: if the average tenure of 2 years includes people still working at the company, there are a lot more variables to content with before you can know anything. A 3 year old company could have an average employee of it have been working there for 2 years and not a single person who joined the company having ever left (e.g. if at year 1 there was a decent amount of hiring). I think this is probably why parent wanted to restrict the definition (and why it's worth thinking about this angle) - because otherwise the company ramp up and trajectory and hiring patterns become hidden variables and you can't glean anything out of the tenure numbers on their own.

I still don't get what's bad about that. So what would be a good tenure for a 3 year old company if 2 years is bad? 2.5 years? 1 year? 6 months?

It creates an extremely subjective comparison between candidates.

Part of it is like a sibling comment said, if an interviewer's interests lie more in line with devops, then a devops project that solves a problem he's acutely aware of will be given much higher praise in his mind, and allows him to engage with the candidate more. If the interviewer rarely does any devops and isn't totally sure of the problem space, he may be biased towards thinking it's overengineering a problem that doesn't exist, or may not fully grasp the problem in the time allotted. The candidate could articulate the side project exactly the same but have completely different interview outcomes in both outcomes.

And an argument could be made that "it's a test to see if the latter candidate can articulate a problem and peak the interviewers interest" but in this case the former didn't even have to do that, and thus you are judging candidates by different subjective metrics. And it's especially an issue if the side project isn't directly related to the role (e.g. video game vs cli tool vs database vs website, etc...).

It also means that some candidates will be judged on system design (if a side project is wide scoped) while some candidates will be judged based on algorithmic design (if the side project is very narrow scoped with the details in the implementation).

It just adds so many variables to the interview project that you are no longer comparing "which candidate is the best fit for the job I am actively hiring for" and instead "which gave me the best vibes", specifically because you did not actually measure all candidates by the same measure.

very clearly said, this is such a subjective process.

    > You have to be mentally sick to ask people to code review their side projects.

I would love to do this; it would give me an opportunity to showcase my side projects, my coding style, and all with code that I'm already familiar with.

It would be great, IMO.

Reply on news.ycombinator.com