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

221–230 of 239 posts

Re: How not to hire a software engineer

#221

Post by avemg »

r_smart wrote: post #209
avemg wrote: post #190

Earlier quoted context omitted.

- Tell me about your software development methodology. - How are requirements communicated to developers? - How is work by developers tracked? - What VCS do you use? - What bug tracker, etc? - Do you practice devops? - What's your build process look like? Automated? Continuous deployment? - How big is the team? - Do you do sprints? how long typically? How do you decide what to work on in a sprint? - How do you determ…

I would call those good questions from someone experienced or savvy. The guy I'm talking about didn't even care to know what we make . It's not like we were Facebook or something where he'd already know.

Right, I was responding to watwut's question of "what exactly do you want me to ask?"

Re: How not to hire a software engineer

#222

Post by caseymarquis »

shapiro92 wrote: post #38
externalreality wrote: post #2

All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used. "Can you show you know sufficient SQL? Did you write applications before using Rails/Django what have you? Distributed this, Web that - OK, jobs is yours." After all that the productivity of the programmer is solely based on the work environment a…

> All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used. this is exactly the company/boss i would not want to work for. It is exactly the opposite. You should not care if the person if familiar with the tech you use. Who cares if you do php or c#? Does it REALLY make any difference when it comes to ta…

While it might not always be a huge leap between languages, I think it would be a bit more work to explain something like this to a PHP user: "We used reflection to modify the expression tree Entity Framework generated from this SQLFunctions.DateDiff call to allow dynamic ranges to be used. This has saved us thousands of lines of boilerplate code, but it should only be used in non-critical locations, like reports, as it depends on the internal implementation of the expression tree using a list, which is not guaranteed under any circumstances, but very unlikely to change."

I'm sure there are similar situations going from .NET to PHP. I think they would understand the implications, but I'm not sure they would be able to quickly fix it if the expression tree implementation changed and they had to determine which implementation was being used with reflection.

That said, I would hire the PHP/Ruby programmer who didn't run screaming at the use of reflection and monkey patching over a .NET/Java developer with no interest in all the neat things their language of choice can do to eliminate massive amounts of boilerplate code.

Re: How not to hire a software engineer

#223

Post by infinite8s »

cr0sh wrote: post #150
rightbyte wrote: post #71

Earlier quoted context omitted.

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?

It's illegal in the US for the company or anyone representing the company to say anything more than that they worked for the company, and what they worked on. They can't tell the person that the employee was fired, or anything like that. But as noted - there are ways used to get around such things (that is, the laws of our country). Those laws exist because people were wrongly discriminated against by using such "ref…

That's not illegal. HR/legal just usually prohibits it because negative feedback could potentially be used in a discrimination lawsuit.

Re: How not to hire a software engineer

#224

Post by maheart »

llamataboot wrote: post #141
pmiller2 wrote: post #130

Earlier quoted context omitted.

This is my exact issue with take-home tasks: I can get to an onsite or a rejection with most other companies after a 15 minute recruiter call and a 45-60 minute technical phone screen. So, why do I want to do a 2+ hour homework assignment? Most of the time, there simply is no compelling reason to do so.

I greatly prefer take-homes, because I feel they show off the quality of what I can do under actual coding conditions (rather than the stress of live coding or the BS of whiteboard coding) but it does get a bit tiresome. Especially because it is rarely a 2 hour assignment, they can be 8-16 easy. Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30…

> Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30 hours of work + interview steps.

This lines up exactly with my experience. 3-4 interviews, each requiring ~30 hours of technical tests, and interviewing. Absolutely ridiculous.

Re: How not to hire a software engineer

#225

Post by brianpgordon »

> The property of a puzzle is that you either know the answer to it or you don’t. It doesn’t tell you anything else. It has nothing to do with future performance, being smart, capable or anything else whatsoever. Knowing a particular answer does not mean you have an apparatus to solve real problems in a generic and predictable way. The only thing it tells you is that the person has been in a situation when someone shared a solution with him. Nothing more, nothing less. Just stop already.

Oh come on. It's true that people seeing the problem before is a major confounding factor, but it sounds like the author is saying that nobody ever solves the puzzle in the interview and it's a pure coin flip. That is obviously not true.

The puzzle type questions probably aren't a great fit for startups, but they're not meant to be. Big tech can afford the vast numbers of false negatives that they produce. In return, they're able to effectively conduct IQ tests of candidates without running afoul of the law.

Re: How not to hire a software engineer

#226

Post by itronitron »

watwut wrote: post #200
wsy wrote: post #194

Earlier quoted context omitted.

