Hacker News Reader

Comment by dustingetz | Hacker News Reader

one point al3x didn't talk to: not all startups will teach you to be an awesome engineer. If a startup is really hiring the best of best, a less experienced programmer is not likely to make the cut. Ever look at your code from 6 months, a year, 5 years ago? and how bad it is? Many tech startups don't have time for that, the quality of your work can make or break a startup. Elite startups want "ex-googlers".

So if you want to get good, you need to work with people that are better than you, who have already learned from their mistakes so you don't have to. Find the strongest shop that will hire you. It will not be the best shop. It probably won't be an elite startup. But more mature companies can afford to pay for your learning curve. You also will probably make more money, enough to pay off your student debt and save up to bootstrap when you're more experienced.

View on HN

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.

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

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'.

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.

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.

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.

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.

Expensive, yes. But expensive compared to value produced?

Every decent programmer has stories of a time they put in 10 hours of work to save a highly paid person 20 hours/month for the rest of time. I say stories because there are many such. On my resume I list a number of cases where I added X millions/year to the bottom line of small-medium companies. It is not a complete list. What value should an efficient market put on a programmer who does that repeatedly?

For those willing to work as an employee in the Los Angeles area, the value the market places is significantly under $200k/year. Now you tell me, is that expensive relative to value?

Expense wasn't even remotely the issue I was addressing; the expense of such 'experts' makes sense within the scope of our system. It is the rarity that seems out of place.

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

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

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?

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

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.

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.

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.

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.

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.

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.

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.

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.

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.)

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.]

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

Great point. A good rule of thumb in jobs is that if you are the undisputed top <X>, make sure that you are being compensated very, very well. Because you just sold out. It is quite hard to reach new levels of expertise without explicit, task-related mentoring, and if you're trading off that kind of growth, do it explicitly.

Back when I was a manager, I used to find it somewhat depressing to interview people who had gone to startups or non-tech firms for 5-10 years, reached "senior developer" or "architect" roles, and whose levels of expertise were indistinguishable from the median recent stanford grad. Certainly, they knew more "things" but had failed to grow in either scope or depth.

Certainly, they knew more "things" but had failed to grow in either scope or depth.

It's really easy to let career development and general-purpose learning go to slack when you believe this thing you're spending 80 hours per week on is going to make you rich and change the world-- and when you're surrounded by people who (equally irrationally) believe the exact same thing.

that first sentance is an amazing way to frame salary negotiation, thank you!

This would be (and still is) a great sentiment, but the problem is that so many startups and small development shops are looking for something that most fresh graduates/junior level developers can't offer. It's a real shame, because it appears as if there's often little to no budge, and I worry for the future of the market (and by this I mean for the other 98% of the US which isn't SF or NY) because it's a real issue that's going to start rearing its head, if it hasn't already.

If you work on a startup, almost by definition you'll be doing a lot of different stuff, and changing a lot of things. That is a great environment to learn new different stuff (even out of the engineering field). Maybe not deep knowledge, on the other hand... And, of course, working with great people will make you learn faster and better.

There are also plenty of startups that don't value or recognize technical skill and where it's easy for a junior engineer to get hired. Those are terrible as well, because (a) they'll make you stay mediocre and (b) you end up learning the wrong lessons.

like that HN'er's story of wiping a production DB accientally and the company (a social gaming company) blaming him and bullying him into resigning. (instead of asking why they had given a Jr. Dev write access to production in the first place)

Giving a "junior dev" access isn't the issue; after all, that dev probably writes code that can execute SQL.

The problem there was not having any safeguards against running arbitrary commands and not being able to just rollback from the transaction logs. Seriously, it should be a small annoying incident. Screwed up some data? OK, stop things, restore, rollback to the transaction before you screwed it. Apologize and move on.

Giving the Jr Dev access wasn't the problem; your site should be Jr Dev proof (i.e. have backups). If that wasn't a problem, then they only have themselves to blame for investing in someone they obviously didn't want.

Besides, just because you're inexperienced doesn't excuse stupid behavior, and I'm struggling to think of how one might accidentally drop a database after logging into a production environment—I would suspect that people were already lax about it if a Jr Dev was doing it.

If I recall correctly, he was developing a new feature, and the only way to test his work was by creating and dropping test tables, on the production db. One day he dropped the wrong thing. I don't think he had any technical or academic background, and there was no oversight.

> the only way to test his work was by creating and dropping test tables, on the production db.

Really? He couldn't restore a backup locally and test against that? You guys couldn't roll back via transaction log? Mistakes ALWAYS happen, and it's just unfortunate that the Jr Dev was the first person to get screwed by one.

Reply on news.ycombinator.com