Being a software developer these days is both good and bad. There are a lot of jobs available out there but there is a lot of competition too. If a company is known for looking after their developers well, a lot of developers naturally want to work for that company. So as a developer, you want to make sure you not only have the right skills, you also make a really good impression at every interview. And this includes not saying things that are arrogant, ignorant or inconsiderate.
In my role as an engineering manager, a hiring manager and an interviewer for more than 300 developers in the past few years, these are the things that I have witnessed developers say in their interviews which make them less favorable, even if their resume looks good and they did well at technical test(s). I'm sharing them with you here so you can avoid saying them and ace your next face-to-face interview.
Never say, "That is a stupid framework/technology/language - why would anyone still use it today."
There is always a reason why certain things were done in the way they were, especially in technology. Technology moves fast and things change very quickly. There is legacy code that hangs around for a long time especially in large organisations. You can voice out your opinion in a diplomatic way, but don't be arrogant about it and don't make fun or belittle those who are still using old technologies. Unless of course you are willing to rewrite and refactor that legacy code base in a week, then you can talk.
Never say, "Code reviews are a waste of time. Everyone should just write good code."
Firstly, code reviews are a good thing. If you have never had a commercial experience with code reviews before because you have just graduated or your previous companies didn't use it, it is ok to say so but as a technical person and a developer, you are expected to at least understand why it exists. Code reviews are not there just to detect code smells. It is also for knowledge sharing and for ensuring that coding standards and requirements are met.
Never say, "I would rather write new features from scratch than fix other people's bugs."
I have heard of this statement way too many times, and a lot of the times, these candidates are contractors who chase out greenfield projects and their contracts finish when those projects go live. I understand many developers want to work with a blank canvas and build things from scratch using latest and greatest technology but it does not mean they do a better job or they are a better developer. You can learn a lot from fixing bugs (whether they are your own or of other developers), optimising and scaling existing systems.
Never say, "I just get testers to do testing for me."
When you are asked about your approach to testing, don't think and imply that testing is not your job. You are a developer. You develop features and you build stuff. You have to test what you have built. Your approach to testing might be different to another developer's approach, you might not use Test Driven Development (TDD), you might not know about the latest testing tool in the market, but you must have tested your code in your career as a developer. If not, then you are not really a developer, you are just someone who cuts code.
Never say, "I don't want to use [software/technology/design pattern] ever."
When an interviewer asks you a question about a technology or an app or a software or a design pattern, it is usually because it is important to the role that you're applying for.
Say you're a front-end developer and your interviewer asks you an opinion on what you think about Internet Explorer. She probably already knew most developers don't like it, but she wants to know what you think about using it, building for it and what are some of the quirks that you've learned and so on. Why? Probably because it is one of the browsers that the company supports and their customers use it. If you say you don't want to use it ever, it means you are not going to be a good fit for the role.
And with that, I hope you learned a thing or two about what not to say at interviews and increase your chances of being hired for that awesome developer role. Always remember that,
What you say matters and what you don't say speaks volumes.
Top comments (21)
Nice article but touching on testing and saying your not a developer if you don't test is pretty harsh. Many many digital agencies bill per hour and testing is rarely/almost never a factor. The client doesn't care about tests, and certainly don't want to pay for them. Just my 2c. I worked in agencies for a while and have never written a test while with them, likewise as a contractor, most of my clients would never pay for tests so they simply aren't there.
On the flip side if your in a big business then yes, tests are pretty much mandatory, and even in some companies they have dedicated test developers. So it's quite a harsh statement to make saying your not a developer if you don't write tests, you simply aren't accounting for context. The rest of the points are good though 🙂
I agree. Context is critical. In all we do. There are books focused only on this: how we're biased to think in absolute terms when in reality things make sense only within contexts.
This applies to all her points, not just the one regarding testing. (e.g. code reviews are a waste of time if done on trivial code or without the involvement of both parties)
If no one else will defend you, I will. I work in a Korean company where everything is "GO FAST FAST FASTER". At the same time, planning teams don't know what the hell they're doing and don't do prototyping of their UX flow, design is then delayed, features are flung here and there, added, removed, backlogged, the scope constantly changing, and by the time the project is ready to hit the development stage the completion deadline is an hour away.
This is quite similar to how it is in a badly-run agency, and in these situations if you have devs that take pride in their work and manually test edge cases as best as possible while they work, then it can be done without major issues. Of course, testing is the way to go, but there are situations where it just isn't feasible and they would rather finish the project and figure out the bugs as they are reported rather than set up tests that are torn down and redone every other day along the way.
There is also the scenario of rapid iteration in a startup environment where a pivot could mean all your tests need to be redone. In a perfect world, we would all do TDD.
I hope I'll never have to maintain any code you, or someone like you, wrote...
Don't me mean. He has a point. In real life things like budget, time, purpose etc matter (as oppose to the software books and articles suggest we should always write).
Would I skip unit testing for life-critical or mission-critical software? I'd have to be crazy. Would I skip unit testing for my blog UI? Absolutely!
Have you ever worked in a digital agency? Do you bill your clients for tests?
I am a one if those QC testers in a big company. We get testing requirements from developers. If you don't test your software then it really isn't production ready, more like alpha or beta ready.
Big company = money to spend. Missing my point entirely about testing when working in digital agencies
I didn't missed any point, I asked how can you tell your software is ready with zero testing? How do you make sure you have reliable software? Are your customers your alpha testers, that's a really bad methodology imo, but hey if they're paying cheap I guess is on them anyways.
Most agencies I've worked in have had their own CMS that they've manually tested, which is bad I know, but not my choice. It's reliable because most of the time it's been in production for a while any issues that do crop up were fixed.
Alot of software needs tests, but generally the customers agencies get want a cheap solution. Tests simply aren't budgeted.
I must add, I agree tests should be there, but it's not up to me, or the guy next to me, it's up to the client if they want to pay for the additional time, and 99% of the time that isn't the case. That's what you get when it's cheap, you get a bare minimum to pass as a website.
Bad practises are rife, my problem that I pointed out with this article is that not everything is unit or feature tested, sometimes it's just not feasable because the end client doesn't want to pay and are working on a budget, adding tests to apps costs time and money, which they don't have alot of the time.
You're right, it is on them, I can put an argument for them easily enough, but it's not my money to spend and my boss wouldn't sign off on it because it costs him money.
I think this one "That is a stupid framework/technology/language - why would anyone still use it today." is indeed not really the way you say it. But I think it's important to make your preferences in frameworks clear. I always pick a sentence like: "The right tool for the job" or something like that to nuance it.
Yea good way to say it.
I cant resist but ask...
Based on your experience how much more childish/spoiled are developers in general in comparison with other professions?
My assuption is that those sort of statements are easily accepted just as a scapegoat for somewhat lack of maturity.
😂
You see this could be used in your advantage, you just need to know a little bit of child psihology. Next time try with these questions for those people:
Actual people that dont want to work with technology X are never going to show up on the interview in the first place...
Pretty much common sense: these are things the interviewer doesn't want to hear, not necessarily all true, depends on the setup, context, etc.
Most of the hiring managers out there are on autopilot and often don't stop and think, so yeah, if you really want the job, and don't care about anything else, don't bring these up.
You should've just said that it worths to be diplomatic and not confrontational. Also internet explorer is fine nowadays, finally that it's called Edge and based on webkit. IE11 is also bearable to an extent if you need to support it, much better than the old IE6 days.
Actually that should be considered okay. Usually there is a description on what technologies the job is about and you have to draw the line on things that are beyond that. Otherwise you will end up doing the job for two or more.
If HR kicks you out, because of that (instead of updating the skill matrix) then this is anyway not the place you might want to be.
I understood the article as TDD a requirement and didn't take into account manual testing. I perhaps interpreted the article differently to what it was meant to. Sorry
Maybe maybe. I guess we'll never know the real meaning haha. Have a great weekend!
If a developer goes to an interview and says something listed on, he don't deserve be called developer.