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

Hire people who aren’t proven

leonardofed.io

Post reply on HN
Print view View original

371–380 of 460 posts

Re: Hire people who aren’t proven

#371

Post by snowwrestler »

ConcernedCoder wrote: post #212
snowwrestler wrote: post #29

Earlier quoted context omitted.

By all means, you should use whatever criteria you would like to hire your own staff. But in general, I would encourage folks in computer tech industries to be hesitant to assume such a binary approach to evaluating prospects. "Did you code for fun in high school?" might be a useful question now, because software development as a field is so young that high school students can try out significant work easily. But in…

Say what you will, but who would you rather have take out your appendix? The doctor who worked nights and weekends to put him/herself through medical school because it was the love of their life and their dream to help people?... or the guy/gal who only chose the same career path for the money?

I want the person who is going to do the best job. Hiring is hard because there are few reliable proxies for knowing that in advance. It's not as simple as "who worked the hardest to get here?"

Re: Hire people who aren’t proven

#372

Post by superqd »

01100011 wrote: post #336
aphextron wrote: post #328

>Don't hire like FAANG companies, don't use their best practices, don't use their super oiled processes, don't play their same games with the same rules. I'm back on the job market for the first time in 4 years and it seems like things have changed a lot. I'm now stuck in this weird twilight zone where every single company I talk to has the exact same process that they run through the motions as if it were dictated f…

I understand the blank mind feeling. I was on a phone interview with Oculus 2 weeks ago and had a simple circular buffer question. I was expecting something a lot harder, frankly, and hadn't practiced writing a circular buffer in a while. I was doing fine until I got half-way through and wanted to refactor my code. Since we're under time constraints I tried to push through and use my existing design choice but it sta…

Good luck

Re: Hire people who aren’t proven

#373

Post by AngeloAnolin »

Applicants in general I feel are always to be on a disadvantage because most companies leave the hiring to the HR Department, who have very little clue on what they need to actually be looking. Most of the time, they would have a checklist, where if the person does not meet enough of their threshold, that person is immediately passed off for the next applicant.

Add the process that some folks do to screen candidates - lots of times, these are not objective in nature and tend to skew towards most applicants who seem to have a very impressive profile made up of fancy words and half truths.

Re: Hire people who aren’t proven

#374

Post by Invictus0 »

laurentl wrote: post #10

> 1. Can this candidate do the job? I'd go so far as to ask: "can this candidate learn to do the job?". In our recent job postings, I've started adding a specific paragraph after the desired qualifications stating more or less "if you don't tick all the boxes above but are motivated to learn and grow, please apply. We'll teach you what you need to do the job" > 2. Will this candidate be motivated? This. Even more tha…

Would you mind sending me a link to one of your job postings? I'm a mechanical engineering graduate looking to pivot into a CS career. My temp email: stadumajoc@memeil.top

Thanks!

Re: Hire people who aren’t proven

#375

Post by ankimal »

laurentl wrote: post #10

> 1. Can this candidate do the job? I'd go so far as to ask: "can this candidate learn to do the job?". In our recent job postings, I've started adding a specific paragraph after the desired qualifications stating more or less "if you don't tick all the boxes above but are motivated to learn and grow, please apply. We'll teach you what you need to do the job" > 2. Will this candidate be motivated? This. Even more tha…

We took out all mentions of prior knowledge and experience in our entry level job postings. In our more experienced posting, we only ask for prior work experience building software for X years. We list only our stack and even caveat that by saying that it can change. I can wager that most software engineer positions fall in this category.

Another relevant point here is that women are less likely to apply for positions with a predefined list of requirements even if they are only missing 1 of them as opposed to men. So why are we shooting ourselves in the foot with all of these requirements?

Re: Hire people who aren’t proven

#376

Post by walshemj »

arkades wrote: post #153
snowwrestler wrote: post #141

Earlier quoted context omitted.

Sure, I didn't mean to imply that there aren't people who are passionate from a young age about being doctors--there certainly are! But, I think it's not taken as a necessary attribute within the medical field. There are a lot of great doctors who didn't decide to pursue medicine until college, or maybe even later, and as a whole the field seems fine with that.

