Hacker News new | comments | show | ask | jobs | submit login
Ask HN: How do you pivot your career when jobs want years of exp in a stack
178 points by milofeynman 6 months ago | hide | past | web | favorite | 145 comments
Learning frameworks and platforms through udemy and pluralsight. Side projects on github. What did you do to get a response back from jobs you've submitted an application to? Did you apply to junior roles when you were a senior in the other stack? Thank you.

Don't write anything on your resume that would indicate "number of years experience" -- list your jobs, explain key achievements, don't distill anything down to a number. Your resume should NOT explain who you are, or go into real specifics -- it's an advertisement for you, as simple as that. If they want details, they'll have to schedule an interview.

Once you have the interview, you can talk about your experiences, why you're a good fit, what you do in your spare time, etc -- they will not tally up years of experience or record your answers directly into an Excel spreadsheet.

Also, don't say you're "pivoting" your career. Just don't.

You're focused on the wrong thing. The resume comes way too late in the job acquisition process to really matter. The vast majority of jobs are filled through networking, not applying cold with a great resume.

You need to work on meeting people in your field, at the companies where you want to work. It's not what you know, it's who you know. Go out to meetups. Be a friendly, helpful person. Make friends, lots of them. One of them will make the connection for you at some point.

I still doubt the "networking" part.

I've got my first job in the states because a recruiter called me. Same for the second job. The third one was through being acquired. The fourth one, you could call networking if you call showing up for a recruiting event networking. 5th one? You guessed it, recruiter called. Sixth one? Yep. Exactly.

Before that, I worked in Germany. 1st job, applied cold. Second one, applied cold. 3rd one, applied cold. 4th one was working with a friend, so there's that. 5th one, applied cold for contract work, converted into a job. So half networked.

So, if we're generous, 2 out of 11 were networking.

As far as I'm concerned, work on the things you care about, build your skills, and when you switch jobs, make sure it propels you forward in some way. If you're a social person, by all means, enjoy meetups/meeting people because it's something that works for you. But don't force yourself to yet another meetup just because everybody says you should.

I still get recruiters randomly messaging me. However they're all looking for someone to move laterally, not up. This wasn't the case when I was more junior. Much like salary I find myself wondering if there isn't a limit to finding new opportunities without networking.

There might be. I don't know. I've been approached by recruiters, told them point blank "not what I'm looking for, here's what I want", and they just pointed me to those opportunities instead.

So I think part of the answer is clearly saying what you want. I don't know if that holds for positions like Director /VP at large tech companies - these are always somewhat political - but it seems to hold up to pretty much right before that.

