Contribute to open source projects.
Ask HN: How to get a job when you suck at coding?
21–30 of 65 posts
Re: Ask HN: How to get a job when you suck at coding?
#22Create your own job. Find a niche and try to build a niche product. This require some kind of domain knowledge though
Re: Ask HN: How to get a job when you suck at coding?
#23Never do real world project and waste your time. You want a job? Go do leetcode for three months. Interview 3 companies, do leetcode, interview 3 companies and repeat.
Re: Ask HN: How to get a job when you suck at coding?
#24Seems you need to push yourself to do advanced things in your projects even if it's not strictly necessary. I always try something new even though there is no real need. I do that mainly because it naturally interests me, not because of career considerations.
So, maybe you are just not passionate about programming? Realizing this is not a bad thing.
Re: Ask HN: How to get a job when you suck at coding?
#25If you know you want to be in this field, work on marketable skills. I suck at coding as well and just worked on gaining marketable skills over the years.
I'm able to get a job most anywhere these days.
Re: Ask HN: How to get a job when you suck at coding?
#26I worked with people even less skilled. Java/.NET folks "programming" through clicking around and drag and dropping things in Eclipse/Visual Studio. Test folks with no idea on how to do any automation or even how to setup/configure a freaking Jenkins ("manual" testers). HackerRank/Codility is a very narrow specialization of computer science - dynamic programming. Pity that such narrow domain has become the benchmark…
I'm not sure you know what dynamic programming means. It's a very specific algorithmic design pattern. Those sites test much more than that one tool in the algorithms toolbox.
Re: Ask HN: How to get a job when you suck at coding?
#27I worked with people even less skilled. Java/.NET folks "programming" through clicking around and drag and dropping things in Eclipse/Visual Studio. Test folks with no idea on how to do any automation or even how to setup/configure a freaking Jenkins ("manual" testers). HackerRank/Codility is a very narrow specialization of computer science - dynamic programming. Pity that such narrow domain has become the benchmark…
Oh I remember working with "manual" testers tasked with automating software integration tests. Developers end up writing all the tests.
Sorry for such a juvenile question (I've only worked on small projects by myself before, but I'll be at my first internship with a large company ay the end of this month), but when should I even write unit tests? And should I write them for every function? Even the trivial ones? What defines trivial? Also, how about functions that write to a database? Should I refactor the code to separate the db writes and the computation, or just wipe the db after each test? I feel like unit tests could be a big help for my code, but how should I approach them? I just can't seem to justify the time it takes to come up with cases for everything.
Re: Ask HN: How to get a job when you suck at coding?
#28You probably do suck at coding, but that's actually OK. Lots of people suck at coding, even people who have been professional software developers for years.
It's hard to get that first job, but just keep trying. With a bit of luck you'll end up in a position where some people with more experience can mentor you. This will be a bit painful at times because you'll fail a lot, but you'll learn rapidly.
Do learn Python, it's a really accessible language and highly valuable in the marketplace. Just keep at it. If you have a degree in CS all of the knowledge is in place to succeed.
Re: Ask HN: How to get a job when you suck at coding?
#29Earlier quoted context omitted.
Oh I remember working with "manual" testers tasked with automating software integration tests. Developers end up writing all the tests.
Sorry for such a juvenile question (I've only worked on small projects by myself before, but I'll be at my first internship with a large company ay the end of this month), but when should I even write unit tests? And should I write them for every function? Even the trivial ones? What defines trivial? Also, how about functions that write to a database? Should I refactor the code to separate the db writes and the compu…
Always write them when the code will actually be used.
You typically test all "trivial" functions, partly because they're easiest to test and sometimes very easy to screw up. It can be much harder to properly test non-trivial functions. Often you want to split them into smaller, testable units.
Functions that write to database get tested. The tests spin up a temporary test database and run against that. See rails for an example. Often just against sqlite3 or something, but of course that's configurable.
You can justify them because tests save time. They make starting slower (especially when you're new to testing) and they make editing and altering much, much faster. They also lead to more reliable applications on average, and the ability to make changes quickly.
I don't follow my own advice, because I'm lazy. But I really wish I tested every bit of code that I could. And it's the stupid kind of lazy--testing would make my life easier, all things considered.
Re: Ask HN: How to get a job when you suck at coding?
#30Earlier quoted context omitted.
Oh I remember working with "manual" testers tasked with automating software integration tests. Developers end up writing all the tests.
Sorry for such a juvenile question (I've only worked on small projects by myself before, but I'll be at my first internship with a large company ay the end of this month), but when should I even write unit tests? And should I write them for every function? Even the trivial ones? What defines trivial? Also, how about functions that write to a database? Should I refactor the code to separate the db writes and the compu…
Next time you are fixing a bug, write a failing test which reproduces the bug before making any other changes.
Don't overthink it, automated tests should save you time. Write them to replace tedious manual tests. If you weren't going to test it anyway, don't bother.