jlees

Sometimes, the goal of an interview is to get you to think about something you don't know. If you knew every answer to every interview question perfectly, what does the interviewer learn? It's quite enlightening to get out of that comfort zone and see whether someone pulls an answer out of their backside, honestly says that they don't know, or somewhere in between. I'm not saying all interviews should be like this for everyone, and I think interviewers should be very much aware if that's what they're doing -- which I think is less the case ("oh, the candidate didn't use a linked list but solved the problem some other way? 0 points!").

I also think that having a strong track record of contributing to open-source software says a lot more than the kind of job I had; I wish I had discovered and gotten really involved with a project like Python or Debian back when I was that age. Instead, I released game mods, which isn't too bad a use of your time if you find that sort of thing fun.

I quite like this site for an accessible, well-scoped intro with some good example code: http://guidetodatamining.com/

It felt a little like going back to college a couple of years after graduating, where a layer of nostalgia wasn't enough to disguise how much I, and the place itself, had changed. (Because college, like WoW, is a lot more about the people for me than the physical buildings.)

Others have posted links on how to meet UK startups. Perhaps there are meetups or conferences you can attend to get to know some startups, or look at the HN job postings. Startups are fun because there is more learning and challenge, things are often changing and you have to adapt to mistakes. But they have boring bits too. Being at a startup isn't a magic bullet.

Can you take on more responsibility in your job and challenge yourself in new ways? Investigate new technologies to create more efficient solutions to problems you are solving (e.g. continuous deployment, analytics, dashboards, code health, new frameworks, cross-platform development, asynchronous patterns, client-side apps...).

Perhaps your hunger for learning is a sign you should go back into academia. I felt similarly while working in the year after I graduated, so I went back to do a Master's. I think it was the right move for me, but it isn't the right move for everyone.

If you have the finances for it, maybe it's time to quit, travel for a bit, write, relax, and start coding for fun again. But eventually you might have to worry about money, so keep thinking one or two steps ahead.

Finally, another way to achieve fulfilment is to seek mastery elsewhere. Whether it's fitness, gaming, language or other skills, you can mark time at your job while expanding your mind outside of working hours. I had an incredibly boring internship and pretty much the only way I got through it was working on math problems and studying linguistics for fun during my lunch break and evenings.

Good luck!

For example, if someone starts a scene with "Isn't it lovely to be here in Paris?", I accept that we are in Paris, but I don't have to think it's lovely.

The takeaway from this to non-improv discussions is that I'm more aware of the fact that although I might disagree with the comment someone makes, I accept that the writer has that opinion and that they believe it to be true, and if I want to challenge any part of it then I'm going to have a much better time of it if I start from their version of reality.

I found https://www.mysliderule.com/ a while ago which seems to be the same kind of thing - might be worth checking out.

It depends a lot on the kind of project the company is building, of course. A developer platform vs a consumer app will have a vastly different need for such things. I work at a 10 person developer-focused startup and as an ex-PM with engineering chops, I jump between building the product itself, working on developer-facing stuff, and randomly helping out. I definitely wouldn't call myself a product manager at the moment, though -- if you really want that as your job title then you probably need a slightly larger company where you can take the reins on product from the CEO, while the CEO switches to focusing on developing the company itself.

http://twinery.org/

I was intrigued as to how one would even figure out the sequence of operations used to encode progress into a 'phone number'; a quick search turned up an in-depth report (http://www.dougbabcock.com/mtpo-passwords.txt) which doesn't appear to be credited in Allan's article. It looks like Doug used a password archive to figure out the steps as an exercise in cracking, which itself sounds jolly fun.

TalkBin (YC W11) was a platform for allowing customers to SMS local businesses, but getting brick and mortar businesses to adopt a new communication channel isn't easy.

Plus, as one other commenter points out elsewhere in this thread, once you've been on the other side of the table for a while, you get a much better idea of where your own strengths lie (and what you're up against, which can instil a lot more confidence than you might think!).

One thing that I think separates senior engineers from juniors is a level of confidence and willingness to tackle the unknown and learn new things, tempered by pragmatism that they don't all need to be tackled and learned right away.

I wonder if the experience would have been different in the Bay Area due to the sheer number of folks in a similar position?

What did you do to get your head around it, if the docs are not so accessible? Just build stuff until it the pieces start to fall into place?