I guess like you said: common courtesy, don't waste my time or yours. Why send an email if its' not worthy of a response?

The former is certainly true; the latter, probably not.

I'd simplify to: "It's a rational strategy that maximises coverage."

Being rejected is unpleasant in any context; one way to minimise the unpleasantness is to downplay the value of any one interaction.

If you make a big effort, the disappointment is magnified. This is why the first and most important advice to folk on dating sites is "message and move on". Otherwise you're going to get bitter, which is even more self-defeating.

Rejection is painful because of the "simulation heuristic" -- imagining yourself enjoying working at the place / going on dates with the person.

The simulation heuristic works the other way too. You can easily imagine being disappointed by the new restaurant. You know what? Let's just go to Shmookey's, we always go to Shmookey's on Thursday and get the steak.

edit: actually, no, simulation heuristic isn't quite right. Sunk cost fallacy? Someone help me out here.

Of course, the counter to that is that taking a dump in a thousand baskets also leads to no eggs.

While the quote is very funny and I give you that, the analogy doesn't fit. A more apt analogy would be - throwing your eggs without care in a thousand baskets, chances are most eggs will break.

How would you describe emailing a hiring manager/developer with something like "lol, give job pls?" Not very egg-like at all...

It's a hirees' market at the rockstar level, as always.

SF, New York, London, Amsterdam, Berlin, etc. all have huge talent shortages. Even developer markets that were relatively soft in the past such as Poland and India are starting to become competitive as the war for talent becomes more global.

I think of those who understand algorithmic reasoning (i.e. understand loops, assignment, etc.) they also fall into two categories. Those who can understand more abstract programming concepts (indirect referencing, recursion) and those who can't - you can definitely still be a good programer without understanding those but it will limit the areas you can work in.

Indeed, I haven't met any programmer who couldn't understand recursion when explained in clear terms, same goes for indirect referencing.

If I had to divide the programmers who really understand algorithmic reasoning into two categories, those would be

- A: those who program because it's their job,

- B: those who program because it's their passion.

I believe this grouping is more helpful to explain differences.

https://student.brighton.ac.uk/mod_docs/cmis/past%20papers/c...

You wrote students, while I meant professional programmers. It's not because some people have a tougher time learning those things (whatever the reason can be) that they have no change to get them by the moment they are active professionals.

This said, if I tried to apply your grouping to the people I have been interviewing last year, I would have approximately 100% of them in one category, hence my comment.

Because they are shown examples, instead of taught how, people memorize how to do stuff, instead of learning it from principles.

Take the classic question, recursively reverse a linked list.

You will see a lot of people making false starts, or trying to reverse the list in some way like they would reverse an array, or even repeatedly walking the list to the end.

But if you understand some simple rules about recursion, it's fairly easy to figure out how to do this on the fly. And that is so much better then memorization, because you can explain why you are doing things.

first you are reversing, so you're moving backward, which means you calls your function, then do assignments. If you were doing something moving forwards, like printing in order, you'd print first, then call the function.

Now we need to worry about the end, and the beginning.

First, the beginning, which happens after we have recursively walked the list.

Now, we want to walk to the last node before null, and we need a place to store what we return. so assuming we have something like this in c 'node * recursivereverse(node * current)' and a node structure with next as the next link (we never touch our data)

our test is if (current->next) node * newbeginning = recursivereverse(current->next); else return current; //some assignments go here;

return newbeginning;

Then we just need to figure out the assignments.

Now, people may get tripped up and try to use the new beginning... but then they have to walk it to the end... but the current node already knows the node that comes after it.

so we assign current->next->next = current; IE the node that was previously after the current node now points to the current node as it's next. And that's fine for all the rest of the list, until we get to our original beginning node. We need to worry about the new end.

Since it's going to the end, we need to point it to NULL, otherwise it will point to it's predecessor, meaning we'll have an infinite loop at the end of the last two nodes.

Easy way to deal with it is to just assign the next of the current node to NULL, for each node.

so we add to current->next->next = current; current->next = NULL;

