Live data from Hacker News

Hire people who aren’t proven

leonardofed.io

61–70 of 460 posts

Re: Hire people who aren’t proven

#61
post #45

I think tons of experienced people that love programming moved on because of the "Google Interview". You got all this experience and love making stuff for users, but you don't know the "insert trick of the week" to solve the latest "elite" programming question. Bye Bye. No more jobs for you.

Turns out that Google isn't the only outfit hiring coders. I could never have passed their interview but I've had a long career making a good living working for companies that never asked me to write a self-balancing binary search tree off the cuff.

Re: Hire people who aren’t proven

#62

As someone who is currently looking for a job I can definitely relate to the troubling HR in software field. What I started doing is working on my own content to help recruiters decide if I am what they are looking for. I added more information about ME, what I am passionate about, what I was passionate about previously, and what I am looking for to my about page ( https://getaclue.me/about ). This way, recruiters ca…

If you are in the Frankfurt Germany area, I have a position open there for a C# developer.

Re: Hire people who aren’t proven

#63
post #49
post #43

Earlier quoted context omitted.

CS/programming is almost unique in this regard in that there's a significant school of thought out there that, if you haven't been programming as a hobby since you were a kid, that's a disqualification. As you say, there is pretty much zero expectation in any other STEM field that you did much more than take some science classes in high school and liked them. (In STEM. Obviously you presumably don't apply to Juilliar…

It’s messed up in the other direction too, though. There’s no other STEM field where you attend a six week “boot camp” and expect to get a job. Or where people with two years of experience are “senior”.

Exactly. The standards are incredibly low. This can be a good and a bad thing.

Re: Hire people who aren’t proven

#64
post #24

Earlier quoted context omitted.

> It gives newer engineers more opportunity to succeed in areas where they are strong or just gives people who can fit a mould succeed, but doesn't allow someone who is creative and can think outside the box to shine as existing beaurocracy bogs down the smallest of change.

One of the hardest challenges of being an engineer, especially at senior levels, is protecting your peers from bureaucracy - but it is a doable challenge. A corporate structure is like any other social structure and it can be navigated and changed over time with persistent work and buy in from the bottom up. That being said, larger corporations do have more structure because they don't want you to repeat the mistakes…

I find most corporate structures, levels of management and reporting requirements (that aren't legislation based) all stem from the fact that the "boss" can't trust the lower level guy to do their job and make decisions without consulting someone higher on the hierarchy.

In a small startup, this isn't a problem, because decision making happens immediately. In a large corp, you end up with bureaucracy this way.

How does other organizations that are large solve this problem? In the millitary (at least, in the US, and other western doctrine millitaries), the sqad or captain or ground level troop has a lot of freedom to make tactical decisions, as long as that decision is to move towards the goal (or what's normally called the commander's intent). Why doesn't this method work in a corp. environment?

Re: Hire people who aren’t proven

#65

>Google's interview best practices strictly focused on algorithms and data structure questions won't help you in your interview process. They mostly don't help because they bear no resemblance to what 99% of developers actually do, even at Google. Realism in dev job interviews is criminally underrated.

completely agree. It's been done to me (at Google), and I'm guilty of this myself. I tend to ask a bunch of obscure questions about topics that ultimately have nothing to do with the daily job. I gloss over the banality of what they'll actually do (push data in and out of databases.. ), in favor of javascript scope, map/reduce esoterica, C pointer arithmetic, blah blah.. shit that I know. It's kinda stupid.

Re: Hire people who aren’t proven

#66

I don't see how 'hire people who aren't proven' can be compatible with 'can this candidate do the job'. You want to know if they can do the job, but you aren't interested in any proof for that?

30-50%(used to be 90%) of any programming job is doing crap you didn't know how to do before.

If they have a proven track record of figuring things out experience is minimally valuable.

Re: Hire people who aren’t proven

#67
post #49
post #43

Earlier quoted context omitted.

CS/programming is almost unique in this regard in that there's a significant school of thought out there that, if you haven't been programming as a hobby since you were a kid, that's a disqualification. As you say, there is pretty much zero expectation in any other STEM field that you did much more than take some science classes in high school and liked them. (In STEM. Obviously you presumably don't apply to Juilliar…

It’s messed up in the other direction too, though. There’s no other STEM field where you attend a six week “boot camp” and expect to get a job. Or where people with two years of experience are “senior”.

I suspect some of it is the terminology. If your job is mostly routine tasks in a lot of fields, you're usually called a technician (well, or a "genius" if you work at an Apple store). In Silicon Valley-style tech, computer scientist/programmer/developer have all been sort of munged together.

There are other areas where "engineer" is thrown around pretty liberally as well in the US. But title inflation in software is probably more pronounced than just about anywhere else.

Re: Hire people who aren’t proven

#68
This advice seems kind of crazy to me. I think you want someone who is proven in some skill-set, just not necessarily the exact one you are hiring for [1]. In software engineering, many skills are easily picked up. If you know C++, Java probably won't be too hard to learn. Angular and React aren't all that different. Even backend and frontend development have a lot of overlap.

Many companies want experienced and proven hires and I think this is completely reasonable. If you can afford it, would you rather have Lebron James on your team or a rookie who shows some promise? However, I take issue when companies get too specific in their requirements and exclude candidates for not possessing skills that are easily learned by someone who is proven in other areas.

[1] The exception might be junior developers who you are taking more of a risk on, but also get paid less as a result. However, there are costs to training a junior developer including paying a salary while they get up to speed and using up experienced devs' time to train them.

Re: Hire people who aren’t proven

#69

> 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…

> 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"

Totally agree. I was involved in the hiring process (new for me) in the last two hires and this was my main motivation. I primarily looked for passion in the field[1]. I didn't care if they explicitly knew what we were programming in, or what frameworks we were using, or w/e. I wanted to know if they were interested in the area, if they wanted to learn (if needed), and if the workload areas (backend, frontend, etc) were areas they wanted to work in.

I wanted to hire a bright person, passionate in what they do, and interested in the problems we'd give them[2]. I felt like if those three were true it didn't matter what they knew.. within reason, of course.

[1]: I'm not saying what I did is right or wrong, just explaining what I did. [2]: By interested, I mean they want to work in X language with Y workload. Not explicitly that they were personally invested/interested in the product domain as a company. I wouldn't expect that of anyone.. rarely, imo, do companies inherently do such interesting work that people should be personally invested. Ie, solving cancer or feeding homeless. A job can be a means to a paycheck. I just want it to be enjoyable for all involved, as much as possible at least.

Re: Hire people who aren’t proven

#70
post #54
post #11

Earlier quoted context omitted.

After 10 years, most veterans have learned not to care. Or at least, not care too much.

I have about 12 years of experience, occasionally I'll find myself really interested in some tech. But generally speaking, the technical problems don't interest me anymore. I find myself more fascinated with the business problems. But generally speaking, businesses have been structured to exclude the developer from these problems until it is dev time, in which case the problem is presented as "here's an issue, here's…

I worked for a small web-consulting agency for 3 years that allowed me to be a part of everything from the sit-down consultation with the client, to the estimation of engineering effort, to the design/build, and to the demo and support of the production version. Its not a given to have this access and you generally have to ask for it, but it is available to you if you ask.

Pros: I learned how to listen to customers, create proposals that tend to close, and upsell... all while being able to build the end product. This has helped me to close a good number of side projects after I moved back to working for larger companies.

Cons: The challenge working as an engineer in these small firms is that your resources are limited to the budget of the customer, which can be too small to do top-notch engineering work. You can generally find the balance without sacrificing too much quality, but you will never be completely satisfied with your work-product.

Post reply on HN