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

91–100 of 239 posts

Re: How not to hire a software engineer

#91

Post by gwbas1c »

morkfromork wrote: post #3

Lately I have done a few at home code challenges for companies. They usually take several hours. They are perfectly functional and use minimal code but, the only feedback I receive is: "we're not moving forward". They won't discuss anything with me. The only impression I get is that your company is terrible and I will never respond to your recruiters again.

Honestly, this is why I'm skeptical of take-home coding. They require a high investment of my time, and a lower investment of the hiring company's time.

It's fine when I'm in a "my job is to get a job" situation, but I haven't been in that situation very much.

As a result, I only start these kinds of projects when I have a clear understanding of the company; and when my personal ramp-up will be very small. Otherwise, I just walk away. My free time is limited.

Re: How not to hire a software engineer

#92

Post by ozzyman700 »

sethammons wrote: post #74
tzs wrote: post #53

If I had to interview someone for a programming job, I think I'd try using LeetCode problems, but NOT as coding challenges. I'd pick a few problems that the candidate and I both find somewhat interesting, and then for each do three things. First, we'd both read the problem, and talk about our understanding of what it is asking for. Second, we'd talk about algorithms to solve it, probably at a whiteboard. No need for…

I have seen my fair share of candidates who can talk just like you suggested, but literally cannot put even simple solutions into code. Like, can't write a for loop or an if-condition but could walk through a problem like you describe and can even talk about tech trends.

Personally I get intense panic seeing a person's face looking at me while I try to avoid off by one errors.

It's all in the experience but that might be the other side to the situation you are describing.

I am practicing a lot to be more comfortable but I still feel bad for those people who interviewed me and ended up disappointed.

Re: How not to hire a software engineer

#93

Post by kpollich »

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…

Couldn't agree more. An ability to learn quickly, to self-teach, to solve problems is vastly more important than any degree of exposure to a specific piece of technology. These characteristics are as much about your skill level as they are about your attitude and approach to software engineering, as well.

Re: How not to hire a software engineer

#94

Post by gwbas1c »

Honestly, this article sounds like a rant.

Hiring is hard. A lot of interviewers aren't good at it. Every technique that gets promoted has flaws.

We could be like doctors and have a grueling licensing process, and then interviews that are mostly about finding mutual interest. But, I don't think most of us like the idea of a licensing process.

Re: How not to hire a software engineer

#95

Post by BeetleB »

rightbyte wrote: post #71
jahrule wrote: post #64

Earlier quoted context omitted.

wtf. what you are describing is something that i would say is suable. and should be. you basically said dont hire that person to someone. because of your bad experience with that ex-colleague ?. you are denying that person a chance. how come ? what are you going to do next time someone calls for reference ? the same ? immature, questionable, discriminating practices...

Strange. Where I live it's common practice to ask former employers about a persons performance. I you have no prior work experience they would want to call your math theacher or army drill instructor. In the US it's illegal? It's discrimation yes but isn't that the whole point of a recruitment process?

Not at all illegal, and is quite the norm to ask for references.

You can get sued for anything - it need not be illegal to be sued for it.

Re: How not to hire a software engineer

#96

Post by ozzyman700 »

falsedan wrote: post #31
dblooman wrote: post #24

What i've noticed recently with interviewing candidates is some lack the ability to work outside the way they work normally, especially in practical tests. Things like, "I usually work from home, so its too difficult to concentrate in this meeting room", "I use Windows, so writing code on a Mac is really hard" and the most common for some reason for why the technical exercise isn't working "Intellij usually saves the…

Unless the IDE you use everyday is the whiteboard, these are all fine and valid criticisms of your hiring tests. If you want to see real-world results, give candidates real-world conditions (including their preferred OS/IDE/workspace environment). > under pressure is this a common occurrence in your company? people expected to code well under direct supervision and a strict short time limit?