and then you have a reversed linked list. This makes certain assumptions about the list (like it has at least one node, and isn't circular), so don't just copy this for your interview.

So with some simple rules, I figured out how to reverse a linked list. But those simple rules aren't taught, or at least, I came up with them for myself after I became a computer science tutor at my college, because I needed people to understand recursion.

So I guess my point is, it's not that people can or can't understand recursion, it's whether they are taught to think about things in the right way.

Now to a certain extent, we need to teach people to generalize, but if you teach people a general rule (always worry about the beginning and end of any data structure, and that's important for everything, including memory management and debugging) and a recursion specific rule (call the function first to reverse, call the function after to use the current order), and they can generalize.

Too often people come to program with the ability to copy code and get it working (and that isn't anything to denigrate, because it's not simple), but lack the understanding of how to think about things in a deeper way.

static MyLinkedList<T> ReverseLinkedList<T>(MyLinkedList<T> linkedList) { if (linkedList.Next == null) return linkedList;

  var newTail = linkedList.Next;
  var reversedList = ReverseLinkedList(linkedList.Next);
  newTail.Next = linkedList;
  linkedList.Next = null;

  return reversedList;
}

In my mind, a link list is a bunch of nodes with arrows pointing right. To reverse the list, all I need to do is point the arrows to the left.

6(ish) lines of code later, and I've got a recursive reverse method.

Probably because this is similar to the Linux kernel programming style. Many of us learnt C from the kernel or projects that follow it's coding style.

  perl -pi -e 's/^(\t+)/"  " x length($1)/e' recurse.c

If that statistic is true, I would say that they probably understand algorithms very well, can prove the runtimes, know which data structures to use and why, etc. What they can't do is actually implement it in working code, or write anything else outside of those concepts, like writing a graphical user interface or writing a simple website using some popular language + framework.

When start-ups, profitable ones, are offering £35k + bonus + stock options (worth £0), for senior developers, in Central London, there's not a talent shortage.

Similarly skilled developers are getting £35k+ & bonus outside of London, where the cost of commuting/living is significantly cheaper, in established companies with full benefits packages, that don't expect them to work 50 hour weeks. Inside London, those devs who are working in finance are getting paid £45k+, big bonus, gym, laundry, etc. thrown in, with the same workload expectation.

Experienced (and good) Senior iOS developers in London are regularly being offered less than £40k.

No surprise many talented staff have left London, for equivalent salaries, less stress and cheaper cost of living (especially as they hit the age where kids appear in the picture).

No surprises many younger devs look at the £25k starting salary in London, where transport and rent will cost them £1000/month, vs. £25k out of London, where it will be more like £500/mo, and decide that London is not worth losing £6k/yr after tax.

While there are certainly companies trying to hire iOS developers at 40k, there are also companies trying to hire iOS developers on 80k+ and iOS contractors on day rates of £500/day.

What you're probably seeing is selection bias. That is the crappy jobs (i.e. low pay) stay on the market far longer than good jobs. Hence you end up thinking that crappy jobs represent a large proportion of the job market than they actually do simply because they stay around longer.

But if I go and search: http://www.technojobs.co.uk/search.phtml?page=2&row_offs...

You will see most senior dev roles advertised with a range, that seems to average out about £45k. That's for the whole country, and London seems no different.

Personal experience with London based recruiters was that despite jobs advertising £60k, the number that the recruiter had from the client was actually lower. When asked about the requirements for getting the top end of the pay scale, "Well, they really only want to pay low 40's", was something I heard time and time again, and caused me to not apply, time and time again.

Crappy jobs? Maybe.

EDIT: Also, I've seen an expensive corporate salary survey (shh, don't tell HR), and whilst London mid-senior people have seen a good bump to their salary in the last 2-3 years, the averages there were approx: junior ~£28k, mid-level ~£36k, senior ~£47k, architect ~£60k, dev lead ~£72k).

As someone working in finance in London, this seems way too low. I'm on 97K and bonus has been 50% for the last 4 years. Contracted before and made more after tax.

I can't believe that startups hope to attract talent with 35K + bonus? But I also doubt you're right about 45K jobs in finance being anything but entry level.

http://www.itjobswatch.co.uk/jobs/london/c++%20developer.do

(me? c++, perl, python, unix, front office, could price an option with Hull open, or an IRS, but not going to try anything like a Vol swap without Quant Assistance. There, another vague datapoint).

That's before you start looking at contractor rates...

http://www.technojobs.co.uk/search.phtml/php/searchfield/loc...

There are a few above 40, but they don't sound mid-level/generic.

All of the people that I know who work in London (not just in banks) are earning at least £35k+, almost always more than that. These are newly graduated developers, with lots of room for advancement.

Conversely I know very few developers outside of London who are earning close to £35k, outside of London its much more likely to be research (ARM etc) and they tend to pay ~£28k

Most grad jobs in London will top out at £30k.

http://www.technojobs.co.uk/search.phtml/graduate-developer/...

