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

How not to hire a software engineer

tonsky.me

Post reply on HN
Print view View original

101–110 of 239 posts

Re: How not to hire a software engineer

#101

Post by DoofusOfDeath »

C1sc0cat wrote: post #61
kristopolous wrote: post #10

I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…

That's what happened at my first job - told to get the book on Fortran from company library and learn it.

To be fair, I found Fortran 77 to have the easiest learning curve of any language I've had to pick up. It only required about 2-3 hours of reading, plus a little more Googling to understand the challenges of having it interact with C++ code.

Re: How not to hire a software engineer

#102

Post by PopeDotNinja »

Circuits wrote: post #99

At my company we don't bother with specific problems. When we ask a candidate: "If you were asked to build x program how would you go about it", the answer we are looking for is along these lines: "I would go online and find someone who has already done the problem and replicate/alter it to fit my needs". The majority of the questions we ask are like: "Where do you see yourself in 5 years.", "What does our company do…

I just started using an ToDo app called "Remember The Milk", and it works for me so far. The next time I get an interview question that asks me to make a ToDo app, I'll be tempted to respond with "I already have one that I like. Why don't you try it, and if you don't like it, tell me why." I doubt that would go over well, but maybe it would. Who knows!

Re: How not to hire a software engineer

#103

Post by Circuits »

PopeDotNinja wrote: post #102
Circuits wrote: post #99

At my company we don't bother with specific problems. When we ask a candidate: "If you were asked to build x program how would you go about it", the answer we are looking for is along these lines: "I would go online and find someone who has already done the problem and replicate/alter it to fit my needs". The majority of the questions we ask are like: "Where do you see yourself in 5 years.", "What does our company do…

I just started using an ToDo app called "Remember The Milk", and it works for me so far. The next time I get an interview question that asks me to make a ToDo app, I'll be tempted to respond with "I already have one that I like. Why don't you try it, and if you don't like it, tell me why." I doubt that would go over well, but maybe it would. Who knows!

It depends on how the question is phrased. If they hand you a white board and say: "Show us the code" then you are going to have to build something. However, if they ask you something like: "If we asked you to build a ToDo app that solves x problem, how would you do it?" Then it's reasonable to assume they are open to more solutions than you jumping up and grabbing a marker. Being able to distinguish those differences is also important.

Re: How not to hire a software engineer

#104

Post by augustk »

meijer wrote: post #46
kristopolous wrote: post #10

I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…

> Do you see what's not there? Programming language competency. Database knowledge. Things like that. I hear this a lot, but I'm not sure I agree 100%. I want to work with people who can write idiomatic code and are able to use a database efficiently (or who are at least willing to learn these things).

Sometimes idiomatic code results in code which is hard to understand, as exemplified by the C idiom `while (s++ = t++);' for copying a string from t to s. It's always good to be able to read idiomatic code, however.

Re: How not to hire a software engineer

#105

Post by mawburn »

nsb1 wrote: post #50

I don't ask brain-teasers during an interview, but time and time again the value of a simple coding assignment has proven its worth. It is simply amazing to me how many candidates seem to lack the basic ability to code a couple of nested for loops, and weeding those candidates out early streamlines the whole interview process. I will typically do this on a phone screen, having informed the candidate beforehand that t…

Is it amazing that they can't do them at all, or they can't do them in the spotlight in a totally unfamiliar? I have a strong feeling that most of the people you think fall in the former are actually in the latter.

Yes, the solution might be a couple nested for loops. But if it's a new question to the interviewee, then they don't know the solution yet.

Re: How not to hire a software engineer

#106

Post by etxm »

I like giving coding “tests” but I prefer to let the candidate pick an issue from an open source project ahead of time. I want to be on as close to the same footing as the interviewee.

I like to see them work in as comfortable and nerve free environment as possible.

And in the event that the person doesn’t get hired, they have a commit on their GitHub and maybe added some value to a project.

Re: How not to hire a software engineer

#107

Post by metalgearsolid »

I've helped hire 3 software engineers to both work with me and mentor me and they were all failures.

First two hires quit after only a few weeks.

Third hire was temporarily successful. He eventually revealed himself to be both a jerk and not very technically skilled, so I spoke to higher-ups to get him removed.

My hiring strategy was designed to be simple and respectful. A simple, 20 minute assignment completed between phone screening and on-site. And 2 on-site interviews. Despite the 3 failures, I still feel like it's a good strategy. But evidence says otherwise!

Re: How not to hire a software engineer

#108

Post by yitianjian »

jimbokun wrote: post #90
externalreality wrote: post #78

Earlier quoted context omitted.

I wish everyone thought that way but they don't. In today's rapid paced world if you don't know Rails (not even Ruby) but Rails, for example, and we're using it - then you ain't in... and here write this 8 hour code test so we can subjectively judge it because grading code tests to see if you don't put logic in your controllers make our egos hum.

Maybe nitpicking certain micro-design choices isn't always helpful, and maybe it doesn't need to be a task requiring 8 hours, but I believe a "work sample" of actual code is the only technique that has any research backing it as a good way to evaluate potential hires.

If you're recruiting with a specific company and specific team that you love, sure. But I can't imagine committing multiple hours of my time to each random company's take-homes. As a rule I don't really do any take-homes - the couple I've done haven't been very useful in terms of my own time investment into the problems themselves, and the companies have not been worth it to go above and beyond.

Re: How not to hire a software engineer

#109

Post by piokoch »

theelous3 wrote: post #42
techterrier wrote: post #9

Earlier quoted context omitted.

Try not to judge the individuals too harshly in this circumstance - their lawyers have probably forbid them from saying much if anything at all.

I'll judge them all the same because it's not illegal to give someone feedback. Unless you have discriminatory hiring practices in which case the judgement holds true, or your legal team is so far up their own and everybody else's ass, the judgement still holds true.

Partly the problem is "the system" people created for themselves. At some point people started suing employers because of some really contrived reasons so employers became very, very careful.

If there is a big company that hires a lot of people and this is managed by many HR stuff, it is much cheaper and safer not to give any response than go through every rejection response to double check if something seemingly innocent cannot be interpreted as "discriminatory practice", rightly or not.

Post reply on HN