> There are a lot of great doctors who didn't decide to pursue medicine until college, or maybe even later, and as a whole the field seems fine with that. Med schools are increasingly selecting for that, in fact. Second careerists tend to do better (because they're adults), and have less burnout (because they're more likely to have made a knowledgeable adult decision about what they're getting into, rather than being…

One of the pioneers in the Pc business Ed Roberts (invented the altair 8800) did that.

Eventually became a GP (family doctor) in Georgia

Re: Hire people who aren’t proven

#377

Post by ankimal »

tomnipotent wrote: post #208
zvrba wrote: post #185

Earlier quoted context omitted.

> You can't because it's a bs metric like "culture fit". I'd disagree. An indirect metric is "Can I as the technical lead [1] communicate effectively with the candidate?" If the leadership is stable, then a "yes" to this question is likely to imply "yes" to the "getting along" question. If all "subordinates" can effectively communicate with the "hub" (lead), it's not unreasonable to expect that they'd be able to get…

I translate this as wanting a candidate that is compliant and can remove his ego to work in a hierarchal management structure. This is fine, of course, but let's not confuse that as "getting along" or "culture fit" when it's really "following orders".

We have taken out any mention of "culture fit" which to me means more of the same. Instead, we measure culture addition. How will this person add to our culture?

Re: Hire people who aren’t proven

#378

Post by ankimal »

wgerard wrote: post #80

My co-founder and I believe so strongly in this that we started a company around it. So many companies are willing to let perfect be the enemy of good. It's why this concept of an MVP has to be hammered in over and over again. And yet, we still let this mentality pervade hiring. We hire people on the slim chance that they'll need to re-implement a consensus algorithm and not on the 99.99% chance that all of their wor…

We recently hired an outstanding engineer who graduated from a bootcamp and previously did not apply because we had an archaic requirement around "BS Computer Science or equivalent" in our job description.

Re: Hire people who aren’t proven

#379

Post by gwbas1c »

One of my filters when phone screening is to ask simple questions that the candidate should know given the stated experience. I try to use topics that will separate out someone who's "faking it" versus someone who has the deep (or shallow) knowledge that someone with XX years experience should know.

For example, (back when ARC was new,) I'd ask someone with 5-8 years objective C to explain how autorelease works. (If you programmed in Objective C without ARC and didn't know about Autorelease...)

Or, for Java and C# I ask some questions about exception handling. It's a very simple concept that a lot of novices screw up. (If someone with a nontrivial amount of C# or Java can't explain some exception handling basics...)

(Basically, my pattern is to get the candidate to discuss some well-known details about memory management or error handling in a language that the candidate states experience in. Any competent programmer should be able to do this.)

I then ask some more theoretical questions that are relevant for the kind of programming needed for the product. These are the kinds of things that someone who has the experience needed should know without thinking too hard about the question. If someone can answer with a lot of hemming and hawwing, that's okay too. Someone who just can't discuss this kind of theory really isn't capable of the job... Or learning the job.

Re: Hire people who aren’t proven

#380

Post by dan-robertson »

mirko22 wrote: post #135
parthdesai wrote: post #35

Earlier quoted context omitted.

And what about when companies these days exploit the term "caring"? I like programming as much as the next person here but i'm not going to code 80 hours a day. I also like going to gym and working out, riding my bike, playing soccer and hanging out with friends. Companies these days expect you to have side projects or contribution to popular open source libraries while having a job. Oh and did i mention asking you q…

On the other hand imagine how much you would learn if you could spend all you gym and bike time learning computer science and other things (not saying you should but the more time you out into something usually you know more about that thing). Also I think knowing data structures is essential cos you are using them ALL the time you just don’t know it cos you never bothered to learn them. But they are corner stone of…

> Also I think knowing data structures is essential cos you are using them ALL the time you just don’t know it cos you never bothered to learn them. But they are corner stone of every program.

Disagree.

Most data structures fall into four categories:

1. Basically a list/array/set

2. An association (map/hash table/dictionary)

3. A struct/record

4. A union/enum/choice amongst finite options

It is only in specialised algorithms and when strictly necessary that one must deviate from these (and the second two aren’t even really data structures). In such situations it can be useful to have other things known but even then I think a lot can be done with some combination of:

1. Binary tree

2. Trie

3. Hashing and Bitvector magic

4. Canny

I don’t think much is lost by getting stuck and needing to research in such cases.

Post reply on HN