Those that are higher are not real "junior" jobs - there's one that advertises "up to £50k", but then asks for 3-5 years experience. 5 years good experience puts you at the top end of mid-level.

There are a few finance jobs, that are looking for junior quant. developers. Yes, they are advertising above £30k. But they don't make up the bulk of the jobs on offer.

(And yes, I have a lot of anecdotal evidence too, for outside and inside London, having spent my early years working for a company with offices in Bath/Bristol/Reading, and the obligatory London "HQ").

But to me, they are the outliers, of what is a market that is generally not paying much of a premium above outside London salaries (I knew some architects on £70k, waaaay outside of London, and many seniors on £50k + bonus).

And I didn't want to make the comparison, but yeah, these numbers are terrible compared to what you will find in the major USA cities.

You misread my statement. A competent mechanical engineer graduate attending college in the past 5 to 10 years has more CS experience and coding ability than most CS graduates. The talent shortage, as it were, comes from restricting your view to the CS and CE fields.

To review, this is what i wrote (emphasis added): "Many people, especially coming from an engineering background, have the requisite programming and computer science experience to do what you need."

I might agree if you change your statement to "Many people, especially coming from an engineering background and who have an interest in programming, have the requisite programming and computer science experience to do what you need."

what fractions of ME and CS graduates would you say are competent, out of curiosity?

I'd be very appreciative of any leads you could offer to top tier companies (FB, Google, Amazon, MS, mid-sized YC companies). My contact info is in my profile.

The school does do quite a bit to get us in front of people, but students also take the initiative to get intros. Many in the initial class went to start-ups.

This is the school: http://hackreactor.com/

> WE’VE GOT CONNECTIONS

> Breaking into the tech industry can be hard on your own. We’ll help you craft a portfolio, guide you through practice interviews, introduce you to companies at our hiring day, and walk you through your job application process.

Their connections have brought top-rate speakers from Heroku, Pinterest, Twitter, TapJoy, Coursera and others and the connections did get more companies in the door than we have graduating students. That list just doesn't include some companies that stuck to more conservative screening practices.

I commented here to connect with those seeking skills I and my classmates have to offer, not to solicit criticism from the peanut gallery. I love Hack Reactor.

No they are not. One would think it's easy to find smart people who can learn new things, but I've dealt with both young and senior developers (by senior I mean writing code 15+ years) and was amazed how most of them feel comfortable being completely ignorant of new technologies/libraries/frameworks/best practices/whatever.

I've met a rockstar the other day, and could feel him being the one I'd hire immediately. It happens once or twice a year for me.

You might not call them rockstars, but in my book, they are.

I don't know how to judge that comment.

It is true that if you take anyone who is competent and ask them to teach you something that they learned in the last year, they should be able to come up with something. If not, then you've likely got "1 year of experience, 15 times". However my experience of people who think that they can judge people in the way you are judging them will judge by asking random questions about random technologies. Which is basically rolling the dice - if the person is exploring the same things that you are, then they get the gold star, otherwise you are convinced that they don't.

Let me give you a concrete example. You ask me what my primary language is. Perl, but right now I'm doing a bit of work in C++. Now you know that I'm a dinosaur because I'm using archaic languages. But don't notice that I have actually programmed in a host of other languages, and at this point learning the latest language is not going to help me be better at what I do. If I need it, I'll learn it then.

You ask me something about promises and jQuery and I draw a blank. I never liked front end work, and I've been working on back end stuff for the last decade. Boom, I'm a dinosaur in your books. But ask me what I'm reading, and you'll find out that I'm working through a book on hierarchical Bayesian modeling. I've also been doing some thinking about how people fail to understand the statistics behind A/B tests, and have been working on a series of articles that a lot of people seem to like.

In short, it is likely that you would quickly judge me poorly. Yet I believe that this reflects more on your judgement than my abilities.

Coders have misconstrued fizzbuzz into a whiteboard pissing contest because they want a binary yes/no interview framework... But that causes them to miss the forest for all the trees.

So at the end of the day, it's not really about experience, it's the attitude.

I only know "Promises" because I saw that on HN recently. However the concept behind JavaScript promises is one that I've seen before (I first saw it buried in a sideways way inside of http://search.cpan.org/~karasik/IO-Lambda/) and the name "promises" already has a spot reserved in my brain for their use in infinite streams. Therefore if someone mentions JavaScript promises to me again in 6 months I'll draw a blank.

There are some code samples linked in the articles in http://elem.com/~btilly/ab-testing-multiple-looks/index.html if you want to look. I wasn't writing that code for anyone except myself, so it isn't particularly pretty. (It did get the job done though.)

