Hacker News Reader

Comment by misiti3780 | Hacker News Reader

I have passed a bunch of job interviews in the past - but I feel the exact same away and hire this way these days. I really do not see the point of brainteasers or white board coding questions if you have a budget where you can just pay out a contract like this.

Also, I believe there was an article posted here a few weeks back that indicated Google's brainteasers did not lead to quality candidates - I know I am cherry picking something that supports my beliefs but it was here nonetheless.

Also, I have interviewed a lot of people with 4.0 BS/MS in 5 years that turned out to be horrible employees. They were awesome with the brain teaser questions but sucked when they actually had to build something.

I guess I do not see how you can lose if you take the contract-to-hire approach ..

View on HN

I guess I do not see how you can lose if you take the contract-to-hire approach

I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.

Agree with this. There's a definite stigma with contract-to-hire, at least in my group of tech friends.

No one desires to be in a contract limbo where they aren't sure if they're going to be hired for real or or if they're doing the job search all over again in a few weeks.

Further, as soon as you use contract work to determine hiring criteria -- you've added your management into the mix. Are expectations made clear? Is the person's time managed efficiently? If management fails at any point then it's detrimental to the prospective employee's future, likely not by their own fault.

The contract doesn't/shouldn't be for a meaningful amount of work. It should be for the smallest amount of work that will allow you to evaluate the candidate. It doesn't even have to be for 'real' work - it could be a problem that has already been solved, or something that you think could be better but isn't a priority.

The point is, there's no reason for it to be a genuine contract position, and every reason for it to be concise enough for them to fit in during their off hours. After all, you are going to have to look at it too :)

And they do have the time for it: after all, they are making the time for interviewing.

disclaimer: i am 1/2 two members of the management team at my company - if it was larger - this could be a problem I agree

I don't think many candidates are interested in "immediate" hiring. Most people I know need to take extra time to wait for other offers to come in.

It also gives the candidate a way to see what kind of problems he'd be working with, and the quality of the code-base, working conditions, etc.

I think it's a win-win.

Many candidates with current jobs that they would like to leave are only interested in immediate hiring. They do not have the luxury to take several days off of their existing job for a tiny contract which might or might not land them a job that they might or might not prove to want.

One size definitely does not fit all here.

Nearly all of the high quality developers I know aren't interested in contract-to-hire, I know I'm not at all. To many things can go wrong in a short contract window, and regardless of the reality, most immediate hires feel they have a much stronger connection to the employer.

Well I would want contractor rates >$550 perdiem for this short term contract and via my company so I can reap the tax benefit.

Trouble is most employed people will have restrictions on outside work and if its related work the current employer will own that IP.

I recently switch jobs and can say with certainty I had no interest in contracting or contract-to-hire positions.

Quitting a full time job for a new position is a big commitment on my part, and I'd like a big commitment on the other side of the table. Not to mention contracting gigs don't usually have insurance, vacation, or other benefits.

If it means a more rigorous interview that's okay with me.

It doesn't have to be immediate, but most high quality workers will not be interested in anything that requires them to spend a period of time without a full-time job. So whatever contract work you give them will have to be small enough that they can do it while still working a full-time job, or you will miss out on most of the high quality people.

All of you guys are imagining some sort of 6 month junky contract to hire situation. All I'm talking about is a 3-10 day contract like the article mentions.

An unemployed candidate can do a contract like that while evaluating other jobs and possibly waiting for other offers to come in.

An employed candidate can do the work in off-hours.

>filtering out a portion of the highest quality candidates

if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) - well, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.

> if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) ell, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.

I'm not sure if this is a joke, but I'll bite.

The entire problem with hiring is that no-one, I repeat, NO-ONE is capable of determining who are the best candidates. If they could then everyone would the same formula and this would be a solved issue.

GOOG and MSFT have tonnes of hiring data and they admit they can't do this very well. It seems very presumptuous of you to assume you can and anyone who can't is somehow an outlier.

Good point. Maybe the best approach would be to let the interviewer choose the approach that works best for them. It would be sooo refreshing for a company to present me with interview options that will showcase my skills the best.

