I use this process and it works great. We give potential hires a 1-4 hour project to do at home, they bring it into our office to defend. We don't pay them to create the project. We don't look at education. Some of our top coders are self-taught.
A Method I’ve Used to Eliminate Bad Tech Hires
381–390 of 517 posts
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#382Earlier quoted context omitted.
Maybe we're just very different. It would only take me minutes to whip up a few Django models, a few CRUD views and a Bootstrap frontend, but I've never needed to write a messaging system or DB storage from scratch (there are dozens of these off-the-shelf). That having been said, most of my value is writing sane, readable, cohesive code that can easily be extended years later, with a minimum of refactoring. That's wh…
Yup, everybody's different, nothing wrong with that! I appreciate people who do the work you do, but not every software company does websites at all . And even of those who do, plenty have grown to the point that off-the-shelf doesn't work anymore and some specialization is of greater value. (Think Uber, Slack, etc) I agree with your second paragraph completely.
Yeah, exactly. You'd need to go to one of the big companies to need those skills, so you usually get companies who want some sort of API glued together with off-the-shelf components, mainly because smaller companies are much more numerous than larger companies and off-the-shelf is good enough at small scale.
This wouldn't cut it at the companies you mention, I agree. I think the main thing is that the actually valuable skills (being able to figure things out on your own, having an intuitive sense for when a solution is suboptimal even when you don't know the optimal solution, knowing design patterns, etc) are transferrable, so a good developer could work on either thing.
It probably wouldn't take two hours to become acclimated, but after a short ramp-up period, they'd be pretty good at it.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#383Earlier quoted context omitted.
Indeed interesting how different people are. Here, I'm like you. But it carries over to normal job - I work best when left alone. Especially when I have a tough problem to solve, just having people sitting close to me makes me frustrated, and if they're talking, then I won't be able to concentrate at all. It takes a lot of energy for me to be able to work in the presence of other people.
I understand where you are coming from... I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid. The consulting companies or body shops were happy since they could bill 2x the number of heads for the same amount of time. The "buy-side" of Pair Programming were happy because the KoolAid evidently worked. Don't get me wrong, I am all in favor of getting my code eye-balled by anybody becau…
> I think somehow the world was agreeable enough to drink the Pair-Programming KoolAid.
Not sure what you mean. In 25 years, my latest job is the only one that pair, and even then it's only a few teams in a very large organization.
I don't think your AB test makes much sense. The two practices are orthogonal. Complementary, but orthogonal.
If I had to take one over the other, I'd to TDD, or at least strive for excellent test coverage over pairing, but they really don't have anything to do with each other.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#384Earlier quoted context omitted.
I just wouldn't expect to be applying for something / trying to do a test task, where I didn't already have the knowledge. Then again, I don't really use SO anyway - I know somepeople use it daily.
What does it mean "to have knowledge"? How much information qualifies you to be a knowledgeable? Plenty of us have a knowledge. Until, for one of your project you have to use Spring Boot and Hadoop at the same time. You know them well, you work with them already. But then you put both libs into one project and something throws an exception somewhere deep down in the unknown code. This is unexpected and does not come…
I guess that I disagree with many people on HN (and they certainly like to express this with downvotes).
Fair enough.
Thank you for your verbose reply - I'll reflect on it.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#385Earlier quoted context omitted.
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.
> The other problem is that when you pay them you generate all sorts of nightmarish legal liabilities. I was wondering about the tax and legal implications around paying someone for an interview challenge as well. The overall idea seems fantastic, but paying or receiving money for an interview coding challenge is a little weird.
Plus, what about candidate non-completes, doing a paid task for a competitor? (Most people aren't in California.)
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#386This. 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…
I'm a subconscious problem solver also, I do it on purpose alot of the time, I can solve some things immediately but most of the time I get it later in the day when I go back to it or let the answer come to me.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#387This seems like a pretty popular take on the interview process here on HN. However, there's one pretty glaring flaw that I've never seen discussed: if the interviewee can take the problem home, what prevents them setting up a hackathon with their friends at their place, and making the interview problem a team effort? A couple of knowledgeable friends can do wonders, and if you also prep with them a little you can pro…
> setting up a hackathon with their friends at their place, and making the interview problem a team effort?
Cool, can they do that for all of their work from now on? Heck, I'll hire all of them if they're that cohesive a team.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#388This 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…
>> I have a job now, which claims ownership over any tech-related IP I create. Is there an omitted qualifier to this, e.g. ...while on company time; for IP with sufficient correlation to your primary role? I'm having a difficult time swallowing the legal enforceability of "all-day-everyday-any-tech-related-IP" outside of military personnel subject to the UCMJ. Would that suggest that you technically couldn't contribu…
I have to get exemptions for any open source contributions or personal projects. My employer gives those out readily, but I'm expected to follow the process.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#389I a single non tech question that is a very good heuristic for hire/no hire. What is your favorite 4 letter word. I usually ask at the beginning of interview and expect an answer at the end. Answers like fuck and shit === no hire. The other ones tell you a lot about the person
Good grief. We are real idiots on this hiring stuff.
Re: A Method I’ve Used to Eliminate Bad Tech Hires
#390This. 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…
i do love this idea but not sure if doing it remotely is a good idea. We do this in house because I am not sure how to be certain the candidate did not get help. I mean i believe people are generally honest but there will be cases when they are not, and I'd rather not find out 3 months after hiring them. Also there are many indicators along the way, i.e. which parts the candidate got stuck at, did it take them 1 or 3…
Do employees at the place you work at never ask their colleagues for help?