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

What technical recruiters want from engineering candidates

keyvalues.com

Post reply on HN
Print view View original

191–200 of 212 posts

Re: What technical recruiters want from engineering candidates

#191

Post by learc83 »

alxlaz wrote: post #178
learc83 wrote: post #111

Earlier quoted context omitted.

>sume, then write four damn pages of resume. A one-page resume that drops three pages of relevant stuff will put you in the same basket as someone who can barely fill that page. It's not ballast, it's stuff I can ask you about in an interview. To me 4 pages is a CV not a resume. You might prefer 4 pages, but in my experience most people won't bother reading past the first page.

> in my experience most people won't bother reading past the first page. Those people should not be involved in hiring. I know it sucks to read page after page of seemingly irrelevant stuff until you find that one good candidate, but that's literally your job. Complain all you want, then do it. I, too, hate dealing with poor code from irresponsible vendors, undocumented libraries or legacy applications, but I don't s…

>Those people should not be involved in hiring.

My point was that those kind of people are involved in hiring, and the single page resume has become fairly standard.

You personally may prefer a longer academic CV style. I think that probably makes sense, if anyone profession could use that type of resume it's ours.

However, that isn't currently the norm, and I suspect that you'd see a net loss if you always sent out a 4 page resume instead of condensing it to single page of bullet points.

I will say that I could be completely wrong on this. It could be that the increased interest from people who want 4 page resumes might more than make up for the people who won't bother reading it, but I don't think so.

Re: What technical recruiters want from engineering candidates

#192

Post by Jemmeh »

sanderjd wrote: post #118
rb808 wrote: post #44

Earlier quoted context omitted.

> they would gripe about that technology all day long; if they can't complain about its shortcomings and pitfalls, they didn't use it. Lol that is gold. I have to add that section to my interviewing questions.

I disagree. I used to be this gripe-y person, but the more experience I gained, the more I realized that everything is just the result of its trade-offs and started finding the griping both boring - who wants to complain constantly for years and years? - and less productive than maintaining more of an anthropologist's mindset. So to me, constant griping is more of a not-that-much-experience signal.

I agree, I think it's better to ask what some of those trade offs are. What's this tech good or bad at? I'm not gonna complain about a language feature that I can't do anything about. I'm gonna implement the work around and move on. What's the point in sitting around and complaining? I can't alter the language itself and it would be unreasonable to change the project language past a certain point.

Reading into how Javascript was created clarified that the "issues" with the language were. I understand the creators(who are probably far smarter than I) chose to make things that way for a reason. I can often just google these reasons "Why does X language do this?" and understand. Any time I think "This seems silly..." there's a reason for it.

Re: What technical recruiters want from engineering candidates

#193

Post by Jemmeh »

daveslash wrote: post #93
tashi wrote: post #75

Earlier quoted context omitted.

Some candidates, depending on their backgrounds, may be wary of being thought of as complainers or being "difficult." Something to look out for.

A question that I've been using lately is to ask a candidate to pick some technology (anything) that they have strong feelings about - positive or negative. I'll then throw out a couple of examples: "I really like A about B thing" and "In language X I really dislike Y because Z" -- I'm looking to see that they've really thought critically about some technology. Anything.

This seems better, it's more about tradeoffs.

I don't really feel the need to complain about languages. I just find the workaround and implement it and move on. All languages have trade offs. I can tell you that this one lends more to scaling projects or this one is easier to maintain, this one is easier to iterate, etc. But getting upset doesn't do anything. You just pick the best you can and work with it. I'm not going to get mad that my hammer isn't also a drill.

Re: What technical recruiters want from engineering candidates

#194

Post by amorphid »

paulcole wrote: post #152
amorphid wrote: post #84

Earlier quoted context omitted.

The way I think of it is that we haven't yet figured out concrete ways to assess whether someone can or can't be an effective developer on a team. So if you want me to hire you, and I can't directly measure your skills (because I'm a suboptimal interviewer?), then I need data points that increase my confidence that you are more likely to work out. This is a 100% contrived, but here's an example... - I run a dev team…

> but I see you spending a lot of time writing C# in your personal time, or somehow demonstrating a passion for you, I'm more likely to think you'll be a fit. Do you ever worry that you’re overlooking talented people who have a life outside of programming?

It wasn't a great example, and I don't manage a team, or work at a Microsoft shop. I think I was trying to say it's easier to avoid making bad hiring decisions than it is to work on making good hiring decisions. It's probably also hard to practice hiring decisions at all, which doesn't help in reducing the learning curve.

Re: What technical recruiters want from engineering candidates

#195

Post by firstplacelast »

ken wrote: post #78

> It may seem like common sense, but having a deep, enthusiastic, and genuine interest in some aspect of the company (whether it’s the company’s mission, product, technical challenges, or its work environment) is important. This frustrates me so much. What if I can't find a company that offers any such thing? This seems like anti-common sense to me. If you have skills at carpentry, and do a professional job, you can…

This is how you know your skills are no longer in high-demand. When employers want to select for ridiculous crap like that or use vague reasons for denying an applicant like “cultural fit” it’s because they have way too many qualified applicants.

If your skills were truly in high-demand, they would verify that you could do the work and are easy to work with then they’d give you the job (see: Nurses).

Re: What technical recruiters want from engineering candidates

#196

Post by alkonaut »

Jemmeh wrote: post #193
daveslash wrote: post #93

Earlier quoted context omitted.