Hackerrank interviews done with video chat literally have a person's face watching their screen which updates as you type. I had an hour to write a few functions and the person interviewing had the ability to run the tests

Re: How not to hire a software engineer

#97

Post by jillesvangurp »

As somebody hiring more regularly now, I can sympathize. I'm usually operating on the notion that interviews are demonstrably not a very good way to select people. They are pretty random. I tend to embrace this and focus on the big picture: which is do I want to hire them.

So I have only two big topics in my head.

1) Verify that this person is competent by getting to talk about anything remotely relevant. The job here is listening; not asking. If buzzwords come up, ask follow up questions. If someone is a bull-shitter, it will show in minutes. I have some generic questions that I can put in to keep the conversation going but usually, I just focus on stuff on their CV that interests me. Tell me more. Anything. What do you want in a job? Why?

2) Establishing whether I like the person enough for further collaboration. Yes, this is super subjective. But the way this business works is that anyone passing #1 you basically should hire unless you have a good reason not to. Not liking them would be a red flag.

Most of the rest of the interview is selling them on the job and figuring out whether that even remotely aligns with their expectations. This is a sales pitch. As an interviewer, your job is getting the candidate enthusiastic about working with you. If they are good, they'll have other offers lined up. In other words, it is you the interviewer that needs to be nervous about whether they will say yes; not the other way around.

This is the most important step in the interview and this is where you either get somebody enthusiastic about working for you or disengaged. If that's the case, don't hire but if they show eagerness, interest, etc. you basically try to hire them.

It's not like we have a long list of candidates typically. So, decide quickly and act with a sense of urgency.

When I'm interviewed, I think of it as a privilege for the wannabe employer. You successfully got introduced to me by somebody I trust. We talked and I liked you somehow. Now we are talking shop. Your job is to make me want to work for you. Sell it to me. Make an effort. Don't waste my time with bullshit. I'll talk to your HR after you convince me I'm not wasting my time; not before.

Re: How not to hire a software engineer

#98

Post by gwbas1c »

ankit219 wrote: post #39

A perspective from the interviewer's side. Since I run a small startup, when hiring, my first thing to determine was that whether I would be able to work with the candidate. Hence, I would come up with a puzzle, a maths problem, or even a guesstimate, just to see the thought process and that whether there is any "gelling". Things to evaluate are, original thinking, how well the candidate puts his perspective forward,…

I usually give my disclaimer: "These aren't real world problems. Some questions involve code that we wouldn't write in the real world. We only have 45 minutes. The goal is to have a conversation about code."

And then I point out that "it's not practical to spend 2-3 days on-boarding you for a job interview. Thus, these questions are contrived. The best way to succeed is to have a conversation about code, and sometimes you need to play a little bit of the 'tell me what I want to hear' game".

And then, for one question, I need to point out that, "I once had a candidate say, 'I like JSON better then XML. XML's outdated.' This question is to discuss concepts that are easy to discuss with C#'s XML APIs, because chances are, you've used them." (And if the candidate tells me that they don't have a lot of XML experience, it's okay.

Re: How not to hire a software engineer

#99

Post by Circuits »

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?", "Present us with a time when you had to overcome a challenge and failed.". If your going to work with someone then its best you know that they are capable of learning. After all, a degree isn't about proving you know something, it's about proving you have the ability to learn and fight for that knowledge when necessary. It proves you have drive and direction in your life; important qualities in a candidate.

Re: How not to hire a software engineer

#100

Post by sidlls »

jankotek wrote: post #57
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…

> ability to learn, not to create a mess and not to waste time on stupid things People do stupid things and create a mess, while they learn.

They are learning at a new job anyway: the code base, tech stack, and social constructs that contributed to these. Learning the syntax and idioms of a new language is the smallest thing in most cases. Unless the language is particularly esoteric I submit that worrying about the "mess" made by learning it is hardly worth considering compared to those other things.
Post reply on HN