Ask HN: How to get a job when you suck at coding?
1) I have a bunch of projects, but they're terribly boring and have ugly looking code. For example, I spent a year working on an ecommerce site. It does what it needs to do, but there were no smart decisions behind the back end. I never had to use design patterns nor data structures. I just pieced it together.
2) I have a lot of trouble with "HackerRank" style problems. I just finished one, an hour ago, called Codility. Even though I passed all the shown test cases, the final results showed that I got the following scores 13%/95%/0%. The 0% was a debugging problem that required a max of 2 line changes. I have absolutely no clue how I got a 0% there.
I've been trying to get a job anywhere, doing some programming, but all the rejections have destroyed me. Aside from the above coding problems, during interviews companies always seem to want experience in X technology. In one of my most recent final interviews, the VP grilled me about not having Python experience (I don't list it on my resume, but the job required it) and stuff I have barely any knowledge on. For instance, I said I did automated testing as part of a software engineer contract (2 months long), but it was not a job requirement so I didn't get any knowledge beyond writing simple unit tests for my personal benefit. The VP started asking me if I used stuff like path testing, error testing, and a bunch of other words I've never heard of in my life.
Is there any hope for me, or should I look elsewhere?
63 comments
[ 4.2 ms ] story [ 80.8 ms ] threadFor example, I work in bioinformatics and the coding problems I face day-to-day are by no means insanely difficult. If you have a decent grasp of biology, many people would love to employ you as a bioinformatician (pay is low however).
Domain knowledge is pretty useful in programming.
Coding is simply translating human language into computer language. Having some other domain that interests you is pretty helpful. I was into {cars, music, movies, video games, comics, architecture, sports, etc}. I studied and took the exam for Real Estate sales.
After a company I worked at had a security incident, I studied up and started applying my weekend time towards HackerOne (freelance security penetration testing) -- that helped me land a job at a security software company.
Do you have any rec's for places to look for bioinformatics positions?
I found my last job through Indeed. Typical channels work, job search sites, finding specific company career pages, etc. If you want to be in academia (which I don't recommend), then search for labs through university pages.
Even the Who's Hiring HN threads usually have a couple bioinformatics positions listed.
But aside from that avenue, It sounds like you may have been burned by interviewing for coding roles too early. In my experience CS degrees are great for computing fundamentals, but not so great for the real-life project experience that they'll be looking for. Building a few reasonable sized projects from start to finish is where you'll start to get the hang of design patterns, data structures and pretty code. You have to work through building a bunch of crummy projects at first before you start to realize where you can improve for the next ones, and where design patterns will start to make sense.
One thing to be aware of is sometimes the interviewer is totally into tech stack X and if you're not into tech stack X you're going to have a bad time, no matter how good you are, so don't take it too personally (but I know that's hard!).
Good luck!
This is not optimal. At the very least having knowledge of usual data structures and some common design patterns is kind of a requirement to get any decent development job. But I think you might actually know more about data structures/patterns than you think.
When working on the ecommerce site, you must have had come across some of these. Let's say the site was written in a high level language. For sure you have used/seen classes, array (or some higher level wrapper like lists in Python or slices in Go), hash maps. When fetching products to be displayed in the "storefront" part of the site, you might have used array/list/slice to store these.
I assume the ecommerce site used database to store data. So perhaps there was singleton pattern used to get a database connection (although this one is not the best example). What about dependency injection? How was configuration passed to objects?
Did some classes inherit from other classes? Did you see interfaces? E.g. a classic example is a payment method interface and then specific implementations for different payment methods (card, direct debit). If there are interfaces it's quite likely you will find a factory to get instance of a specific object implementing the interface?
Have you done any frontend work in JavaScript? If yes, you must be familiar with event listeners. There's a good example of observer pattern for you (queue where you register listeners for specific events) which is very important for event driven programming.
>>> 2) I have a lot of trouble with "HackerRank" style problems. I just finished one, an hour ago, called Codility. Even though I passed all the shown test cases, the final results showed that I got the following scores 13%/95%/0%. The 0% was a debugging problem that required a max of 2 line changes. I have absolutely no clue how I got a 0% there.
Try more of these courses, with practice you will get better. It's very likely you have missed something very obvious with the problem where you got 0% although you thought you got it right. Perhaps you haven't tried it with all example input values?
--------------
Anyways, I would start by taking small steps. Whatever job you currently have, try to become a better programmer by using new or better techniques while in your 9-5 job. Perhaps refactor some old part of codebase and use more effective data structures to make the code more efficient. Use objects and composition to make the code easier to read and understand. When working on a new feature, write unit tests alongside the code.
Also, when it comes to interviewing, you will also get better at it with experience. I have had quite a lot interviews in my career and I can definitely say I was pretty bad at interviewing 7 years ago. Today I am noticeably better and do very well in most interviews and whiteboard exercises.
Do an online exercise or two, study up on data structures and patterns, maybe create some small project to keep some fresh programming footprint in memory. Then go try more interviews, you'll do much better.
Don't do that.
Most companies go with the mode don't hire unless the candidate is a great fit, because they don't want to bear the cost of a mistake. I have failed a decent number of interviews, some on technical ground, some on personal ground. I still think I am not a bad programmer, despite the failed interviews.
Like you I also have doubts about my abilities despite 12 years of work history in the Valley. Impostor syndrome.
Realize that most people are not as smart as Zuckerberg, and that they don't have to be. Don't use geniuses as a measuring stick of yourself.
The most important question is whether you like coding. If you do, pursue it. Whatever deficiencies you have, you will mend as you get more experienced.
....... ok then
How quickly can one build and how quickly can it scale ? - Speed is the name of the game - is it not this rule which holds true when building things on internet.
Or else, most of top internet apps are just going to be php,rails,node web-apps
One of the reasons that facebook succeeded in the early days of social was because it was so stable and well built. Their major competitor in the early days MySpace was a notorious frankenstein's monster of different codebases that regularly went down and broke parts of the site.
The chasm that separates web site and web application is wide facebook has always been a very advanced web application. I have spent a good portion of my career building decent scale (not facebook scale) web applications.
Several years ago I hired a data engineer who's primary experience had been in building custom data sets for BI organizations in big companies. He happened to drop in on an early planning meeting for an RFP we were completing and heard what we were proposing the MVP cost to build out an internal application for a company would be. Shocked he asked the room "why would someone pay us this much to build an overblown website". Two years into the project he gave our wider team a presentation on his role in the project the architectural complexities and places the team had innovated on the last slide of the deck he wrote "Closing Remarks: We should have asked for twice as much to build something this complicated"
1. What works really, really well is pairing people with deep domain knowledge and some programming ability with those who just have great programming ability.
HackerRank/Codility is a very narrow specialization of computer science - dynamic programming. Pity that such narrow domain has become the benchmark in evaluating the skillset of a software professional.
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.
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.
However, don't test the compiler/interpreter and don't test your framework/libraries. Tests shouldn't look like this:
This test will never fail and won't tell you anything. Don't test your dependencies code if you're using active, popular packages. Test that your code passes in the right values, and handles any errors that could happen in a reasonable manner.The time savings you can get out of a good test suite are almost limitless. Good test save lots of time in development and prevent broken things from making it to production.
As you build it you will learn a) best practices and b) what "good" code looks like.
Your code will begin to merge with the style of the good during this project and will rub off on the next project you choose. Eventually you can do a green field project where there is no good example code of. Still, there will be examples of the building blocks, and how you architect other kinds of building blocks together, so you can then learn how to properly architect a project. Now you will be better than a huge amount of programmers because a) you care and b) you have built a few real world projects.
Speak to your strengths in the interviews, reference successful projects and what you did on them. Remove any absolutely terrible code from your GitHub etc. If that means starting from scratch, that's fine, because none is better than terrible, and most people agree a GitHub is not a prerequisite for most jobs. That being said, casual hack projects and attempts on your GitHub is not bad. It means you are interested.
Besides practical projects, be sure you have "completed your education" of classic comp sci topics -- just because you graduated from uni doesn't mean you know all of the classical topics and common interview questions. We all need refreshers. Try to focus on the parts that apply to real world projects, sure, but be sure to have the fundamentals down.
Good luck and stay hungry to find good solutions and take those hacker rank style challenges one a time. You will be great eventually, and able to get a good job soon.
This is great advice.
When hiring we are usually looking for "T-shaped" [0] skill sets which you haven't developed at this point in your career. But it starts with self-motivation and some sort of itch you need or want to scratch.
You can also contribute to other open source projects and those can appear on your github profile - code, tests, docs, tooling, resources/graphics, etc. Getting your commit accepted will normally allow you to go through some kind of review - especially on more active projects. Find something interesting with helpful committers. Lots of projects have 'need help' tags in their issue tracker.
[0] http://www.hrzone.com/hr-glossary/what-are-t-shaped-skills
Keep applying.
One more thing - it'd help to include how long you've been out of school, how many interviews you've been on, where, etc.
Right now you're in crybaby mode, masked as 'give me advice'. What you're really asking for is some sympathy from strangers.
Software dev is one of the easiest fields to get a job - try being a psychology graduate. Wipe them tears, figure out what information you actually need to get a job, ask, learn, apply, work hard.
Full disclosure: I was a psychology graduate.
I did a PhD, learned and loved stats (and R) and discovered that coding/development was kinda fun. Now I have a job with a well-known tech company doing data science.
But still, it would have been way easier if I'd gotten a degree in computer science. No PhD (and years of poverty) and I'd probably have a bunch more money.
But yeah, you should focus on what you can do, not what you (feel you) can't.
Remember that interviewing is both a negotiation and is highly subjective. If you do well, but aren't a great fit for the open req, you may find a new req is created for you. Follow up with HR if you get rejected for a position to see if there are any other positions that might be a good fit. Ask HR if they have any constructive criticism from the interviews.
Some interviewers will suck. Walk it off. I've been berated and given backhanded compliments by interviewers. You need to evaluate what you did in the interview and what you could have done better. Sometimes your effort will simply not make a difference -- you will need to learn to accept that. A mentor in the industry and your college employment office should be able to help you hone these skills and develop some new soft skills (the things that employers look for but don't show up as line items on resumes). Sometimes you just need confidence and you can get that by practice. Nobody likes rejections, but at least they come with practice.
Ask your interviewer what you could have done better. You may not get a satisfactory answer (interviewers and companies may create liabilities or violate policies by answering those kinds of questions), but it can't hurt to ask. I will spend a little more time than most interviewers to try and coax out anecdotes which show initiative and grit. These don't necessarily have to be coding related -- they are attributes of people, not only of coders. If those anecdotes aren't prepared by the interviewer, I politely suggest that those things are great to open with.
Programming is largely about learning on the job and less about memorizing APIs. I want someone who truly wants to work at the same company (is at least somewhat passionate about what we do), wants to row in mostly the same direction (or at least get to the same destination), who is humble enough to want to improve their skills, and who takes the initiative to fix issues before they become problems.
If you can improve your next interview by learning from a previous mistake, do it. Certainly brush up on data structures and algos before you interview. This will require knowing which one to use in a given scenario. If you interview for a Python position, know how the language compares+contrasts to languages you know. Spend at least a little time rewriting code into Python. Open the REPL and play around. Look at Rosetta Code[1] to compare a chunk of code in a language you know and your target language. Do some "code golf" (see HackerRank section) in the new language.
When you code on websites like HackerRank, make sure you iterate. Just because you completed a task doesn't mean that's an optimal way to solve it. Revisit tasks you have solved and try to optimize them. Try to find out how others have optimized them.
[1] http://rosettacode.org/wiki/Rosetta_Code
That's subjective and is up to you. I don't see any reason anything you've mentioned necessarily disqualifies you from a programming job.
It seems like you are taking the rejection from the VP to heart. Consider something else -- they decided to interview you knowing that Python was in the req and wasn't on your resume. Either the VP is disappointed at HR wasting his time or he was willing to give you a chance. If it was the latter, what could you have done to impress him / show some competency in the required field? Could you have offered to study the language and do an interview homework assignment? Could you have played up your current programming skills? Did you have enough time to learn the basics of the language before the interview?
> I spent a year working on an ecommerce site ... I never had to use design patterns nor data structures. I just pieced it together.
You built a project! Focus on the positive. Even better if you did it by yourself and on your own initiative (not as part of a class project). Unless you installed turn-key software, it certainly did require data structures (arrays, queues, hash tables / associative arrays / dicts) and algorithms (sorting, database lookups). Most basic web work only uses a very few vanilla ones. Unless you've already optimized it, you can probably find a way to do multiple things in parallel or batch some DB queries and then highlight that. Web sites frequently can benefit from memoization or caching. There are TONS of tricks for serving web pages faster[1].
There's a world of security-related topics surrounding ecommerce / web sites (XSS, SQLi, clickjacking, etc). There's also web fundamentals that I question interviewees (http protocol, auth, sessions, cookies).
> I passed all the shown test cases, the final results showed that I got the following scores 13%/95%/0%
Would you feel more or less competent if that 0% score was a bug on their end? Consider both forks of the decision tree. Consider the likelihood of each. Do something about it. Try to tweak your submission and iterate. Or focus on a different tool. Try "code golf" on HackerRank or try math problems on Project Euler.
[1] https://developers.google.com/web/fundamentals/performance/c...
So, maybe you are just not passionate about programming? Realizing this is not a bad thing.
I'm able to get a job most anywhere these days.
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.
See Codility lessons: https://codility.com/programmers/
If you have shipped this or finished this project for a customer then this is more worth imho then being good in those coding tests. For most tasks it isn't necessary to to make smart decisions. Just piecing stuff together so that a job gets done and/or a customer is satisfied is better then trying to be cutting edge.
When I first got started in my career I created 10 email addresses and used them to make 10 accounts on Dice.com I made 10 very different versions of my resume and started tracking the types of companies I got responses from. If I had an interview I would take notes about the style of the interview at that company and I tweaked the resumes to try to get more responses from the types of companies I enjoyed interviewing with.
Code problems are rough, I've built some cool stuff in my day but the anxiety of a quick solve on something I have never seen before breaks my brain. How can I have a 4am miracle at 11am infront of a whiteboard.
I have a strategy that has helped me land several jobs I really enjoyed.
Be up front, tell the company ahead of time your sense is that you consistently fail to demonstrate your skills with these types of problems some companies might tell you to fuck off and that will be it. But some companies might find a different way to get what they want out of you.
Additionally do as many in person interviews as possible for parts of the field you aren't interested in. In 2015 I started doing a search and felt rusty, so I made a dev ops oriented resume and interviewed for like 30 dev ops jobs. I didn't want to work in Dev Ops I'm a data guy. But it's amazing how getting comfortable going in for an interview will make you better at the interviews you want to land.
Also as someone who has been a hiring manager I have observed a funny problem that people with CS degrees have. Most early career CS people are really boring there is very little character to who they are. They are essentially a product of the curriculum that taught them.
Go build some opinions on something thats not part of a bandwagon trend then find ways to bring it up in your interview. It will help you be more memorable.
I'm a Data Scientist but I love interrogating app developers about how they feel about authentication methods like JWT and I talk about the parts of Angular that impressed me and finally helped me break through into Javascript. I don't use those things as answers to questions I just bring them up as part of conversation during the interview. It demonstrates that you have depth and can contribute beyond being a ticket monkey.
When you said you knew X and the VP asked you if you y, z he didn't need you to know those things he just wanted to see if you were a one trick pony
if you had said "I'm not familiar with y and z but I am really fascinated by v and w which I have studied on my own time can you tell me how y and z compare to v and w"
No matter how he responds you just go "Wow it would be really cool to get to work with you guys and see how you integrate y and z that sounds super interesting"
If a VP wont let that dialogue happen and they just want to power trip and interrogate you remember: the biggest mistake people make at car dealerships is forgetting that they can get up and walk out.
Its your job hunt take back the power.
patio11 had a good post on this
http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
You should optimise for passing the pub test not the programming test, and you probably don't want to work at a place that hands out codility tests.
Here's some anecdotes from my hiring experience:
My team and I once rejected a lad because we thought he would get bored after a couple of weeks. He got 100% in his codility, flawless technical interviews etc... He was too good for us and our trivial domain (this was a FTSE100, our services were consumed by 90% of the companies teams, in a very buzzwordy area).
Same company: two candidates, the first was technically better than the second. However no one who spoke to the first said they would be keen to go for a pint with him. The second was an absolute mensch so he got the job. He even said in the interview that he thought it was going terribly...
Once I interviewed two Devs on the same day, HR sent the offer to the wrong one and he accepted. Our team didn't know until he turned up on Monday morning.
Before my current gig I interviewed for a contract at a startup. The product was simple: just applying tech to a sector that is all man power based at the moment. This was the hardest technical interview I've ever had to give. I was asked to write the longest common subsequence algorithm. I did not write one line of code: eventually it turned into me watching the interviewer write the code. I was sure it was a disaster. The guy said he loved me, and wanted me to do the 'pairing' test again... All because of the pub test. I declined.
The interview for my current gig was a 30 minute chat on Skype. A team mate told me it was between me and another, but he was boring.