I've become a real believer in the "portfolio". I make the assumption that any person with a github (bitbucket/etc) site with a track record is someone worth looking at; if their portfolio demonstrates quality work and the resume looks all right, I'll recommend them.

Yes, false negatives, people with horrible IP agreements get screwed, etc. False positives are much worse than false negatives in the common business wisdom.

It seems to me like software engineering is one of the only fields with people arrogant enough to assume that every good and passionate programmer should also be doing programming as a hobby.

I loved software engineering so much that I decided to turn it into a career, so that I could do it every day. But now you want me to do it every day and every night? No. My work during the day is fulfilling. My hobbies provide variety and an opportunity to pursue other interests.

It seems to me that software engineering is one of the only fields with people arrogant enough to assume that employers should hire folks without being able to see what they've actually accomplished.

A "portfolio" does not have to, and should not, consist of side projects. Don't have any real code that you are allowed to share? Obviously, many employers won't hire engineers without reviewing existing code or having you engage in a coding exercise, but here's an idea: take a bunch of screenshots of public-facing applications/functionality you've built for your current and/or past employers. With WordPress and a $25 portfolio theme, you can have a decent-looking showcase of your work product up and running in a matter of hours.

If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem.

What? Not everyone works on front-facing, UI applications. What if I contributed a good amount of code to a large tech company's networking infrastructure. What do you want me to show you? A picture of the servers? A picture of Amazon's homepage or google.com, if those are the companies I'm working for?

Not being able to show "code" or "screenshots" is not the fault of the prospective employee (as you "oh so subtly" implied with your last sentence).

If you're concerned about your ability to convince a prospective employer that you're the real deal, that's for you to figure out, isn't it?

The point here is not what you share, but that you have something to share and can present it in a manner that's compelling to your prospective employer. In some cases, that might be nothing more than a well-written, detailed description of what you developed. In others, a picture is worth a thousand words and can a preferable format for somebody who isn't a great writer.

And finally, while I wouldn't be so naive as to argue that "engineering" equals "working on public-facing applications", engineers should consider the risks of roles that do not enable them to work on systems that are "visible" or "close to the money". Obviously, there are some industries and specializations that provide lucrative opportunities that don't do this, so there are exceptions. Not every young engineer, however, can realistically count on being able to build a decades-long career in these industries/roles.

> A "portfolio" does not have to, and should not, consist of side projects.

I agree with this

> If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem.

I disagree with this. If you require this to be true, you've instantly excluded everyone's experience in either government (particularly defense), or industry when you work on internal services. There's a huge number of enterprise developers at my current company who will never be able to show you their work because they're all internal applications. Maybe a "case study" would work, but you have to be real careful of not to cover anything that doesn't fall into the trade secret category.

If you're in an industry where it's typical for candidates to be limited in what they can share, then ostensibly the hiring criteria and process would reflect this.

If I have two candidates and the only signals are (resume, portfolio), then I will select the highest signal. I am sorry, but I can't in conscience decide to take someone without proven work over someone with proven work without other information.

If your resume is significant, then I will probably add to the signals with a phone call followup. I'm not looking to create false negatives.

I also want to point out that taking some time to develop a small and interesting project (say, a pure left-leaning red-black tree with deletion - not much code, but tricky to get right) does not take that much time and massively demonstrates your capability over having nothing at all. It also demonstrates your social awareness of the state of the field when you have a github account with projects in recent technology.

> If I have two candidates and the only signals are (resume, portfolio), then I will select the highest signal. I am sorry, but I can't in conscience decide to take someone without proven work over someone with proven work without other information.

On the upside, the person with a code portfolio and less other hobbies is also more likely to be winning to commit more of their time to work, stay later, do "hackathons." It's a win-win for the employer! /s

I couldn't agree more. I think far too many candidates fail to make an effort to demonstrate what they have achieved in the past, which is generally a pretty good indicator of what they're capable of delivering going forward. Although portfolios are a must for designers, I'm always amazed that more developers don't put something similar together to showcase their work.

Early in my career, I decided to transition away from mechanical engineering and applied for programming jobs. Many companies refused to even talk to me. But for one that did set up an interview, I brought in listings of software I'd written. I basically ran the interview, bringing out the listings and explaining what I did, and I got the job.

