Hire people who aren't proven - <AUTHOR> https://leonardofed.io/blog/startups-hiring.html <comment><USER2> I think hiring has become more difficult now that programming has been discovered as a well paying mainstream career. When I started in the 90s most people I worked with had a passion for the craft but now I find we interview a lot of people who have a CS degree just for the career prospects but not out of interest for the craft.

I find it much easier to deal with someone who has no relevant experience but cares vs someone who had 10 years experience but doesn't care. Now someone who has 10 years AND cares is rare but pure gold.

<comment><USER3> 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 most high-end professional fields, that's not true. Imagine asking a prospective medical resident "did you treat any diseases in high school?" or "how much surgery do you do in your spare time?"

I think we should take it as a positive sign that people are approaching software and computer technology as a professional career that they can professionally pursue. That approach can produce great work too, and a growing field means a greater diversity in how people find and display their passion. Getting a CS degree is not easy, and requires some base level of interest and commitment to complete. Even a bootcamp is not free, and takes some focus and work.

Anyone above a certain age (like me) came into the industry sideways, as it was developing, as a result of personal passion and interest. Let's not mistake that for an inherent property of a good tech employee... every industry on Earth started that way at some point.

Computer technology industries are maturing, just like railroads, oil development, aviation, telecommunications, and dozens of other industries have over time. That's not bad, and we will have to take it into account as we consider the model employee.

Hiring people who are "not proven" might also mean hiring people who are well trained, but maybe have not yet proven their passion in a way you recognize.

<comment><USER4> Doing software development in high school requires a computer (even a ~$400 that is shared with the family is sufficient), interest, and time (so one can spend hours required reading tutorials/watching videos). Basically, nothing too much out of the reach of your average teenager -- with the exception of interest/dedication to the art.

Doctors, and most other professions, cannot be practiced without a lot more investment. If we lived in a society where access to resources required for practicing those careers would be easily available to teenagers, we would see young high school students do that too. I don't think you're making a fair analogy here, there is basically no way a high schooler could even _attempt_ treating diseases but it's very possible for a high schooler to program 6-8h a day and learn.

<comment><USER5> > and time (so one can spend hours required reading tutorials/watching videos)

This is maybe not out of reach for an average teenager, but it is definitely out of reach for quite a substantial portion of the population, the poorest percentile might just not have the time to dabble in programming. They might have to take care of siblings, work for a living or to pay for college later.

<comment><USER3> Right, looking for signals of "passion" has to be done carefully so it doesn't become just a proxy for socioeconomic class. This is also true when thinking about "cultural fit" within a company.

<comment><USER6> This is an interesting case where the laws around interviewing may make this harder.

What you want to measure in the interview is passion. What you can see is their accomplishment. But accomplishment is roughly passion × means. A rich person can accomplish more for the same effort because they have more power at their disposal.

But you can't easily cancel out means in the interview because you sure as hell can't ask any direct questions about their socioeconomic level, for good reason.

</comment></comment></comment></comment></comment></comment><comment><USER7> > 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 than question 1. I've had a lot of good surprises with motivated candidates who didn't have all the expected qualifications. Some of my best hires were people whose CV didn't line up with what I was looking for but who demonstrated impressive motivation to get the job. On the other hand, I've often been disappointed with "perfect" candidates who didn't have the right mind-frame for the job. (Note: I'm not saying I'm expecting slavish devotion and "giving it 200%" every day of the week. But if your personal, intrinsic motivations don't align with the job's responsibilities, it won't work).

> 3\. Will this candidate get along with coworkers?

Duh. But also, how do you actually test objectively for this without introducing bias? And how do you insure you're not creating a monoculture that will eventually harden into navel-gazing and dogma? I'm really of two minds on this topic.

> 4\. What this candidate will be in three, six, twelve months from now?

Related to the rephrasing of 1. Can the candidate learn and grow? And will we provide the right environment for them to grow?

One of my favorite quotes is from an ex-manager who hired me when I was far from ticking all the boxes on the job description. "If you hire someone who has all the necessary qualifications for the job, they'll be bored in 6 months."

<comment><USER8> >> 3\. Will this candidate get along with coworkers?

> Duh. But also, how do you actually test objectively for this without > introducing bias?

You can't because it's a bs metric like "culture fit". After about a dozen people, you can no longer ensure people will get along or like each other. I only have five brothers but I don't even like all of them.

People have quirks, and it's easy to find reasons to pass on candidates because of them (reminds me of Seinfeld and how the characters ended relationships because of man hands or toes). I see this a lot in non-technical hiring where marketing folk exclaim "I like the candidate, we have great rapport" only to discover the candidate was subpar.

> I'm really of two minds on this topic.

I used to be, but after suffering through a bout of mental illness that rendered me an anxious mess when I was once the life of the party really changed how I evaluate this dimension. Be kind and assume the best, which we can all agree would be amazing if the tables were turned.

<comment><USER9> I disagree that this is a bs metric.

When I look for personality, I'm looking three things:

* How they ask questions for things they don't understand

The problems I give are directly applicable but I leave a few slightly vague. Someone really experienced could fill in the missing pieces easily, but usually this doesn't happen. I then ask them if the problem makes sense or if I missed anything. If they can't tell me that the problem isn't clear, or they need more information, then they'll have trouble working with a team trying to solve and communicate problems.

A mediocre candidate will say that the problem isn't clear with "I don't understand". A good candidate will explain what they don't understand. A great candidate will ask for clarification on the vague piece without much fuss.

* Reaction to not knowing something.

I have a hard problem that I give at the end. I clearly tell them it's not expected to be solved and that I just want to talk about how it might be approached. If they get angry, say "oh I know how, just give me 5 more minutes" then stand there blank, etc, then they're not going to fit in a team that is trying to solve hard problems together.

A good candidate will stay calm and provide any sort of input, ask any sort of questions, or show any sort of interest. Sometimes people get nervous here, so I keep this very very lighthearted.

* Are they full of themselves/assholes

This is pretty evident within the first few minutes, and really rare (and almost always accompanied with a stream of buzzwords after every sentence).

A good candidate won't be an asshole.

<comment><USER8> Everything you've mentioned are shallow assumptions based on brief exchanges with people. These are not qualities you can effectively suss out in a few hours through an interview process. You can at best get hints, but just like how GPA is not an indicator of a students on-job success neither is an interview - or our conclusion - any better indicators to the candidates success.

> Are they full of themselves/assholes / This is pretty evident within the > first few minutes

Not it's not. People can act awkward during interviews, it's a stressful situation. Some people need to peacock to feel self-confident - I may not like it, but I'm not going to fuck with their future because of an emotional reaction I had to how they present themselves. I've hired plenty of "assholes" that just needed the benefit of the doubt and a chance to grow.

We're not psychologists or therapists, so we should we stop trying to "figure people out" and decipher complex human interactions & behavior by trying to bucket them into checkboxes for whether or not someone is good.

Be kind, give the benefit of the doubt. This is someones career on the line, not a first date. Treat it with the respect and gravity you'd like someone to give you.

<comment><USER10> Hey, if a candiate is ready to be an asshole in an interview, what are the chances that he will be an asshole to his team members to just get that raise or a promotion?