A question that I've been using lately is to ask a candidate to pick some technology (anything) that they have strong feelings about - positive or negative. I'll then throw out a couple of examples: "I really like A about B thing" and "In language X I really dislike Y because Z" -- I'm looking to see that they've really thought critically about some technology. Anything.

This seems better, it's more about tradeoffs. I don't really feel the need to complain about languages. I just find the workaround and implement it and move on. All languages have trade offs. I can tell you that this one lends more to scaling projects or this one is easier to maintain, this one is easier to iterate, etc. But getting upset doesn't do anything. You just pick the best you can and work with it. I'm not g…

Every technology is designed through tradeoffs. Choosing a technology and the using it properly reqires understanding those tradeoffs. What they are, why they were made. I whine about the appetite for secret allocation that my C# program has. I whine about the mess that is writing the equivalent C++ or Go code, and the learning curve of doing it in Rust.

It’s whining on the surface but it’s really 90% tradeoffs and 10% badness.

Being able to critique design mistakes in eg. an API means you have a pretty deep knowledge on the domain (and/or API design in general). Being able to argue the downsides of a certain technological tradeoff (such as GC vs not, dynamic vs static) is also important. No one will be able to win an argument on tabs/spaces or dynamic vs static but everyone should be able to point out some drawbacks and benefits.

Describing the merits of a technology is just as good as describing the drawbacks. I chose drawbacks/whine because (unfortunately) I am myself much more enthusiastic when describing flaws than positive sides - itself a flaw, but a very common one.

Re: What technical recruiters want from engineering candidates

#197

Post by Jemmeh »

alkonaut wrote: post #196
Jemmeh wrote: post #193

Earlier quoted context omitted.

This seems better, it's more about tradeoffs. I don't really feel the need to complain about languages. I just find the workaround and implement it and move on. All languages have trade offs. I can tell you that this one lends more to scaling projects or this one is easier to maintain, this one is easier to iterate, etc. But getting upset doesn't do anything. You just pick the best you can and work with it. I'm not g…

Every technology is designed through tradeoffs. Choosing a technology and the using it properly reqires understanding those tradeoffs. What they are, why they were made. I whine about the appetite for secret allocation that my C# program has. I whine about the mess that is writing the equivalent C++ or Go code, and the learning curve of doing it in Rust. It’s whining on the surface but it’s really 90% tradeoffs and 1…

I see where you're coming from. I think I just don't like the "complain about it" angle.

I can't change the language itself. I feel like a lot of people stress about those issues and can talk about them at length. I'm usually like "This isn't optimal, here's the workaround, this other language does it better but it's got other issues that are even worse for what we're building. Problem solved, moving on." Like, it's just another problem to solve at my problem solving job. The answer is not elegant, but that's the case with so many things in the real world...but this is probably the stoic in me.

Re: What technical recruiters want from engineering candidates

#198

Post by latte »

bm1362 wrote: post #189
repolfx wrote: post #160

Earlier quoted context omitted.

I think you radically over-estimate the number of people who want to learn Elm in order to apply for a job. I've done a lot of hiring and we use a "cool" language (Kotlin). We don't mention the language to recruits although it's not a secret (discussed on our website), because we want to hire people with many different platform backgrounds.

We had a problem advertising Clojure, everyone showed up wanting to write Clojure but didn’t care about our product. As a series A company it was hard to get purist to focus on shipping and we started weeding candidates out that gave off a ‘I just want to work in Clojure’ vibe. Eventually new stuff got written in Java and we migrated off of it due to the hiring pipeline mostly but when we told candidates some honestl…

So can one say that you migrated off of Clojure because it attracts a wrong type of people?

Re: What technical recruiters want from engineering candidates

#199

Post by cuddlypsycho »

jtmcmc wrote: post #186
cuddlypsycho wrote: post #49

"EQ and self awareness" What a crock of sh*t!! This is what happens when you pack HR departments with humanities and gender studies majors. Personally I do not read any resumes, all the hiring I've done was either by referral or through online websites like angelList. This is my process: - Check your linkedIn, look at your experience and education. Catchy schools and companies is good BUT also that you are not a bran…

wow you sound terrible to work with based on this post.

Well I'm not running for a popularity contest. A players like to work with other A players. My jobs is to make sure we maintain that environment. If that means being very selective and exclusive and hire based on merit only then so be it.

You'd be surprised how many engineers actually find that approach a breath of fresh air in this age of diversity and inclusivity.

Re: What technical recruiters want from engineering candidates

#200

Post by learc83 »

repolfx wrote: post #168
ummonk wrote: post #125

Earlier quoted context omitted.

>There are plenty of young software engineers who hear about first-year salaries at Google and expect similar comp packages from startups. (Are they being too greedy? Meh, they're just misinformed or need to take some time to recalibrate their expectations.) If they're choosing between working at a company like Google or that startup, it's not greedy to expect competitive compensation.

I think it was implied by context that they weren't. Obviously if you need advice of "don't be greedy" then such a person isn't simultaneously weighing up an offer from the top of Google's pay tier, otherwise that wouldn't be greed, it'd just be realism.

I don't think that was implied by the context at all.

>that wouldn't be greed, it'd just be realism.

I think that's the point. Startups routinely want to convince people to work for them for less than established companies. They often talk about wanting to hire people who care about solving the problems they are working more than money.

When someone is being realistic by pointing out that they can make more money elsewhere, they say they are just "being greedy."

Post reply on HN