In all seriousness, are suits still a thing for interviews? I don't remember the last time I heard of a company that was anything more than business casual dress (and lets be honest, many firms are much more casual than that).
I'm not in industry, but in CS academia interviews seem to be the one holdout where people do usually wear suits. People attending conferences don't (except in Asia), professors don't, the department chair doesn't, the interview committee themselves probably won't either, but there's a ~70%+ chance that someone interviewing will. Or at least a sport coat and slacks (I guess not technically a suit, but close enough). You probably don't really have to, but people tend to err on that side for an interview in an unknown setting.
I've hold for a while the attitude that if a company pays attention if I'm wearing a suit in a job interview, I shouldn't get a job there.
I don't have anything to complain about that attitude. In retrospect, it saved me from quite a few bad situations that my inexperience would make me accept. But things changed and it does not apply anymore (am not even technically working on IT anymore).
You'd probably be wrong. Cultural fit may be important, and you don't want to get strange looks on an interview. At the same time the company still might be quite good - as in "early Google"-like good.
Wearing a suit to job interviews that you would be doing with 7 years of experience working at a defense contractor is definitely a good idea, assuming you had a favorable experience at the defense contractor and were looking for something similar.
People that did not expect you to wear a suit will be fine with it because they will understand after that long in that formal of a workplace it is reasonable that you expect yourself to wear a suit to interviews and other formal meetings. (If they don't then they would likely be a poor 'culture' fit, once again assuming you liked your previous environment)
People that did expect you to wear a suit, are much less likely to hire if you if you don't.
I dress up a work, even going so far as to put on a tie some days. It has been mentioned by other engineers that they don't feel dressing up is the uniform of an engineer. But I say nuts to that, conformist. I dress up because I don't mind the look, I also like to draw a line between my private wardrobe and my professional one, it helps remind me I still work for "the man" and it drives me forward in the right direction. I say this as a counter point. I buy into the notion of wearing a suit (one that fits).
at my startup, the dress code is casual/sandals-ok except when meeting with clients.
as a rule, you never want to be under-dressed when meeting with people who you want to give you money. being wrong on this even once could cost you money, possibly a great deal of it.
if you show up in a suit and tie and everyone else is wearing sandals, the proper etiquette is to say "mind if i remove my tie?" and then remove your tie and jacket and unbutton your first shirt button.
instant business casual, which mixes fine with sandals. this also demonstrates social competence which may or may not be a factor in your hiring.
The obvious solution is to enquire about dress code at the company at the time of setting the interview. It doesn't have to be awkward at all - 'what do people wear to the office?' is a perfectly reasonable question. If they say 'business casual', then you can go +1 and wear a suit. If they say 'casual' then turn up in business casual. If they laugh and say 'whatever' then just turn up looking smart and confident.
Thinking that you always have to wear a suit is some type of throwback where the interviewer had all the power - I don't see interviews like that. Interviews should be a mutual meeting of people where they work out if they should work together. An inability to even work out what the dress culture is like before the meeting betrays, to me, an inability to get basic background research in place before any meeting.
So just ask, and then dress appropriately based on the answer given.
yeah, this works, until the boss's boss is also there unannounced, in a suit. meeting of equals? not anymore. it happens in both technical and executive interviews.
the point is not to fit in, the point is to minimize the risk of sartorial faux pas to zero. ZERO.
At many tech companies in SV (not even startups - tech companies like Amazon, Google, etc), it would be a sartorial faux pas to wear a suit to an engineering interview.
you have this impression because your typical engineer will wear a cheap, ill-fitting suit he bought the day before. this will make him look like a schlubby teenager trying to make a good impression among his cooler peers, instead of a manicured professional.
also, the suit isn't going to make you any smarter. you have to be competent. engineers also shy away from suits because they see morons wearing suits. correlation != causation.
show up looking like vint cerf, and the story is different. if you don't know who vint cerf is, look it up. he happens to work for google at this point in time.
I know who Vint Cerf is. One of my friends met Vint Cerf at Google, and I hope you see the irony in citing Vint Cerf. Vint Cerf is viewed within Google as a highly eccentric (aka weird), albeit brilliant, individual. If you come in looking like Vint Cerf for a standard engineering interview, you will look very weird and out of place.
A suit, even a well-tailored, modern cut suit, will be very weird in a software interview at Google.
Don't believe me? Spend a few hours at Google's Mountain View office to get a (admittedly superficial) sense of the culture there.
In my experience, it is very common for the recruiter and/or HR person to suggest what you should wear. If they don't, I would think it somewhat safer not to wear a suit to most tech interviews. (As much as I know y'all want to be all contrarian - "I'm not a nerd, I love looking smart!")
One time, I wore a suit to an interview (where the recruiter forgot to tell me to wear casual) and was literally mocked for doing so. Not just a good natured ribbing either, this was a good five minutes of really angry tear-down. And this was no startup, they had probably 200+ people. I got to stand there in front of maybe ten interviewers getting "dressed down" for my attire, like some sort of boot camp grunt. I lost all respect for my interviewers at that moment. If a group is so single-minded that me dressing up a little "too much" gets mocking, I'm happy working elsewhere. This same group also picked on me for using Linux instead of a Mac.
If conforming is so important to a group that someone dressing up or using a different OS is so offensive they cannot even pretend to be decent people, I'm happy to see that signal as early as possible.
But please, if you find yourself acting like this: turning down (or even openly mocking) candidates for their formal attire, please consider that you are hiring people who disregarded common wisdom about interviewing. You are hiring people who, when dealing with something as important as interviewing, decided "it's recommended I do x to increase my chances, I'm too cool|awesome|unprofessional to bother with that!"
That doesn't mean mock someone for being sloppy either, I'm just tired of clothes being such a big deal either way.
Wish I could stay at one company for 7 years. Or at least one city. Grass is greener and all that. I keep my cv updated even when at work, when deciding on tech to use or books to read I often think about how they will fit into my skills portfolio next time I have to job hunt. Feels really bad when I admit it. I hope I can change my luck and stick around because I'm really not a mercenary - I never started interviewing before leaving and I never treated my work like a card-punching factory job.
Way ahead of the game when it comes to wearing a suit. I've been wearing a tie all my career. And I used to work in games where it was highly inappropriate (but people there are very acceptable of all kinds of eccentricities).
I cannot agree with this at all. Conflating duration with personal growth is the problem here. People who get "comfortable" in a job and just keep doing it for multiple years, those folks will find that all of a sudden[1] things have changed and they don't have a job and they don't know what they want to do. But that is because they stopped growing, not because they spent too long in their job.
[1] "Sudden" to the person in the job but generally if you look for the signs its pretty obvious when some part of the company is going away.
Interesting look at how to stay relevant. As some other posters have noted, duration != irrelevance. That is, you can be irrelevant to your field after being at a company one year (if they have you doing mindless work that rots your brain), or still relevant even after a decade, if you have challenges.
I particularly enjoyed his point about interviewing once in a while, as that definitely sharpens skills that are not typically used in a job.
One thing I'd add is to keep your linkedin profile up to date all the time. This can help you know the local companies as well as folks who will be good to approach for a soft intro for interesting companies.
It's certainly useful when you find that someone accidentally made something n^5 instead of n and you need to explain to that person why they were very, very wrong.
Yes, this discussion happens with junior engineers. I keep finding O(n^2) code that should have been O(n) or O(n log n), and not just as an academic exercise, because it slows the website down.
I've run into plenty of cases where something was unacceptably, brokenly slow for a handful of inputs, and I wanted to figure out why, and then I realized "Oh, this bit of code is O(n^2) and it's running into a weird edge case with a large n", and then fixed it. I've also run into cases of regular expressions running in exponential time, which is always entertaining.
Big-o is about a specific class of optimization, and a theoretical understanding of it is important.
It is important to distinguish between asymptotic optimization vs. i/o optimization vs. code optimization.
I'd argue if you can't do the first one you're less likely to be able to handle the next two. Yes, you can do it intuitively to some extent. However, I think it's important to be systematic about it so we can have meaningful conversations about it beyond "doing it this way is slow and if we do it this way it's faster."
Big-O is an extremely easy way to sum up the running time of an algorithm. Sometimes it's misleading, but usually it's fairly informative, and with most code it can be worked out with just a glance or two. It's so simple and yet still reasonably informative that I'm not sure how it wouldn't be useful.
It's not that optimization is important, it's that understanding computational complexity is important. Why? Because it tells you when some kinds of optimizations might help, and when they likely will not. It helps you not write inefficient code in the first place, or it lets you use a simple algorithm when it will be sufficiently fast for your needs.
If you have a basic understanding complexity you almost certainly have seen and can more or less read the notation, as you probably needed it in order to develop that understanding of complexity in the first place. Whether you really need to understand some of the finer details, if you should have a tattoo of the Master theorem, well, I don't know.
Your comments appear to be critiquing the existence of the notation itself. I'm not sure what you expect the alternative to be. Words are used to communicate concepts.
Knowing the complexity of algorithms is important, correct? How would you go about teaching something like that to a student? Limit yourself to generic terms like linear vs exponential? Would that student have as nuanced an understanding of the subject compared to if he or she learned Big-O notation?
I'm involved in several (20+?) conversations a year where Big-O is used. It's mostly used as a very efficient shorthand for explaining the source of a performance or memory problem (instead of an algorithm being "slow" or "big", it's that it is an algorithm whose performance is acceptable for certain set sizes), and why a particular change is a good fit for the solution.
(Then again, I also am involved in a few constant-time optimisation discussions a year, where cache coherency beats out complexity as useful in an algorithm.)
I don't expect people to know the notation, but I expect that they can explain the underlying values for a particular algorithm.
If you just want to keep up to date on interviewing skills, make a habit out of doing interview-style problems. I don't think you need to worry about wearing a suit or writing on a white board. Careercup is a fairly consistent source of interesting interview-style problems; I find myself perusing it sometimes even when I'm not remotely interested in another job, because a fair number of the problems are interesting in and of themselves and simple enough to not take up much of your time.
There are also plenty of other sites, usually with a competitive edge, like HackerRank or TopCoder. Doing problems like these really is not a waste of time even if you're completely content with your job. While a lot of it may seem like algorithmic trivia, you'll internalize it sooner than you might expect, and then you'll start finding real-world uses for some of these tricks and, more generally, your "mental overload" when thinking through a piece of tricky code will gradually go down and down.
Re: interviewing frequently just for practice, that's great if you're in an area with an abundance of tech companies. I think that could be risky if you're in a city with just a few that you'd want to work at, though. You don't want to bomb an interview at the only other company in your city you'd want to work for just because you were rusty and used them for practice.
I couldn't disagree more. Interviewing is definitely a skill (beyond solving interview problems), and like anything - if you don't do it often you will not be very good at it.
You're free to disagree, but I don't think you responded at all to the actual point I made regarding "interviewing for practice" in a city where there are only a small handful of companies that suit you. I never said or even implied that interviewing itself isn't a skill.
So look outside your city or your comfort zone and interview with other companies.
You may be an exceptionally charismatic person that can get any job you want, and if so, you can ignore the blog post and my responses. Think about it though, are you working at your dream job? Is there somewhere else you really want to work? Wouldn't it suck to choke at that interview?
For me, part of the challenge with interviewing is remaining calm under pressure (your future depends on how you answer the following question...). After a couple interviews recently, I found it got a little easier to handle.
Interviewing is also a matter of selling yourself, and this is more than just answering questions or solving problems - you also need to be asking your interviewer good questions. If you lead them the right direction they can come up with answers for why you're the best person for the job. (Asking the right questions can also help you determine whether you really do want to work at a company.)
That's easy enough to overcome though. Just have mock interviews. Do it with friends, coworkers, or people from tech meetups. I actually find it much more embarrassing to interview with friends than with strangers also, so that helps with the "jitters" too.
I will soon have been at my current job for eight years. Whether that's too long or not depends on the flexibility you have in your job to keep growing your skills and responsibility.
This article strikes really close to home for me. The company I had worked for nearly seven years laid off a bunch of people and I could see where things were headed. Fortunately I've been doing mobile development and it's particularly in demand right now, so I was able to land a new job in a few months.
> Interview at Least Every Other Year
If you struggle to communicate under pressure like I do, then it's important to do this a _lot_ more often. My personal goal is a phone interview at least once a quarter and one or two in-person interviews a year.
I would also add another rule:
Don't apply to too many places at once. (Especially if you're currently working!) Keeping up with the responses, doing the interviews, and solving coding exercises can be a full time job in itself.
Edit:
The other thing I learned to do was to note all of the questions that I didn't have an immediate, natural response for. Some of them I was able to think of better answers later on that helped me in the next interview. Some I asked other people to see how they responded, and I realized I hadn't always interpreted the question correctly.
52 comments
[ 1102 ms ] story [ 1295 ms ] threadbeen to a few interviews where the interviewers were wearing a t-shirt, jeans and sandals.
But for the tech jobs most people want, it's a really bad idea to put a suit on for a interview.
Why? Are you saying that some company will give you a hard time because you are wearing a suit? That would certainly be humorous.
Humorous as in "Haha, I have no intention to work in such a place, ever".
I don't have anything to complain about that attitude. In retrospect, it saved me from quite a few bad situations that my inexperience would make me accept. But things changed and it does not apply anymore (am not even technically working on IT anymore).
People that did not expect you to wear a suit will be fine with it because they will understand after that long in that formal of a workplace it is reasonable that you expect yourself to wear a suit to interviews and other formal meetings. (If they don't then they would likely be a poor 'culture' fit, once again assuming you liked your previous environment)
People that did expect you to wear a suit, are much less likely to hire if you if you don't.
as a rule, you never want to be under-dressed when meeting with people who you want to give you money. being wrong on this even once could cost you money, possibly a great deal of it.
if you show up in a suit and tie and everyone else is wearing sandals, the proper etiquette is to say "mind if i remove my tie?" and then remove your tie and jacket and unbutton your first shirt button.
instant business casual, which mixes fine with sandals. this also demonstrates social competence which may or may not be a factor in your hiring.
Thinking that you always have to wear a suit is some type of throwback where the interviewer had all the power - I don't see interviews like that. Interviews should be a mutual meeting of people where they work out if they should work together. An inability to even work out what the dress culture is like before the meeting betrays, to me, an inability to get basic background research in place before any meeting.
So just ask, and then dress appropriately based on the answer given.
the point is not to fit in, the point is to minimize the risk of sartorial faux pas to zero. ZERO.
you have this impression because your typical engineer will wear a cheap, ill-fitting suit he bought the day before. this will make him look like a schlubby teenager trying to make a good impression among his cooler peers, instead of a manicured professional.
also, the suit isn't going to make you any smarter. you have to be competent. engineers also shy away from suits because they see morons wearing suits. correlation != causation.
show up looking like vint cerf, and the story is different. if you don't know who vint cerf is, look it up. he happens to work for google at this point in time.
http://pseudodoctor.com/2012/06/vint-cerf-is-the-architect/
scroll to the bottom.
I know who Vint Cerf is. One of my friends met Vint Cerf at Google, and I hope you see the irony in citing Vint Cerf. Vint Cerf is viewed within Google as a highly eccentric (aka weird), albeit brilliant, individual. If you come in looking like Vint Cerf for a standard engineering interview, you will look very weird and out of place.
A suit, even a well-tailored, modern cut suit, will be very weird in a software interview at Google.
Don't believe me? Spend a few hours at Google's Mountain View office to get a (admittedly superficial) sense of the culture there.
Now I just ask everytime, "tell me what to wear". If there's no recruiter, I'll cold email. Stupid clothes.
One time, I wore a suit to an interview (where the recruiter forgot to tell me to wear casual) and was literally mocked for doing so. Not just a good natured ribbing either, this was a good five minutes of really angry tear-down. And this was no startup, they had probably 200+ people. I got to stand there in front of maybe ten interviewers getting "dressed down" for my attire, like some sort of boot camp grunt. I lost all respect for my interviewers at that moment. If a group is so single-minded that me dressing up a little "too much" gets mocking, I'm happy working elsewhere. This same group also picked on me for using Linux instead of a Mac.
If conforming is so important to a group that someone dressing up or using a different OS is so offensive they cannot even pretend to be decent people, I'm happy to see that signal as early as possible.
But please, if you find yourself acting like this: turning down (or even openly mocking) candidates for their formal attire, please consider that you are hiring people who disregarded common wisdom about interviewing. You are hiring people who, when dealing with something as important as interviewing, decided "it's recommended I do x to increase my chances, I'm too cool|awesome|unprofessional to bother with that!"
That doesn't mean mock someone for being sloppy either, I'm just tired of clothes being such a big deal either way.
Way ahead of the game when it comes to wearing a suit. I've been wearing a tie all my career. And I used to work in games where it was highly inappropriate (but people there are very acceptable of all kinds of eccentricities).
[1] "Sudden" to the person in the job but generally if you look for the signs its pretty obvious when some part of the company is going away.
I particularly enjoyed his point about interviewing once in a while, as that definitely sharpens skills that are not typically used in a job.
One thing I'd add is to keep your linkedin profile up to date all the time. This can help you know the local companies as well as folks who will be good to approach for a soft intro for interesting companies.
I'm not asking why optimization is important, I'm asking about the notation that only seems to appear in interviews.
It is important to distinguish between asymptotic optimization vs. i/o optimization vs. code optimization.
I'd argue if you can't do the first one you're less likely to be able to handle the next two. Yes, you can do it intuitively to some extent. However, I think it's important to be systematic about it so we can have meaningful conversations about it beyond "doing it this way is slow and if we do it this way it's faster."
If you have a basic understanding complexity you almost certainly have seen and can more or less read the notation, as you probably needed it in order to develop that understanding of complexity in the first place. Whether you really need to understand some of the finer details, if you should have a tattoo of the Master theorem, well, I don't know.
("You" being whoever, not you).
Knowing the complexity of algorithms is important, correct? How would you go about teaching something like that to a student? Limit yourself to generic terms like linear vs exponential? Would that student have as nuanced an understanding of the subject compared to if he or she learned Big-O notation?
(Then again, I also am involved in a few constant-time optimisation discussions a year, where cache coherency beats out complexity as useful in an algorithm.)
I don't expect people to know the notation, but I expect that they can explain the underlying values for a particular algorithm.
There are also plenty of other sites, usually with a competitive edge, like HackerRank or TopCoder. Doing problems like these really is not a waste of time even if you're completely content with your job. While a lot of it may seem like algorithmic trivia, you'll internalize it sooner than you might expect, and then you'll start finding real-world uses for some of these tricks and, more generally, your "mental overload" when thinking through a piece of tricky code will gradually go down and down.
Re: interviewing frequently just for practice, that's great if you're in an area with an abundance of tech companies. I think that could be risky if you're in a city with just a few that you'd want to work at, though. You don't want to bomb an interview at the only other company in your city you'd want to work for just because you were rusty and used them for practice.
You may be an exceptionally charismatic person that can get any job you want, and if so, you can ignore the blog post and my responses. Think about it though, are you working at your dream job? Is there somewhere else you really want to work? Wouldn't it suck to choke at that interview?
For me, part of the challenge with interviewing is remaining calm under pressure (your future depends on how you answer the following question...). After a couple interviews recently, I found it got a little easier to handle.
Interviewing is also a matter of selling yourself, and this is more than just answering questions or solving problems - you also need to be asking your interviewer good questions. If you lead them the right direction they can come up with answers for why you're the best person for the job. (Asking the right questions can also help you determine whether you really do want to work at a company.)
> Interview at Least Every Other Year If you struggle to communicate under pressure like I do, then it's important to do this a _lot_ more often. My personal goal is a phone interview at least once a quarter and one or two in-person interviews a year.
I would also add another rule:
Don't apply to too many places at once. (Especially if you're currently working!) Keeping up with the responses, doing the interviews, and solving coding exercises can be a full time job in itself.
Edit:
The other thing I learned to do was to note all of the questions that I didn't have an immediate, natural response for. Some of them I was able to think of better answers later on that helped me in the next interview. Some I asked other people to see how they responded, and I realized I hadn't always interpreted the question correctly.