<comment><USER8> He's not being an asshole. He's probably stressed out and doesn't know how to cope well. This is behavior that can be addressed and improved. After 20 years and hiring 100+ developers through three exits and an IPO, I've only met 1 actual "asshole" that couldn't integrate and needed to be let go.

The problem is that we're too quick to be offended and we look for excuses. I'm in the middle of hiring a business analyst, and my COO didn't want to hire him because he didn't send her a thank you note after an interview (but he did send one to me). She thought he was an asshole. See the problem with that train of thinking?

Everyone is an asshole to someone.

<comment><USER11> _He 's not being an asshole. He's probably stressed out and doesn't know how to cope well._

Life is stressful, work is stressful. My manager and his manager are reasonable people but after my second assignment, they said I missed a requirement and that it was a "big f' up". Guess what? I found that refreshing after dealing with managers that beat around the bush and you had to constantly try to figure out what they were thinking - or even worse, they didn't tell you anything until your review.

I've had to whiteboard architecture in front of CxOs, be interviewed by potential investors, etc. It's when things get stressful that you really need people who can keep their wits about themselves.

<comment><USER8> > they said I missed a requirement and that it was a "big f' up"

It's free to say things, doesn't make it true. Too often we assume because someone is in a position of power - or is wealthy - that whatever they say must be true. It's not. Sure, we have to nod our heads and pretend it is to keep the job but that still doesn't change the reality.

Shit rolls down hill with exponential momentum. I've seen many instances where a CEO says something innocuous like "I'm a bit disappointed in X" but by the time it gets to someone that can fix it the management in between transformed it from a simple comment into a condemnation. People like to exaggerate things to make something seem more important or impactful than it really is.

There's also a big difference between an interview and dealing with work everyday. I know plenty of people that shine under the pressure of interviews but not under the job itself (and visa versa). You cannot determine these things about a person from an interview. Period. Performance in an interview has very little correlation to job performance (if any).

> you really need people who can keep their wits about themselves.

I need a diverse group of people that I can collaborate with to get things done. If they can't keep their wits about, it's my job to deal with that issue and get them back on track and protect them from organizational crap. Might as well expect every girl or guy you date to be a model with a PhD.

<comment><USER11> _It 's free to say things, doesn't make it true_

Well, when the requirement was in big bold writing as one of the key features on a PowerPoint slide...

 _I need a diverse group of people that I can collaborate with to get things done. If they can 't keep their wits about, it's my job to deal with that issue and get them back on_

That's not a luxury you have as you move up the ladder - even if moving up the ladder is just being a real senior developer/architect (by knowledge if not by title).

My first job at 22 was as a computer operator trying to get my foot in the door was within 6 months build a custom, networked data entry system used to support a completely new department and a new line of business. Working at small companies, you don't get the luxury of hiding within the bureaucracy. The one time that I did work at a large company, it was suffocating.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> 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 work will be writing CRUD-like code.

We (as in, Headlight) deal with a lot of bootcamp grads and people who are entering tech later in life (which for tech, means 25+). It's shocking the number of them who are insanely adept at software development for the amount of experience they have and are completely overlooked because of any of the following:

* Their pedigree

* Their experience given their age

* Their program's focus on practical software development and not on more academic topics

It's really mind-boggling. It's great for us, because it's a totally unappreciated and under-served market. Still, I can't imagine how frustrating it is for those candidates. We're still new, but so far our clients' satisfaction with our candidates has been nothing short of enthusiastically positive.

All that to say, you should really consider adjusting your hiring expectations drastically. You're building a house. Why are you trying to hire a civil engineer, and not a contractor?

<comment><USER13> Most corporate dev jobs can be effectively handled by someone who can reliably show up and pull words from a database and display them on a screen.

<comment><USER14> Yes but it's mind-boggling how complex you can get quite a straightforward system by just piling new requirement changes on top of old without maintaining proper data-model in application, even if database is fine-ish, this results in a monster that slows down the system and the development speed.

So in principle, a lot of people can do it but only some do it while not making things more difficult for the next person.

</comment></comment></comment><comment><USER15> The problem that has happened at my company is that we take a "chance" on bootcampers or other people who aren't proven, we spend the time and effort to mentor and train them, pay them well, and then they turn around in 9-12 months and leave us for another company with their enhanced experience. It has happened 3 times so far, so we have stopped hiring bootcampers, and fresh grads and instead have started hiring people with a couple of years under their belts or more, since they appear to at least want to stick around enough to contribute positively to our teams.

<comment><USER16> Conversely, I found it _really_ hard to establish myself as a solid contributor and even a technical leader when I joined a team as a (relatively) newly minted developer.

No matter how far I progressed, or how competent (even excellent) I became, I was _still_ perceived as the "kid", even though my colleagues are only a few years older. I think I've mostly overcome this, but TBH I'm still not certain and I've been here for ~3.5 years in this role, and have been promoted to senior developer. None of that matters to my coworkers.

Moving teams is a much easier way to shed that "newbie" reputation (a path I decided not to take). Is it possible someone is creating this culture at your work that locks people into their role when they join the team?

<comment><USER17> What diminoten said

</comment></comment></comment><comment><USER18> Lately what I have been trying out is telling people: if you want to come for an interview can you prepare a small presentation of one of the data structures that you know about or like, or ideally hash tables (as they cover wide range of topics).

If a person than comes in for the interview in about a week from when he is told this and can't present that DS to some depth I don't bother to go on with much longer interview.

I got lot of criticism for this ranging from who needs data structures, we are not building libraries to this is too complex to ask a person.

But in my opinion if someone tells you what you are going to be asked on the interview and you don't even bother to prepare at least a little bit i can assume me you will act like that at work too.

Why a data structure? Why not, you don't necessarily need to like or know anything about the domain you will be working in, same way you might not care or like data structures.

This doesn't apply to someone writing HTML maybe but for a senior programer it should be easy to figure out how a simple linked list works, if you don't care about learning it I don't care about wasting my time interviewing you.

I would like if some of you might give me thoughts on this approach.

<comment><USER19> Is it really possible to be a senior programmer without understanding a concept of linked list? Mindboggling.

<comment><USER20> I interviewed one who had a lot of trouble finding the largest integer in an array... I mean, it really was a bozo-filter level problem, and it amazed me how many people couldn't do it.

Personally, I hate white-board interviews, but I'd be relieved (and yet annoyed at the same time) if you asked me to find the largest integer in an array.

</comment></comment></comment><comment><USER21> Why would any company _have_ do hire people and train them? Companies these days don't really come to a hault if they're in need of a few developers, and as the market is saturated, they can hold out indefinitely until they believe they have a "rockstar."

According to my experience, a lot fewer companies than even a few years ago are in a hurry to talk to you despite them having a job posting and you having more experience. Most of them will take their sweet ass time, and it will take even longer if they've replaced their HR or their own recruiting process with a recruiting firm, and usually they'll engage in the same process of finding a "rockstar" while taking their time because then they can fit in time for another client and make more money.

Besides, the incentive for hiring the unproven developers is quickly dying off with services like Triplebyte that can test and interview developers for you for a nominal fee. Those who would normally be in charge of hiring at a company never gets to the point where they've interviewed a bunch of people and decides that they're tired of interviewing people and hires the candidate who seems the most intelligent.

<comment><USER22> > Companies these days don't really come to a hault if they're in need of a > few developers