If you read the company's web site, and are a curious and interested person, then you should pretty quickly stumble upon things you would like to know which aren't written there. So if you come up empty, either you are not interested in that company at all, or your curiosity is so easily satisfied that a plain web site can answer all your questions. Both is not a great sign for a prospective employee. Even suppose yo…

It just sounds like complete rationalization. That is not how humans work nor how companies work. That is not how interest in things work especially not in work or position. Yes, it is test of whether you know that social thing. So, if the company is treating it as the test of that, then it is fine. Instead, the parent was almost offended over that "No interest at all, just looking to check another box on his list of…

I generally agree with your view, an experienced candidate will be able to figure out a lot of the work environment during the interviews before meeting with the hiring manager. Although I generally have a few softball questions that I ask as either filler or to see how much thought they have given to how their development teams work.

Re: How not to hire a software engineer

#227

Post by llamataboot »

maheart wrote: post #224
llamataboot wrote: post #141

Earlier quoted context omitted.

I greatly prefer take-homes, because I feel they show off the quality of what I can do under actual coding conditions (rather than the stress of live coding or the BS of whiteboard coding) but it does get a bit tiresome. Especially because it is rarely a 2 hour assignment, they can be 8-16 easy. Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30…

> Recently I've had three or four interviews that didn't quite get to the job offer stage, but they did both include over 30 hours of work + interview steps. This lines up exactly with my experience. 3-4 interviews, each requiring ~30 hours of technical tests, and interviewing. Absolutely ridiculous.

I wish there was like one long interview process I could go through - I do a bunch of technical work, I answer some standard questions on video, a bunch of companies review it all, and the ones that are interested schedule a 1-2 hour personal conversation to make sure we are a good fit.

I suppose that is what triple-byte is trying to do.

But really, we're all at-will employment, let's just work together for 3 months or so, see if you like my skills and I like your culture and if not just part ways - I'd even be happy to work at a wage cut for the first 3 months. But having a full-time job interviewing while working a full-time job is exhausting, esp when after 30+ (!!!) hours of interviews and conversations, you can be cut at the final stage without a single word about what went wrong.

Re: How not to hire a software engineer

#228

Post by JustSomeNobody »

mjcohen wrote: post #207
kristopolous wrote: post #188

Earlier quoted context omitted.

If I smell any bs then I immediately change tactics and make sure I put them deep over their head. For example, "what are the strengths and weaknesses of classifying grammars via the Chomsky hierarchy?" There's 3 ways to answer these kinds of questions and it exposes you as either a genius (or in this case a linguist), a non-genius (real geniuses are as common as 7.5 ft tall people) or a bullshitter trying to look li…

For Chomsky, I would hazard finite state automata, BNF systems, and Turing machines. I might then mumble about number of tapes and time to recognize, and then stop.

Type 0, Type 1, Type 2 and Type 3 (aka: Type K grammars).

Type 0 is an unrestricted grammar.

Type 1 is a context sensitive grammar.

Type 2 is a context free grammar.

Type 3 is a regular grammar.

For our (CS) purposes we typically use Type 2 and 3.

Re: How not to hire a software engineer

#229

Post by JustSomeNobody »

FussyZeus wrote: post #168
bitL wrote: post #146

Earlier quoted context omitted.

8 hour code test - you are an optimist! :D Recent trend in Silicon Valley is 1 week to 1 month (MVP) coding test in a hot area (e.g. Deep Learning), preferably coming with unique world-class solutions during that time :DDD And you get a phone interview only when you went to a Top 10 school.

In this market? I'd laugh in the interviewer's face. Like hell I'm doing a month of unpaid work for your "prestigious" opportunity.

It's another way for them to age discriminate.

Re: How not to hire a software engineer

#230

Post by leetcrew »

jahrule wrote: post #80
sk0g wrote: post #70

Earlier quoted context omitted.

When asked for an assessment of a co-worker, providing said assessment is immature and somehow discriminatory? What do you even think is the point of references? Not everyone's great to work with, I'm sure you have had a few co-workers you would rather not work with again, right?

yes, doing what the previous poster did - giving vague "bad signals" even against company's policies - is what i consider immature and discriminatory. references in form of background check - worked years a, b, c, on projects x, y,z - yes, sure. references about performance, likability, etc - why ? how are you going to judge that ? are the references legit ? are you going to get references on the reference giving peo…

in most cases, people are only getting called up for a reference because the applicant specifically chose to list them. if the only person they could think of to use as a reference has nothing good to say (or gives subtle negative signals) that's a pretty strong sign there's something wrong with the fellow.
Post reply on HN