Being Laid Off | Hacker News Reader

Being Laid Off

39 pointsthrowawaygo13 comments

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 "not letting unqualified people in", so that we can feel deserved of those big checks.

--You can't virtual whiteboard a dp solution to my lss problem with contrived memory constraints? Sorry I just can'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'm rolling for scratch for some reason.--

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.

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'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.

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.

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'm unparalleled, if I may. But you want me to tower of hannoi your fizzbuzz.

I'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.

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.

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.

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.

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.

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.

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.

I feel your pain. Stay strong. Good luck.

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

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.

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.

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.

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.

Management is where the money is at. A big part of a manager's job is managing (manipulating) people, which gives managers the opportunity to focus on those skills,which is how you make real money. I'm just an IC waiting for them to throw me my next peanut.

Reply on news.ycombinator.com