[jcampbell1]

I run a bootstrapped company and we hire the cheapest engineers we can find. I interview for competence in the one thing they understand, and then just how fast they learn. I cannot overstate the number of people out there that are incredibly smart, but can't describe basic information like how the HTTP protocol works. It is completely baffling. These people can be explained how the protocol works in 10 minutes, and spend 8 hours at home looking at the Chrome web inspector, and completely grock the protocol. I find myself a seed planter. These people are smart enough to figure it out, but for some reason they don't do it without a 10 minute verbal overview.

My advice to any to young person is to judge the job by the quality of the mentor. Smart people feel ecstasy when learning new things, and if you have anxiety about your job, then you are likely in the wrong position.

[dustingetz]

i totally understand and respect your position and that's definitely a strategy that can work.

The other end of the spectrum is, you could contract someone like Tony Morris[1] at $250 an hour for 20 hours a week, and he will build your product faster than a team of untrained engineers, or more likely, build a product that untrained engineers aren't capable of building, with a defect rate close to zero.

Not every strategy is right for every business, but generally, the harder the technical challenges, the more cost effective it is to pay for a superstar.

[1] http://tmorris.net/posts.html

[oblique63]

Yeah, but I think the over-arching idea that the OP was getting at, was "what if we can breed these 'superstars'?"

That would certainly seem feasible if you interview for personality traits, interests and learning skills, more than actual/concrete knowledge and working skills. And of course, this would be a lot more cost-effective as well. In that case, I would say that the key would lie in paying more attention to human psychology/intelligence research than to tech blogs/circles to find out more about 'superstars'.

[btilly]

To a point that is possible. However there are key lessons that don't really sink in until after you have made certain mistakes and have seen the consequences. For instance I understood the value of forcing variable declarations, and of having multiple layers of safeguards after a typo in a variable name caused me to take down Bloomberg's ftp server about 15 years ago.

Judging from ability and personality, it was clear at that point that I had potential. And I received some excellent mentoring. But potential and mentoring do not ensure a smooth path to success.

[oblique63]

While that's true, it still seems a bit orthogonal to the point, because the argument being made is essentially about efficiency, not necessarily effectiveness. If we think about all the people that have had such experience changing epiphanies, then take the subset of those who might actually be able to communicate these valuable experiences across in a programming interview, suddenly your selection pool becomes rather small. Which is oddly reminiscent of the current 'talent shortage' issue. Thus, approaching the problem from a different angle which considers this concept of 'experience' to be more of a byproduct of a certain set of traits than a trait itself, you suddenly open up your list of possible candidates to something a lot more workable.

Because after all, there is nothing preventing people selected for personality traits to reach these same epiphanies that 'experienced' people have (regardless of mentorship), it's just a matter of whether or not you as an employer would be willing to accept this 'risk'. Given the current state of affairs with regards to 'talent', I could see many finding the risk permissible. Not to mention the fact that the set of 'smart people with potential' is not mutually exclusive with the set of 'smart people with experience'; of course, selecting purely from the set of people that meet both criteria would still fall under the realm of chasing unicorns, but the point is that the two are not exclusive.

[btilly]

The point that was made was that smart people with potential are cheaper to hire and easy to train. My point is that smart people with potential and training are great, but aren't actually as good as smart people with potential and experience.

The trick is, of course, that smart people with both potential and experience tend to be easy to identify..and very expensive.

[oblique63]

Well yes, but the fact that they are expensive is a byproduct of their rarity (which results in us talking about cheaper engineers), and that can be symptomatic of a system with an efficiency problem. The argument then is about confirming that it is.

[mbillie1]

> That would certainly seem feasible if you interview for personality traits, interests and learning skills, more than actual/concrete knowledge and working skills.

That's a good chunk of the way we (ThoughtWorks) interview, along with general smarts and good company fit. It's easier to teach a very smart person [language x, skillset y] than it is to teach a random person who knows [language x, skillset y] how to be very smart.

[porker]

> And of course, this would be a lot more cost-effective as well

Only if you can retain them, once they get smart and realise how good they are. Gratitude (and staying with the company who invested in you) aren't popular these days.

[virtualwhys]

You mean the guy that one could argue is solely responsible for the Code of Conduct header on every TypeSafe affiliated Google Group?

Yah, that guy. Sure, for $250/hour he's probably fairly amicable.

He's categorically brilliant (in FP implemented Scala, certainly), but good luck grokking his mile long type signatures when he's gone from the project.

Saying that, if part of his consultancy is to train the team in FP and explain his code, then there is "real" value in the hiring; otherwise, where would you know to begin when updating the system down the road?

