Ask HN: How to get a job when you suck at coding?
64 comments
Seems like you are taking your interview rejections to heart.
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.
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.
Is Zuckerberg really considered to be a genius programmer? He's a very shrewd businessman alright, but Facebook is just a php website
'Facebook is just a php website'
....... ok then
....... ok then
As originally built by him, it was indeed just a php website.
>> it was indeed just a php website.
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
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
After I started writing my response I realized you might just be trolling but I thought people might think its interesting anyway.
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"
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"
I honestly was not trolling. Maybe naive, maybe posting without thinking about it much, but not trolling
Is it better to be a genius programmer, or an average programmer with an good understanding of the problem domain?
I am biased, but real understanding of the problem domain will beat programming genius every time. Very few problems require genius programming, but most require an acute understanding of the problem [1].
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.
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.
genius programmer? Not at all.
This is the best answer currently on this thread.
Build a small, real world project, and compare along the way to other good examples of the project. As small as Tic-Tac-Toe or a (nice) todo list app.
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.
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.
> That being said, casual hack projects and attempts on your GitHub is not bad. It means you are interested.
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
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
I 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 in evaluating the skillset of a software professional.
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.
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.
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.
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.
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.
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.
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.
Write them for everything (I'll note some exceptions). Use code coverage tools to see what parts of your code are not being hit by tests. You'll find some surprises there (tests not actually testing what they say they do). When something breaks write a test that would have found the bug, and then fix it. A good test suite will save you tons of time. If a piece of code is hard to test, it's bad code (lot's of branching logic, doing way too much in oe function/method, managing/changing too much state). Re-write it so it's easy to test.
However, don't test the compiler/interpreter and don't test your framework/libraries. Tests shouldn't look like this:
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.
However, don't test the compiler/interpreter and don't test your framework/libraries. Tests shouldn't look like this:
def test_foo():
foo = Foo(a=1, b=2, c=3)
assert foo.a == 1
assert foo.b == 2
assert foo.c == 3
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.
Are there any other areas you are passionate about? Particular industries that you may have more knowledge than the average coder? Having inside knowledge of an industry can help make-up for lack-luster coding skills.
For 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).
For 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).
Agree with this.
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.
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.
Domain knowledge is OP's best shot indeed, putting brain & hands into applications with a defined perspective may help OP extract value from his CS studies and, who knows, a vocation.
I have a M.S. in comp sci and a B.S. in biology. I would love to work in Bioinformatics. I'm currently a general developer.
Do you have any rec's for places to look for bioinformatics positions?
Do you have any rec's for places to look for bioinformatics positions?
Where are you located?
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.
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.
I was going to suggest something like that. I have worked with bioinformaticians before, and while the code is often very poor quality, it is also used for one off calculations, so doesn't need to be great in terms of maintainability.
How are your people skills? It makes a big difference to have a project manager who's got a decent understanding of the tech. I work with a great PM who didn't make it through the interview as a developer but was asked to join as a PM.
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!
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!
You don't need to know a a whole lot to do corporate dev. You just need to be agreeable and friendly.
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.
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.
Wow, yeah I agree on the psychology graduate thing.
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.
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.
This is my experience after working at quite a few large companies over the last 4 years since uni.
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.
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.
So, do you want a job ? Or want to get better at coding ? The two are not often essentially linked.
> 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.
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.
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.
I agree. Call it lean, and sell it as though you are solving customer problems via prototyping.
Software development involves many disciplines besides coding. You've already had some experience with automated test development, so maybe consider SQA. If you can read code and describe what it does in a natural language you might want to be a tech writer. If all else fails you can go over to the dark side and be a manager. It's not as much fun as coding but can be more lucrative.
> Is there any hope for me, or should I look elsewhere?
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...
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...
You 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.
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.
+1, been in the industry for about 15 years now, and I still suck at coding. At least I know how to indent it and make it look pretty!
Never 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.
Time to start thinking about your job hunt as a search optimization problem.
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.
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.
Great reply. You sound like a Data Scientist friend I know, I'm having the feeling like Data people are the coolest around.
Truly a great answer.
Try approaching the process a little differently. Sell yourself as someone who solves business problems, not someone that can just code in language X.
patio11 had a good post on this
http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
patio11 had a good post on this
http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
reading the comments in this thread makes me wonder where all these jobs that hire you for skills and interviews other than pure coding are.
Seems 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.
So, maybe you are just not passionate about programming? Realizing this is not a bad thing.
What kind of companies are you looking at? (And where are you located?). Don't look at the super sexy startups but consider enterprise crudware? A lot of times they have important problems - code that "just works" - but don't need the latest tech and have teams to handle different testing methodologies.
Practice this coding tests. Some basic ones will also make you a better engineer in everyday life.
See Codility lessons: https://codility.com/programmers/
See Codility lessons: https://codility.com/programmers/
Consider becoming a technical project manager. Among other things, a big part of your teams role would be to translate stuff the engineers are doing to other non technical people, departments or sometimes customers.
If 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.
I'm able to get a job most anywhere these days.
Create your own job. Find a niche and try to build a niche product. This require some kind of domain knowledge though
Contribute to open source projects.
I'm not convinced that is the solution to the problem in this case - If the OP is concerned about the quality of their code and has taken a string interview rejections to heart, having pull requests closed with minimal explanation would probably compound the issue.
don't take rejections personally. They aren't rejecting you. They are rejecting you-for-this-position-at-this-time. And they may reject you even if you pass all of their paper requirements if they aren't sure you are a "superstar" because there is implied risk in hiring someone that doesn't fit "perfectly" and isn't ready to commit code to production on the first afternoon.
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
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
>>> 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.
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.
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.
I've worked with plenty of people who suck at coding. Being good at coding doesn't seem to be a prerequisite.
While I agree with the sentiment, the poster seems young and would probably benefit from some positive feedback. Any suggestions for how (s)he may get a foot in the door somewhere?
Just to encourage you, and everyone else who feels this way sometimes, including myself, is the following. It's also true.
Sometimes the best performers start out as the ones who naturally are weak at the skill.
Take swimmers. How many top medalists came up from being kids with bad asthma?
So you do have some amount of control over your performance long term. Some amount of that is determined by the reaction you choose to hardship.
Another divergent point is, sometimes top performers don't get recognition in all arenas... So if an interview fails you, by all means see it as an opportunity to improve yourself ( one of many such opportunities, for sure ), but don't go imagining interviews are perfect.
Thanks!
Sometimes the best performers start out as the ones who naturally are weak at the skill.
Take swimmers. How many top medalists came up from being kids with bad asthma?
So you do have some amount of control over your performance long term. Some amount of that is determined by the reaction you choose to hardship.
Another divergent point is, sometimes top performers don't get recognition in all arenas... So if an interview fails you, by all means see it as an opportunity to improve yourself ( one of many such opportunities, for sure ), but don't go imagining interviews are perfect.
Thanks!
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?