| > A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one. Most job listings I've seen don't really have that many hard requirements. They may mention technologies you'll be working with or things they'd like to see, but that shouldn't stop you from applying if you don't know them all. Take this with a grain of salt because I've never done resume filtering, but when I interview someone, I look at their resume and ask them about the things on it that I also know. (And I'll decline the interview if there's no overlap.) So for my stage in the process, the optimal strategy is to put the things you're best at on your resume, even if they're not listed on the job description. You get to pick what we talk about. For the most part I'll assume that if you've mastered those things, you can master the things we're looking for too. (Subject to some constraints: if there are four interviews, they shouldn't all be about the same things. So each interviewer might be assigned a broad area to discuss or have to write down their questions/area before the next interview starts so the next interviewer can pick something else.) > "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN. I look for a core concept or two for each area/technology and ask about that: * For SQL, that definitely means join. If you don't know how to join two relations, you should learn or take SQL off your resume. * Likewise, for C/C++ I want to know that you understand memory safety. Who owns memory across an API boundary. * For algorithms / data structures (a likely main topic if you're a recent CS grad), that for a simple problem you can use the best basic data structure (array / list / heap / balanced tree / hash table) and tell me the time and memory complexity in Big-Oh notation. > Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything. That's not the sort of job I do or interview people for. I have no idea what interviews for that kind of job are like. But if you're not doing sophisticated SQL or algorithms, surely you're doing something with your time? What is it? Can you emphasize it and sell it? > The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow. That's not a problem with interviews; it's a feature. Why should someone want to hire you if you haven't been growing? Or if they do, why should they want to pay you as if you were actually gaining experience for those years? I'd be looking for a better job the whole time. |
Do it long enough, and you learn how to make almost anything from nothing.
And that should be considered an employable skill....