YMMV, of course. For all I know, I accidentally have the right magic keywords in my LinkedIn or something. (I don't know. I only update it every few years, so I certainly am not paying enough attention to tell :)

”(...) they're all looking for someone to move laterally, not up”

That’s probably safer for them. IME many recruiters doesn’t really have enough knowledge about the role they are trying to recruit for, so it would probably be very risky for them to try to find a ”rough diamond” since they are not really able to make such a judgement call with high enough chance of succeeding.

> I still get recruiters randomly messaging me.

Define "recruiter".

People who recruit. I get messages from recruiters who are direct employees of the companies they recruit for, self-employed recruiters and recruiters for contracting shops. Probably a variety of others, too.

Interestingly I'm the exact opposite, of the 4 jobs I've had all have been through network, from the very first grocery stocking job to IT and product jobs.

When I hire the first thing I do is also reach out to my personal network to see if anyone is looking for work or know anyone who is.

My wife did just manage to land a job with a cold application, though, so it's not like either way doesn't work.

That's one of the benefits of recruiters in my book - they get paid to do the networking.

No, using a recruiter is nowhere near the same thing as networking. If you think this, you don't really understand what networking is about.

Did I say it was the same thing? If you think that, you can't read. But no, go ahead and use some of your obvious social finesse and let me know how the mystery of networking and its meaning has eluded me for the 50 years I've been alive. Ya punk. And then tell me how a person who contacts, and stays in contact with, many people at many companies, and many workers, in a certain field (a.k.a. a "recruiter") isn't doing networking for you.

Most of my opportunities have come from networking, including the longest, most prosperous role.

I always hear this, but I've never been hired through networking, nor have I ever seen someone hired through networking.

I suspect that to be more the case in very large companies. Luckily I have never worked in one.

Large companies are probably even less likely to hire due to networking - it helps more with smaller companies. I have helped gotten friends hired at companies I’ve worked at, and vice versa.

My boyfriend got his current job when my friend mentioned that her friend had the same degree as him and had mentioned the company was hiring, would he like to be put in touch? The company is about 15 people altogether.

I pivoted my career and got hired through networking (active attending meetups)

I've never not been hired through networking, and I've never worked for a large company. YMMV.

I'm working at a place where I don't know anyone who was hired except through networking.

Depends on what you call networking. Being involved (speaking), mentoring, reaching out to people in your social circle who have contacts in professional circles you're interested in, etc. Networking isn't showing up to a something posted on Meetup.com, grabbing a slice of pizza and a drink, and making small talk.

No, eating meetup pizza is not the whole of networking, but it's a very easy path that can certainly lead to the rest.

Of course, it's still a matter of initiative. You have to make those connections, not expect being on auto-pilot to result in a pot of gold.

I got hired in an industry (finance) I had no experience in after giving a talk at a meetup, then an 'interview' in a pub.

> they will not tally up years of experience or record your answers directly > into an Excel spreadsheet.

About half of my interviews started with an HR phone call where they spew their laundry list of technologies and ask me to disclose the years of experience and how do I rate my skills from 0 to 10 for each element in the list.

How do you typically rate yourself on these scales?

You can't call yourself anything lower than a 9 lest they move on.

I'm not the right person to ask. I've never managed to get a job that involved HR screening phone calls.

I usually rate myself from 7 to 8. Probably 9 if I have 5+ years of experience or I would be confident consulting.

Once I rated my skills as 10 for a technology I know quite a lot about. I was then told that I was showing off and that I need to work on being more humble.

Ouch. I think I'm starting to see why so many people get jobs through connections rather than cold applying.

They're testing for Dunning-kruger - either you're below average and you rate yourself a 7 or you're a 10 and you rate yourself an 8.

Good advice but as many are pointing out, many a times the job description will have some kid of "number of years experience" requirement. Even if it means asking for X number of years when the technology has existed for X-N years.

Ideally this should be the flow in having a job conversation. This will clearly lead to better fit for both the employer and the employee. Unfortunately, most of the real world jobs ask for some kind of number as experience, even though they know that the number does not directly translate into anything meaningful.

> they will not tally up years of experience or record your answers directly into an Excel spreadsheet.

They absolutely will ask for the exact years and months if you haven't listed them, and they'll think you're hiding something if you prevaricate.

> Don't write anything on your resume that would indicate "number of years experience"

So hold off on start/end dates at jobs then? Since those could be used to figure out experience?

>"Also, don't say you're 'pivoting' yout career. Just don't."

I tend to find such polemics unhelpful. Usually when someone tells me "just don't", I end up really wanting to know the mechanism behind what is causing such a stern warning.

For example, if I asked someone, "should I jump out of an airplane with no parachute",...

and someone says...

"just don't, because unless you have lots of luck and can defy lots of laws of physics, you will most likely be killed"...

then they have revealed a very clear and concrete reason, which strengthens their assertion of "just don't".

I see no such evidence for or against using the word "pivot", and I can imagine scenarios where the word even resonates with certain types of people.

Startups "pivot" because they failed in some way.

Pivoting your career can be construed as having failed somewhere and needing to find something else.

In the context of a career, phrase it as evolving your skills to match market demand. The very people who "pivot" resonate with will immediately associate it with failure.

Pivoting sin't because they've failed. It's because the path to their goal has changed or isn't what they previously thought. Basically, they're adjusting to new information (market, industry, etc) just like the rest of your definition.

Yes, it's an overused term but it's NOT a sign of failure.

I think this is bordering on a no true Scottsman argument, although maybe unintentionally. But whether that's true or not, I think lots of people take it as a euphemism for failure.

They are pivoting because they don't want to fail. They maybe made a mistake or the market changed, acknowledged it and took action based on this information.

For me this is not something negative at all

I agree with your comment except the last sentence. Negative or not, I think it's a poor choice of word to use in the context of a CV/career.

When interviewees are asked "So why are you looking to move from your present job?". Saying that you need a new challenge sounds very different than "needing to pivot".

it can be construed that way, but it can also be construed other ways. Perhaps how it is construed acts as a filter on who you want to work for.

^^^ This ^^^

I agree with you in general but I agree with parent about the use of the word pivot and its synonyms in this case. By using that word in an interview, you are signaling inexperience which the OP is trying to avoid.

This not only signals inexperience, it also invites questions on why did you decide to pivot (did you fail? any other negativity there?). This is not necessarily bad, you can theoretically use those questions to your advantage.

However, interview gives one a very limited time to impress. Better use it to discuss your strength and the future, not invite archeological queries.

The reason, at least to me, was implicit: Because the word itself is a signal of bullshit and is likely to raise flags for many people doing the hiring.

There isn't anything more concrete than that. YMMV. In this particular case, it rings true to me.

My thoughts exactly. Software development in general is a high-bullshit career, so I think anyone involved in either building software or hiring people to build software is going to have an extremely well-tuned bullshit detector.

Pivoting is the new failure. It casts you in a bad light, like putting a reason for leaving as being fired. Additionally, pivoting means you're trying something new, and this is less valuable than having experience in the job. It means you'll have to spend a lot of the employer's time (money) messing around, making mistakes, breaking things, etc - as is necessitated by learning.

100% with regards to "just don't".

Independent of that, I think using the word 'pivot' here is fine. We all know what he means. There might be a different word with a different connotation that some people may be more receptive to. But, pivot is well within the realm of reasonable words to use here.

What did you do to get a response back from jobs you've submitted an application to?

Round an unsolicited job application down to a no-op; this is not how the majority of jobs get filled. Instead, you should find someone with decisionmaking authority in the company, talk to them, and get them interested in you.

The "N years of experience" thing not a requirement. It is a polite fiction. It was put there by someone who may not even be associated with the team that is doing the hiring. But if you come through the front door, there exists a team of people who will aggressively filter on that fiction because if they don't filter on it then the larger organization will ask "What is it, exactly, that you do here?"

Your mission, should you choose to accept it, is to only have these people involved to schedule the interview that a decisionmaker has already committed to giving you and/or collect the resume that they need for their records now that you're hired.

Senior engineers applying to junior roles are selected against fairly aggressively. This is an unfortunate shibboleth, but it is a widely used shibboleth.

Senior engineers should apply to senior roles; the vast majority of hammers swing in approximately similar fashions and as you get more senior you're not being hired to hammer in nails-per-hour. You're (hopefully) doing things like helping younger employees understand the difference between screws and nails, pushing back on the person who asked for 100k nails on a house that has been uninhabited for 6 years, developing processes to avoid wood rot around your nails, etc etc.

Incidentally: Serious software shops are largely aware of this. If a company thinks that a Pythonista with 5 years of Python experience cannot be a Rubyist in single-digit weeks, that company is probably not a great place for software people to be.

Hah. Thank you for this post. You have a way with words.

I would focus on learning the stack/framework you want to find employment in.

Do an initial project creating an app to do something for you. Use that to try to find another project/app you can create for someone in your network as a freelance project. Become active in the community for that framework. Blog, write tutorials, reach out to others in the community to build relationships.

When applying for jobs I would list your job title, company and years. Then have another section for the languages/technologies you have used. I never match them up one to one. They will ask how many years experience you have with what they are using. With new frameworks a year to a few years is good enough to get in the door.

Becoming active in the community is going to open more doors than resumes. Once someone knows you and that you are capable it's easier to land a position if they can recommend you.

Good luck with your pivot.

Thanks for the insight.

The number of years thing is bogus. Just ignore it and apply. I remember seeing posts asking for more Rails experience than DHH himself has. Something like 8 years of Rails experience when Rails was only 6 years old. Those requirements are almost always written by some of the least competent people in the company.

Yup, agreed. On my resume I have a list of my jobs and the things I accomplished at those companies, and I don't mention tech stack or language unless it's relevant to the accomplishment. At the bottom I have a "keyword list" of the frameworks and languages I've used and feel competent in, without saying anything about years of experience. (I've found this is useful to get through the recruiters who filter by keyword.)

