
Being Laid Off - throwawaygo
What does it mean to be an engineer, laid off. It means I am studying algorithm challenges to get a job I have been doing for 20+ years. I will do it because that is the tacit agreement we all have made. To torture our fellows in the name of &quot;not letting unqualified people in&quot;, so that we can feel deserved of those big checks.<p>--You can&#x27;t virtual whiteboard a dp solution to my lss problem with contrived memory constraints?  Sorry I just can&#x27;t take the risk of letting you write code on my team. Excuse me while I go back to copying and pasting stack overflow into my oauth library I&#x27;m rolling for scratch for some reason.--<p>We have all seen the coder who talked a good game and nested 10 loops deep and bragged about how much work their code was doing.  But apparently detecting them is impossible without puzzles in high stress environments.<p>Being laid off means I have to stare you in the face knowing full well I have more experience and make better decisions than you in most practical situations, but you will turn me away because I didn&#x27;t catch your gotcha question where you cleverly described a scenario that could be solved using a single server. But instead I designed a system to scale to several thousand tps quickly, and forgot to ask scale requirements because this is the third architecture interview today and all have been aimed at the scale of your org.<p>Being laid off means that I am suddenly responsible for adding interview puzzles to my skillset after spending 11 months saving my company millions of dollars writing real software.<p>I have learned all my skills on the job. Truth is I will do better if you put me in a room with better people. If you measured the ability to develop expertise rapidly you would see that I&#x27;m unparalleled, if I may.  But you want me to tower of hannoi your fizzbuzz.<p>I&#x27;m gonna go play animal crossing and see if I can forget writing this post.  I need to start doing leetcode questions in the morning.
======
shams93
The tests are used to enforce age discrimination bias indirectly to shield
from lawsuits. But at the same time I can't stand those employers who are
quick to hire and quick to fire usually they're too lazy to do decent job of
vetting. Its a tough question how to analyze someone's capabilities. So there
is no easy answer. If you were working tons of unpaid overtime your github may
be a ghost town who has time for side projects when the main job is asking for
80+ hours a week. There's no easy answer here except we should stick to
practical questions and avoid testing for computer science concepts which are
only valuable for university teaching or research positions in computer
science.

------
quickthrower2
Small software companies. (Not startups.) They really need people who can do
the actual job, so they tend to interview for that. I've never done an "algo"
challenge in an interview. I've been asked to write code though to solve a
contrived problem, but that's unavoidable.

------
throwaway40year
I got laid off on my fortieth birthday. It hasn’t bothered me at all. Been
working on building my own SaaS. I refuse to take algo interviews. Recruiter
is hitting me up to work at same place as before for more money. Get your
hustle on and get your last laugh.

------
giantg2
I can relate to the interview part.

I have applied to horizontal positions in my company and been turned down so
many times. They ask lots of questions that you would never hear on the job.

