Ask HN: Got a CS degree, but I’m unable to be programmer. What can I do?
I recently graduated and have been grinding for interview prep (leetcode and CTCI mostly), but I’m getting no where. Easy problems take me 2-5 hours. I experience PTSD like symptoms from the constant barrage of negative thoughts the difficulty and stress of doing these problems are causing me. I don’t have time to do anything else and no objectively measurable progress is being made. Even if I get a problem right, I gain little to no satisfaction at this point. I completely hate what I’ve gotten myself into.
I put all my eggs in the “being a programmer” basket and it’s clearly not for me. I do have a computer science undergraduate degree which I’m hoping I can use for something. Are there any career paths I can pivot to that are less cognitively demanding than software engineering where this degree would be an asset?
322 comments
[ 2.8 ms ] story [ 294 ms ] threadOne possibility is you just aren’t wired for the interview process, but could make a competent programmer given the chance. The other is you got the degree. It just aren’t wired for programming in general.
In either case there are a lot of near-programming jobs where your CS degree can be valuable. Thing Sales engineering if you are outgoing, QA if not, and technical support if you are in the middle. All 3 allow you to be technical, and can lead to programming jobs if you are so inclined. And all 3 positions are filled with people who wish they had a CS degree.
I'm ready to be downvoted for this, but if you can't solve a problem in 15-20 minutes, just look at the solution, understand it, and memorize it. The more problems you work on the better your pattern recognition will get, and it'll be easier to solve related problems. Unless you're a genius programmer, I seriously doubt most normal people can easily and flawlessly answer these stupid questions within 15 minutes in an interview setting.
Also keep in mind that the vast majority of interviewers will tell you that they're looking for a good thought process as opposed to the correct solution, but they're 100% full of shit so don't believe what they say. There are hundreds of engineers who have already memorized 300+ leetcode problems and WILL write correct and bug-free code in an interview setting, and they will get the job no matter how good your "thought process" is. However, there are SOME companies that care about thought process, and those are the ones you have to look for. Unfortunately I haven't found out how to determine which companies actually do that, but typically they're start-ups. This only applies if you're in the Bay Area, however. I can't comment on what it's like outside of California.
I feel like nobody in the thread truly read your original post. You asked for alternative career options because you can't solve leetcode problems and that's absolutely ridiculous. You can absolutely get hired as a software engineer, you just have to play the game. Keep leetcoding and you'll eventually crack an interview. It's just a numbers game. Good luck!
I don't advocate memorizing solutions because I don't think it sticks. I prefer to look at the solution and implement the algorithm myself. Pattern recognition is key though. And I too believe that most interviewers who say they're looking for "thought process" are full of shit. Partly because the question always seems easier to the interviewer and than the interviewee. But mostly because all the candidates who did grind through hundreds or thousands of leetcode, hackerrank, careercup and/or topcoder problems have skewed what normal interview performance looks like.
I'm very interested in this divide between people who are for white board interviews and against it and how it correlates with job performance and content. I may make a separate post about it because I'd like to get to the bottom of it.
I agree and I think its illegal to do so. Its a form of discrimination so they have disguised it as a "coding challenge".
I am actively interviewing right now. Also interviewed at FANG companies. This is absolutely 100% correct. Those people don't give shit about thought process as much as they do about correct bug free solution under 15 minutes. If you take even JUST 2 MINUTES to think they start looking at you suspiciously and reject you in their mind. This is really a fucked up situation.
Don't listen to people telling you that you shouldn't be a programmer. Doing these sort of puzzles has very little to do with 90% of what programmers do. There are jobs that need these algorithm skills, sure, but they're not the default jobs.
On the other hand, it's not a waste of time for a young person to just go through a few of these a week as they are job hunting. And you really do get better at them as you do more and more. Certain patterns repeat, and the tricky ones usually have nice explanations that you can certainly learn from. They are also FUN if you do them in a stress-free situation outside an interview.
Also
> (They do exist, even if they're not as common as they should be.)
I'm curious why you think interviews _should_ be non-algorithmic. How do you propose interviews be done? How else are you supposed to find if someone can employ critical thinking + has the necessary programming skills? And yes, most interview questions _are_ original and not straight from Leetcode so they do demonstrate critical thinking + programming skills.
I keep it very short. I try to make it low stress. I try to make it fun and funny. Why? I really want to know if the candidate can work with me and how they will work. I don’t care one bit whether they can remember the big O notation of a red-black tree search or whether they know how to reimplement a complex datatype. I care how they will work with me in my environment.
You might say “you’re method is just too simplistic. People can game it and get through.” It’s been accused of that before. And frankly, I can memorize algorithms and game that interview. Try gaming me while we pair on some code and I try to toss in a few roadblocks. Try to game me as I try to see how you will react as we work together. It’s hard, and my methods have been quite successful for me.
As for the pay, I don’t pay people what Amazon, Google, and Facebook pay. But I pay very well and people stick with me so it seems to work out.
And by bug I do not mean super hidden tricky language feature you get to look up on language standard to not misuse.
Most people I meet haven't had my path to success, but it is possible. My gut feeling is that I'm a small statistic because people give up quite easily when they think their goals are unattainable. My first programming position took me 15 interviews to land a job!
Pretty much nothing will accurately predict how well someone is going to do on the job. The best approximation is for them actually doing the job.
Also, the two most important things that we look/test for throughout the process are: 1) how good of a fit the candidate is for the team/company (do they get along with their team?) and 2) how enthusiastic they are about working with us (did they do some research on us ahead of time? are they excited about the opportunity?)
^ this is a doggone well-phrased and accurate summation of the challenge of team-building. Raw capability is by no means a predictor of how well someone'll work with the organization.
Besides, it's possible to take 2 weeks off of your current job.
On the “pay reasonably well” line, the average new college grad salary is 50K. I’d wager that the vast majority of salaries in the field exceed that. The googles of the world pay way in excess, and they may make you do some stupid dances to get in the door, but that’s not the real world, that’s just one weird part of the world.
That's a problem for people who haven't done internships and have just graduated. Architecture skills and knowing how things are/should be designed come from experience, which a lot of people don't have.
On the other hand, algorithms + data structure knowledge and how they're applied do not really require experience, just knowing fundamentals well.
So your method is definitely good for experienced people but not for new grads/interns. And these are methods the industry employs anyway — big companies do stress more on system design for industry hires, less so for new grads + interns.
Leetcode style questions almost never require anything resembling critical thinking. The only thing they demonstrate is problem solving under pressure.
Background: I've been a programmer for 33 years. I have never (directly) used a tree of any kind. (I've used STL and Java maps, which I think are trees under the hood.) Asking me to do something with a tree in an interview question is therefore probably a sub-optimal way of determining whether I'm a good fit. Yes, I know what a tree is. No, I don't know it like the back of my hand, and I don't know the algorithms in detail. Yes, I could probably figure it out during an interview. But expecting me to know that background when I come into an interview, when I have never used it so far in a pretty long career, and so I'm probably not going to actually use it at the new place either... that's asking me to memorize a bunch of stuff that isn't actually going to be useful on the job. That's a bogus interview approach.
Algorithmic questions should be something that the interviewee hasn't memorized the answer to, but also that they don't need to have memorized a bunch of background or know the "trick" to be able to answer.
Now, I'm in kind of a different world. I've worked mostly in embedded systems. If you're interviewing for a job where they use a lot of trees in their data structures, you probably ought to know them. If you are interviewing at one of the big boys (Google, Facebook, et al), where an improvement in the structure you use to represent the data can mean that you need several thousand fewer machines, they are going to really care about your grasp of the nuances of data structures. But, despite Google's size, most jobs are not at Google, or at that type of place.
If you're going to classify only Google, Facebook, Amazon, and their ilk as "paying reasonably well", then I do not agree with your definition, but I will agree that you'd better be able to pass Leetcode-type questions in their interviews.
See https://github.com/icopp/tech-demo-1 and https://icopp.github.io/tech-demo-1 for an example of one I've done before.
That said, is there any type of programming are you good at? What actual work have you done? Have you shipped an iPhone app or launched a basic website? Were your comp sci courses brutally hard and you spent hours working at them and barely eked out a degree?
I’m asking because you just may be failing because of anxiety, not “stupidity”.
No, not everyone requires certification to be a PM, but many places do, and in many cases it helps get past the resume filtering process.
So get a PMP cert if you want, or don't and find a company that isn't going to discriminate on the lack of a certification. It costs a bit of sanity and $500 some to pad PMI's coffers, but its basically paying $500 for your resume going to the top of the stack. Sucks, but it is how it is for a large enough number of companies to matter.
"Defacto" may be the wrong word, perhaps "ubiquitous" would be more correct, but your point is valid.
This particular PDF [1] really helped me understand the roles better.
I also read the book "The Product Manager's Survival Guide" (ISBN-10: 007180546X) and found it to be a pretty good basic introduction, when I needed it.
Lastly, nothing beats having cross-disciplinary experience by chance in any job. What lead me into product management was always "getting stuck in the middle" because I was equally capable of being technical as well as talking with a user and understanding their needs. I was more of a Technical Product Manager, however, than a pure Product Manager (an important distinction).
[1] This is a legit download - "The Strategic Role of Product Management" it's a link to a PDF on the Pragmatic Marketing website - https://cdn.agilitycms.com/pragmatic-marketing-v2/SRPM_PM180...
I don't think "being too stupid" is that factor. I mean... you're smart enough to graduate with a CS degree!
Are you doing these interview prep just because you enjoy the training, or are you in "cram mode" trying to force yourself to get better?
> Even if I get a problem right, I gain little to no satisfaction at this point.
In order to make "deliberate practice" like this less stressful, you should establish a baseline of doing some task in a way that makes you enjoy it.
Step aside from interview prep, take a few days and focus on anything other than programming, then casually think about what YOU want to create -- for your own personal use/enjoyment -- to satisfy your creativity. Not to "grind" and get better at it -- but simply to tinker and fiddle and read and discover.
Once you're programming (or maybe reading, or writing, or painting, or making music etc...) just "for the kicks," you might try to dive deeper into a part that you don't understand well -- if you're not going anywhere, take a step back into the comfort zone, and do what you enjoy for a while, then try something harder again.
That may be more a result of how your work history rather than shift in the industry norms.
You basically handle all of the technical things that are over the heads of the normal sales team, both pre and post sales. This will often look like integration type work -- trying to figure out how to make your companies product work in the prospect/customer's environment.
It's a very different role, but also valuable, and having any kind or CS background may put you ahead in many companies.
Get out there and interview if its important to you. The more interviews you fail the better you will get at them! If you wish to master the silly technical interviews IMO the best way is to throw yourself into the fire.
Most of what I do as a software engineer is not particularly complicated; it's playing with Legos or akin to construction tradework. I've got to have attention to detail, and a mental map of how the piece fits into the whole, but it's not super clever or complicated. And I try my damndest to avoid things that are clever or complex, because they're usually far too easy to get wrong, and create too much work for future-me down the road. A startling percentage of my time is just doing variations on database crud operations and munging data from one source through some transformations and pushing it at some destination.
If you like programming itself, don't pull the parachute cord on it just yet. There are plenty of companies that aren't tech companies that need programmers -- maybe that's less pressure mentally and from actual demands from the job? Something to think about, at least.
Also, consider a secondary skill or interest and mull over what kind of company could benefit from the intersection of that and your programming skills. (That's somewhat inspired by this: https://medium.com/the-mission/make-the-pursuit-of-curiosity...)
Now before presuming you can't handle a workload at a company that isn't all testing-mensa-crazy, you might want to look into how you respond to this stress before evaluating the best course of action.
As other commenters have said, there are many options, but at the root of it you should understand what/why you feel this stress and it would be best to get professional advice on that.
I'm the last person who wants to advocate pharma-everywhere solutions, but I've worked with some extremely talented people who otherwise struggled through life and managed to find the right formula that worked for them.
I got into programming because I like creating things, having ideas and making them happen. Algorithms like you find in programming puzzles rarely stand in your way to create things. GoogleFu / BingJitsu tends to solve most problems pretty quick.
Now your search skills often depend on what you are aware of to look for
I enjoy programming puzzles from time to time, usually advent of code, but I also don't get a huge level of satisfaction from solving those problems so I don't do them all and often just cherry pick the most interesting ones after the event is over. Often the most interesting thing is to see what techniques other people used to solve it. Which is really the key point for a professional software developer :- be aware of techniques and know what kind of problems they can be used for. Often techniques can be applied to problems in ways that are just not obvious.
So, first piece of advice, look for jobs that don't do puzzle based interviewing. Smaller companies are good targets, they don't need to do formula based recruiting ( however many do try to copy big players approaches to interviewing )
Ok, so maybe you really don't want to be a dev...but there are other specialist areas, like testing, devops, UI (Ux). But that would greatly depend on what you enjoy.
If none of it is of interest, then there is all kinds of tangential roles, recruiters, product management, HR. But may require further study.
Just work out what you really like doing
If you are getting interviews then bombing them all - then you can start to worry. If you really don't get anywhere you can try looking for QA/test jobs where you usually have to know a bit about software and end up writing scripts and maybe move into dev later with some more practice.