I've interviewed many candidates, and it surprised me that pretty much none of them would take the initiative and sell me on what they could do. They'd passively wait for questions and then answer the questions.

Right. Most "brain teaser" technical interviews are just an oral test. We all know that passing a test is hugely different from productive work.

I don't understand why technical interviews are not more oriented to "how would you design X? Ok, what objects? What interfaces? How does that work, explain like I'm your 10yr old nephew? Ok, pseudo code that part. What are challenges with it? Have you coded similar things? Tell me about one. How would you do it different now? How would you convince me that it's worth refactoring? How about if I was your peer and I told you your idea was the worst thing I'd ever heard? Ok, now assume I'm working for you, and it's my second week, explain how to write your new design from scratch, and what some gotchas I should avoid are?"

We all know that green field coding is a rarity, and most time is spent writing/running tests, refactoring, bug squashing, design writing, code reviewing, team managing (always at least upwards and sideways). Most of this is still "technical", but seems to be overlooked with endless stupid brain teasers. I know what Knuth volumes are, I know what google is, and I know my basic algorithms. Most people don't need to have memorised how to implement random algorithm x.

> Google's brainteasers did not lead to quality candidates

This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser questions in interviews.

I disagree on whiteboard coding though. I don't find it that easy, but I think it's reasonable to expect a demonstration of relevant skills before you hire a candidate. Any sensible interviewer won't expect syntax-perfect code on a whiteboard, but it's at least a way of seeing if the candidate can walk the walk rather than just talking for an hour.

> I guess I do not see how you can lose if you take the contract-to-hire approach ..

For the first month, the vast majority of people are relatively unproductive. After the next month, good candidates are generally still going through a significant learning curve. Contracting several candidates for a few months to pick one who seems good enough is expensive for relatively little output - apart from salaries, they need desks and computers etc, and you have to do some interviewing to pick them in the first place. It's not a worthless approach, but I don't see it as a panacea.

Well, the person that referred to the article used the wrong term. Certainly brainteasers don't work, and they have been prohibited at Google for awhile. But the recent article stated that there was no correlation between interviewers and job performance. That the beloved hash table, distributed computing, priority queue, red-black tree questions that you pepper people have nothing to do with the quality of the person you hire.

Which I have argued many times on here, should be glaringly obvious. Measure what you want to measure. I have never said "I'm so happy we hired Jane, she just tore up that smart pointer implementation yesterday". I like and dislike colleagues based not on comp sci algorithms, but whether their code is readable, how many bugs are in it, how quickly they can produce production quality code, whether they are responsible and hit deadlines, if they ask for help when they need it, if they offer help when other need it, if they are creative, if they are doers and achievers, if they take baths (seriously), if they step out of their office and interact once in a while, if they are problem solvers, if they read and keep up with their field, if they are capable of learning, if they write good documentation, if the client likes them, if I like them, if younger people look up to them, if older people feel some pressure because here is somebody up and coming, if when I go to modify their code I only need to change it in one place, and my change fits in naturally without breaking 15 different things (because it is designed with extensibility in mind), and that my heart beats a little faster because their code is just so beautiful. And so on.

Google doesn't try to measure any of that. At all. And then you (google, not you archangle_one) express mystification at why your interviews do no better than chance. There's a clue there, I'd say. If you don't measure job performance, why do you think your measure say anything about job performance?

i once needed a job so bad and was asked to solve a Rails challenge. i never did Rails before but i learned it and solved the challenge in a week. i also thoroughly documented my learning process and decisions. However i was rejected for being too fresh which i understood, i learned a lot during that week and even though i didn't get the job i feel that i achieved something. so i also don't see how you can lose with a contract-to-hire approach.

That's great that you got something out of it, but I have to wonder why it took them until after you completed the task to figure out that you were "too fresh."

the best reason i remember was that it wasn't unanimous. my submission had to go through several people, and while the guys who i had direct contact with showed that they liked me, the decision came after their meeting with the CTO.

They also knew before hand and gave me a chance perhaps i would do something very impressive. i'm not saying my submission was perfect, i might have done a couple of things wrong, or during that period they might have found someone better, there might have been several reasons i think, but i still learned a ton about Rails.

Reply on news.ycombinator.com