They had me working on obscure systems like FileNet and Neoxam. I even filled
roles above my level, like tech lead (I'm a mid level dev). I got my AWS certs
and it still took me a long time to move into a new position. It wasn't even a
promotion, just a lateral.

The biggest thing I have learnt on the job is that you should not care about
what the company or most others think. They are only there to F you over
because they have this goal (and you should too): get in, make as much money
as possible, get out as soon as possible. Skill and value mean nothing. Use
the politics and people to get yourself ahead.

------
sloaken
I am sorry for your pain. I have never had the 'algorithm quiz' interview, and
am proud to say I have never given that quiz.

IMHO If you are good with algorithms, your resume should show it, and you
should be able to speak to it. If your resume does not show the skill then
they should not grill you on it. Of course as a interviewer you must be
skilled enough to recognize a valid understanding of the algorithm the
CANDIDATE explains not just the ones you as an interviewer knows.

That said, I have seen plenty of resumes where people will list off doing in 3
months, that which would take a genius a year. Validating that you actually
did XYZZY verses just attended a meeting on topic is a key objective of the
interview.

------
Olumde
I am in the same boat now and, frankly, I am starting to care less. My medium
to long term plan is to commercialize the tech that I've been developing
privately for several years now. Were it not for that I'd happily throw myself
into studying a big book of algorithms. However I resent spending time that
would have otherwise been spent developing my tech -- which is about 1½ years
from being ready, (still some R&D and several layers to build out) -- studying
algorithms that most (standard) library provide.

------
sosilkj
I feel your pain. Stay strong. Good luck.

------
johnnyo
If you were in charge of the interview process, how would you design it?

~~~
bsldld
The only way that is good is to call the candidate onsite[0] for a day and
give them two practical assignments[1]. First half-day assignment without
internet connection but access to books, and the other with internet
connection. The candidate is free to ask questions to the team members at
anytime[2]. Then at the end of the day have a 1-hour group discussion(not
interview) conducted by the team on how the candidate attempted to solve these
two assignments.

[0] This can be done remotely, but to avoid cheats the team members will have
to remotely monitor the candidate's screen and so will be wasting their own
time.

[1] Assignments should be from the challenges the team is facing during their
day to day job or already resolved.

[2] Will provide indication of communication skills of the candidate.

This method will be both quick and better at finding right candidate for the
team.

Edit: added the communication part during the assignment phase.

~~~
2rsf
And then you will see threads complaining about wasting a whole day just to be
rejected, spying on your computer remotely or focusing too much on very narrow
domain knowledge.

Taking your idea to extreme would be having a long period of evaluation
period, maybe a week or month, but for obvious reasons this wouldn't work
either.

------
aliston
This is why I am going back to school for an MBA and looking for roles outside
of software engineering. Being a SWE is a great way to make decent money
immediately out of school, but the reality is that, unless you're a true
standout, it's hard to justify your cost as a senior engineer versus someone a
few years out of school. You might think you can "make better decisions in
most practical situations," but the reality is that you probably can't - at
least not in a meaningful enough way to justify your significantly inflated
cost versus a younger engineer to an employer. The experience curve in pure
software engineering is asymptotic or perhaps logarithmic at best, and the
situations in which additional experience matters are rare. In contrast, the
impact of a good manager, recruiter, financier and so on is limitless. My
peers that went into investment banking, consulting, and the corporate world
are now getting director and vp titles, making partner at prestigious firms
and so on. In 5 years they will be blowing me away financially unless I change
something.

Like you, I've come to realize our interview process is stupid, despite taking
part in it probably 100s of times by now. In fact, I think the entire concept
of rank and hierarchy in software engineering is stupid. I'm tired of the
pendantic arguments we get into, the endless architecture debates, design
docs, managers using phrases like "impact at scale", listening to L7 wind bags
spout off abstract technobabble and so on. In the end, I had to conclude that
most of it is bullshit. I've seen the pattern enough times at some of the most
iconic companies of our generation to determine that this is actually the way
it works in most cases. It's as though we took the corporate hierarchy from
1950's GE and tried to apply it to the software engineering profession, when,
in reality, software is much more like a trade. Ultimately, I think it stems
from some sort of superiority complex or need to feel as though we are
progressing towards something, so we set up a bunch of rules and hoops to make
it difficult for others to reach our status as a vaunted FAANG engineer.

Ultimately, I had to look at myself in the mirror and think about my business
value. For now, it's possible to ride the tidal wave of demand for software
engineers at a select group of companies that happened to stumble upon a money
printing machine. However, I'm not particularly confident that abundance will
continue. My advice would be to take this as an opportunity to pivot into
something that will allow you to more dramatically differentiate yourself
professionally. Everyone and their mom is studying computer science these
days. Companies are discovering they can hire remote developers. And, as
you're discovering, this is no career path for old souls.

~~~
throw_this_one
Yeah but soft engr you can get into a project where you get over the initial
hump and can coast, do like 20 hours a week of work. Get paid pretty solid.
Work remote and still do a fine job. Plenty of time to concentrate on your own
stuff.

All of those other roles you're going to have to have facetime always. Playing
politics. Is that worth it? Maybe.