They are probably equally amazed that you are not able to discriminate between fads and/or half-assed rehashes of decade-old technologies and actual new technologies.

You should hire someone if they will create more value than it costs to employ them. That's it. It is irrational to do anything otherwise.

So many SV companies seem obsessed with creating islands of purity.

I've spent the last 3 weeks reading documentation around qt 5 in preparation for some 5.1 mobile development I plan on doing, for example.

(In case you thought these issues didn't affect you: http://bugs.python.org/issue13703)

First and foremost, it's fun for anyone interested in engineering to begin with. Second, for programmers, it gives you a tactile experience of programming, and a real respect for what Assembly language really is and what it does, why a compiler is important, how interpreted languages are run differently, and why optimizing your code is important.

You will never know the direct effect that this secondary understanding will have, but the unknowable effects here will be wholly positive, I guarantee it.

I remember one semester in college where it clicked for me... I was taking CS61C, machine structures (basically learning C and how it translates to Assembly) and EE40 (basically learning electronics and how silicon works, and how processors work at an electronic level) and suddenly I understood at least on a basic level how everything worked. The code you type in gets compiled to ASM which gets loaded into memory which the processor loads instruction-by-instruction into registers which are represented by the states of transistors which are loaded each clock cycle by the switching of voltages on a germanium-doped silicon plate which causes the voltage to swing at a certain predictable speed at a given frequency which is controllable and engineered to tolerances which put the whole thing in sync. Holy shit. And each part can be understood in isolation, combined, and it makes sense. It's engineering at its best—break down the problem, understand the tolerances, rinse (with a HF acid wash) and repeat. No single part of it is beyond the realm of understanding, but together they build a system of such complexity, and it's amazing and beautiful that it all works as well as it does.

Knowing this—yes, it makes me think about programming differently.

Because, yes, I'm relatively comfortable not caring about technologies that will return to complete obscurity within 6-18 months.

That seems like a pretty low bar.

I consider it a low bar to have repositories on GitHub or answers on StackOverflow yet the fact is that in London this group numbers in the thousands. This isn't all of the talented people but it gives you an idea of the rarity.

The answer makes that into a complex statement, and if your company can solve that problem, then it has solved a great many problems.

A lot of this coming from being able to expect/plan for future enhancements/changes than the one-off output. My own personal reference with this comes from managing several projects with local and overseas teams with varying degrees of experience.

Exponential effectiveness can only come from improving maintainability, readability and reducing code size. Fact that minimalistic approach also diminishes original development time is only a minor side effect. By the way, a true rockstar developer most of the time reduces code size and improves readability while adding features.

So when you see next time a commit, that adds features and reduces code size, - you know who you are dealing width.

My manager is very similar--his mind works about twice as fast as mine, and he's very productive. He'd never, ever call himself a "rock star" though.

Edit: It is especially weird when the post then refers to people with an engineering background, since those people are more likely to be working on low-level embedded coding.

The first part of the story is convexity, also known as the "10x phenomenon": http://michaelochurch.wordpress.com/2013/03/14/gervais-macle... . This is generally a good thing, but it's bad in the context of rapid scaling (which is what most VC-funded startups are trying to do) because convexity creates a need to fill specialized job queries fast. In a saner world, companies could hire a generally smart person and give her 6 months to train up. Most VC-funded startups either can't afford that, or don't think they can. They want "plug and play" and that necessitates purple squirrel queries, which creates a job market that leaves them just as unhappy as employees.

It sucks for both sides, but the upshot is that when you get a job, you're generally paid well (perhaps to compensate for the wonky purple-squirrel queries, companies going out of existence, and high turnover).

Incidentally, as bad as our job search latency is, I think it's worse for regular managers at the same pay level. In managerland, the going assumption is that it takes 1 month to find a new job per $20k; for us, it seems to be 1 week per $20k if actively searching. The biggest mess for us is the stereotype that makes active searching dishonorable because "good developers never look for jobs" (which isn't true).

The reason for the Resume Blizzard is that it's free to send one. It also gives companies the right to indulge in the myth that they're hyperselective because "we only give an offer to 1 in 500 candidates". It's technically true, because 485 of those were resumes merely scanned for some bullshit reason to reject (e.g. last job was too long/short, state undergrad, lack of buzzwords).

Here's an idea that I had: an online-ed website where you get credits for completing coursework, and sending a resume has a non-zero cost in credits (which is refunded if unopened). It's the best way that I can come up with to make front doors work again.