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.
Hire people who aren’t proven
61–70 of 460 posts
Re: Hire people who aren’t proven
#62As 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…
Re: Hire people who aren’t proven
#63Earlier 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”.
Re: Hire people who aren’t proven
#64Earlier 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…
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.
Re: Hire people who aren’t proven
#66I 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?
If they have a proven track record of figuring things out experience is minimally valuable.
Re: Hire people who aren’t proven
#67Earlier 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”.
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
#68Many 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…
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
#70Earlier 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…
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.