
Ask HN: In Need of Career Advice - potta_coffee
I&#x27;m in need of career advice. I&#x27;m a self-taught developer, I learned programming as a kid and always dabbled in it but I didn&#x27;t make it a career until 2014. Since then I&#x27;ve done a number of different things - automation for QA testing in Python, web development in Python, PHP, .NET, Javascript, and now I&#x27;m building cloud automation and management tools in Go, with some front-end interfaces built in Vue. I believe I&#x27;ve consistently provided very good value to my employers and many of the projects I&#x27;ve delivered are still in production several years later. I&#x27;ve also managed teams and have gotten pretty good at managing and delivering projects, but I wouldn&#x27;t call myself a project manager.  
My real question pertains to my future. I&#x27;m 36 and I&#x27;m starting to worry about being aged out. Also, I&#x27;m self-taught and I&#x27;m always learning and studying, but I really dislike leetcode. If I have a choice between building something and grinding on problems, I&#x27;m going to build something, or learn more about things that interest me like languages, compilers, interpreters etc.<p>My problem is that I&#x27;m really struggling getting job interviews, and then landing a job when I do get an interview. Last year I interviewed for a Django development job, something I&#x27;m perfectly qualified and capable of doing, but I didn&#x27;t get the job because the questions were all about the internal data structures of SQL, esoteric questions about Python internals, etc.<p>I&#x27;m at a loss for what my plan should be. Get a CS degree? Grind leetcode? I need to define a good path forward. I know I can&#x27;t control the future but I&#x27;d like to still be employable 10 years from now.
======
sloaken
You cannot control the BS interview. I had the same type of interview, it was
for C# and .Net. All the questions pertained to debugging SQL errors. LOL The
interviewers were dicks, and after the interviewer I told their HR I was not
interested in the job.

That said. You have 4 choices IMHO -

1) go into management. Although most techies enjoy hands on and would hate
this option. Personally I like team lead, as it was techie enough and I became
the buffer between the non tech management and the people doing work

2) settle into a secure job. i.e. big company / government. They typically do
not lay off as you get older. Although government and universities respect a
degree.

3) keep chasing the new tech. This requires a lot of time self learning. You
will find some tech will run dry on you. I find this path the hardest, but the
most satisfying. But it is not the tact I took as I have a family to feed.

4) become an expert in A tech. Expert to the level that you have a blog on it,
you present at conferences etc. This sounds like it would be real cool, but
the risk is the tech dies. Yeah Java is still strong, but Pascal is not.

~~~
_ah
5) become an expert in A Field.

There are lots of little niches where the programming languages and techniques
change, but the core problems of the field stay the same. Deeply knowing a
particular corner of the industry can serve you well, partially because you
know the nuance of the problem space and partially because you will start to
know the relevant individuals in that space.

Examples: Fintech (consumer), Fintech (enterprise), High Frequency Trading,
Media (video), Healthcare, Advertising and Ad Platforms, ....etc

------
gofreddygo
Hey potta_coffee, I'm in a similar situation as you. I have decided to accept
leetcode-style prep as my best choice. I'm a few months in my part time prep.
I can, maybe, make it a little bearable for you.

~~~
gofreddygo
After the initial denial phase, I took it as a challenge and that mindset has
helped me. I tried a variety of tools including anki to my own homegrown
leitner system. They all suck for this. Don't waste your time.

The key to slaying this dragon is repetition. If you identify repeating
patterns and just fucking practice them and own them, you make a lot of
progress. Just like you learn to draw. One mistake I made initially was to
follow common advice and 'just solve leetcode'. No it does not work (for me).
Don't waste your time. First own the basics.

Its similar to the mental models approach that Charlie Munger advertises, just
limited to this domain. A few common patterns solve a lot of common problems.
e.g.

* using hashmap to find a pair/triplet that match a criteria in an array of numbers * kadane's algorithm - to find contiguous subarray * dfs - for "find all combinations" type of problems * coin change / knapsack - solves a lot of problems in DP space * implementing merge sort/timsort/heapsort * implementing quick sort * a classic problem involving a trie implementation * two pointer approach to navigating arrays

These cover a large swath of interview questions (programming + whiteboard)

Once you add in your vast real world experience, you really have a strong edge
over other candidates in further rounds. Especially in a hiring manager's
perspective.

definitely get the book Elements of Programming Interviews (I printed it out
and read it chapter wise as time permits. Sometimes while cooking). I focus on
array, string type questions

And finally, another thing I realized is ... to get what really want, you must
be ready to lose it. Fear of rejection is real, creepy and my biggest
deterrent. I've since told myself - I want that job at google. I will try all
I can. I am not afraid to lose.

Fuck it man, just do it.

------
wontonzealot
This won't be advice on where to go career wise but some tips I can offer
since I recently just wrapped up the interview circuit and my background is
very similar to yours.

As much as you don't like leetcode, doing those exercises is effective and
meaningful. I understand where you're coming from - I also lack the classical
CS background that a company would find in a CS graduate. Leetcode questions
might seem like they're very theoretical and unpleasant but a lot of those
questions focus on the standard algorithms and data structures (stack, queue,
hash map, linked lists, trees) - some of which has opened my eyes to solving
some problems efficiently that I face at my job. Heck, some of those I've
already been using but never knew/used the right term for it! For a long time
I hated the idea of Leetcode too and I avoided doing it because I would have
to conform to a broken interview process where I felt like I had the
experience to make up for that missing CS knowledge. This was arrogant of me
and wasn't working so I tried to adapt.

