Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Method I’ve Used to Eliminate Bad Tech Hires

mattermark.com

Post reply on HN
Print view View original

201–210 of 517 posts

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#201

Post by daxfohl »

rnovak wrote: post #122
verbify wrote: post #87

Earlier quoted context omitted.

I agree, maybe I'm a poor programmer, but 2 hours seems incredibly unrealistic for: a) Creating a frontend form to submit movies b) Creating the database to store movies c) The 'search to find the movies' feature Maybe I could do it in two hours, but it'd be pretty bad, and there's no point showcasing poor quality code. My favourite was when they asked me to produce examples of things I had coded. Like any other crea…

Do you not use frameworks or anything? CoC (Convention Over Configuration) solves most of the problem for you, since it's basically CRUD, and that is boilerplate stuff in pretty much any language.

Of course the task should be a test of the stuff you'll be doing on the job. If the job is to create quick websites without a whole lot of complexity for lots of clients, this would be an apt test. I'd fail that miserably and probably not like the job anyway. If the job involves working on more complex backend systems, then have the candidate write an async messaging system or DB storage system from scratch. I'd ace that. If the company has a large product, give multiple projects and let the candidate self-select.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#202

Post by bojo »

ubernostrum wrote: post #43
redwards510 wrote: post #14

Earlier quoted context omitted.

I don't mind homework, but companies need to start specifying their salary range up front. I've been having a lot of time wasted lately by getting through Tech Interview #1 or Homework #1, only to find out their max salary is laughable for San Francisco. "You should just find that out upfront" I hear you saying. Well that is not always possible. Recruiters either don't know the range, or lie about not knowing, or you…

In addition to salary range up-front: find out up-front if they're actually hiring you, or want to do the "contract for a while, then maybe we'll hire you for real" thing. I had to say no late in the process to several companies which offered me the contracting-to-maybe-hire dance.

I had an incredibly bad experience with this recently. They failed to do the end-of-contract review on time, extended the contract period numerous times after, and when they finally got around to the review said, "we're not a good fit." I actually liked the people and the job, but got the distinct impression it was just a team full of devs that wanted a devops to clean up their terrible infrastructure mess, future proof it, and then let them go.

Never again will I do contract-to-maybe-hire.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#203

Post by developer2 »

nolite wrote: post #104
pauljaworski wrote: post #21

This is literally the only way I've gotten job offers. I'm a very competent programmer, but when I'm asked to solve some silly puzzle with someone staring over my shoulder, I freeze under pressure and can not think at all. Luckily not everyone thinks solving leetcode problems is a good way to hire.

I've been in situations together with clients deploying a product, them presenting it for their managers, orpreparing for a big demonstration, and something goes wrong due to some unforeseen environmental factor you couldn't have imagined or predicted, and breaks in a way you don't expect, despite the weeks of testing you've done. You've got your main client staring over your shoulder, arms crossed saying fix it, and…

>> despite the weeks of testing you've done

I have never in 12 professional years been given weeks to test anything. On only a couple of occasions have I been given 3-4 days to extensively test a project with multiple months of development time behind it.

Clearly you're talking about the project where the developer(s) told you very explicitly that it could not be done in less than 3 months. So you just assign the Jira ticket a 3 week deadline anyway. And then flip out when a half-assed project fails to ship. Welcome to the world of software development.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#204

Post by peteretep »

greglindahl wrote: post #187
peteretep wrote: post #179

Earlier quoted context omitted.

Most external recruiters don't make much more than a couple of placements a month, so they are absolutely incentivized to amp their commission up as much as possible without losing the sale. Was this not the case when you were working as a recruiter?

As a hiring manager and candidate dealing with external recruiters, that's not what I saw happen.

How did you get people you didn't hire to share with you their actual salary preferences, and companies that didn't hire you their actual salary ranges? Sounds like that would be super useful info

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#205

Post by eloff »

I wish I could filter jobs by this criteria. Can we do this in the who's hiring thread? I'm sick of the interview process and massive unpaid work assignments cough Compose cough only to find out after investing thirty unpaid hours that they can't offer US market rates to a Canadian for 100% remote job. Oh and they also want to own anything you do in your free time.

