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

The Terrible Technical Interview

techcrunch.com

Post reply on HN
Print view View original

131–140 of 236 posts

Re: The Terrible Technical Interview

#131

Post by StevePerkins »

jes5199 wrote: post #124
tptacek wrote: post #106

Earlier quoted context omitted.

Stipulate that it is. Why is that a good idea for an interview?

personally, I think the SVN question is a pretty good example of "can you talk intelligently about any aspect of any complex system you've ever worked with?". If a candidate can explain one , I'll recommend to hire them. The resume provides a good list of possible subjects to discuss, otherwise I just cast about randomly, try to chase threads in the conversation until I find something with some depth.

This.

Re: The Terrible Technical Interview

#132

Post by pmiller2 »

Darmani wrote: post #129
bsder wrote: post #111

Look, if you want to talk about code, the easiest and best way to sidestep this issue is to have people bring code (somewhere between 200-1000 lines) to the interview. While they may not have a github presence, they've probably written something on a computer outside of business at some point. I really don't understand why more people don't do this. It doesn't even matter if it is their own code. The fact that they w…

I tried this with the first few people I interviewed. None of them had any code from outside work to bring. (This includes a brilliant and hardworking coworker that I practice-interviewed -- he just hadn't coded outside work in a very long time.) We wound up switching to giving code challenges instead.

>It doesn't even matter if it is their own code. The fact that they will have to talk intelligently about it means that it will accomplish its task.

I think you missed this part. Anybody can go on github and grab a repo and pick a specific section of code to talk about. This still accomplishes the goal of finding out if the candidate can understand code and communicate about it.

Re: The Terrible Technical Interview

#133

Post by philsnow »

blister wrote: post #119
mingmecca wrote: post #95

I lose about 20 points of IQ in a technical interview. It's nerve racking (I wear black shirts to hide the sweat) and it cost me a job working for a well known VR company. I passed the 'practical', which was a 2 hour coding test to generate a working game application, but the tech interview probably did me in. I've been programming games for almost 20 years, and as far as I know I'm one of the few who has done lead/s…

Have you thought about jumping into the world of Serious Games?My company is usually looking for experienced game developers with industry talent. The "Serious Games" side of the house is (to me) twice as rewarding as the other side. We don't live and die on the finicky sales cycle of the public and get to focus on delivering cool products that are already paid for by one customer. If you want to chat more about it,…

> already paid for by one customer

.... tactics sims for militaries ?

Re: The Terrible Technical Interview

#134

Post by tonyarkles »

jaredmcdonald wrote: post #14

> It is time for engineers–especially excellent engineers for whom demand is high–to start to flatly refuse to do whiteboard interviews. This might be a viable strategy for people who have a well-established career/credentials/references (etc), but for junior-level candidates still trying to prove themselves (such as myself) I can't see this working out too well.

That's one of the harder parts of the process, and it's partially because of poor expectations on the part of those doing hiring.

To me, it's absolutely ridiculous to expect to hire a junior developer and have them come with a fully-developed set of skills. If they do, that's great. But if you're hiring someone fresh out of school, you've got to be approaching it as hiring someone that you're going to train and mentor. For me, the number one thing I look for in a junior developer is the ability to learn.

Here's an example from early in my own career. I was just finishing up my 3rd year of a combined CS/EE program, and looking for a summer job. I got in touch with a biology lab that needed a developer for the summer to build some (very cool) software to support the neurophysiology experiments they were doing. I looked at the job requirements and thought "well, I don't know most of this stuff, but I'm sure I could pick it up."

The interview progressed like this:

> Do you know Python?

I'd heard about it, but have no real experience with it. I downloaded it last week and started playing with it though, and it doesn't seem too different than other languages I've used.

> How about VisionEgg (neurophysiology module for Python)?

Well, I downloaded it at the same time I downloaded Python. I've managed to get a window to open up, and I'm displaying a square that's got a cool animated habituation pattern on it. (Note: 1 week prior, I had no idea what a habituation pattern was) I do have a bit of OpenGL experience from a class I took, and that's the underlying library that VisionEgg uses.

> Well, so far, you're the only applicant who has actually made an effort to look at the specific tools we're using here. I've got one other applicant coming this afternoon, but unless they somehow have more experience with these tools than you do, the job is yours.

It turned out to be a great experience, and they hired me back on the following summer. I went from being a total Python noob to contributing patches back into VisionEgg. I think most junior positions should probably progress like that. Give me a keen junior developer, and let me shape and mould them into a not-junior developer.

The flip side to this: if you're expecting the person to be productive on day 1 or 2, you'd better be hiring someone with experience. Whether or not they have code they can show you, they should be more than capable of going into serious detail about past projects they've worked on (within the confines of NDAs and such, of course).

Re: The Terrible Technical Interview

#135

Post by politician »

jes5199 wrote: post #124
tptacek wrote: post #106

Earlier quoted context omitted.

Stipulate that it is. Why is that a good idea for an interview?

personally, I think the SVN question is a pretty good example of "can you talk intelligently about any aspect of any complex system you've ever worked with?". If a candidate can explain one , I'll recommend to hire them. The resume provides a good list of possible subjects to discuss, otherwise I just cast about randomly, try to chase threads in the conversation until I find something with some depth.

I completely agree with this - asking about VCS is a cross-cutting question that nearly all candidates have experience with unlike, for example, graphics, desktop, or cloud experiences. So, requesting that the candidate explain their VCS workflow is a way to generate a practical and relevant data point to use when evaluating multiple candidates.

For example, the 1-in-a-million candidate that has used git with a CI/CD configuration (note: I'm also outside SV) versus the candidate who uses TFS ("git? You mean Github? Yes).

Re: The Terrible Technical Interview

#136

Post by blister »

StevePerkins wrote: post #84
SnacksOnAPlane wrote: post #73

Earlier quoted context omitted.

Why is Atlanta not attractive to tech workers? Georgia Tech has a phenomenal CS program, and we've got a pretty large and diverse startup population. I'm not sure if what you're saying isn't true, or if I'm just biased and not able to see Atlanta from an outsider's perspective.

Heh, I kinda let that dig slide, because the rest of the comment was very well thought out and on-point. However, of course I disagreed. Atlanta is by far the technology hub of the southeastern United States. It has no competition to the west until you reach Houston (and even that is mostly specific to the energy industry). It faces only mild competition from the Research Triangle region of North Carolina, and beyond…

Hey now, we're doing some pretty kick-ass things over here in Augusta. We may not be as big as Atlanta (yet), but we're working our butts off. You should come down some time and take a look at what we're doing at http://theclubhou.se

Re: The Terrible Technical Interview

#137

Post by rupert_murdaaa »

bsder wrote: post #109
foz wrote: post #17

In my organization, we start by looking at what the candidate has actually done. We ask for a github profile, and any side projects they might have worked on. If the CV and body of work look interesting, we go on to a phone screen - general questions, clarifying points on the CV, explaining the job, answering questions. For the on-site interview, we ask candidates to bring their laptop. We advise them to use a typica…

> In my organization, we start by looking at what the candidate has actually done. We ask for a github profile, and any side projects they might have worked on. Fail. You just killed the quality of your pool. You've just negatively screened against people with a life (experienced, 30+ years old, generally with a family) and screened for people with no life (aka single, male 20-somethings). For an example, if John Car…

> You've just negatively screened against people with a life

That kind of works both ways, though, doesn't it? As a 30 year old developer with a family, I don't want to waste time interviewing somewhere that has the expectation I'll work outrageous hours. If I get filtered out early in that process because I'm not involved in multiple OSS projects or whatever, all the better for me.

That being said, resumes are a really shitty way to get an idea of someone's experience and talent. If I'm hiring someone and they can show me a github profile or blog entries or a Stack Exchange profile or slides from a local user group presentation or anything besides their resume, it really helps me get to know them better, and -- all else being equal -- will probably set them apart.

Re: The Terrible Technical Interview

#138

Post by seanwilson »

mtviewdave wrote: post #33
StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

> "I see that you've spent X years using Subversion for source control. What are your opinions on trunk-first development vs. branch-first development?" Actually, this demonstrates a problem right here. It's not clear to me what you mean by these terms. A quick Google search ("trunk-first vs branch-first svn") suggests that you're not using common terminology. After thinking about it for a minute or two, what I _thin…

I don't see the issue to be honest; it's an interview, not a written exam. You can think aloud, the interviewer can guide you if you're confused by the terminology and you can ask clarification questions.

Re: The Terrible Technical Interview

#139

Post by crdb »

I've seen two kinds of motivations: that for career climbing, and that of an engineer who enjoys making things. I personally prefer my engineers to have the second.

I tried hiring the normal way (CV, white board) and had one candidate worth speaking to in over 200 applicants.

We decided to try something else. We stopped reading any cover letter or CV and wrote that in the job ad. We asked candidates to build a simplified version of what the job was about, taking about 4 hours, then to send us the code which we'd discuss with them over the phone at their convenience. Anybody whose code passed would be hired, and if people couldn't be bothered because they were already famous they could send us their libraries. Nobody took the Starcraft best of 7 option :(

Why we did this:

- having to write code eliminates those who can't, or who can't be bothered; not having complex unrelated hoops to jump through eliminated those who are good at career climbing;

- we replaced the hours candidates would normally spend dealing with HR or travelling to a site for something ("cultural fit") that overselects the polished anyway, with something people we want would enjoy doing (solving a problem, writing code);

- no pressure, access to your "external brain" (Google, your own libraries) unlike with a white board; allows for the anxious to pass, and those who outsource a lot of their knowledge to the machine (like me);

- you can tell a lot about how people will approach their job from the way they approach the small version of it; documentation, structure, abstraction levels, choice of libraries, and if you're wrong about the candidate's reasons you can always clear it up in the chat;

- it's fair because everybody has to tackle the same problem;

- no discrimination since it's all ability based: I took to Skype-text-chatting with candidates instead of voice calls mostly because I don't like talking on the phone. It was only when she sent us her passport scan for the contract that we realised one of our candidates was female. Another team member didn't have a CV; it's because he was just finishing high school, as we discovered when we talked to him, but his code was good enough, so he got the offer and skipped university.

I've never had to put out another job ad (not for myself anyway) because I have so many qualified candidates left over from that round, and from the team network. Surprisingly, we didn't get spammed; the requirement to post code seems to have been mostly understood and we only had a half dozen "dear Sir/Madam"s.

So I disagree with you, but YMMV. We were hiring for a small, distributed team solving relatively well known problems. Requirements are probably different at Google or Facebook.

Re: The Terrible Technical Interview

#140

Post by pmikesell »

ditonal wrote: post #4

In my experience, a lot of companies are combining _all_ these things. So you're expected to do a phone interview, a test project/coding test, a whiteboard test, and the management brown-nosing at the end of it where you get to pitch that you've studied a hard technical skill your whole career just because you're so passionate about getting woken up at 3AM on PagerDuty to build _their_ vision, and definitely not beca…

Ok, I agree with most of what you said, but you must admit that there are a large chunk of "software engineers" out there that are just terrible, right? Companies have to do something to try to filter good from bad. So what's the answer? Or maybe you don't agree with this?

Incidentally, I think you're wrong about "one huge reason all this happens is to discourage job-hopping" ... I think it's actually just that people don't know what else to do, and this is what they've always done. It's how they were interviewed, and they got the job.

Post reply on HN