My small company has had to put our biggest contract on hold since July after having 2 senior developers leave in quick succession. We're burning through cash and have only just this week managed to find a replacement for one of them. I've almost gone down the agency route (again) but the fees are pretty hefty for a team our size (3 at the moment).

I'm not looking for rockstars, just someone with some familiarity with .NET MVC.

Edit: We're in the UK, FWIW.

<comment><USER23> I feel your pain. Trying to hire perm in London at the moment is a real challenge, even with a recruiter. Contractor rates are obscene (5-8x perm). Recruiting and retaining is what keeps me awake at night over and above any tech issues that I'm working on.

<comment><USER24> How little are you paying your dev that it can be 1/8th of a contractor?

Even the cheapest dev I have ever met in London wasn't as low as 1/5th of the most expensive contractor I have met.

<comment><USER23> Ah yeh, sorry, my mental maths strayed a bit into hyperbole there, it's more like 4-5x

<comment><USER24> How much are you trying to pay your dev that it can be 1/5th of a contractor? It's no wonder you're having trouble finding anyone.

</comment></comment></comment></comment></comment></comment><comment><USER25> 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.

<comment><USER26> 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.

<comment><USER25> I run into the "Google Interview" almost everywhere now days.

<comment><USER11> I can speak about my last 5 jobs over 10 years. Before that, I stayed at one company way too long.

Job 1 - I had already been working at one company way too long. But I wasn't asked any tough technical questions. I explained both my professional experience, and that I got my start as a hobbyist in 86 in 6th grade.

To be honest, with my programming experience I was overqualified for the job, but I wanted to get into .Net and away from C so I took a high level entry job as a .Net developer and it was basically a vertical salary move (wage compression is real).

2\. I remember having a real simple written test that made sure I could write FizzBuzz, knew the basics of .Net and knew how to design and use databases. After that, I sat down and did pair programming with an IDE where I had to make failing unit tests pass. Again I was still punching below my weight class, but I was more concerned with learning than maximizing salary. It was a 10K bump and with a well known at the time Fortune 10 company.

3\. Basic technical interview making sure I knew .Net, JavaScript and relational database theory. They asked a lot of questions about architecture and my "whiteboard interview" was drawing out a relatively complex, scalable system.

4\. Slightly technical but the main question I remember is "tell me what steps are you going to take to create this software development department we need". I was interviewing for a Dev lead position without knowing it.

5\. "Here are some real world issues we are having with our architecture. We are on AWS. How are you going to solve them?"

Yes I'm still supposedly a hands on developer.

<comment><USER27> Companies that consider themselves special generally "Google Interviews". That include bulk of the FAANG class companies, or any body who pays in the same ball park.

There are also a huge alumni of the FAANG club, who have a vested interested in doing "Google Interviews". Basically these people have spent so much time(thousands of hours) that the only way they can justify it is by making that interview process that way. Anybody who hasn't spent that kind of effort is obviously beneath their station.

But I hope you see where this is going.

>>Here are some real world issues we are having with our architecture. We are on AWS. How are you going to solve them

The "Google Interview" club likely won't ask you these questions. Their job isn't to build software. It is to get good at interviews, if you are good at interviews, interviewing is your day job, as practicing questions brings you a raise/promotion/title-change every year.

Why waste time building software?

<comment><USER11> And that's why I've never had any interest in the Silicon Valley/Startup culture.

I'm very happy in a major metropolitan area with a relatively low cost of living anf a good relative salary working as an "Enterprise developer/architect".

</comment></comment></comment></comment></comment></comment><comment><USER28> I have run into some of these issues in the past when trying to get into software.

I'm a chemical engineer / scientist with some programming experience/skill* but I would suck at modern coding interviews because I don't program regularly in my past 3-4 roles. I would have to get up to speed on the job, with pre- prep before the job started, and I could develop into an awesome programmer. Most job posting are written such that I am 99% certain my resume would just be a 'fast pass' in the 10 seconds a recruiter might look at it. Oh well, engineering is pretty interesting too... so I really can't complain much.

*My programming experience and background: \-- wrote Python/PyQt apps for parsing/analyzing/visualizing semiconductor device data, wrote sensor simulators/analysis tools in MATLAB and Python. Wrote image analysis routines in Java/ImageJ. I taught myself the languages and libraries and wrote correct and performant code.

I dabble in Python, JS, Julia, Rust, C++, various LISP's at home but I don't have a lot of time or energy after 8-10 hours a day of engineering work.

I have done a fair amount of PLC programming and control system design in the past. I also have 10+ years of post PhD engineering and physical science in several different fields and all of the capability and skill sets required to be successful in those fields.

Software gigs I have applied for in past generally have not even given me the time of day... oh well.

<comment><USER29> Job mobility is at an all time low unfortunately, due to the incredibly risk- averse environment.

</comment></comment><comment><USER30> I think this is good advice... for larger companies with well established patterns. One of the issues of a startup is that the founders are breathing down your neck and often don't care a whole lot about "well designed software" (or want to overbuild mvp products). Standing up to management, building best practices, and being agile while still pushing back when needed against founders/sales isn't easy but it's something engineers in a startup environment have to deal with directly constantly.

A larger company has more layers of management to, hopefully, help filter that out. Larger companies have best practices written down and figured out, CI/CD pipelines in place, etc. It gives newer engineers more opportunity to succeed in areas where they are strong, while letting them have mentorship in areas they are new to them.

<comment><USER31> > 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.

<comment><USER30> 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 of the past. That can obviously go too far, but if any constraint becomes "You're limiting my creative expression!" then you've missed the goal.

<comment><USER31> 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?

<comment><USER32> It works where there is a shared mission. But when team A wants help with project 1 and team B's priority is project 2, and they need approval from team C because it touches their code, well, you get the bureaucracy and constant escalation that you see in big software companies.

</comment></comment></comment></comment></comment><comment><USER33> >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 from somewhere, and I've yet to even have a genuine conversation. It inevitably leads to a "live coding" session over the phone where I completely go blank and am unable to perform because programming under a time constraint with someone staring at your screen is absurd. Problems on the level of fizzbuzz become impossible because my mind simply goes blank in those situations and I freeze up. It'd be nice if someone would just give me a take home project where I can actually code something properly and show off my skills, rather than conclude that I'm an idiot who can't even code after 20 minutes of struggling with some toy problem through my intense anxiety.

<comment><USER34> 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 started the anxiety train rolling. In a couple minutes my mind fogged over and I literally couldn't comprehend the code I had written a few minutes ago. The interview ended poorly and I didn't get the job. I finished the code after the interview, along with some test cases, and the whole thing worked great. It wasn't that I didn't understand the problem, I just couldn't implement it with someone breathing down my neck.

I interviewed with Nvidia a week later and almost had a similar issue but in that case the interviewer sensed my reaction and managed to talk me through things. I managed to recover and now I'm scheduled for an on-site.

<comment><USER35> Good luck

</comment></comment></comment><comment><USER36> Passion can't be measured with credentials so why do companies keep screening for them?

I spent the last three years studying as a hobby and as a full time student learning multiple frameworks, front-end and backend, and additional technologies that made me curious like Vim and I can't even land a single technical interview.