Like another commenter said, you can't control the BS interview, BUT here are
some things that I did which helped me, and I hope you find some of them
useful:

1) Learning the standard data structures and algorithms, and doing 2-3
leetcode type problems a day at varying difficulties helped me gain confidence
in answering those types of questions and at least being able to get through
the more basic technical interviews. Pair program with a friend to try and
solve the harder ones together so you can get used to the live remote coding
interview style and keep each other motivated.

2) Studying up on system design helped me to prepare for the harder technical
interviews where they ask you "how would you build Instagram" on a whiteboard.

3) I went the engineering management track. This also varies wildly between
companies but ideally this type of role gives you 50/50 hands on/management
type work. I had to study up on the behavioral questions, prep responses to
those "was there/tell me a time where..." type questions and put my management
style into words.

4) I always ask the initial phone screen person about the interview process in
detail just to know for myself what to expect and how I can study
appropriately. If they're not clear about it or they're vague about it, I lose
confidence in that company because I will likely fail somewhere along the way.
I've been to an interview where the company uses Python, which I didn't know
at the time and they told me not to worry because they only want to see that I
know the basics - when I got to the interview, they asked me to build
Minesweeper and asked me to build Blackjack on the whiteboard. I was
unprepared and so I failed that.

5) Even after landing a job, keeping up with the Leetcode exercises to keep
that stuff fresh. Never forget how long it takes to ramp up again after not
doing it for a while.

6) Practicing to think quickly on your feet. Basically if you don't know an
answer to a question or you can't answer it for whatever reason, highlight
something good to balance it out and recover from the stumble.

~~~
potta_coffee
Thanks for taking the time to respond. I've been spending a lot of time
studying and implementing data structures and algorithms and other
fundamentals, I've just avoided the leetcode problems. You make a lot of sense
though. I have a lot to think about, I'm just trying to identify what efforts
have the best chance of paying off.

------
rpeden
I think you have several points working in your favor.

A big one is that you can do more than just code. You've planned and delivered
projects that solve business problems. Even if you don't consider yourself a
project manager, the ability to take business requirements and translate them
into applications that solve business problems is valuable.

Also, consider the possibility that 'aging out' might be a lot smaller in some
subsets of the development community than in others. In my experience,
companies using .NET are likely to see age and experience and even a few gray
hairs as a good thing. Probably because .NET tends to be used by older, more
established companies. So you might consider looking more in that direction.
Just be careful not to end up in a job where your sole duty is the maintenance
of an ancient VB.NET Web Forms app. You can have a lot of fun with C# and .NET
Core, though.

I've also noticed that .NET interviews are a lot less likely to use Leetcode-
style problems. I've always prepared for those kinds of questions, and was
even looking forward to them! But I've never encountered one in an interview
for a .NET related role. They've always been more interested in getting to
know me and talking about the problems I've solved. There have definitely been
take-home coding tests, but they've always been the kind of test where they
ask you to create an application using ASP.NET MVC or ASP.NET Core, and
they've always given a set of specs telling you what the app needs to do. I've
never had one of these take me more than a couple of hours.

There are no guarantees, of course. Someone else who replied mentioned they
had a crappy .NET interview where all of the questions were about SQL. On that
note, if you like .NET then learning some of the more advanced bits of SQL
Server and T-SQL wouldn't hurt - and might actually be fun, and will even
carry over to other databases. For example, if know how to use PIVOT in T-SQL
to flatten several tables into a single report, you'll find it pretty easy to
do the same thing with crosstab in Postgres.

Finally, consider looking at programming jobs in non-tech companies. I know
this goes against advice I see often on HN. But I've talked to many developers
who seemed super happy working for banking, insurance, and manufacturing
companies. I've seen a lot of age diversity among devs working for these
companies, too. Without a doubt, there are some non-tech companies that are
terrible work environments for developers.

But there are also plenty of them that understand the importance of
technology, and actually treat their tech people with respect. If you ask the
right questions in the interview, you can usually get a good sense of how
developers fit in with the rest of the organization.

The downside is that you're more likely to end up working on boring projects
at non-tech companies. Lots of CRUD apps, lots of wrestling the data you need
out of massive, not-so-well designed databases. These companies will probably
pay less than tech companies, too. But you'll probably work less, and deadline
pressure won't be as severe. There are certainly non-tech hellholes where
you'd end up with long hours _and_ low pay. That's why you ask lots of
questions during the interview to try to weed these companies out. If you do
that successfully, you may just fine a company where you'd want to stay for a
decade or two. You might also have the opportunity to make a big impact in
ways that you wouldn't at a tech company. You'll probably find lots of low
hanging fruit in the form of problems where you can apply very basic AI/ML to
help the company save money.

Anyway, that's just one possible path. sloaken's reply mentions 4 choices, and
I agree that they're your best options. I suppose all of my advice above falls
into option 2 on sloaken's list - settle into a secure job at a non-tech
company that's likely to be around for a long time. You could even combine 1
and 2, and aim for dev management/team lead at a non-tech company. In those
roles, you'd be able to get to know people throughout the org - and learn
about all sorts of painful business problems you can help solve.

~~~
potta_coffee
Thanks for taking the time to respond. Lots to think about.

