How to Land a Software Engineering Job?
The other day I read this piece by David Byttow on “How to land an engineering job”. And I don’t fully agree with his assertions.
I do agree, of course, that one must always be writing code. Not writing code is the worst that can happen to a software engineer.
But some details are where our opinions diverge. I don’t agree that you should know the complexities of famous algorithms and data structures by heart, and I do not agree that you should be able to implement them from scratch. He gives no justification for this advise, and just says “do so”. And don’t get me wrong – you should know what computational complexity is, and what algorithms there are for traversing graphs and trees. But implementing them yourself? What for? I have implemented sorting algorithms, tree structures and the likes a couple of times, just for the sake of it. 2 years later I can’t do it again without checking an example or a description. Why? Because you never need those things in your day-to-day programming. And why would you know the complexity of a graph search algorithms if you can look it up in 30 seconds?
The other thing I don’t agree with is solving TopCoder-like problems. Yes, they probably help you improve your algorithm writing skills, but spending time on that, rather than writing actual code (e.g. as side-projects) to me is a bit of waste. Not something you should not do, but something that you don’t have to. If you like solving those types of problems – by all means, do it. But don’t insist that “real programmers solve non-real-world puzzles”. Especially when the question is how to get an software engineering job.
Because software engineering, as I again agree with David Byttow, is a lot more than writing code. It’s contemplating all aspects of a software system, using many technologies and many levels of abstraction. But what he insists is that you must focus on lower levels (e.g. data structures) and be expert there. But I think you are free to choose the levels of abstraction you are an expert in, as long as you have a good overview of those below/above.
And let’s face it – getting an engineering job is easy. The demand for engineers is way higher than the supply, so you have to be really incompetent not to be able to get any job. How to get an interesting and highly-paid job is a different thing, but I can assure you that there’s enough of those as well, and not all of them require you to solve freshman year style problems on interviews. And I see that there is this trend, especially in Silicon Valley, to demand knowing the computer science components of software engineering by heart. And I don’t particularly like it, but probably if you want a job at Google or Facebook, then you do have to know the complexities of popular algorithms, and be able to implement a red-black tree on a whiteboard. But that doesn’t mean every interesting company out there requires those things, and does not mean that you are not a worthy engineer.
One final disagreement – not knowing exact details about the company you are applying at (or is recruiting you), is fine. Maybe companies are obsessed with themselves, but when you go to a small-to-medium sized company that does not have world-wide fame, not knowing the competition in their niche is mostly fine. (And it makes a difference whether you applied, or they headhunted you.)
But won’t my counter-advise land you a mediocre job? No. There are companies doing “cool stuff” that don’t care if you know Dijkstra’s algorithm by heart. As long as you demonstrate the ability to solve problems, broad expertise, and passion about programming, you are in. That includes (among others) TomTom, eBay, Rakuten, Ericsson (those I’ve interviewed with or worked at). It may not land you a job at Google, but should we focus on being good engineers, or on fulfilling Silicon Valley artificial interview criteria?
So far I’ve mostly disagreed, but I didn’t actually give a bullet-point how-to. So in addition to the things I agree with in David’s article, here’s some more:
- know a technology well – if you’ve worked with a given technology for the past year, you have to know it in depth; otherwise you seem like that guy that doesn’t actually know what he’s doing, but still gets some of the boilerplate/easy tasks.
- show that software engineering is not a 9-to-5 thing for you. Staying up-to-date with latest trends, having a blog, GitHub contributions, own side projects, talks, meetups – all of these count.
- have broad expertise – being just a “very good Spring/Rails/Akka/…” developer doesn’t cut it. You have to know how software is designed, deployed, managed. You don’t need to have written millions of lines of CloudFormation, or supported a Puppet installation by yourself, but at least you have to know what infrastructure and deployment automation is. (Whew, I managed to avoid the “full-stack” buzzword)
- know the basics – as pointed out above, you don’t have to know complexities and implementations by heart. But not knowing what a hashtable or a linked list is (in terms of usage patterns at least) hurts your chances significantly. Knowing that somethings exists when you need it is the practical compromise between knowing how to write it and not having the faintest idea about it.
- be able to solve problems – usually interviewers may usually ask a hypothetical question (in fact, one that they recently faced) and see how you attack the problem. Don’t say you don’t have enough information or you don’t know – just try to solve it. It may not be correct, but a well-thought attempt still counts.
- be respectful. That doesn’t mean overly-professional or shy, but assume that the people interviewing you are just like you – good developers that love creating software.
That won’t guarantee you a job, of course. And it won’t get you a job at Google. But you can land a job where you can do pretty interesting things on a large scale.
The other day I read this piece by David Byttow on “How to land an engineering job”. And I don’t fully agree with his assertions.
I do agree, of course, that one must always be writing code. Not writing code is the worst that can happen to a software engineer.
But some details are where our opinions diverge. I don’t agree that you should know the complexities of famous algorithms and data structures by heart, and I do not agree that you should be able to implement them from scratch. He gives no justification for this advise, and just says “do so”. And don’t get me wrong – you should know what computational complexity is, and what algorithms there are for traversing graphs and trees. But implementing them yourself? What for? I have implemented sorting algorithms, tree structures and the likes a couple of times, just for the sake of it. 2 years later I can’t do it again without checking an example or a description. Why? Because you never need those things in your day-to-day programming. And why would you know the complexity of a graph search algorithms if you can look it up in 30 seconds?
The other thing I don’t agree with is solving TopCoder-like problems. Yes, they probably help you improve your algorithm writing skills, but spending time on that, rather than writing actual code (e.g. as side-projects) to me is a bit of waste. Not something you should not do, but something that you don’t have to. If you like solving those types of problems – by all means, do it. But don’t insist that “real programmers solve non-real-world puzzles”. Especially when the question is how to get an software engineering job.
Because software engineering, as I again agree with David Byttow, is a lot more than writing code. It’s contemplating all aspects of a software system, using many technologies and many levels of abstraction. But what he insists is that you must focus on lower levels (e.g. data structures) and be expert there. But I think you are free to choose the levels of abstraction you are an expert in, as long as you have a good overview of those below/above.
And let’s face it – getting an engineering job is easy. The demand for engineers is way higher than the supply, so you have to be really incompetent not to be able to get any job. How to get an interesting and highly-paid job is a different thing, but I can assure you that there’s enough of those as well, and not all of them require you to solve freshman year style problems on interviews. And I see that there is this trend, especially in Silicon Valley, to demand knowing the computer science components of software engineering by heart. And I don’t particularly like it, but probably if you want a job at Google or Facebook, then you do have to know the complexities of popular algorithms, and be able to implement a red-black tree on a whiteboard. But that doesn’t mean every interesting company out there requires those things, and does not mean that you are not a worthy engineer.
One final disagreement – not knowing exact details about the company you are applying at (or is recruiting you), is fine. Maybe companies are obsessed with themselves, but when you go to a small-to-medium sized company that does not have world-wide fame, not knowing the competition in their niche is mostly fine. (And it makes a difference whether you applied, or they headhunted you.)
But won’t my counter-advise land you a mediocre job? No. There are companies doing “cool stuff” that don’t care if you know Dijkstra’s algorithm by heart. As long as you demonstrate the ability to solve problems, broad expertise, and passion about programming, you are in. That includes (among others) TomTom, eBay, Rakuten, Ericsson (those I’ve interviewed with or worked at). It may not land you a job at Google, but should we focus on being good engineers, or on fulfilling Silicon Valley artificial interview criteria?
So far I’ve mostly disagreed, but I didn’t actually give a bullet-point how-to. So in addition to the things I agree with in David’s article, here’s some more:
- know a technology well – if you’ve worked with a given technology for the past year, you have to know it in depth; otherwise you seem like that guy that doesn’t actually know what he’s doing, but still gets some of the boilerplate/easy tasks.
- show that software engineering is not a 9-to-5 thing for you. Staying up-to-date with latest trends, having a blog, GitHub contributions, own side projects, talks, meetups – all of these count.
- have broad expertise – being just a “very good Spring/Rails/Akka/…” developer doesn’t cut it. You have to know how software is designed, deployed, managed. You don’t need to have written millions of lines of CloudFormation, or supported a Puppet installation by yourself, but at least you have to know what infrastructure and deployment automation is. (Whew, I managed to avoid the “full-stack” buzzword)
- know the basics – as pointed out above, you don’t have to know complexities and implementations by heart. But not knowing what a hashtable or a linked list is (in terms of usage patterns at least) hurts your chances significantly. Knowing that somethings exists when you need it is the practical compromise between knowing how to write it and not having the faintest idea about it.
- be able to solve problems – usually interviewers may usually ask a hypothetical question (in fact, one that they recently faced) and see how you attack the problem. Don’t say you don’t have enough information or you don’t know – just try to solve it. It may not be correct, but a well-thought attempt still counts.
- be respectful. That doesn’t mean overly-professional or shy, but assume that the people interviewing you are just like you – good developers that love creating software.
That won’t guarantee you a job, of course. And it won’t get you a job at Google. But you can land a job where you can do pretty interesting things on a large scale.
If you want a job in the companies he listed (i.e. Google) you’d better know how to write algorithms from scratch.
…and never use them again after the interview
The post is titled “How to land a job” not “How to be effective at it”
It is never about the algorithms themselves. It is about the skills they leave in a developer after he learns to write fast and error less complex stuff on a piece of paper. They are looking for those skills.
Unfortunately, they don’t have an easy way to test for them. They don’t have a way to query you for those skills without basically giving you very very related tasks. A lot of the problems actually go down to recognising a famous/classic algorithm.
Also, they are very afraid of false positives. You will probably never ever write what they ask you to write, but chances are if you can handle this complicated thing, you will probably handle simpler things with no problem. A false positive is very rare to happen using this approach. The false negatives, however, is the price they pay for it.
(Source: myself, been on a few interviews, onsite included, and chatted with interviewers)
The false positive avoidance hypothesis Georgi posted seems entirely reasonable. I do share Bozho’s gripes with the method though. Further to them, spending that much time on algorithms leaves you with less time to spend on other things.
I’d say any level of knowledge on how businesses run and why they work that way would greatly increase the effectiveness of both in-house and tech company developers (said company is ultimately providing services to somebody else). This encompasses quite a wide range of topics covering human motivation and interaction, peppered with bits about how technology fits in with all that. This takes a long time to master and is almost entirely absent from modern university curricula.
Actually doing anything else that is not related to the absolute basics makes you a better developer, as it exposes you to how others think, whether this is in business, the arts or any random field (e.g. professional childcare..). There is a limited amount of time available to a developer to connect and appreciate the world around them. There are certain activities which will make that person appreciably better – knowing computer science basics to the level required by Google interviewers by heart does not, for me, come on top of that list.
Another very useful activity would be writing more often like Bozho does, so you don’t write in circles and repeat yourself like me.
I have one objection to the ‘false positives’ approach. The algorithm stuff is not necessarily “harder”, it’s just different. Implementing a red-black tree isn’t as hard as creating a continuous delivery process, neither is harder than designing a good API or writing well-tested code. It’s harder for those that haven’t been doing it on a daily basis, i.e. most software engineers.
Great advice at the end.
When you build a presence – have a blog, Github, go at conferences, meet with others. Anything that will not make you “a ghost”. This will not only get you more good job opportunities, but also makes the interview process much easier. Interviewing is very hard and there is never enough time to judge a person skills. Anything that helps will be considered a very big plus.
The reason why a developer should implement or attempt to implement at-least the most well known algorithms is probably because that is the only way he/she is able to understand the reason for the time/space complexity of a given algorithm.
You should also have a look at “programmer-competency-matrix” — whether you agree or not, it is a nice one
http://sijinjoseph.com/programmer-competency-matrix/
I do agree with the matrix. But notice how the top section is labelled: computer science. And basiedes, “Knowledge of advanced data structures” – I do have “knowledge” of them, I know they exist, sometimes I remember their complexity or their usecases. But nowhere in the table it says you should be able to implement one.
Yeah I am agree with Georgi. I am not a software engineer myself, but I am an engineer. Skill does matter. Another things? Not so much. In my case, for a fresh graduate, for example, if you know how to draw with AutoCad, Revit, 3dMax, Rhino, even if your GPA is about 2, I can guarantee you that most companies will accept you. All graduates have the same basic skill, and a standout skill is what most companies are looking for. Acquire those skills now!
https://tushirnitin.wordpress.com/2019/09/10/top-8-best-backend-frameworks/