
Ask HN: Will a support engineer position hurt my career as a software engineer? - smooch-freeze
Context: I have a B.S. in Computer Science from a top cs school. I
started a hardware company in undergrad, raised a seed round and
worked full time on it for over a year. We shut down recently and I&#x27;ve
been interviewing for software engineering positions.  During my time as a
founder, I coded much less than I wanted to and instead focused on nearly every
other aspect of our business. I have a strong foundation and know my cs
fundamentals well, but I don&#x27;t have any depth with the latest node libraries and
front end frameworks.<p>I&#x27;ve been interviewing in SF and found that larger companies typically want
really specialized roles and require experience I don&#x27;t have. Smaller companies
are more open to versatile positions, but I&#x27;ve had multiple companies come back
after onsite interviews say that I would be a good fit for a &quot;customer success&quot; &#x2F; &quot;support&quot; engineer.<p>Some companies have defined the role relatively well even though the position is
new for them, and for others I&#x27;d be the first hire for that position and it  
isn&#x27;t well defined.<p>I&#x27;m worried that these roles might pigeonhole me in the customer support
category in the same way a QA engineer might have difficulty transitioning to a
software engineer. I&#x27;m also worried I won&#x27;t grow my coding skills as fast as if
I were to take a full-time software engineering position. Finally, these roles
seem to have significantly lower salaries as opposed to even entry level
software engineers and I worry that I&#x27;d be undervaluing myself by taking a
salary that is much less than market rate.<p>1. Does anyone have general advice and perspective on support and customer
success engineering positions?<p>2. Would I be hurting myself as a software engineer by taking one of these
positions?<p>3. Are these typically &quot;growth&quot; positions, i.e. are they like a entry level
developer position that leads to software engineering, or do most people who
become support engineers stay support engineers?
======
kogir
I may be an oddball, but I expect engineers at at startup to help with
support, and would absolutely hire someone who had worked in a support role
over someone who hadn't if they're otherwise equally qualified.

The experience is super valuable - especially if you leave with a spidey-sense
for what product features and UI gimmicks will cause users the most trouble.
It's way better (and cheaper!) to fix issues like that during development than
after a product has been released.

So much stuff released now is frankly user-hostile. Hidden, undiscoverable but
essential actions and controls, and needless complicated interactions. Ugh.

~~~
mrits
It is more efficient to know what product features and UI gimmicks cause the
most trouble getting an aggregate of feedback from multiple support people.
One of my first jobs I was the lead and sole UI engineer for a startup that
had about 15 people doing UI training and support. In addition to filed bugs
they'd deliver me summaries of the paint points along with ideas on things we
could improve.

------
rudimental
The support engineering role can vary from organization to organization. In a
support role, you probably won't grow all your coding skills as fast as if you
worked full-time developing. You will get good at debugging and some other
aspects of development, but you will likely build less and grow less in some
areas (unless you spend time during or outside work building). You will still
grow, though.

These roles can pay less, it depends. Your market rate is largely a function
of interviewing skill and negotiating skill. Work on both of those. Keep
interviewing and find the right fit somewhere. Sell yourself (technical and
non-technical skills). Did you lead a team at your previous company? What
value can you add to projects in your potential new job?

Ask 3 at interviews - "How many support engineers in the past year now work
75%+ time building software for people, internal or external?" If there are
previous support engineers, that will give you insight.

Keep practicing your interviewing. You may need to learn some node and a
latest (e.g. React, Angular) front-end library. One way to demonstrate is by
building a small project, hosted on GitHub, which shows you can build
software. These two things (especially interviewing better) is very likely the
only thing between you and the job you want (full-time software engineer).

Ways to interview better include practicing white boarding by doing algorithm
problems. Think out loud during that, and ask clarifying questions. Same with
onsite coding- think out loud, ask clarifying questions.

You have cs degree from a top school, and some entrepreneurial experience.
These have value. Many roles are open to you- find one that's a good fit for
your and your employer's sake.

Referrals will help you, too. Having an advocate inside the company who knows
you will make it more likely to give you a chance.

