Live data from Hacker News

I will not do a tech interview

medium.com

181–190 of 554 posts

Re: I will not do a tech interview

#181
post #95
post #54

Earlier quoted context omitted.

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 wi…

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…

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.

Re: I will not do a tech interview

#182
The interview process doesn't work for some because it's a gross power imbalance where the interviewee has no control. The interviewee suffers at the whims of the interviewer. Some interviewers enjoy their temporary power over people who are normally not in a position of no power. The interviewee has no recourse for whatever power trip the interviewer throws at him. Many programmers hate not being in control and get anxious at the prospect. The process is doubly hard for introverts, who may be brilliant in the quiet time when alone, but who fail miserably when suddenly put in a position of an extrovert selling themselves. It's unnatural and upsetting.

I feel this is different than in almost all social interactions, such as working with clients or participating in meetings. There is more equality and control in those kind of negotiations.

Re: I will not do a tech interview

#183
I agree 100% with this post. Any time it is feasible, the best way to know what it is like to work with someone is to work with them. Small contracts and transitions from contract-to-full time allow both parties to learn a bunch about each other with minimum risk.

Re: I will not do a tech interview

#184

Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…

Exactly. I am a very vehement opponent of quizzy, obscure-knowledge or high-pressure tech interviews. That said, I think a good tech interview is irreplaceable. I like to work through a complex problem with the candidate, oftentimes I don't know the answer, nor do I expect them to be able to finish the problem (this is made very clear) -- I do expect them to sink their teeth in and think out loud with me. I would nev…

> relatively low-stress interview

Is there such thing? I doubt it, unless you're interviewed by someone you already know well.

Re: I will not do a tech interview

#185
post #72

Earlier quoted context omitted.

Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients? Of course not. Interview situations are very, very different than the others. Meetings and code reviews are with co-workers, whom you know and trust. Meetings with clients could be nerve-wracking for other reasons, but the…

I guess it depends on the industry/clientèle, but meetings are fundamentally very similar. You are worried about what "they" will ask and if you will be able to answer the questions. With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles. In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have…

I think the computer there would be so you could see your progress, not so you could look things up. Write the display rule, then sanity-check; fix the margins and remove the bullets, then make sure it's right; etc.

Re: I will not do a tech interview

#186
post #42
post #27

Earlier quoted context omitted.

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

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.

Re: I will not do a tech interview

#187
post #17
post #8

I like oracle way of hiring. You got a degree from a decent college with decent GPA you are in. Very clear and straight forward. If you got in a decent college and graduated with a decent GPA - you are smart and somewhat hardworking, you should be doing well in your job.

Google recently revealed that going back over the data they kept about past hires demonstrated that an individual's GPA was completely independent of the quality of their future contributions to the company. Why should Oracle be any different?

google are a notoriously selective employer, so it's hardly surprising that GPA has limited predictive power within the sample of people who were successful applicants.

Re: I will not do a tech interview

#188
In our company we understand that testing up-front can be off-putting, but we rather pass up a great candidate than hiring a poor one (we do subscribe to Polsky view on candidates http://www.joelonsoftware.com/articles/GuerrillaInterviewing...). We allow them to test at their pace (codility.com) from home first, then we re-test them on-site (to avoid the 'someone doing my homework' effect). After that the next interview is pretty much talking on the code written code and approaches or decisions that the candidate took. So in that sense is a great piece to further discussion.

The issue is that where I work we can't subcontract as a way to 'test' for candidates. The code is so proprietary, and have so much red tape (Options Trading platform) that we don't trust anyone unless you are full-time. Also, the code is fairly complex and embedded in it's industry-speak that unless you come from the same industry subset, you will not be productive (like knowing what Black-scholes, instrument, or delta means). So the investment to getting any good developer to be able to produce is immense. We considered subcontracting for assessing a candidate, but it is fairly hard.

Also we have seen people that do extremely well on every other aspect of the interview but can't deliver when asked to write a piece of code. Good or bad it does show your ability to work under pressure (I am not sure if it's extreme in the financial industry, but stress levels here run fairly high... for a fun read http://codesnipers.com/?q=interview-the-wall-street-programm...). So when you're getting your coffee, someone comes and says 'we need to fix this' it will probably be as intimidating (or more) as having a code interview.

Lastly, maybe because we've seen it often enough, there are a ton of programmers that can't write code (yes, the fizzbuzz crew). Having the codility test filter in front of all eliminates a lot of that chaff we see, so we don't even bother with the candidates unless they get a good-enough result in codility (we do look at the code, not just if it passes/fails the unit tests, but we don't bring the candidate for an actual interview until we have a reasonable expectation that they can program). We understand we will miss Ike Ellis, and we accept that as part of the tradeoffs between time and opportunities.

Re: I will not do a tech interview

#189

Not quite the same, but I once had a no name company (getglue) tell me that I need to do a 3-hour programming assignment before I can interview with them. I have too much self-respect for myself to put myself through that process. I declined the "opportunity" to interview with them. The interview process is broken and many of the interviewing techniques either do not correctly judge a candidate, or place too much bur…

Good decision. I regret very much that I didn't make the same decision you did.

I did a 5-7 hour programming homework assignment, didn't hear back for weeks, and then it was just from a recruiter (sorry, we've decided not to continue the process).

I won't do it again, ever. It's not the wasted time that I regret so much. I do agree with you that there is a self-respect element to this.

Re: I will not do a tech interview

#190

Earlier quoted context omitted.

Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview. Stressful situations happen a lot more than never in the real world (and sometimes they even involve talking to people, like customers) -- I don't want to have coworkers who can't handle that.

For me, the interview has always been way more stressful than anything I've had to do on the job. I think lots of people feel the same way (partially based on what I've seen performing interviews myself).

I'm sorry to hear about how stressed you get during interviews, but unfortunately the stress you demonstrate during technical interviews is a useful heuristic when determining whether or not a candidate would be a good fit for a company. Is a good signal all of the time? No. Is it a good signal most of the time? Probably.
Post reply on HN