After coming to the Bay Area, I was thinking my github portfolio and communication and networking skills would at least get me in the door to prove myself.

Once coming I found out I would need to learn CS topics to get past the technical interview and that React would be a good entry point for a first job. So I left and studied another 6 months before returning. The second time I got a part time job as a coding instructor at a bootcamp because I have a history in teaching, but still struggle to get in the door for engineering interviews.

Nobody takes me seriously without credentials, I always thought that in a technical interview people would be able to figure out where you stand and not need credentials. The problem is companies get flooded with resumes so they build automated software to screen the best candidates but passion can't be screened.

</comment><comment><USER37> At Origin, we've hired multiple people without computer science degrees and whose resumes you would never pick out of a stack. One of our key players, for example, was a commercial real estate broker who taught himself how to code. The reason we hired him is that we're a 100% open-source project and he just started contributing. And he turned out to be really great. By the time we gave him a fulltime offer, he'd had several months to demonstrate what he could do. For anyone who is struggling with not having the right background or degree, find an open-source project and start contributing. It's a great way to prove yourself and you'll learn new skills and make awesome new connections along the way.

<comment><USER38> That makes sense. It's also how I look at hiring. People who have made good contributions to our codebase (arvados.org) are first in line.

Being able to look past the resume and pick up good people who don't fit a traditional pattern is definitely a skill. Business people tend to not understand this because they are stuck on matching patterns. In other words, don't let non-technical people be in charge of hiring developers :)

</comment></comment><comment><USER39> I get the sentiment but I have two problems with this.

1) Different stages of companies require different hires. When you're starting out, find the hungry ones. They'll get better at programming if they care, and they'll build a lot of stuff. Once you have real customers and are growing like crazy, hire experienced people to help you scale.

2) There is a difference between the "interview process" and the screening process. I agree that thinking about "Can this candidate do the job?" and "Will this candidate be motivated?" is the best way to go. But I don't have time to sit down with the ~200 junior engineers who sent me their resume on Indeed in order to figure that out. Hence, I filter by 5+ years of experience, and track record of working in multiple programming languages (don't screen specific languages though). Are the metrics perfect? No. But in my experience they weed out the people who are too junior to be successful on my team.

Interestingly, I think that if my company were bigger we might go back the other direction. Once we're on a stable path, and we have a few senior engineers who want to go into management and/or do some mentorship, we can afford to bring on more junior people and help them grow into great engineers.

There are many stages of companies, startups especially, and in some situations it makes perfect sense to use some plain old metrics.

<comment><USER40> "Years of experience" is a very misleading metric. Someone could have 2 years of experience but be more motivated and/or have worked in a more demanding environment than someone with 5 years of experience.

seniority !== skill

<comment><USER39> Which metric do you use which is never wrong? Or do you perform a full-on interview for every person who sends you a resume?

<comment><USER40> Of course not. But finding talent is far more subtle than "how many years has this person been in industry?" That doesn't account for passion, motivation, how much they learned and accomplished on the job, etc.

</comment></comment></comment></comment><comment><USER41> 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?

<comment><USER42> 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.

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

I can't understand this point of view at all.

When Google wanted to build the world's best JS JIT they didn't hire anyone who was generally able to figure things out - they hired the person with the most experience in building dynamic language JITs in the world. Experience is everything! Experience is knowing which rabbit holes to not go down, knowing who to speak to when you need help, what ideas haven't been tried yet, etc.

<comment><USER43> I think it's totally unrealistic to compare the average coding gig with writing a custom JIT from scratch for Google. In most businesses the difference between 'very good' and 'world class' won't have a large enough impact to spend the extra resources getting that rockstar.

And then there is the issue of actually retaining top talent...

</comment></comment></comment></comment><comment><USER44> Unmentioned Important Addition to Headline:

...because if you are trying to hire people that are proven, you will have to pay them a fair market rate.

<comment><USER45> > fair market rate

Or is it that people that have not been proven before have a lower market rate, justified (so "fair") by this lack of pre-validation ?

</comment></comment><comment><USER46> There's a critical kernel of truth here that I want to point out: work-sample tests. The longer I spend building teams, the more I am convinced: there are people who do WSTs as a way to qualify applicants, and there are people who just aren't serious about hiring.

It's easy to write a WST for simple things, like "can you literally write a computer program that does this trivial straightforward thing". It's hard to write WSTs for things that feel fluffy, like "can you manage a team". But here's the thing: as long as that fluffy thing feels fluffy, what that really means is you haven't bothered to figure out what success looks like for that role, and you couldn't even evaluate that person let alone hire for them.

There's a company in Indy called Woven ([http://www.woventeams.com/](http://www.woventeams.com/)) that'll do it for you, too. I have no relationship with them other than that they're nice people who are trying to unfuck hiring.

<comment><USER47> It would be great if you could convince large tech companies to use work sample tests, but I just don't see that happening. So in that sense maybe work sample tests can be a differentiator attracting candidates that don't want to spend a few weeks doing Leetcode prep every time they look for a new job.

On the other hand work sample tests also have drawbacks. I don't know if they're actually that much better than regular interviewing methods; I think they just contribute an orthogonal signal instead of a stronger one. I don't feel I can cheerlead them as much as you do in your first paragraph.

I think in an ideal world companies would allow candidates the option of choosing either their work sample or their resume-blind, standardized interview gauntlet. People with a lot of interviewing anxiety could self-elect a work sample option. But if you impose a work sample on every candidate I think you'll reduce your pool of available hires.

I was offered a work sample test recently and was told to spend about a week on it. I started working on it a little bit the first day and really enjoyed the exercise. But I was also interviewing with at least five other companies at the same time; I simply didn't have the time between work and traveling for onsites to really commit to the work sample.