Good luck!

------
rt2016
I would wait it out and look for a true software engineer position somewhere
else. With a BS from a top school, startup and management experience under
your belt you should be a solid candidate for software or product management
jobs and shouldn't have to settle for support engineer.

From what I've gathered a support engineer is a combination between a QA
engineer and an applications engineer, both of which are considered to be way
less technical than a SWE. You likely wouldn't be responsible for new feature
development at all as a support engineer.

In general they're not on the same ladder, so it's not a natural transition
from support to software engineer. Like you mentioned, you'll have to settle
for quite a bit of a pay difference, which will still exist if you transition
within the same company. However, if it's absolutely your only way of getting
your foot in the door at this company and you're set on working there, it may
be something to consider.

------
codezero
No, it shouldn't but it depends.

You need to find the right position for you, if possible find a company where
support engineers have moved on to software engineering roles.

If you are rusty, you'll want a role that will give you the ability to develop
the skills you're lacking to get a SWE role.

There are a lot of different things support engineers do and it will vary
wildly between companies. A bulk in my experience are very weak on the
engineering side, so it may help to join as an early support engineer on a
team that will allow you to have some autonomy.

Edit: Also consider how much time it will take you to become a SWE if you're
working full time, versus how long it would take if you dedicated yourself to
brushing up on skills and interview prep full time.

------
devonkim
1\. Customer success / support is fine in combination with other skill sets
that are higher value such as SWE. But I would still say that the employer
history is more important. For example, I'd rather be a customer support
engineer at Google than an architect at a terrible, no-name software company
or one of ill repute.

2\. It can widen your perspective into how to better write more maintainable /
usable software but it won't help you a lick for getting through first or
second round interviews with reputable software companies that drill you on
algorithms and code fluency.

3\. I've only ever seen customer support engineers promote up to managers in
my experience. In my case, I was hired on as a team lead for a combination of
support and operations and after burning out I'm starting my own gig with some
lessons and insight I may not have learned otherwise. I wasn't held back so
much by technical ability as much as runway saved up and finding a set of
ideas I could imagine committing up to a decade of my life on. However, the
loss of fluency in coding over time ironically makes it take longer for me to
get out an MVP than if I had just pumped out code for years.

Be extremely careful with not very well defined positions regardless of title
- they can quickly become "do everything other people don't like to do" jobs
that burn you out with few real skills of actual business or technical value.
It is truly a sacrifice for anyone with potential to do speak up and just go
do some of that work, and most companies have zero capability of recognizing
when that's happening both large and small. Would you feel bad giving John
Carmack a job telling customers how to fix their IPC/SPX networks to play Doom
or resetting keys for people that misplaced them? Because that's what these
jobs can devolve into if you don't have the right support behind you and a
management team that knows when someone is actually overqualified versus being
slightly underpaid / good value (overqualified is a terrible value long term
because they will quit fast and the churn costs you valuable time /
resources).

There are very few people IMO that match the balance of empathy, technical
skill level, and tolerance for terrible things. Despite great reviews and high
customer satisfaction, I consider myself terrible at it.

------
fiftyacorn
I think seeing all the different stages of software development help you as a
developer. Nothing like supporting a legacy platform that was written with
good intentions, and best practice at the time - and understand whats worked
and hasnt worked.

You can also get closer to the users - which is interesting to see how
software and changes affect them

------
pfarnsworth
Let's be honest, yes you will hurt yourself. Most engineers will look down on
you, and once the market tightens up you won't pass the resume-smell-test.
It's not fair, but it's the truth.

If you're serious about being a developer, then get a developer job, don't do
customer support.

------
Spooky23
Is "customer success" related to sales?

I had a gig like that many years ago that had a commission component that paid
very well.

~~~
codezero
Depending on the company, but in general customer success is post sale. It can
involve things like up sell and cross sell, but this usually isn't relevant to
support engineers.

------
jf22
I turned down a candidate with only support role experience. Wasn't because of
the role itself.

He didn't know how to code.

