Ask HN: Is it possible for someone to not be cut out for software engineering?
I&#x27;ll try to answer your question and provide advice on each of your points but to your broader question, <i>yes, absolutely</i> someone can be not cut out for software engineering.  The people I know who were &quot;not cut out for it&quot; usually went to school for CS because &quot;that&#x27;s where the jobs are&quot; but it wasn&#x27;t necessarily where their passions were.  Several of them ended up in tech, but often on the sales or management side, not in software development.  Really, if you enjoy it and want to do it, you can <i>become</i> cut out for it.  You&#x27;ll simply learn what you need to learn to become successful.<p><i>- Working harder than others in college.</i> I don&#x27;t find this to be a particularly useful guide for anything other than your work ethic.  You had a respectable GPA and were willing to spend 60 to 80 hours per week on schoolwork.  So what if someone was able to eek by more easily? Maybe they had a leg up on you and got into it earlier.  Maybe they wouldn&#x27;t have put in that time if they needed to.<p><i>- Rejected interviews &#x2F; performance anxiety &#x2F; bad at algorithms</i> I can&#x27;t speak to working for &quot;the big 4&quot;.  I haven&#x27;t had any interest in doing that, myself.  There&#x27;s plenty of great jobs out there at smaller companies (including startups).  If you know you&#x27;re bad at algorithms, start studying.  Grab the ones from interviews that you&#x27;ve been bad at and learn them up and down.  Write example libraries of each in a few programming languages.  <i>Put them in a GitHub&#x2F;GitLab&#x2F;BitBucket repository.</i>  For the languages you&#x27;re targeting jobs in, find an open source project in the language that has a good community and participate.  Find a library you wish you had and write it.  <i>Put them in a repository.</i><p>Failing at interviewing at a top-tier company may be an indicator that you&#x27;re not cut out to work at one of those top-tier companies.  This sounds worse than it is.  Maybe you wouldn&#x27;t thrive in that environment as much as you&#x27;d like to thrive?  Wouldn&#x27;t you be happier with a job at a smaller outfit where you can grow, or maybe just a <i>different</i> outfit?  If Google&#x2F;Facebook&#x2F;whomever else you consider top tier is proving too difficult to get in to, look elsewhere.<p>I mentioned the whole repo thing and this is advice you&#x27;ll find all over Hacker News and elsewhere.  It&#x27;s not an industry fairy tail ... it works.  In your <i>cover letter</i>, specifically mention your experiences with the languages they&#x27;re looking for and link to relevant projects.  In your resume, provide a link to your GitHub ID or relevant ID on another site that has a list of your projects.  If you&#x27;re lucky, they&#x27;ll have already looked over some of your code.  But don&#x27;t count on it.<p>Having that available gives you the opportunity to creatively <i>deflect</i> those technical questions.  Remember, they&#x27;re asking you to demonstrate your knowledge.  Just because they gave you a whiteboard doesn&#x27;t mean you can&#x27;t demonstrate it differently.  Three years ago I took an interview[0] and was asked something algorithmic around multi-threading.  I had written a library in a private repo that handled message passing between two applications running on the same machine in a thread-safe manner and was directed to the white board.  I said &quot;I can do you one better&quot;[1] and mentioned a library I had written for thread-safe in-memory message passing between two applications running on the same machine where I not only had to solve that problem, but had to do so very performantly and had to address a number of other corner cases.  The interviewer let me log into my BitBucket account, plugged his laptop into the meeting room&#x27;s TV and after a quick apology about the code quality (it was actually pretty good, but not perfect which was why it wasn&#x27;t public, yet), I showed him the solution.  The upshot was that the <i>entire rest of the interview</i> was me walking through this code[2].  Why did you use a Mutex there? Why a ManualReset there but an AutoReset there? It was a <i>lot</i> of fun.<p><i>1)</i> Yes. When the benefit of getting into a top tier company outweighs the grief in trying to get there.  Maybe you&#x27;re there, maybe not?  Ask yourself <i>why</i> you&#x27;re focusing on these specific top-tier companies and find out if there&#x27;s a company not currently in your list that may fit those criteria would be my only advice here.<p><i>2)</i> You&#x27;re already doing this.  Post mortems are a good idea.  Another thing you can do is join some meet-up groups that have professionals in the parts of the industry you&#x27;re trying to get into.  After you get to know some people, you&#x27;ll find folks who do regular interviews.  Ask them to help you.  I used to give a <i>lot</i> of interviews and I have volunteered for interview prep many times.  A lot of anxiety around interviewing comes from social anxieties in general.  Joining a meet-up group will give you practice at introducing yourself and making a good first impression.  Walking up to random strangers at the super-market and striking up a conversation works, too (I&#x27;ve done this as practice, my self).<p><i>3)</i> My last two answers are my best advice.  A mentor would be helpful, but it doesn&#x27;t have to be such a formal mentor&#x2F;mentee relationship.  Get into some user groups&#x2F;meetups and meet others in software development who are where you want to be.  Make friends and those friends will become your mentors by default if you&#x27;re willing to seek advice, ask for help, and accept hard observations you may not want to hear.<p>And, most of all, hang in there.  It sounds like you really <i>like doing this stuff</i> and <i>want to do it</i>.  You&#x27;re already ahead of most of the people I used to interview.  Granted, it wasn&#x27;t at a top-tier company (though we were a huge internet company) and it wasn&#x27;t for the sexiest of development jobs (because that kind of attitude would have had you hired pretty easily if you were even close to qualified where I was at).<p>[0] This interview found me.  I wasn&#x27;t looking at the time but my dad&#x27;s advice of &quot;never turn down an interesting interview&#x2F;opportunity&quot; stuck in my head, so I was <i>very</i> casual in this interview.  That turned out to work in my favor for whatever reason and I ended up being offered the position at a salary figure I had never expected to get.  I didn&#x27;t take the job because it required moving out of state and that wasn&#x27;t an option for me at that time.<p>[1] This sounds really arrogant and I&#x27;m embarrassed to say that those were <i>my exact words</i>.  It could have <i>easily</i> been off-putting to the interviewer and I knew that, but because of the last footnote, I was overly casual and confident (if I didn&#x27;t get the job offer, who cares, I probably can&#x27;t take it anyway!).  The funny thing was, this group of people went from extremely formal in the beginning to casual by the end.  I felt like we were having a discussion like I&#x27;d have with other developers over beer, not like I was having my knowledge put to the test and when the &quot;thanks&#x2F;hand-shakes&quot; happened at the end, one of the guys said something along the lines of &quot;Thanks for your time, I really enjoyed this interview&quot; to me, which stood out since I can&#x27;t remember an interview experience that equalled it.<p>[2] I picked a perfect library and I ended up using this library in two other interviews as example code.  It was a tricky bit of logic where you had two applications, each in different security domains with both responsible for processing some data and one responsible for requesting and writing the data.  They used MemoryMappedFiles to share the data between them and had to manage situations where either side may not be in the position to be able to receive the data, so it covered a number of scenarios neatly in one library and made message passing with these odd requirements a simple matter of a few lines of code wrapped in whatever threading construct one wished to use.