</comment></comment><comment><USER48> There is definitely economic incentive for a busines to find 'diamonds-in-the rough', or there abouts, so to speak. ( [https://idioms.thefreedictionary.com/diamond+in+the+rough](https://idioms.thefreedictionary.com/diamond+in+the+rough) )

The traits to look, suggest:

'lack of' of prestigious education background,

living in non-metropolitan area,

perhaps somewhat muted self-promotion skills

genuine and _continuous_ interest in the particular field

\+ all the other soft-skills (team work, work ethics, respect for others, etc).

But I think to enable long term, mutual benefit between the business and employees, the business must be able to place itself, virtually, in the position of employee.

And ask: in addition to salary, why would the employee continue with me?

I feel that aspect is rarely discussed, written about.

I made some mistakes in my personal career development. And the most significant ones where due to me believing that the companies (senior managers) I work for, actually cared about my aspirations.

So, for myself, I had adapted this career management strategy, that I picked from lawyers:

'Up-or-out' [https://en.wikipedia.org/wiki/Up_or_out](https://en.wikipedia.org/wiki/Up_or_out)

Basically, I would not stay in one company for more than 3 (max 5 years), if I do not make meaningful incremental career growth (that also includes compensation growth).

Following that, even though late in my career, helped me to get recognition, better relations in the industry, as well as better monetary compensation.

</comment><comment><USER49> I'd add the caution that you should have clear criteria for what represents success in the job, and the timeline. If the candidate doesn't meet those criteria in that timeline, you both should agree that it isn't working.

My previous job was running a small Sys Admin consulting company. We hired 4 people over the years who definitely fit into the "not proven" category, with very mixed results.

Two really struggled: One of them was "ok" but needed a ton of management, the other never really got a basic level of proficiency despite spending most of a year "studying" and working at the elbow of various masters. One worked out really well and was a great worker. I feel like there was another one, but I can't dredge up the specifics.

The proven people on the other hand were mostly rockstars. The one that wasn't was largely due to my mismanagement of them.

So: Yes, absolutely hire the unproven. But have a plan.

</comment><comment><USER50> >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.

<comment><USER51> Internships are probably the best job interviews.

<comment><USER52> Yeah, but that only[0] works for entry level developers.

[0] I'm sure there are exceptions.

<comment><USER2> True. Contracting is sometimes also a way to find good people.

</comment></comment></comment></comment><comment><USER53> 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](https://getaclue.me/about)).

This way, recruiters can decide if they like me or not. Another thing I started doing while reaching out to companies is saying that I am open to 3-6 months "tryouts" if you wish.

I feel like we should have more of those. I also realized that social media is very powerful for finding your way in 2018. Gone are the days of wanting to work at a Fortune N company because they are doing great work. Most of those unicorns turn into corp machines that they were trying to stay away from.

Another thing I started doing is looking for people that share my passion. Anecdotally, Forums, IRCs, Telegam and the such communities are definitely booming once again thanks to the dissolution of privacy.

One challenge - esp if you are someone who cares about software and software engineering field - you have to do A LOT more work on your own. I work full- time and I work when I get home. I don't see this changing.

EDITed to add some \n

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

<comment><USER53> Thank you for the opportunity but I am located in Toronto, Canada.

</comment></comment></comment><comment><USER55> I find this is incompatible with the list of 4 questions:

> Cut luck out of your system.

You can't decide to do that. If you're a small company, you are only sampling a little bit and luck will either help you or hurt you. If you are large, the law of large numbers will give you something like the average. You can't decide if you're small or large.

As for finding people who are proven, it's up to you what level you are after. If you want anyone who'd played division 3 football, you have a reasonably large number of candidates. If you have a left back who's played Champions League and is under 25, you have a small number of candidates.

Try to go with larger sets, because then the LLN will help you. Don't ask for anyone who's played any sport for your football team, just anyone who has played football to the level you need.

Another important thing to think about is how to work with the great mass of ordinary people. At some stage if things go well, you may have to engage with people who are not wanting to spend 80 hours at your office, or who don't spend their weekends contributing to exactly the projects your firm is interested in, and who maybe aren't even all that interested in what you do. Motivating such teams has been a major value-add for a large number of household names.

</comment><comment><USER56> My initial interest in programming started before 1990. Due to an insane number and variety of mostly personal factors, the farthest I ever got was a couple ancient javascript/HTML experiments, a few small-to-medium side projects in MS Access and some intermediate router configuration. I've primarily just done tech support. I've performed well in the jobs I've chosen, though, because I get along well with others and tend to be loyal to the organization, even if I know this is sometimes foolish. It's simply how I'm wired.

Despite all the time that's passed and all the things I've dipped my toes into, I feel no closer to choosing a language, framework or tooling. I have no friends who are serious developers. I'm good at learning new things, but it happens slowly. It would probably take me 6 months to a year of dedicated daily time & effort just to ramp up on any one particular sub-technology (which, considering that I'm a rideshare driver to make ends meet, is a challenge)-- and there is no guarantee it would help me find work, since I have no idea who's hiring for what, or what those jobs are actually like.

All that being said, other than 'professional entertainer' (haha), a software developer is all I've really ever wanted to be, and I think with enough time invested the right way, I'd be really, really good at some aspect of it. I built myself a custom checking account database to better predict its future balance, and I'm happy every time I interact with it (except when it crashes for reasons unrelated to my code). The biggest question of all remains, though: Is it even worth the trouble to try, because would anybody even consider hiring someone like me?

<comment><USER57> The best place to learn is when you're hired as a software developer at a company. It doesn't matter if the company is good or not, you'll be forced to learn to make the product work. Change a few jobs and some years of tinkering and you'll likely get the fads, buzz, experience, etc.. Best place to start is as junior dev and quickly move up. Learning at home will never give you work experience since the 'real world' environment is not replicable at home.

</comment></comment><comment><USER58> 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.

</comment><comment><USER59> > 3\. Will this candidate get along with coworkers?

I think this 'getting along' is often misinterpreted as become best friends. I think a better way to state this question is

'Will this candidate be able to have successful working relationships?'

There is no reason you can't have a wide variety of people -- that would never choose to hang out with another-- working successfully together.

</comment><comment><USER60> As an unproven, but extremely passionate and motivated person (who is literally 2 hours away from going into his first Software Developer interview), I found this calming. If I don't get this position I really hope I find a company with the same ideals portrayed in this article.

<comment><USER10> Good luck!

</comment></comment><comment><USER61> As a dev straight out of university this blog resonates with me. I know I don't even come close in knowledge to a senior dev so in interviews I try to emphasis that I have a hard working personality, positive attitude, strong desire to learn, etc. Traits I think a company would really want if a dev was lacking in the specific skills. Sadly it feels like it always falls flat and I end up coming across as naive.

I think mainly the problem is rooted in employers cynical approach to hiring employees. It's hard to evaluate people on less measurable data points when you don't trust them. It's easier to trust tests with easily quantifiable results rather than those with grey areas.

</comment><comment><USER62> The problem is that those things can be faked during an classic interview by a good actor (or "salesperson"). It's much harder to fake problem solving skills on a whiteboard.

The pair programming approach is not terrible, but might be problematic if skill fields (technologies, environment) of interviewer and candidate are not perfectly aligned. So either the candidate will have to work in the company's setup they're not familiar with, or the interviewer will try to follow something they don't easily understand.

</comment><comment><USER63> 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.

</comment><comment><USER64> Sometimes it feels that even being "proven" isn't enough for a lot of companies that expect you to happen to know the six programming languages they put in their job ad, because if the ones you do know don't match up the recruiters will assume you're not a good fit regardless of your years of experience.

I do agree though that YMMV, and some companies are better than this and accept that you might be capable of picking up new languages and technologies.

</comment><comment><USER65> For what it's worth, I work at one of the large tech companies mentioned. I would disagree with some of the characterization. For example "Don't do whiteboard coding on riddles or puzzles" \- I think this is great advice, because questions like that are frowned on where I work too! Generally, the coding questions we ask come from real world applications.

I've also worked at a startup, and I think this article misses something that really could be helpful: there are different skills needed to work at most large companies and most start-ups. At most early-stage start-ups, scaling is not a problem. There are examples of companies that had to scale quickly, but for the most part life at a startup is about finding where your market is. I think that start-up hires also need to be more flexible: there's more room for specialization in larger companies, whereas in smaller companies, engineers that focus on one or two things can be pretty disruptive as the needed work shifts.

</comment><comment><USER66> I feel like I tend to value theory more than most people, and when I interview, I tend to ask extremely theory-heavy questions that I think are typically pretty difficult.

However, I don't usually care if they can actually work out the answer in a short amount of time, as anyone can probably find an answer to a question in about fifteen seconds on pretty much any search engine. What I measure is how well the person asks questions.

The way I figure it, it's far more important that the worker is good about unblocking themselves; you can't expect someone to have memorized every algorithm ever, but it's not unreasonable to expect them to bother someone who knows a bit more about the subject when they don't.

Just as an FYI, I don't have any fancy credentials, or really any qualifications at all, so it's not like I'm pushing some kind of MIT/Harvard/Berkley ridiculous agenda onto people.

</comment><comment><USER67> I am very skilled, highly educated, and interview poorly. When companies hire me, I get big promotions, leadership pulls me in, etc. This is because I'm not "an engineer" or "a programmer." The departments I work in obviously know/recognize me but the business doesn't know the job function really, its starting to be a more recognized area. The fact that I got as far as I did is hilarious, and I know how to find a lot more people like me at any time, and they'd never have gotten any of that value without hiring people like me. I also don't know how you would discern a "fake" me from me, without some of us on the interview. My interview was conducted by some highly qualified people and a few not qualified people, so I knew I had room to grow because there was a lot of dead weight.

</comment><comment><USER68> Very good points, being on the lookout myself I realize this also works the other way around. I need to be good at answering:

* Can I do the job and can I communicate my weaknesses and strengths?

* Will I be motivated?

* Will I get along with the people?

* What will I be 3, 6, 12 months from now? What do I want to achieve?

* What's my motivation and attitude?

* How do I learn?

* How do I work through blocks?

</comment><comment><USER69> It's a great sentiment and I would love to hear this blog poster's success with his system that he described. Does he have actual metrics as to how effective his description is, or is this just another example of someone on the Internet making an edict with no data backing it?

</comment><comment><USER70> I recommend "Why Employees Are Always a Bad Idea" by Chuck Blakeman. It describes how to build a company where everyone is a stakeholder and not a child that needs constanct watching and stupid rules in order to function. No titles, no working hours, unlimited vacation time, you hire the whole person (not just the BS smile at work part). You work together because you want to find and make meaning. No CVs and skills are far less important than personality and fit (skills can always be learned).

The book is the reason I'm building my own company because this is how I want to work and live (I used to work for a company like that, but unfortunately, due to personal circumstances the founder had to split and the company disappeared).

<comment><USER45> Great idea, but then couldn't they replace you and what you're doing (since they won't be your employee they'll be business partners) ?

<comment><USER70> No, it was the unique combination of people that made the company. Once two key people left, everything fell apart.

</comment></comment></comment><comment><USER71> Having hired folks who weren't proven, most didn't work out. However, the ones who did work out were great.

One difference that stood out beyond courage and attitude is how engaged in actualizing one's potential the candidate is.

Everyone has potential. The person doing the hiring may see it. The candidate may, or may not.

The only thing that mattered in the end was the candidates ability to actualize their own potential beyond what they may see in themselves, given an opportunity.

The questions "What do you build/work on when no one is looking" is one interesting question to elicit a sense of their attitude towards their potential, and if they have the courage to undertake building/learning something for the sake of learning.

<comment><USER72> You have to kiss a lot of frogs to find the prince this way. It can be very time consuming. If your company has more time than money - it's a reasonable strategy.

<comment><USER71> Agreed on kissing a lot of frogs. I wasn't recommending it, or not, just what one experience was. Over time, it's less useful, but it's important to still remain as open as possible.

</comment></comment></comment><comment><USER73> On the actual job ad, and how it sounds, I like to cite:

[https://tudorbarbu.ninja/message-to- recruiters/](https://tudorbarbu.ninja/message-to-recruiters/)

>We're looking for a person with more than 100 years of experience in software development, coding everything from BIOSes to cloud applications, knowledge of all past, present and future operating systems and setting up secure networks. The applicant must also be able to juggle up to twenty balls and read hieroglyphs, be fluent in Swahili and dance like Michael Jackson (especially moonwalking – nice to have at corporate Christmas parties).

</comment><comment><USER74> 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.

</comment><comment><USER75> I dunno, I tried to hire based on potential, and I just let them go after six months of him failing to grasp even the basics of the job. He did fine in the interviews but ultimately you cannot fake experience.

<comment><USER76> We've hired multiple people based on potential. A few of them have worked out astoundingly well. More than that have quit or been let go for not being able to handle the job.

It's pretty demoralizing to let someone go. It's pretty annoying to have them quit in the first week. (Or even the first day!)

But it's pretty awesome when they work out and you get to watch their skill grow over time.

</comment></comment><comment><USER77> I wish this was a thing, but it's not.

I worked for a company that did some layoffs of some good people. They're capable, but their bullet points don't match many jobs .... so they're looking for and endlessly long time.

These are great people more than capable of learning. At their previous jobs as a team they did more work than teams 3x their size.

I know a few places that turned them down in favor of folks who matched the bullet points... but not the job.

It's difficult to watch as I see news of places "desperate to find workers"... but refusing to hire good people.

</comment><comment><USER78> I read " _You must have 10 years experience of <tech>_" as shorthand for " _Have you stopped learning new things? Come and work here._ "

<comment><USER41> That's ridiculous. Why does learning new technology mean you need to stop using the old technology?

<comment><USER78> It doesn't, obviously. My point was about how companies advertise jobs. A company advertising a job with a requirement of 10 years experience in a technology wants someone who's able to tackle pretty much any problem from the outset. _They 're not open to people learning._

</comment></comment></comment><comment><USER79> A major GPS navigation company hired me for a job I wasn't ready for in 2006 when I was 24 years old. It was my first job at a big company.

I'm pretty sure I got through because they were growing way too fast and I slipped through the process somehow.

Being dropped into the deep end and surrounded by smart and experienced people was incredible for me. It took me a while to get up-to-speed but when I did I'm sure I more than repaid their investment.

</comment><comment><USER80> I can't disagree with this person more.

More than anything have learned that education and training are hugely important and hiring to train leads to mediocre staff who think their two years of development work stack up to your 4 years of college and 6 years of professional experience.

They take forever to start writing productive code, if they ever bother leaning at all.

I will never hire someone without a degree or equivalent experience again. Even for Jr. roles

<comment><USER81> This strategy may weed out duds, but it will also occasionally overlook great people. One of the brightest engineers I know dropped out of high school and got a GED, but was obsessed with tech and practiced building things daily. He's 30 and a VP now.

</comment></comment><comment><USER82> This feels a bit like a strawman. I've interviewed with FAANG companies and I run interviews and I don't see these puzzle questions. I see people looking for basics and looking into problem solving and hints that candidates have done good work before. Granted, I've seen that urge to ask puzzle questions in some quarters, but I've regularly seen that ignored. Maybe though I've been blessed..

</comment><comment><USER51> The author makes some good points. But, I wish they had offered some ways to test the dimensions they speak of: courage, attitude etc.

</comment><comment><USER83> So, with this in mind, can any more experienced professionals say how you can stand out as an 'unproven' new grad/dev?

I've got work experience that isn't a tech internship (network support at a major uni), and code projects, but without that internship (I did research instead), it seems I and people like me are constantly at a disadvantage.

</comment><comment><USER84> Yup! Tom Peters - of "In Search of Excellence" fame - advocated the same mantra back in the late 90's. Yes I am that old.

It makes for great copy. Really.

But then, when push comes to shove, the old search for a lego piece that fits with all the other lego pieces continues, so that there's the alibi.

It reminds me of IBM's "nobody ever got fired for buying IBM".

Life continues.

</comment><comment><USER85> In all fields, search for hacker mindset: curious, intelligent, self- motivated, capable of independent R&D and execution.

</comment><comment><USER86> I don't think that the hiring process in terms of what you need is that hard.

You just need to hire people that match your company culture, matching the skill set you need for a given salary range.

Hiring someone who blends well in the company culture is half way there.

Now, if there's someone that matches this line of thinking in the pool of talents, is another story.

</comment><comment><USER87> > "Don't hire like FAANG companies"

I work for a FAANG, and we don't hire like that either. The motto is often "hire for potential, not track record".

The dark pattern lurking in that is age discrimination: A motto like this can easily be taken as an excuse to completely dismiss track record, or even consider it detrimental.

</comment><comment><USER88> Nice post, I think it can be more difficult for less-experienced (but talented) people to find jobs than it should be. However in some ways the FAANG companies are better in this regard since they hire many people out of college and strive to have an objective hiring process that can be passed by less experienced people.

</comment><comment><USER89> Hope you don't mind me sharing some thoughts I wrote on this topic that are similar to the linked article...

Hiring is broken.

[https://medium.com/@simonhamp/a-new-way-to-hire-tech- talent-...](https://medium.com/@simonhamp/a-new-way-to-hire-tech- talent-942ca2e7db8f)

</comment><comment><USER90> Joel Spolsky figured this out a while ago.

1\. Smart.

2\. Gets things done.

Read this. [https://www.joelonsoftware.com/2006/10/25/the-guerrilla- guid...](https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to- interviewing-version-30/)

<comment><USER46> There are good tidbits in that post, but the way you measure "smart" is awful and almost entirely subjective. The conversation "just flows"? Really? Gee, I wonder if that's likely to make you hire people who have the same background as you.

I agree that the "gets things done" part is important! But I think you should measure if they can, in a controlled environment, instead of just going off the resume and seeing if it has worked out in the past. Lots of total dipshits manage to ride on the coattails of successful teams.

</comment></comment><comment><USER91> Seems to me that at some point hiring moved away from hiring based on potential to hiring based on pure skill and how many boxes the candidate has checked. Companies seem to just want people who can turn the crank, which doesn't sound all that appealing.

</comment><comment><USER92> The author hits on a lot of great points here, that I believe speak to a larger theme: there's a ton of undervalued programming talent out there and finding that talent can give your company a huge leg-up on the market.

</comment><comment><USER93> I think the manhole covers are round because they're really heavy and it'd probably be tedious to orient a square or any shape with multiple sides to match up perfectly every time you put them back on.

</comment><comment><USER94> If you look at NFL as an example, even with such intensity of the scouting methods, that will tell you how hard it is to find talent

</comment><comment><USER95> not only does the industry not have a labor union, there's a culture of passion which is almost like having a negative union.

any time passion is involved, you are being paid less than market. cash is a more liquid currency and can in fact buy passion.

</comment><comment><USER96> So to fix hiring let's hire people on even more subjective bases !

</comment><comment><USER97> Don't forget, FAANG are looking for minions that fit the assembly line in 99% of cases. Not original thinkers or people who are multi-talented, wearing many hats.

</comment><comment><USER98> or be like Netflix and _only_ hire proven people and pay them a lot

</comment><comment><USER99> What amuses me more than anything else is that this dystopia was created by software developers. Oh everyone is going to a bootcamp and saturating the dev job market? Maybe you shouldn't have "disintermediated" every possible job from accountant to truck driver. What's good for the goose is good for the gander.</comment>


Get notified when somebody mentions you on IRC - <AUTHOR> http://mlomnicki.com/irc/2012/10/23/get-notified-when-somebody-mentions-you-on-irc.html

<comment><USER2> I'm a big fan of IRC. At work, I'm forced to use HipChat, though. The feature that OP described (mentions) works really great there.

It's great to have it in irssi as well. Testing it!

BTW, when does someone create a working implementation of IRC-based webchat? Please, don't mention grove.io...</comment>


Beer recommendations with deep learning - <AUTHOR> https://medium.com/data-from-the-trenches/deep-beers-improving-the-performance-of-deep-recommendation-engines-using-keras-73c32e4a192a <comment><AUTHOR> I just published part 3 of my beer recommendation with deep learning series. I wrote about how to use metadata to do a hybrid recommender system using keras. Hope this is of interest!</comment>


Show HN: Python framework prototype to avoid the need for JavaScript - <AUTHOR> https://github.com/amirouche/beyondjs/#beyondjs <comment><AUTHOR> It's inspired from nevow and use aiohttp.</comment>


Web Assembly now supported across all browsers - <AUTHOR> https://www.infoq.com/news/2017/12/webassembly-browser-support <comment><USER2> > across all browsers

IE.

Everywhere I've worked, we still have to support it. Unless Microsoft ports Edge to Windows 7/8 and makes it a default browser, I don't see the situation changing anytime soon.

<comment><USER3> _Unless Microsoft ports Edge to Windows 7 /8..._

Support for Windows 8 ends in a month[1]. There's extended support for some users for a further 5 years, but if you're doing client work rather than writing bespoke software for a specific user then IE, and Windows versions less than 10, are effectively dead and gone.

It's perfectly reasonable to use web technologies that aren't supported by IE. Ideally you should have a bare HTML server-side alternative for those users, but that's true for _everything_ that a user might not have (or have turned off, eg JS).

[1] [https://support.microsoft.com/en-gb/help/13853/windows- lifec...](https://support.microsoft.com/en-gb/help/13853/windows-lifecycle- fact-sheet)

<comment><USER4> > Windows versions less than 10, are effectively dead and gone.

Ha! Don't we all wish. Here's the marketshare numbers from this month [1].

\- Windows 7: 43%

\- Windows 10: 30%

\- Windows XP: 6%

\- Windows 8: 5%

And companies are going to be buying extended support for 7 no different than XP so you'll have to wait out that 5 years.

[1] [https://www.netmarketshare.com/operating-system-market- share...](https://www.netmarketshare.com/operating-system-market-share.aspx)

<comment><USER3> My point is that once Microsoft no longer supports any version of Windows that runs IE as it's default there's a very valid reason to stop supporting it as a 'mainstream browser', and using it to avoid technologies that aren't supported by it is somewhat dubious reasoning.

If users with IE6 and users with IE11 get a boring HTML-only-but-still- basically-functional website, and users with Edge 15 get the fancy WASM enhanced website, then that's fine in my opinion.

<comment><USER4> > IE as it's default

So even though Windows 10 still ships IE the fact that it's not a _default_ is enough to not support it? Bad news for Firefox and Chrome then.

> If users with IE6...

Sure, albeit a bit extreme, that's more or less progressive enhancement.

<comment><USER3> _So even though Windows 10 still ships IE the fact that it 's not a default is enough to not support it? Bad news for Firefox and Chrome then._

Using Firefox or Chrome is a step sideways to use an alternative browser. That's great. The more up-to-date browsers people use the better in my opinion.

Using IE is a step backwards _usually_ to support a specific technology that isn't supported by other browsers (and IE is often used along side another browser if that's the case), or because the user is looking for a particular experience. I don't see either of those reasons to avoid using WASM on a new website so long as there's also a fallback to support browsers without it, even if that's a limited version of the site.

</comment></comment></comment></comment></comment></comment><comment><USER5> Any good example projects already using WebAssembly ? Some list with multiple examples would be nice.

<comment><USER6> We should sometimes pause, and think about the disadvantages a new technique will bring to the web.

I am completely fine with asm.js.

Though WebASM is a like a wet dream for big corp with mass of legacy code in C++. We will see Office running on WebASM and other closed binary blobs in near future. It's very contrary to the concept of the open web - do you want to live in AOL-land again, were everything is closed off? No? Anyway great you helped them. I fear WebASM has several downsides that will harm young startups a lot in near future - only unicorns and big corps will benefit, it will be a win-win, less competition, because of harder entry to market, and they can ship their decades old C++ blobs as a service. It's time to wake up, and stop WebASM or severe limit it's functionality. Where is Mozilla foundation? Or is the new Mozilla just another startup, backed 90% by Google money.

<comment><USER7> I am a C coder, and I cannot wait to have my code on the web, decimating inferior languages like JavaScript. If a startup relies on JavaScript to keep out competition from C coders, well, too bad. They will be decimated in terms of performance. The web will be ruled by the best performing apps written in the language of the Linux kernel.

<comment><USER8> Performance in web apps is not a goalpost for everybody. While there's certainly web apps that are problematic in terms of performance, you're unlikely to be running at 100% CPU the whole time, so it's not like using C will be the right solution.

I can see how C/C++ (and, well, more likely Rust) will become a de-facto solution for when you need performance or some type of robustness to your apps (ie probably the right thing for Figma). But the potential performance improvement might be negligible on most makes, and unlikely to offset the fact that you'd be working off a completely different stack making things like debugging and inspecting much harder.

What I think is likely is that using WebAssembly will allow new types of web apps to become popular. Things like video encoders, image editors, etc. Things that you just wouldn't do with JS anyway, at least not in the heavy parts. Thing of a standard web app that uses ffmpeg on the background.

<comment><USER9> > _Performance in web apps is not a goalpost for everybody._

But in 2017 startup and companies are starting to understand how fast response times (on a website/web-app) are of critical importance for gaining a good user base.

<comment><USER8> True, but in my experience bad UI response times are more related to something goddamned dumb like running a series of super expensive scroll events or watching DOM changes for some idiotic reason, more than about raw processing power.

A C solution might make the former faster, but it'd still be a dumb architecture. A cheaper solution than migrating your whole codebase to a separate language and build process is knowing how to deal with events and how to parallelize (or delegate) stuff correctly.

</comment></comment></comment></comment></comment></comment><comment><USER10> Does anyone know when/if DOM support will come to WASM?

<comment><USER11> I am also curious about WebGL and/or canvas approach. This would allow bypassing the HTML and CSS mess not just JS mess.

<comment><USER12> Unless you have a good reason, I urge you to never do that. Even ignoring accessibility (which is pretty much completely ruined in this situation no matter what), you'll need to reinvent every single primitive widget you need yourself and have it work the same as it does on all platforms.

That's a shitload of code shipped to the user before you even write a single byte of code for your application!

<comment><USER13> No doubt someone will build that library though

<comment><USER14> It's been done, multiple times. See qt, gtk, etc.

Personally this revolution can't come soon enough.

<comment><USER15> Didn't Firefox also used to be like this? They reinvented every UI widget, and as a result felt like garbage on Mac.

</comment></comment></comment></comment></comment></comment><comment><USER16> I would try it out, if it would be possible to just type web assembly by hand. Then I would just open an html file or a jsfiddle and play with it.

But as I understand it, it needs a toolchain?

<comment><USER17> Yes, WebAssembly is bytecode that is a IR compile target for other languages, which right now is limited to C and C++ via Emscripten, or Rust via its own normal toolchain or Emscripten as well. It has a plain text assembly output called WAT, but its not really meant to be handwritten, but rather reviewed as a build artifact.

You can see an examples in Rust including the readable Wat output here:

[https://www.hellorust.com/demos/add/index.html](https://www.hellorust.com/demos/add/index.html)

<comment><USER16> If I can't just type it and see the result, I am not much interested. I don't like to install software. As a child of the web, my feet are firmly planted into the cloud.

<comment><USER18> You _can_ do that but why would you want to? The tool you're looking for is wat2wasm, which converts the human readable WAT source to WASM binary, and here [0] is an online tool if you want to tinker with it.

Compiler IR's like WASM or LLVM IR are very laborious to type, they're intended to be produced and consumed by compilers.

You need to write very verbose code with all the type declarations, which aren't automatically propagaged, ie. `(func $foo (param $0 i32) (result i32) ...)` and `(i32.add ...)`. There's very little point in writing code like this by hand, apart from testing and debugging the compiler producing or consuming this code.

It doesn't make much sense to have this "in the cloud" outside of toy tools like this. In any kind of actual work scenario, you'd be running a compiler producing WASM on your development machine and deliver the WASM binaries over HTTP to the client machine. The whole point is to have near-native performance while reducing the compile time on the client side.

But if you want to tinker with it, knock yourself out. Here's the tool:

[0] [https://cdn.rawgit.com/WebAssembly/wabt/fb986fbd/demo/wat2wa...](https://cdn.rawgit.com/WebAssembly/wabt/fb986fbd/demo/wat2wasm/)

<comment><USER19> I like this answer a lot more than the other ones that are just dismissive.

I think there's at least _some_ value in these "toy tools". Would being able to tinker with WASM not help development of compilers? I place a very high value on understanding as far down the stack as you can, I don't think ignorance of every abstraction layer below the one you're working on is a very noble goal to strive for.

<comment><USER18> > Would being able to tinker with WASM not help development of compilers?

There are tools, even web based ones, that allow you to tinker with WASM, compile C, C++ or Rust code to WASM, print out the WAT representation, turn WAT into WASM, run the WASM blobs through JS, etc.

These tools are probably very useful for the guys developing WASM frontends and backends. E.g. sharing a piece of WASM code with other developers.

Should the average developer use them? Not really. Maybe spend an hour poking at things to get the general idea of how it works. You really don't need to understand the details of LLVM IR, SPIR-V, WASM or GCC's GIMPLE in order to use those compilers.

Is it a good idea to understand what and how are intermediate representations used in compilers but actually writing that by hand is not necessary or productive.

</comment></comment></comment></comment></comment></comment><comment><USER20> I tried to use emscripten as a tool chain, it was not the greatest experience.

I really hope better toolchains will appear.

Emscripten seems to be a collection of weird hacks.

</comment><comment><USER21> All browsers? Including Lynx?

Oh, no, you meant all the official browsers of our corporate masters. Sooner or later they'll all be one.

<comment><USER22> We welcome you to switch to Mozilla Firefox!</comment></comment>


Amazon's Flexible Payments Service -- move over PayPal? - <AUTHOR> http://www.amazon.com/gp/browse.html?node=342430011

<comment><AUTHOR> I haven't played with the sandbox or signed up yet, but from the docs it actually looks really good: send _and_ receive money, support for a kind of micro-payments, significantly cheaper transaction fees than PayPal in most cases ... hmmm, cool.</comment>