Dear HN "Who's Hiring" responders

If it sounds like I'm complaining, it's not because I'm frustrated, but because it's slightly offensive to see that being demanded. In my experience, their internal recruiters monitoring inbounds are usually ringing me before my finger is even off the send button. They don't seem to look for or care about a cover letter, and I haven't had trouble getting offers, even from top tier companies. And honestly, I don't even think I'm that impressive. From what I can tell, anyone who has fogged a mirror at a half-respectable tech company already will at least get a phone screen these days.

When I was previously involved in hiring, I don't recall ever seeing cover letters on inbounds either. When asked in person by potential candidates, I always told them not to.

The average time of inspection of a resume is 15 seconds, so it seems it's a two-way street.

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

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

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.

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.

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.

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.

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.

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/

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

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

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

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.

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

a) Hello, you do Python, do you want a job? (with no position details, salary, reason to join, etc.)

b) a) followed by a clumsy attempt to fish details of my contacts (I don't connect with recruiters).

So, er, yeah - "Ha ha, profession!"