Just apply to jobs, and talk about what you've done, and how you did it.

This is great advice. I've worked on lots of different software teams, in various contexts (realtime, embedded, win32, web stuff, dev tools).

If I see an interesting position, I just apply. I know I'll get better consideration if something on my resume resonates with the hiring manager/interviewers. But if you are any good you should be able to adapt what you know to a new programming environment with new constraints.

It's important to remember that the people writing the ads aren't usually experts.

They are mostly worried they will get a bad hire, so they are looking at ways to eliminate potential negatives. They are in a risk reduction mentality. So it is safer to just eliminate candidates.

I treat the "we want people who know stack X" kind of thing as a "Here's what stack we are using" and nothing more. I don't lie and say that I know the stack, but I don't want to work for a company that doesn't understand that a good programmer can switch to a new stack in a very short time frame. On the other hand, you need the ability to pick up a new stack easily.

I hire contractors. I don't have time for people to ramp up on the job. I need them to come in knowing the stack we are working in.

If I were hiring full time devs, I would take a chance but I would expect them to meet deadlines as if they were fluent in the stack - meaning if they have to work weekends or more than 40 hours a week to be just as efficient as someone who knows the stack, they should do it.

I put myself to the sane standards when I'm an FTE. If the company advertised they wanted a proficient React developer for instance and I was honest with them about my lack of experience and I convinced them that I was willing to learn, I would make sure I produced 35-40 hours worth of productive work even if it took me 60 hours to do it.

I'm not putting in extra hours necessarily for the company, I'm doing it to further my own career.

Hiring contractors is a different, but if you skip over an experienced JavaScript developer for a W-2 position because they aren't familiar with React, you're going to miss out on a lot of great employees.

You'll miss out on people like me who refuse to play that game. I don't expect to be fully productive for the first few weeks on the job and I'm not working through the weekends to try to be. I also don't expect anyone I hire to be fully productive until they get familiar with our stack.

It's completely absurd to put the burden of training completely on the employee. Culturally we need to stop accepting this.

It's completely absurd to put the burden of training completely on the employee. Culturally we need to stop accepting this.

Why is that so absurd? Part of the culture in tech is that there is no loyalty on the side of the company or the employee -- I'm okay with that. The company can lay me off at anytime but I can also change jobs and take the skills I learned with me and probably earn a higher pay anytime. What incentive does a company have to train employees in that environment?

Much of what you learn to get up to full speed doesn't directly transfer and is more beneficial to the employer than the employee.

>What incentive does a company have to train employees in that environment?

The normal incentive is access to a larger employee pool and cost. You have access to a much larger group of applicants if you're not looking for 100% productivity on day 1.

Also if you are willing to spend a bit of time training your employees, they are less likely to leave. Give them raises equal to what they're worth on the open market and most of them have no reason to leave.

Reducing employee churn is worth a lot of money. No employee is anywhere close to 100% effective on day 1, and from experience, training goes a long way towards improving employee retention.

Not providing training because you're afraid an employee will leave sounds a bit like a shop owner who is so scared that someone is going to steal a few pieces of candy that he locks down his store so tight no one wants to shop there. Sure a few people will take your training and run, but that's just the cost of doing business.

I work as a contractor and that is kind of similar to what I do. If I have to use a new tech (an important one in the stack but not the main one) I will normally invest 5~10h of my time pre-anything in learning the basics of the stack.

Then if I get stuck at something I'll try to fix it first, then learn more about the stack to see if I'm missing something basic and finally ask for help. These go normally for free if it's because of my lack of knowlege; otherwise I'll charge for them ofc.

I've also found out it's quite important to explain this to whoever is hiring you. That way they don't feel cheated on (money) nor like you are slacking off and working only X hours instead of 2X per week.

PS, your comment sounded quite negative/exploiting, probably that's why the downvotes.

PS, your comment sounded quite negative/exploiting, probably that's why the downvotes.

How is that "exploitive"? When I'm contracting I always get paid 10 -30% more than I could get as an FTE all in - even if I include the cost of benefits, paid time off, the gap between employment, etc.

When they want me to work more than 40 hours a week, they pay me for more than 40 hours a week.

Companies don't hire contractors over FTEs as software developers to save money per hour worked. They hire them because they need to ramp up development fast and need the flexibility of reducing head count fast. The only difference between an FTE and a contractor in today's economy is that the company is honest about your expendability. As a contractor, you should charge a premium.

> "When I'm contracting I always get paid 10 -30% more"

From my experience (and quite a few people in a similar situation), as a foreign contractor I am making ~50% less money than FTE are making doing the exactly same job just because of the country I was born in.

I am not charging this learning time because I don't want/need to, but I would certainly not work with a company who would require me to do part of the job for free. However I am in a privileged situation where I can choose. Forcing an employee to do a not-in-the-contract learning for free is exploiting them (because they could have other needs to do in their own time, family, other jobs, etc). If they want to learn something on their own time that would improve their work that's great and definitely a plus, but not everyone can do that.

but I would certainly not work with a company who would require me to do part of the job for free.