Sorry for ranting, I'm just pissed off at how an industry that brags about how they pamper their employees can treat them like garbage during the interview process.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#206

Post by JauntyHatAngle »

blazespin wrote: post #172
zachd1_618 wrote: post #49

This. 100% this. As many others are saying, I find that this is the most comfortable way for me as an interviewee to demonstrate that I do in fact know what I'm talking about. Put me in front of a room full of people and a whiteboard and throw something at me, and I'll freeze. Freezing in that situation and being a bad engineer are wholly separate things. Anecdotally, when I get one of these problems, I spent 20 minu…

This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem.. The other problem is that when you pay them you generate all sorts of nightmaris legal liabilities.

>This works, but make sure they spend the 2 hours in your office and not 12 hours at home solving a 2 hour problem..

Did you read the article?

That's what the article author is saying not to do, they prefer to see a well worked solution after you define a particular technology, showing they are adaptable and have thought it through properly.

Limiting them to your office, timeboxed, advantages people who spit out lines of code quickly, which is definitely not the right fit for a huge amount of coding positions, especially when you are emphasising logical choices and design decisions.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#207

Post by mahyarm »

verbify wrote: post #87
mahyarm wrote: post #54

This is the coding exercise/homework interview. A bunch of place do this in some form or another, usually without paying the person, and as part of a series of interviews on an interview day. I myself don't like homework questions, mostly because I still have to do an onsite, and I only have so much time to do these things. They are usually much longer than 2 hours too. If you communicate upfront that it should only…

I agree, maybe I'm a poor programmer, but 2 hours seems incredibly unrealistic for: a) Creating a frontend form to submit movies b) Creating the database to store movies c) The 'search to find the movies' feature Maybe I could do it in two hours, but it'd be pretty bad, and there's no point showcasing poor quality code. My favourite was when they asked me to produce examples of things I had coded. Like any other crea…

We only expect you to make what is possible in 2 hours, and we've seen a bunch of similar exercises. It doesn't have to be poor quality, just basic. Usually the UX isn't expected to look nice at all either.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#208

Post by cloudjacker »

ahh wrote: post #10

This system is interesting but has a crucial flaw: I legally can't take part. I have a job now, which claims ownership over any tech-related IP I create. There are processes for getting exceptions, but a) you won't get them for actual job-related things b) I'm not asking Google for an exception so I can interview somewhere else. This is true for nearly anyone with a standard SV job. So if you're willing to restrict y…

A standard SV job .... in CALIFORNIA .... must restrict those agreements to things done on company time, on company equipment or suffer the whole employment agreement being invalid, severance clause or not!

Use that paid time off, or "flex" hours.

And regarding the paper trail, payments under $600 need not be reported to the IRS. 1099's only get filed after you have been paid over $600. Ask for cash.

Re: A Method I’ve Used to Eliminate Bad Tech Hires

#210

Post by FireBeyond »

zaroth wrote: post #78
throwaway4job wrote: post #59

Earlier quoted context omitted.

This isn't a viable approach for much of the hiring pool, as a majority of working engineers have contracts which explicitly forbid work for contract for other employers. As such, if you hire any of those, you're hiring somebody with a proven willingness to ignore their contract, which is a strong anti-pattern.

IANAL, but that's not what this is. "Work for contract for other employers" could literally mean I can't help my neighbor mow his lawn in exchange for a beer. In this case what it really means is a non-trivial amount of work done for meaningful profit. If I fix a friends computer in exchange for a nice meal, I am using my relevant skills to perform work, but I'm not actually violating a contract forbidding outside wo…

Ever hear of tortuous interference? When one party induces another to break their contract with a third party. For as realistic as your example is (no employer is going to sue because you mowed your neighbors lawn), plenty of employers can, have and will sue when they realize you have hired away one of "their" people, regardless of your rights and theirs.

Learning of your little deal to pay them for software development work will be the stick they use to hit you with that interference suit.

Post reply on HN