[jcampbell1]

> with a defect rate close to zero.

Most of our defects are not software defects, they are product/marketing/strategy/SEO/SEM defects.

If American Express wants to launch some app with defined features, then Tony sounds like a great guy. We kinda understand our customers, but not really. We throw pasta at the wall and see if it sticks. Once it sticks, I can hire Tony to make it great. Tony will never accept us as a client for good reason.

[kamaal]

I don't have decades of programming experience. But with whatever limited experience I have I can tell you. Especially with software knowing what to do is the most difficult part, doing it isn't even a problem.

A product is ultimately a discovery which you have to do in iterations. It won't be until the last iterations you will know what to do. Once things are clear you don't a rock start to get things done, any one can do it now. Rock stars are needed speedup those iterations, do the discovery super fast and get the clarity.

[terenceong]

i might be missing something but is tony morris someone who is famous for being really good at programming or something? i googled him and couldn't find anything concrete, and yet you and the guy you replied to seems to already know who this guy is and have some kind of assumption about his abilities. i'm sincerely asking.

[virtualwhys]

Tony Morris is more infamous than famous.

In Haskell he's nobody special; however, in Scala he's known as one of originators of Scalaz, and has made contributions to the development of the Scala language itself. TM is very strong in category theory and has no problem speaking categorically about the correctness of his views.

He's a polarizing figure in the Scala community and seems to enjoy pissing people off (again, the code of conduct banners seen on Scala Google groups can be by and large attributed to TM, which is an accomplishment, thus the infamous claim).

In TM's defense, as a teacher he does force the reader to stretch beyond their current (limited) understanding. If he came across as less of an a$$hole then he'd probably have a larger role in Scala and the programming world as a whole.

[RockyMcNuts]

Most important thing in your first job is your boss. You are going to learn a massive amount, not just the job skills, but how to work in a group/company. The distance is massive between learning the right things from someone who does things in a first class way, and the wrong things from someone mediocre or worse.

Second is the company. You join the right company, and it's a solid growing company, or a rocket ship, you have lots of opportunity to learn and grow. Conversely, if it's a truly awful company known for unethical practices or engineering nightmares, it can end up haunting you, both in teaching you the wrong things and a possible red flag on your resume if you stay too long.

[jcampbell1]

In a flat organization, your boss is going to be irrelevant. I would gauge a company by whether the interviewers teach or belittle. I personally find belittling okay, and can learn in that environment. "fuck you, if you are such an expert, then you can explain it to me. If you can't explain it, then you are probably full of shit." I have no problem saying that, but most people won't/shouldn't.

I get high from learning no matter whether the people are assholes or teachers. Most people need good mentors that are not managers. Any organization where managers have time to teach are too hierarchical.

[franciscoprat]

A manager can be a mentor regardless of the type of organization. What is important if you want to improve a particular skill set is that the people that are managing you truly understand what it takes to do your job well and can provide feedback on what you are not doing well from a "do-ers" perspective - more of an apprenticeship model.

I have personally found that mentors are great for career advice and resolving questions, but never have enough "skin in the game" to invest their time in my development.

[jcampbell1]

I used the word mentor incorrectly. What you want is peer teachers, not mentors. Mentors by the corporate definition are largely useless. You contact them 1-2 per month at best, which is pointless.

What you want is a person that observes your code, behavior, interactions, demeanor, etc., and tells you how to do better. It is impossible to have perfect introspection. You need to find a guide more than the corporate definition of "mentor". People need apprentice masters more than mentors, I wish I had used a better term.

[RockyMcNuts]

that's pretty much what I meant... if you've just graduated that person is not really your 'peer', maybe not your 'boss' either ... a lot of times real world roles and relationships don't line up with org charts.

[RockyMcNuts]

interesting... After about 3 years I agree. But a first job, someone's got to show you the ropes and get you up to speed with processes, testing, coding standards, help you get unstuck from time to time. I guess by boss I don't necessarily mean team manager, but whoever that is, mentor, direct senior. If nobody has that role, you'd better be pretty self-directed. 'Flat' better not be a synonym for free-for-all with no process, standards, code review, or you might learn some bad habits if you're not a natural (and even then.)

[dchichkov]

Most important thing in your first job is that the team is well balanced. And that you are collaborating with people who are amazing, rich and had history of doing great things before. [As to your boss, of course having a nightmarish boss fresh from some traditional caste system could be disastrous and can end up haunting you. But that's an outlier case.]

[rhizome]

Just out of curiosity, do you phrase the question, "how does the HTTP protocol work?"