1. 12

I’m a few years (6) into my career now and I’ve learned a lot. When I go looking at potential new jobs, I read the description and think “yeah I can do all of that no problem.” Then comes the resume review and interview and I go through the same process each time, describing the same things on my resume[1] and website, hitting all the job description bullet points. But this doesn’t seem to work very well.

My question is: what are some of your experiences proving to employers that you are ready for an upward career move? For example, going from software developer to senior developer or architect.


[1]: I’m thinking a portfolio with executive summaries of projects (like artists and photographers have) would be more effective than a resume. I swear every interview I’ve had, it’s like the interviewer didn’t even read my resume.

  1.  

  2. 14

    All of my upward moves have been internal, and of the form “well, we agree that I’ve been doing the job pretty successfully; let us make my title match what I’m actually doing”. IME, seniority is as much taken as it is given. (Not sure to what extent my experience is typical.)

    (E.g. if you want to lead, mentor an intern/junior/…, or arrange to lead a small low-stakes internal project; if you want to architect, shadow an experienced architect, provide designs for your own components, and/or propose important refactorings; etc.)

    1. 7

      IME, seniority is as much taken as it is given.

      Bingo. Show initiative in a polite yet assertive way, deliver results, and talk about those results to the right people.

      1. 4

        seniority is as much taken as it is given

        This sounds like good advice. Perhaps it is more applicable to intra-company movements than moving to a new company. Hiring markets are probably be more efficient than intra-company hierarchies; that is, internally companies could be stifling a lot of value by not helping juniors move into seniority, and this inefficiency can be capitalized on by just taking the responsibilities of seniority for yourself.

        1. 3

          IME moving between companies is always where you move up

      2. 7

        There’s two sets of issues:

        1. The job requirements listed in most job postings are technologies, even though that isn’t really what the company is looking for.

        2. Most resumes omit huge amounts of relevant information, and again often overfocus on technologies.

        To become a senior developer you need some technical skills, but also to be able to work independently. That means being able to scope a project, know when to ask for help, prioritize, learn new technologies on your own, etc.. Almost no one puts this on their job postings because they can’t quite articulate it; instead they put years of experience or random list of technologies they use, conflating “knows this technology” with “will get started on this quickly/can operate independently”. Not the same thing at all.

        On the resume side, often it’s “I did a thing!”. You also need to give context, why this thing was needed, and outcomes, why this thing was useful. And also there’s some stylistic stuff like, yes, no one reads the resume, they skim it at best.

        So you need to make really sure it shouts INDEPENDENT WORKER YES I CAN WORK INDEPENDENTLY at the top, and it’s not buried 3/4 down the bottom of the page as an implied side-effect of a project scope that isn’t actually clear because the person interviewing doesn’t work at your company and so has no idea how impressive the thing you did actually was.

        If you can share:

        1. The skills you’ve seen listed, where you’ve said “I can do this!”.
        2. Your resume.

        then can probably give specific advice.

        (I write a little bit about this here - https://codewithoutrules.com/2017/07/16/which-programming-skills-are-in-demand/ - but I should probably do a “here’s how you write a resume” blog post, since I have Opinions.)

        1. 2

          Yeah I subscribe to your website, really enjoy the articles :) I’ll PM you my resume info. I was hoping to learn other’s experiences in this thread, not ask for unsolicited career advice.

          1. 1

            BTW, from your blog post:

            Learn the problem solving skills that employers will always need. That means gathering requirements, coming up with efficient solutions, project management, and so on.

            Learning these skills is one thing. Demonstrating that you’ve learned them is another. Hiring managers don’t just want to see “project management” listed on your resume, they want to be sure that you can actually perform those skills (after all, their hiring decision is a multi-thousand-dollar bet on you, they want to be sure that their bet pays off). Could you speak to some techniques one could use to demonstrate these skills?

            1. 2

              I’ll try to write a some more when I have time, but here’s a quick example on the resume level. Let’s say you’re applying to a job where you don’t know the technology stack. And sadly it’s a cold application with no one to introduce you. You’re sure you can do the job, but you need to convince them. So:

              • You probably want to say “I can learn new technologies quickly” in the first paragraph or two of the resume, because otherwise they might just skim your list-o-technologies, miss the thing they think they need, and drop your resume in the trash.
              • You also want to give a concrete example.
              • You want to demonstrate that the skill had real business value.

              So e.g. you can have opening paragraph or bullet list at the top of the front page that has bit saying “I can learn new technologies quickly, as I did at a recent project where I fixed a production critical bug on day one, even though I hadn’t worked in Java before.”

              1. 2

                As someone who is at a startup that’s currently hiring, I when I’m skimming a resume, I’m looking for experience, not skill lists.

                You can say “Project management” on your resume. But it’s far better to say “Was project manager for project x, successfully handling cross-team portions y and z. Project x shipped early and under budget”, and show me that you’ve managed projects.

                If you want to convince me that you’re a senior developer, your resume should reflect that you’ve been doing the kind of work that people expect from a senior developer. Leading projects, mentoring more junior colleagues, shipping major features, etc.

            2. 3

              I swear every interview I’ve had, it’s like the interviewer didn’t even read my resume.

              Some will, some won’t, and some will ask you to basically read it to them at the start of the interview (the ol’ “walk me through your background” gambit). It’s up to you as the candidate to be ready to talk about any part of what’s on there or in your experience in any level of detail and in line with the professional image you’re trying to project in interviews. You should have patter prepared for a quick overview of your background, an in-depth walk through your resume, and some specific things you learned at each step along the way. This is in addition to all the usual stuff you need to be ready for, including specific instances of a project failing, a time you delivered something late, how you handled a conflict at work, a time you disagreed with your boss/team, etc.

              The proof, as they say, is in the pudding. You shouldn’t offer a specific thing to say you’ve “leveled up skill x”; what they’re looking for is the whole package. They should be assessing your specific skills as they apply to the job and holistically judging how you are to work with, how quickly you learn, and other soft skills/qualities. If you’ve “leveled up” in any areas, it should be reflected in those assessments by you coming out in the top tiers of who they’ve interviewed for those skill sets. If the position is for “senior Javascript engineer” then they’ll probably have exercises, whiteboarding, a take-home project, or other direct tests of your JS knowledge. That, coupled with your soft skills (a senior dev often needs to work independently, be very organized, a self-starter, can train junior folks, etc) will inform them how ready you are for the position.

              To prove these things you need to have a history of these skills, a readiness to learn/do more within each one, and be able to sell yourself on each quality during the interviews. In junior positions, be on the lookout for opportunities to take on more responsibility. I’m sure that, no matter where you work, there are many of them – there never seems to be a shortage of tasks that other people don’t want to do or don’t feel like learning much about. Take those on and soon you’ll have lots to talk about in interviews to show you’re ready for greater challenges.

              You gotta grind like everyone else who made it. It can take applying to dozens of jobs that you are sure you’re a perfect fit for to find a place that will take a risk on someone trying to move up.

              1. 3

                I am pretty convinced that it’s the wrong question to ask. You don’t “prove” anything to your prospective employer, because it’s not a University exams, and a job is not a favor. You come to an interview with the skills you have, and it’s their job to find out if they can use them. If they don’t it’s either because they simply don’t or they failed to recognize those. In both cases it’s not a candidate’s failure, you just go and look for another company.

                (Unless of course you really don’t have any useful skills, but from your question it doesn’t seem to be the case :-) )

                1. 1

                  I think the virtue of this advice is that it enhances the confidence of those who believe it. You don’t internalize the rejection so you are more confident in the face of future adversity.

                  I know that I internalize that rejection as a total judgment of my abilities. It’s easy to forget that interviewing is a game of imperfect information for both sides.

                  1. 1

                    You make a good point and I will certainly keep it in mind, but as a principle I don’t particularly like burden-shifting. The stoic in me wants to figure out how I can make something better.

                    1. 2

                      You’re in a bad position for that, however. Because no interviewer/recruiter is going to give an honest answer why they don’t want to hire you (even when they could). So you can’t really make an informed decision and learn from it.

                  2. 2

                    I can think of a couple of stumbling blocks that might be in your way. First, how are you getting the leads in the first place? Are they coming from personal connections and referrals or are they from job boards? Your interview experience sounds like job boards. Personal connections can give you a “warm introduction” that pre-positions you as an advancing professional before you ever walk through the door or send in a resume. Friends and mentors can be a good place to start.

                    Second, your resume may be “coded” toward lower level positions. There’s a certain way of describing projects that emphasizes the strategic or large-scale work versus detailed work. Fair or not, people expect that detail work equates to entry level whereas work described in terms of its business impact equates to senior developer or architect. This also goes for “work on tech” versus “work on people.” Senior developers, tech leads, and architects spend as much time teaching, guiding, and mentoring the team as they do implementing the code.

                    The truth is that every position involves a combination of detail work and high level. People and code. But how you express those positions on your resume makes a statement about where your personal focus lies.

                    1. 2

                      In one case of going from engineer on feature X to tech lead of feature X I demonstrated ability without knowing I was being tested for this role from the start. The existing tech lead was having health problems effecting their work and my hindsight read of the situation is that management wanted to fire them but was not comfortable with the risk of doing that before identifying a replacement. So I was brought onto that team and of course was not informed of the situation, so I was unaware. After a few months when it was clear I could handle the technical aspects and teamwork aspects, management promoted me. Of course this was not across companies, this was within the same company. Definitely easier to go up in the same company and making lateral moves between companies should not require any special proving.

                      1. 2

                        And just for more concrete data, at one point my next direct technical move up would have been to a formal title within BigCo that was about 7 defined levels above entry level and 1 level below “Fellow” which was a terminal level for folks with a suitcase full of patents, buildings named after them, etc. That role had very specific and fairly stringent requirements that were well documented. If I wanted to pursue it, BigCo made it very easy to understand exactly what was required and how to go about it. Again this is for internal moves.

                        1. 1

                          Thanks for sharing, I appreciate it and it teaches me a lot. My experience at a medium-sized company has been much the opposite unfortunately: it’s very hard to understand what opportunities are available and what the requirements are. Perhaps this fact is the most telling :)

                      2. 2

                        If you are getting to the interview, then your resumé is doing its job. As the seniority of the positions you apply for grows, the usefulness of that document tends to shrink, leading to other aspects of the job application process taking on more importance. So I would focus on what happens after the resumé is reviewed: the interview itself. When you say “doesn’t work very well”, what do you mean exactly?

                        Once you are in the room (or on the call) for an interview, worry less about the job description and focus more on showing the person you are talking to that you are great to work with. It depends on the company, or course, but in my eperience job posts say things like “n years of experience in technology x”, but what people are looking for is an ability to communicate well about technical topics, be honest about not knowing answers to questions, and ask insightful questions about what is important. This stuff is often not in the job description.

                        When interviewing a person, I don’t really care what tools or languages they’ve used, or what the high level descriptions of the projects they’ve done are. I am looking for:

                        • Can this person translate a technical problem into language that can be understood, both by someone familiar with the technoligy and someone who isn’t?
                        • Can this person reflect back on what worked and what didn’t on projects?
                        • Do they get defensive when challenged?
                        • Can they describe a time they worked out an issue where they disagreed with someone else’s opinion? How was the situation resolved?
                        • Can this person identify what is relevant in a certain context? For example, if you’re asked to go through your experience, don’t walk through every job you’ve had and explain what languages you’ve used at those companies. You want to say something like “my background over the past n years is mostly full stack development, typically Ruby on the backend and an assortment of JavaScript frameworks on the front end. Before that I did…” Then focus in on particular roles that you can talk about in depth: projects that had interesting problems, where you learned important lessons, or that time has given you insights on. Remember, your resumé was good enough to get you to where you are now and has served its purpose. You don’t need to talk about every job you’ve had. Spent the limited time you have in an interview talking about what best presents your abilities.
                        • Can this person verbalize why they want the job?

                        In terms of getting a higher position, you need to be able to say “I haven’t done this specific thing before, but I have this relevent experience that shows I have related skills. I am confident that I can take the additional responsibility on.” As others have mentioned, some companies prefer to promote from within. But a lot of people advance their careers by changing roles and companies at the same time.

                        One other thought is to think about what kind of companies you are applying at. There might be a mismatch that is contributing to your experiences so far.

                        1. 1

                          Context: Most of my career is at startups with a big focus on growth. When I’m hiring anyone (engineer, marketing person, whatever), the first thing I look for is the ability to learn. A simple question – in your last {job, project} what did you learn? The most interesting people to me are the ones who have clearly reflected on a past experience and have an idea of what they would do differently (and the same).