Two years ago, I ran out of money. So, I started interviewing. One example was interviewing for the Apple Watch team. My experience included the design and code lead of an Apple Watch product, which was featured by Apple. But, I failed the Coderpad. Why? The interviewer wanted me to use a new Swift generic syntax, which I had never seen before. With an unfamiliar code editor. In under 10 minutes. Did it matter that I had an Apple Watch product, which he could download from the AppStore and ran super fast on a Series 0? Nope. Did it matter that he could download a 29K Swift based functional ontology that I wrote? Nope.
The point is that there are two skills: writing code and getting past the interview. The latter is often conducted by a 20-something, just out of college. So, there is more emphasis on tacit knowledge of the tools and techniques. It feels more like passing a finals exam.
A few years ago my CEO hired Gayle Laakman to prep the team for an acquisition by a FAANG. I loved the puzzles and read her book  cover to cover. But, I hated the premise of avoiding "false positives". A famous false negative is Max Howell  (who went on to write Apple's Swift Package Manager)
So, how did I get a gig? I kept trying. Learned new frameworks. Focused on jobs interviews which had a take home. During the on-site, I insisted on using my own laptop. An often overlooked factor in achieving a coding flow-state is muscle memory.
I've been told that some companies are shifting from whiteboard to take-home -- particularly during covid. Post covid, if the option is available to you, try moving to the Bay Area or Austin and attend every single hackathon that looks interesting. If you don't want to leave HI, maybe contribute to an open source project in some way.
Or perhaps, start a company. Maybe there's an opportunity in refactoring Aerospace code? I dunno. Now, I'm guessing ...
Yes, you should. Working at Google is awesome. The interview process can be intense but the benefits are worth it, and honestly I love the culture here.
Please get Cracking the Coding Interview if you don't already have it. Do the problems on paper and eventually time yourself to see if you can fit a solution into ~35 minutes.
I'd also recommend watching MIT OCW 6.006 Introduction to Algorithms if it's been a while since you did a Data Structures and Algorithms course (or, if like me, you never actually took one!)
Once you've got a few CTCI problems under your belt and have a wide enough range of knowledge, you can try some free practice interviews through interviewing.io (referral link). They'll match you up with interviewers from e.g. Google, Facebook, Amazon, AirBNB, etc. for free, anonymous mock online interviews, where (importantly!) you'll get full feedback from the interviewer afterward. They'll tell you if they'd move you to the next step, what you did well, and what you could improve. Notably, real interviewers are often barred from giving this feedback for legal reasons, so this can be very valuable.
One thing to note is that if you're interviewing for e.g. SWE, you can usually delay your interview as long as you need to in order to study. I delayed my phone screen for like a month and my onsite interviews for a few months.
Also note that many people who got hired here got rejected on a previous round. You can almost always try again later if you don't get through this time (usually after a year).
I had a recruiting firm send me this book. Pretty interesting.
When I went, there were always a few companies where the representatives had a badge that said "I hire frosh." My advice would be to check it out to get a feel for what's going on. I wouldn't expect a whole lot, but at the very least it'll be good prep for the frosh/soph fair.
A word of advice - when I went to the fall career fair during my freshman year, I actually found it quite stressful. I ran into a couple of recruiters who came off as condescending, and the overall atmosphere seemed pretty stressful (gotta hustle for that internship). It was a bit of a contrast from the dorms and even office hours, where people are generally happy to lend a helping hand.
When I took CS 103 later, Keith Schwarz actually had a fairly negative view of the effect/messaging of the fall career fair towards freshmen. He felt that the competitiveness and the inevitable rejection of certain internships would not really provide a positive view of one's learning. Learning is a long process, and getting rejected from a dream CS internship might lead some to feel that their classes were for nothing. It's ultimately up to you whether you want to view your CS education as more of a pipeline into a good job, or an opportunity to intellectually explore (you can of course balance both, and there is no right way to do it).
So if you wanna hustle for an internship, then by all means go for it. However, keep in mind that the career fair is only one way to get your foot in the door. If you wanna be a real snek, network around and find people who can give you referrals for companies you're interested in. Also code up a project or two and put it on GitHub (with a link on your resume). Most importantly, read the good book.
And as cliched as it sounds, as a fairly targeted, short-term thing, you might consider jumping on leetcode and grind through some of the exercises there. How useful that would be depends a lot on the nature of the company(s) you wind up interviewing with, of course. Some companies are really big on these kinds of exercises, others less so.
Also, depending on what language(s) you currently know and work with, you might find value in spending some time learning another "trendy" language. Given the next 3 months to work on it, you could probably make real progress on learning a given language to a usable level. For example, if you don't use Go today, maybe spend some time learning it, since it's very popular and seen as "modern" and "trendy".
(Note: Go and React are just examples I picked to make a point. Please don't take this as saying specifically "learn Go" or "learn React".)
Cracking the Coding Interview is selling at $26.49, as a tangential reference
I wouldn't expect "proven techniques", just something that once you go through the book, you feel as prepared as you can ever be (whether true or not), then I would feel it's valuable.
After reading the title, I really did not expect your post to include "I have a BS in Computer Science." I can understand that you might be discouraged, but you're actually in a really good position. You won't need any specific certifications or experience to get a job (in your position), just some skills and a way to demonstrate them. Choose an accessible sub-field of programming - web development comes to mind (i.e. people without degrees and experience regularly get jobs after self-studying for a year or so, so it's definitely within your capabilities) - and work on developing a basic portfolio.
A good place to start would be any one of the multitudes of free resources online (ex. CodeAcademy or FreeCodeCamp). It shouldn't take you very long to get through an introductory course, and you should be able to start working on some basic projects pretty quickly. Once you have a few relatively simple website/app projects (they don't need to be profoundly complex or reflect your "passion" - whatever that would mean, they just need to demonstrate basic web dev. principles), you can start applying to jobs. Your CS degree is actually worth quite a lot here, as companies will be more comfortable hiring you with gaps in your knowledge than they would someone without your background (because you've already demonstrated the ability to learn advanced programming concepts).
Going to local coding meetups/networking and doing some interview prep (example) will also be helpful, as will reviewing the variety of online coding-oriented job-search resources on reddit and elsewhere. I wouldn't start thinking about moving yet, especially without a job. If there really are no opportunities within commuting distance or better job markets within a few hours drive (i.e. what you could realistically travel to an initial interview), then it might be worth considering relocation - but you don't need to start there.
Whatever else you do, you need to learn to manage your perspective. Your post exudes shame, self-blame, unworthiness, etc., and that's obviously a result of how you view yourself and your situation. You view yourself as a failure (or, at minimum, someone who's "not very successful") and you attribute this to never having been "motivated or focused" and making a "terrible" choice not to do an internship. I don't blame you for feeling this way - in fact, I would expect it. However, the fact that your culturally-derived perspective is predictable doesn't make it reasonable (or, more importantly, helpful). In fact, I think it could be very harmful. I'll try to explain why I think that may be in the theoretical rambling below. I see so many posts like yours, where the OP seemingly feels like they need to apologize for their perceived "failure," essentially belittling themselves, when asking reddit for advice, and it annoys me that our society leads people to feel this way (especially when redditors reinforce it by making unwarranted moral judgments - thankfully I haven't seen that here in this thread). If I'm misconstruing your tone, please forgive my assumption!
To understand what I'm getting at, let's start by observing that the US (of which I'm also a product) has a fairly "religious" culture. Now I'm not referring to a common belief in God/Allah/Yahweh or any other supernatural being. I'm referring to our inordinate reliance on myth in talking about ourselves and or society. An example of this can be found in our long-standing fascination with the Horatio Alger-style, pull-yourself-up-by-your-bootstraps, "rags to riches" narrative. Despite evidence to the contrary, Americans tend to believe (and frequently act accordingly) that social mobility is higher than it actually is (1, 2). Sidenote: I'm not trying to make a political point here, and I don't think the data implies any particular political orientation. The point I'm trying to make is that we don't always reflect on our existence in scientific or rational terms.
Instead, we tend to reduce the world around us into binary shades of black and white while inventing intangible concepts to fill the gap between the two. Some of this is simply pragmatic, as we have a limited capacity to fully discuss the world's infinite complexity within the finite timelines of our lives. It makes our lives simpler and easier to understand (if less accurately). This tendency may also be partially a vestige of past cultures that relied on the supernatural to explain the world around them. Whatever the cause may be, one manifestation of this is belief in the just-world-hypothesis or BJW (I don't mean to imply that this is a uniquely American phenomenon, by the way).
The just world fallacy leads its victims to believe that, essentially, people get what they deserve. Using the above-cited example of American beliefs regarding social mobility, one potential impact of this is that we tend to have a negative view of the poor. In particular, we ascribe negative characteristics onto (ex. laziness, irresponsibility, low intelligence) them as a means of morally justifying their disadvantaged position. It's important to clarify that this occurs independently of (or even in spite of) any demonstrable evidence. Social scientists can provide a variety of carefully researched explanations for the existence of poverty, but their findings have little influence on popular perspectives. Given cultural stereotypes surrounding the poor, perhaps it's not surprising that many Americans believe that there is actually a group of lazy, manipulative people living indefinitely off "welfare" benefits, despite the fact that there isn't even a welfare program which would enable this lifestyle. BJW is also implicated in the surprisingly common practice of rape-victim-blaming, wherein victims of rape are accorded (at least) some of the blame for their victim-hood.
The book Cracking the Coding Interview is pretty good. It has sections for each type of questions: data structure, OOP, testing, etc.
You could also look at free sites like HackerRank or LeetCode which have similar problems.
Cracking the Coding Interview: https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850
I remembered the books:
Cracking the Coding Interview, Gayle Laakmann McDowell
Coding Interview Questions, Narasimha Karumanchi
Programming Interviews Exposed: Coding Your Way Through the Interview
Lol, competitive coding is usually overkill for interview prep. Don't get me wrong--if you are good at competitions, you will almost certainly do well on interviews. Coding competitions focus much more on "finding an important insight"--usually beyond anything that you'll have to know for work--and then coding a solution, while interviews focus much more on your ability to hold many different moving parts in your head. Competitions also tend to focus on parsing inputs, which, if you are using a language like C++, is a pain in the ass and can be unnecessarily discouraging if you just starting off.
My advice is to check out the CTCI book and to write working code for as many problems as possible.
Be able to crank out DFS in your language of choice. Code every day. Try and work on problems that are easier to solve theoretically but that require holding a lot of different components in your head while you write the solution. The bottleneck for most people is writing correct code even after they know the solution--not "solving the problem" with theoretical data structures.
Also, know your language well. Spend some time every day typing out the apis for the basic data structures into your lang's toplevel or interpreter.
Amazon has it for 30$ and free one day delivery in most cities:
Cracking the Coding Interview: 189 Programming Questions and Solutions https://www.amazon.com/dp/0984782850/ref=cm_sw_r_cp_api_i_3p22CbWQ5G46S
If it’s through Hackerrank than just sign up and do a bunch of practice questions. If you want to learn more about DSAs I’d recommend going on YouTube and searching Cracking the Coding Interview (CTCI). The author of that famous CS book has made some quick YouTube tutorials on Trees, graphs, stacks, queues, BFS, DFS, Sorting Algorithms, Big O notation and more. If you have more time, I’d highly recommend buying the book itself, as I give it credit for landing me 3 internships and a job at a FAANG. It’s on sale on amazon right now for 32$:
Cracking the Coding Interview: 189 Programming Questions and Solutions https://www.amazon.com/dp/0984782850/ref=cm_sw_r_cp_api_i_rqKZCbMH1F8CP
Here's a really good book by someone who used to conduct coding interviews at Microsoft, Amazon, etc.
Cracking the Coding Interview
Still, it's not likely that you'll see the same exact questions on an actual interview. Just practice a lot and get comfortable with solving problems. That will help you when it's time to code on-the-fly at an interview. Also, it's more important to talk through the solutions. Coming up with an innovative, elegant, or efficient solution with pseudocode is more important than getting the syntax exactly right in a particular programming language.
I give this advice to everyone on this sub who asks because it’s honestly the best advice ever. Buy this book (30$ rn on amazon):
Cracking the Coding Interview: 189 Programming Questions and Solutions https://www.amazon.ca/dp/0984782850/ref=cm_sw_r_cp_api_i_Ic6QCbQXY71DN
I give credit to the author and this book for landing me all my internships and a job at a FAANG. Read it, do what she says to do in the book, and if you still don’t get an internship, I’ll pay for the book.
For DSA I always recommend Cracking the Coding Interview (I think I’ve linked it at least 10 times on this sub... cause it works) it’s on amazon rn for 40$:
Cracking the Coding Interview: 189 Programming Questions and Solutions https://www.amazon.ca/dp/0984782850/ref=cm_sw_r_cp_api_i_QtjXCbCN7EEN4
For Big Data/Github Projects, you want to show you understand the pipeline from start to finish. Your projects should show you can find data, clean and prepare it, preprocess, train, test and then deploy. I’d say 99% of people start with the MNIST data set (people who know MNIST are probably laughing right now reading this). Most people you’ll be interviewing against will likely have an MNIST project on their github, so if you want to outshine them, follow this MNIST tutorial but DON’T put it on your GitHub (or do for now but remove it when you add more projects):
After following that tutorial, try to repeat the process but with other datasets. There are millions of free datasets available online, pick ones that are relevant to your hobbies outside of work, so when you interview you can start with “I really love blah blah in my personal time, so I decided to train a neural net to recognize blah blah, and so I found (or even better, created) a dataset for blah”
For example, I love going hiking and often wonder what kinds of birds I’m seeing in the forest, so I found a dataset of bird pictures that were labelled, trained a neural net to recognize them, and hooked it up to an app so I can now point my phone at birds when I’m hiking, and find out what species of bird I’m looking at.
As for the management/marketing thing, I can’t really give you any useful information so I’ll leave that to someone else.
Also, sorry for the formatting, I’m on mobile. Good luck!
I recommend going through the book https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850/ref=dp_ob_title_bk. It's got the technical stuff and also has sections on what to expect from a soft skills perspective.
There's a popular book I used that helped me get great job offers, and it was written by someone who interviewed many candidates at Google: Cracking the Coding Interview: 189 Programming Questions and Solutions. The questions are general enough that you could write solutions in whatever language you want.
> Is it just a balance between knowing the language, putting it to use and demonstrating the thought process to get there?
Syntax doesn't have to be perfect, but it should be mostly correct. I will say back when I was doing interviews sometimes they would be typing what I'm writing on the whiteboard into a compiler to try and find errors. And they might say "you have an error on line 3, do you see what it is?"
Another important thing is asking a candidate to design the big picture for something - let's say a phone app. That app has to send/receive data from a server, so what OS and webserver software would you use? And that server needs to store data in a database - what database would you use?
For things like that it's just drawings of boxes and arrows with names of existing tools you would use to build a project. (There's usually never one right answer, but some designs are better than others.)
> what do you look for when you hire someone? Impressive githubs?
I think it's great when someone puts a url to their github profile on their resume. I don't "deep-dive" into it, but I glance ahead of an interview to see what kinds of projects they've worked on, and how some of their recent code commits look. I might ask questions about that project in the interview.
> Also, is the market saturated or is it pretty easy to get a job?
Definitely not saturated. I would recommend staying away from the Bay Area and New York though. I considered job offers there myself, and I have friends who work still work there. But the cost of living has reached ridiculous levels there (e.g. a 2-bedroom home even 45 minutes from work can cost $900k or more).
Big companies like Google, Apple, Amazon, others have branches at other cities around the country. Find those smaller tech cities with more reasonable commute times and housing prices.
Check out page 11 of this report for average Software
Engineer salaries by city in the US, keep in mind it's 3 years old now (and doesn't include cash/stock bonuses which can be significant): 2016 Tech Salary Report.
Best advice I can give is check out this book from a library (or buy): Cracking the Coding Interview: 189 Programming Questions and Solutions. It's written by someone who worked as a software engineer at Google & Microsoft and did interviews.
Doing problems out of that book helped me remember some important things that were actually asked about in interviews. I ended up getting two job offers at the same time which allowed me to tell the other company what my offer was and get them to raise it quite a bit.
A great resource to keep your interview skills sharp is Cracking the Coding Interview: 189 Programming Questions and Solutions https://www.amazon.com/dp/0984782850/ref=cm_sw_r_cp_apa_i_cLXGCbRGMVVAS