If I'm hired as a React developer to implement a set of business requirements, they are hiring me to learn and implement the business requirements. They are not hiring me to learn React. If they hired me with the knowledge that I'm not a seasoned React developer, the expectation is that they will not be expecting me to charge them for my learning React as billable time. How is that unfair? My React skills increase my marketability and I'm investing in myself by learning it.

If a person is not willing to sacrifice to learn skills on their own time, software development is not the field they should be in.

I was replying for the situation that you mentioned of full time employees, with contracting I think we both agree.

> If a person is not willing to sacrifice to learn skills on their own time

That's what I mean exactly. They might not have free time! That's why you're supposed to work 40h/week and any extra is a plus, not a requirement. The same argument could be applied to any field, so should someone without free time just not work? That's why it's unfair to require that employees spend large chunks of their free time to learn how to do the company's job.

The same argument could be applied to any field, so should someone without free time just not work?

If you don't have free time to learn to keep up your skills in the IT industry, you won't be employable for long. It's not about fairness.

There are many companies that do care about their employees and let them learn during work time or even teach them themselves! I believe those are some of the best companies around the globe as well (;

Sure a company that is still writing software that is based on their tech stack would be more than willing to make sure that you know that. But what happens when the tech stack they are using becomes outdated?

> I hire contractors. I don't have time for people to ramp up on the job. I need them to come in knowing the stack we are working in.

Employers can bluster all they want; in the end, either they need to be happy hiring someone willing to work for the wages offered, increasing the wages offered and spending a lot more time looking (better wages gets you access to a larger pool, but it in no way chases away the incompetent, you still need to filter) or doing without the employee. As an interviewing worker, this means that you don't need to outrun the bear; you just need to be better than nothing, and better than anyone else willing to work for the same position. I've been working since '95 or'96, and personally don't feel I've actually been qualified to do any job I've had... but I'm better than nothing, and beating the competition is usually not very challenging.

As far as I can tell, the facts on the ground for contract work (which is to say, lower total comp than working as a FTE at one of the local big companies, lower job security, less respect, and generally slightly worse working conditions) means that when you are hiring contractors for a big company, you are hiring from a pool of people who are unable to get the same job at the same sort of company as a FTE.

As far as I can tell, the facts on the ground for contract work (which is to say, lower total comp than working as a FTE at one of the local big companies, lower job security, less respect, and generally slightly worse working conditions) means that when you are hiring contractors for a big company, you are hiring from a pool of people who are unable to get the same job at the same sort of company as a FTE.

Contractors making less and being less qualified aren't the facts on the ground at all in my neck of the woods. If you're making less as a contractor than the similarly skilled FTE, you're doing it wrong.

When I'm W2 contracting, I take what I think my yearly salary should be, divide by 1800 to allow for unpaid holidays, vacations, and 3 weeks to find a new gig and make that my hourly rate. I also add in a premium for the crap I know I'm going to put up with and the lack of benefits.

When you're contracting you get paid for every hour you work, if anything, being an FTE is more exploitive.


I guess I should add for context that I get benefits through my wife's very stable government job. That allows me to be more flexible with jumping back and forth between full time and contracting.

I agree that FTE's tend to get exploited more. Being hourly means that they usually don't want you to work more than 40 hours/week, and if they do, then you're getting paid for it.

Also, it's much easier to shirk the "ownership" aspect of the products. FTE's typically handle the maintenance window in the middle of the night, the deployments, the firefighting. And they don't get paid for it. As a contractor, it's typically accepted when you say "I'm just a contractor, it's really not my product".

Yes, it's much more of a mercenary type arrangement. FTE's will oftentimes treat you as a second class citizen. But, you go home at 5pm.

But, what about job stability you say? Nobody has that. Working somewhere for 10 years and then suddenly getting put on the street is the worst case. You're hobbled. Finding a new gig every 1-3 years keeps you sharp.

The biggest difference is not in how the FTEs treat you; I've never had a contract gig where I was treated badly enough to really care. The big difference is the prestige. Getting a FTE job at one of the top tier silicon valley companies is like having a degree from a really prestigious college. People will talk to you about your next gig who wouldn't otherwise talk to you.

I'm not in Silicon Valley, but I have been in a major metropolitan area for 20 years where jobs have always been easy to come by (with the exception of 2008-2011) and where stock options and bonuses aren't plentiful but wages are high enough for seasoned developers to allow you to easily buy a house in the 'burbs with good schools.

That would put your $90/hr contractor at $162K full time salary; and for base, sure. Base-wise, I'd expect a $90/hr contractor to come out closer to $150K if they converted to full time. But bonus and stock often make up another 30% or more in silicon valley, and you don't get that as a contractor.

This was actually the weird part for me, because I did some contracting around here in the aughts, and the pay was slightly better than fte work, but at that point, few of the FTEs I knew had significant bonus or stock grants. (You'd get options, just not RSUs) - as far as I can tell, this change to compensating developers with RSUs and bonuses is something that happened this decade; FTE comp went up dramatically due to bonus/stock, and contractor income remained competitive with base.

Of course, it's way different at smaller companies, or if you have the connections to avoid the body shops at larger companies, but smaller companies usually pay their full timers dramatically less anyhow, and if you have the kinds of connections required to go direct with the big players, being an individual contributor is probably not the highest value use of your time.

And I imagine things are different outside of silicon valley. Things are... very different and weird here.

Edit: oh also, 'similarly skilled' - I'm a contractor now, and yes, I get paid less than the FTEs I work alongside, I mean, I get slightly more than their base, but no bonus or stock. But... I'm also not similarly skilled. The FTEs doing my job are obviously better, at least by the standards by which we are evaluated. I'd give myself a 1 in 10 chance of passing a technical interview for a FTE job at the company where I contract now, and that is, uh, displaying confidence. My point wasn't that things are unfair; I don't think I'm being treated unfairly, aside from a few minor points, but that after the body shop takes a cut, there's just not enough left to pay enough to get people as good as what you get when you hire for the ridiculously well-compensated FTE positions at the larger and more prestigious companies in silicon valley. And the company matters; I interview often and just a few months back turned down a FTE position at a lesser company, for reasons having to do with pay, prestige, and trust.

Where I live, a good software developer can make between 120K and 145K as an FTE and easily bill from 70 - 80/hr as a W2 contractor. Bonuses and stock options aren't too much of thing either way. Maybe about 10-15% of compensation.

For contract work I can understand that mindset, but for FTEs that's incredibly short-sighted. I absolutely object to expecting someone new to a stack to spend crazy hours until they're up to speed. I see framework onboarding as equivalent to any other part of the onboarding process where a new employee figures out their new team's source code repo layout, build tooling, deployment process, etc.

Hell, even if you're using a framework that I'm intimately familiar with, most frameworks are flexible enough that it'll take a little while to get used to exactly how you're using it.

That's entirely your prerogative. If 100% productivity is expected first week, though, I'm going to make lots of assumptions about what management is like at your company, and not apply. But if you're not having trouble finding the engineers you want/need, all the more power to you.

"Being 100% productive" and knowing the stack aren't the same thing. If I'm willing to pay a premium for expertise and all of the uncertainty that comes with being a contractor, I don't expect them to have to ramp up on the stack and the environment - just the environment.

It's very big of you to be willing to pay overtime for new staff that way.

I invest in my staffs' intellectual equity too, but usually ask them to do their reading and learning on the clock.

Four suggestions:

1. Don't obsess over the specifics on an ad. See if the role is in line with what you have to offer, but don't worry if you don't have the exact number of years of experience they request or one of the many skills they added to what it's essentially their wishlist.

2. Provided you have a solid foundation with some standard skills like JavaScript, Python or Ruby, etc, specialize in a relatively new stack. No reasonable employer expects you to have 10 years of experience in Elixir or React.js. Note also that I used the word stack. You want to become competent enough to become useful to a team that adopts the same stack. Depending on where you live, you might go more or less niche in terms of the stack.

3. Start a blog and advertise the fact that you are looking for a junior position. Document your experience, post about what you are learning, what excites you, showcase your pet projects, etc.

4. Attend meetups. Let people know that you're available.

Re: #4. I currently live in a city that has virtually no tech scene. I work remote and my office is a thousand miles away. What are some ways to get a similar experience, but online? I don't particularly like social networking online (in person, sure!), so I've never tried looking into tech related social scenes.

I've been working remotely for ten years, in a city with a very small but friendly tech scene. A lack of local meetups doesn't always indicate that there's no tech scene, either - when I first started working remotely I was the only person I knew who was doing it, but just by being vocal about it I quickly found others. If there are no meetups in your field then starting one is a brilliant way to tick a bunch of boxes here:

- You will bring people out of the woodwork who are in similar positions, but haven't taken the initiative to start such a group themselves.

- You'll gain contacts in your scene, both locally and in other cities.

- You'll gain experience and profile that will help you in a search for remote work, as you can point to community engagement activities that say a lot more about your dedication than a couple of udemy courses in some particular stack.

If you really don't want to start a local group (or if there's no nearby community large enough to support this) then look for user groups with active online communities (mailing lists definitely count) and try to make some occasional trips to other cities for meetups and conferences.

IRC: get online and talk to people on freenode, the experience there covers both project related and social aspects.

It won't make your city any less dead, but if you get online and help people with what you know, and learn from others, you'll certainly make friends.

I found my last job via a meetup but am currently in the same position as you, which is what makes this a little bit harder.

Start your own tech meetup in said city.

Re #4: I was rejected for a job. The interview process included take-home work AND pair-programming.

One of the specific pieces of feedback I got was that my development style wasn't modern enough - with a recommendation that if 'your current employer isn't exposing you to best practices and new approaches you should attend some relevant meetups in [city]'.

My personal negative take on that was that meetups tend to concentrate on the latest fad. The interviewer could have gone to one meetup in a series and seen one talk/library/strategy that resonnated with him. I could have gone to the next one in the series, picked up something completely different, and still failed the interview?


> My personal negative take on that was that meetups tend to concentrate on the latest fad.

Or, in the case here in Seattle anymore, whatever the sponsor company is trying to promote.

2/3 of the meetups here anymore are mostly tech's version of timeshare seminars.

I have had great success with saying things like “I have 10 years of web engineering experience and have been looking into X for N years/months”.

Engineering skills translate well between stacks and framework/library skills are only good for a couple years. Can you break down a complex problem into estimatable chunks that can potentially be delegated as well? Can you design a system that solves a business problem? Awesome! Nobody will ask you about framework du jour.

Honestly I’d say that if you’re talking at the level of which libraries/frameworks you know, you’ve already lost. That’s junior/midlevel engineer stuff.

Senior engineers solve problems. Junior engineers code in frameworks.

Most code that’s used in production has so much custom stuff anyway that it might well be its own framework.

I guess I'm different in that I care that people understand the pluses and minuses of the various frameworks. I think anyone can pick up a framework or solve a problem. However, can they understand why and when to use x framework to solve a problem and back up why they chose to solve the problem in the way they chose to do it.

Additionally I want someone who can be passionate about the tech stack and frameworks they are using or plan on using. Otherwise, I've got a code monkey who may get things done in the short term but their code and problem solving abilities actually has negative implications in the future when it comes time for maintenance and to add additional features to things.

I don't understand why people label others who care about their craft and the tools they use as junior/midlevel. I think that's lazy. Many times there really is a best way to solve a problem or a best framework for your particular situation or problem. All engineers should care about the tools and what is being used and why it's being used.

I guess its just not enough for me to have an answer so much as to understand why its the answer and under what conditions assumptions can fail. To me that is more valuable when hiring someone who is switching careers than being able to solve a problem in a generic sense.

>I don't understand why people label others who care about their craft and the tools they use as junior/midlevel.

Because we’ve gone through 10 different frameworks already.

I’m not a jQuery engineer or a Backbone engineer or an Angular engineer or a React engineer or a Redux engineer or a MobX engineer or a Node engineer or a Rails engineer or a PHP engineer or a Python engineer. Yes I’ve used all od those to deliver real world projects that made money for my clients/employers, but they’re just a tool I use. Many such tools have come and gone since I started building stuff for the web in the early 00’s and many more will come and go before I stop. I love building stuff and I have a deep understanding of the web, but tools are just tools, they don’t define me.

Yes you want a carpenter with a good understanding of hammers and nails and you need them to know which to use when, but do you really want to hire a carpenter who identifies themselves as “Expert hammerer of 5 inch nails”?

Ultimately, if you are looking for an expert hammerer of 5 inch nails, I am not a good fit. And that’s okay.

> ...passionate about the tech stack and frameworks they are using or plan on using...

I usually lean towards the pro- side in arguments about passion for one's career but even I would have to say that's a rather dubious viewpoint. Tech-stacks/frameworks are the among the least important parts of a software engineering career; they're the means to accomplish the craft, not the craft itself. (And that's even if frameworks didn't go into and out of style almost as fast as the fashions in the clothing industry.) It would be like asking master chefs to be passionate about spatulas and whisks instead about creating great food.

Frankly, I think the most important thing is to have a good resume. Apply for jobs where you don't have all the skills, chances are they'd be happy if you knew half of the things they listed, but would be willing to learn the other half. (Don't even get me started on job descriptions asking for skills that don't get used later, this happens too frequently.)

Also, apply for jobs with different frameworks where you have experience solving their type of problems. That knowledge is much more valuable on a long term basis.

Ask questions like "are you actively making contributions to this framework?" If so, you probably want to know it. If not, just remind them that it will most likely take much longer to ramp up on their (non-public) codebase, but your skill is learning things and solving problems. If you're not employee #1, a lot of the framework plumbing is probably already done for you.

I second this.

I had good luck with suggested resume format of company project I worked on description, and what I did for them on said project. I put together a "portfolio" of screenshots of things I worked on with a description of what I did as some projects were behind a login and the public didn't have access (I created this graph of power usage using highcharts......)

highlight the problem solving skills.

I have to sort through a lot of resumes at my current job and sometimes I honestly can't tell what they worked on. If I sense enthusiasm, and some experience with what we're looking for, they go on.

As with the vast majority of jobs: network. Get to know people, you will get to know where they work, and they will get to know you and how you work. Eventually, if you just go through life as a helpful person, one (or several) of those people will make the connection for you, "hey, we need someone who does X. You do X, right?" You'll say, "yeah, totally, but when I saw that job listing, it said they wanted Y years of experience." And they will say, "well, I know you, you do great work, forget about that."

This comment seems to be downvoted which is disappointing, as this is one of the best pieces of advice here. Apart from when I was a fresh graduate, all of my jobs and contracts over the past 10 years have been from networking.

I'm definitely not a people person, and you don't need to be, you just need to keep up to date with what people in your network are doing. If there is anyone now in a management role, try to meet up with them for a coffee once a year just to chat. Maybe they are looking for someone with your skills (that's happened twice for me). I've also been in the situation where they aren't actively looking for someone, but knowing that I'm available and that I do good work they've made a position just for me.

I've only worked at smaller companies, so I'm not really sure how this would work at the scale of something like Facebook, but other than them having to navigate HR I don't see why it couldn't work.

It's a little annoying when companies put framework names in their job titles. Asking for a "react engineer" or a "boost programmer" will likely turn away a lot of people who would actually be a good fit for the role. My suggestion is to just be open with the company and tell them what you do know and how quickly you can get up to speed. Something like: "I haven't used React on a paid project before, but I have a lot of experience with other frontend frameworks like x/y."

Chances are that the gatekeeper won't know enough to be interested.

You have to get past ignorant gatekeepers. Do some google stalking to find out who's in charge of the team you want to join, and reach out on social media to let them know you'll be applying. Then include "so and so is expecting my application" when you send it to HR. Or something like that.

You should read this:


Patrick may have a skewed view of reality because of his experience but this (and his other posts) brings you in the right mindset.

Thanks for the read, it was... interesting.

Yes, you should get involved in technologies you want to pivot to and be part of the open source. And it doesn't mean just creating a quick hello world app and sticking it to your Github profile.

Side projects which are basically a "hello world" in framework X are not impressive so don't waste time with polluting your Github with N hello world examples.

Instead create something more substantial, either contribute directly to the library/framework which is core of the new tech or build some useful new addition to the ecosystem.

Write some blog posts along the way as you learn and become more and more familiar with the technology and different edge cases.

This, from my experience will get you a lot of interviews.

Also, during the interviews, don't say things like you are pivoting, instead tell them that you are expanding your expertise in a new direction or making a next step in your career. Or that you want to work with this new tech on a daily basis and this job would allow you to do that.

Try recruitment tests like this one https://triplebyte.com/ (read faq: https://triplebyte.com/candidate_faq) or even some remote dev factory type stuff like TopTal to start out otherwise you get that HR phone screen demanding your X years of experience with X stack.

Another method is find a company you want to work for, find where they keep open source projects, and work on them. When they have a job opening you'll be the one they contact usually. Databases, frameworks, Docker, ect are all good for this. Mailing lists and open source projects is how I usually get work and avoid the phone screen demanding X years of exp.

I appreciate BOTH of your points. Did not think about either of those.

Don't apply for jobs that have a laundry list of technogies you should be experienced in. Look for positions where they realize that tech will change every year and people will need to learn. That is the kind of place where they don't see you as replacable labor that needs to deliver on day 1 because they expect you to be gone within a year or two. Find a place that hopes and thinks you'll be there to see a few tech stacks come and go.

A broad technology such as having experience with "databases" or "functional programming" or whatever might be appropriate, but if an ad says "need N years experience with Framework-X" etc. then run away.

If your first contact with the company is a non technical HR person screening you for the appropriate buzzwords: also run away.

I think this is one of the most sensible replies. You only need to look at a HN 'who is hiring' thread though to see these kind of companies are pretty nonexistent.

This is probably true, but I think companies represented on HN's "who is hiring" is a very small subset of all companies. It's very tilted towards the US, and even there it's very tilted towards the startup scene.

You are a senior developer, so you have worked with other people. Make a list of them, see what they're up to. At least half of them will be at companies that are hiring. This is your shortest path to the job you want.


Specifically to get your foot in the door enough that they'll hear you out. If you're truly experienced and capable of picking things up quickly, it shows in an interview (at least when I'm the one doing the interviewing).

Unless you're a true gambler, better to omit than to mislead.

Nobody really cares the number of actual years you have just how well you know something.

In terms of not lying on your resume. Side projects/join a company/team that uses both your stack and what you want to use. Remember, your new company does not actually know how specifically you spent your time at your previous jobs. Was it 50/50 or 95%/5%.

Remember you can learn things a lot faster than n-years experience. So, spread that out over a few years and you do have n-years experience.

Take a pay cut and start on their stack at a junior position. With your experience, you should quickly be able to ramp back up to your own grade/pay level on that stack. Be upfront about your plans. There are companies where your manager can retroactively increase your grade/pay level based on a performance review. This way you are betting on your own abilities while reducing risk for the hiring manager.

What do you mean to pivot you career? It is not the same moving from front end development to backend development than from front end to data scientist. If the pivot is "highly overlaped" you can try to pivot in your own company, as it probably does both things. If it is something where your past experience means nothing then you will have to start from scratch for the new career. But probably you will progress faster because the way of thinking to solve problems helps a little. Also the experience dealing with people helps, as it is not the same to be a young developer who is eager to eat the world and probably highly unaware of his own skills than someone who knows the limit and how a company works.

When I did a small pivot in my career I basically had to start from scratch. So I sit by myself and start working on a project learning what I wanted to work for. Once I was a bit comfortable I apply to mid-level and junior positions.

I'm at a small, dying startup doing Xamarin mobile development and I'm looking to pivot out of xamarin/mobile and into web and data. I am learning online and doing a side project on github, but I don't have experience making this kind of transition. I've thrown on an infrequent job application not expecting much and gotten 0 responses. So I am curious what others who have made that sort of transition do to get noticed. My previous job I found through a local meetup, but it was a framework/language I was familiar with so they wanted/needed me badly.

Moving to web should be easier than data. When you do mobile development you do a little of front end and back end (I was Android developer before). Learning a high demanded framework would help in your case. Data will take more time but you can do it if you start as a data engineer developing the data pipeline. But in this case you probably should aim to bigger companies and be hired would be more difficult without experience. For web a small startup will be fine.

Thanks. Yeah data is a much steeper climb. I am going the web route(I have some experience here already) and will look for a company that does data as well, that way I can learn and get started a little easier.

What made you want to pivot from Xamarin? Did you find there is a lack of opportunities, or do you dislike the technology? As someone who is looking into moving to Xamarin development I'd be interested to hear your thoughts.

Xamarin Forms is a dead end in my opinion. I enjoyed writing non-Forms with a shared MVVM framework, but my job was in Forms. I also find mobile development to be too cornered. I was doing both platforms by myself with no room to grow as a developer. I spent too much time in Forms chasing down Forms bugs and trying to figure out why the latest version of Forms broke something new. So a bit of burnout as well. Hope that helps.

Thanks. I did get the impression when I looked at it a year ago that it was hastily put together to fill a market demand. Good luck!

I would just demonstrate that you can pick up a new stack easily by putting up some code on Github that uses the stack. It's not a perfect solution, but we have hired people before with no work experience in the stack we were using, but with Github code to prove they were comfortable with the tools.

I am going to write this from the perspective of a potential employer.

Personally, I don't look at the years of experience someone has, but at the projects that the person worked on and how good that person is at answering some technical questions (to weed out people that lie about their experience and knowledge).

If you are good at what you do, then have some projects to show your expertise. And there are a few options to get them:

1. help a non-profit for a lower pay or even for free 2. contribute to open source projects 3. create a project of your own where you can show what you can do

> What did you do to get a response back from jobs you've submitted an application to?

When applying don't talk about years of experience, but about what projects you completed and how you managed to get them done.

"1. help a non-profit for a lower pay or even for free 2. contribute to open source projects 3. create a project of your own where you can show what you can do"

What's wrong with projects from previous full-time jobs? My most complex and interesting projects were done during paid hours and since I usually was the only person working on these projects, I can proudly call them "mine", despite being owned by an employer. From the perspective of an employee, if you demanded to have non-paid projects I would thank you for an interview and say "goodbye", even though I have some of these.

I think any of these things (1, 2, 3) are commendable, but expecting any of them is like only hiring a plumber if he has completed any good plumbing projects in his spare time.

I find it completely bizarre this has now become the standard in hiring software engineers.

If possible you can try to find company that uses both stack you have experience with and stack you want to learn. Apply for position with stack you know and let them know you want to help and learn in different areas. That worked for me when moving from mobile to backend.

When I hear this kind of comment I wonder about the mention of "junior" and "senior".

If I may suggest that the title 'junior' or 'senior' is artificial and generally unhelpful in the sort of quest you are on. If that sounds harsh I apologize, when I see development resumes I don't see "levels" I see strengths and weaknesses.

A developer that can pick up a frame work quickly and be productive in it is "strong", one who continually re-factors the problem so that they can re-use the framework they already know is "weak." A developer who can discuss the trade-offs between multiple frameworks in terms of solving the needs of performance, manageability, or resource usage is "strong", one who only knows the trade-offs and pitfalls of the framework they are most familiar with is "weak." Developers who are working on improving their understanding and craft are "strong", developers who are don't understand why their particular framework does something the way it does are "weak."

That is a lot of admittedly contrived examples but I hope they illustrate the kind of developer I look for when I'm hiring. If you have 10 years writing code I want to see a wide understanding of a lot of different systems, if you have 2 years writing code I want to see you understand the key design elements of the systems you are using, and have some idea of why those design decisions were made. It is the difference between being able to code, and code fluency.

So to answer your question, if someone wants "years of experience in a stack" then they may be using that as a filtering mechanism to get rid of people who are unsure of their abilities. I remember reading advertisements in 1998 for people with "5 years experience in Java" when Java had really only been released (early alphas in 1995). I wondered if they were just trying to hire folks who were part of the original team (which went back to 1991 :-). Talking to recruiters though, they were really looking for people who were so excited about Java that they had done an in depth dive on their own. Perhaps you are seeing something similar.

My advice to you is to lead with your strengths. If you have examples that demonstrate those strengths or projects which demonstrated them put them in too. Be honest with yourself about your weaknesses and think about ways to you can eliminate them. Be the strongest developer you can be and always work one ways to develop additional strengths. The rest has, in my experience, taken care of itself.

Pick a new stack. If the technology has only been around a year, then everyone is a senior.

Nope. If you're a senior developer, you're a senior developer. You've developed the thinking skills you need for that level. Places that need very deep experience in a very specific technology are quite rare.

One of the skills you have as a senior dev is that you can come quickly up to speed on a new stack in whatever your field is. You understand the underlying problems, learning the new incantation to make things work is comparatively trivial.

Note: If you entirely switch fields this does not necessarily apply.

Everything depends on your experience, but in my opinion, companies that would only hire based on tech stack aren't worth working for anyway. And marketing yourself on your stack is a bad idea. Ask yourself, what kind of problems are you able to solve? Which domain do you know? When you find the answer, sell that. If you know really well how to solve some issues, you can solve them in any language. And you're not paid for the code you produce, but for the problems your code solves.

There are companies like the one I work for that are willing to hire experienced engineers and then train them on their chosen technical stack. The job engineering descriptions on the Rover.com career page include "Rover’s web app is written in Python and built on the Django framework. Nevertheless, we are willing to train people in Python and Django, so first and foremost are looking for good engineers who are eager to learn."

I think there's another aspect...which is that there is the job and the tools to do the job. The framework is the tools...the job is, in Rover's case, building a web site.

A lot of the time "Requires 2 years experience with foo" is just another way of saying "we want someone with intermediate-level knowledge of foo." If you can demonstrate you have that equivalent ability with e.g. a side project on github, that's probably fine.

In general, don't take job d requirements too literally. Research the job & the company and write a nice cover letter and I think you'd do fine. Worst case you don't get the job.

What is your problem? Firms not following up or what? If yes, the reason might be that HR is overworked and you should just follow up every 5 days or so to see how far they are with your application.

I run coderfit.com, a niche tech recruiting agency in Zurich, Switzerland. If you look for Bay Area salaries in Europe, shoot me a mail!

If you feel confident with a new stack because you've used many other similar stacks in the past, you should just lie and tell the recruiter that you have 6 months or 1 year of experience with it. Recruiters don't want to hear about messy reality - So if you're qualified for the work but not experienced, lie.

Yes. Apply to junior roles, even though you were senior in the other stack.

Any fancy wording will not hide the fact that you do not yet have work experience in the new stack. In fact, you should make your situation clear, to save you and employers time and effort. The sooner you find out you are not a match, the better. That's probably what has been happening. The companies you have been applying to are probably looking for specific experience, and you do not qualify. So they do not reply at all. Each non-response brings you one step closer to finding a match. You know another company which is not right for you right now.

Recruiters are paid by the company to bring in people with specific experience. With no work experience in a specific stack, recruiters are probably not the way for you to grab the bottom rung of the ladder.

You have to talk to people. Lots of people. Ask each one, " Do you know one company which is currently hiring junior people with little or no experience in a specific stack?"

Look for a company which WANTS a junior programmer with little or no experience in a specific stack. They are much harder to find, but they are out there. It's not easy, but it's possible.

Great question. One way is to learn abstract skills such as managing others and finding and executing the critical path to a solution.

If you have these skills you can apply them to different software stacks or technical problems. A high-level and decent understanding of the subject is sufficient.

Steve Jobs had no expertise building computers.

"Number of years required" are pointless meaningless values.

prove that you have experience with a topic rather than years.

build a portfolio of working stuff.


skunkworks something at a current job and if it is successful use that as a selling point in your resume.

and don't use the word pivot. ever.

IME, everyone advises portfolios, but nobody looks at them.

i do.

I will use you as an excuse to keep working on my portfolio when I should really be whiteboarding out fizzbuzz minesweeper in O(logN) time right now.

glad i could help

side projects are just seen as simple toys from employers.

I instead started a software dev side-company that specializes in minimum viable products for very early-stage entrepreneurs. I fish around Linkedin for clients who pay me anywhere between $1000 and $3000 (i honestly just eyeball the amount). For the most part, I pick the stack or look for clients who want a specific technology so i can learn it. This counts as professional experience since I got paid for it.

> What did you do to get a response back from jobs you've submitted an application to?

This is a seller's market. How much trouble are you having getting responses back?

Fundamentals and related experience are more important than highly specific stacks that you can learn in a few weeks.

Choose a very new stack where no-one has a lot of experience.

This is a good idea. Carry on. You will be able to do.

At dice.com we just released a free career path tool that shows you possible transitions from your current role based on our years of profile data in the tech sector. It will also show you what skills are typically required in each role. Hopefully this can help you explore some options while you decide how you want pivot - url https://www.dice.com/career-paths

Small bug on your site : the "years of experience" field doesn't work on non-US keyboard layouts that don't have numbers on the top keyboard row. It's a quite common (and annoying) issue on US sites for us europeans.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact