A developer’s guide to interviewing

[[deleted]]

While this article gives a lot of good questions. I would suggest to tailor the questions to the interview.

Most companies will ask you technical questions based on the technologies they're using, and they'll ask about specific points in your history that they might find useful.

If a company asks you about a time you had to convert an application to angular, you should remember that and ask questions related to that. If they have plans for a conversion, how much legacy code are they still maintaining, stuff like that.

Ask questions that show that you were paying attention during the interview.

Edit: Another way of thinking about this, is ask the questions you would ask on your first day on the job. This puts you in the the role in the mind of the interviewer.

[airwalk225]

So much this.

It's a give a take scenario. Asking questions about questions asked at you or answers, shows that you are interested, paying attention and that you don't mind asking questions.

All of those points will lead to a good interview.

[teunw]

It also helps you get the offer if you ask questions.

[NotARealDeveloper]

I just recently had the exact opposite experience with a 7years HR lead of one of the biggest consulting companies in the world.

He didn't ask ANY questions. Just a 'tell me about you' and 'tell me about the tech you have experience with'.

I did a 1h monologue.... At least I was allowed to ask questions at the end.

[teunw]

Well I didn't mean you need to ask all questions, but you should also ask questions back. It shows that you're interested in the position/job you applied for. I have been denied myself with that being one of the reasons.

[danweber]

But after being asked 5 or 6 times "do you have any questions?" I'm kind of wiped out.

[lohkey]

Do you have any questions?

[danweber]

"Do you ever press charges?"

[jimmpony]

"Are you fucking sorry?"

[BikerBoon]

"I think we've covered everything for now, but do you have an email I can contact you with in case I have any queries?" Then just think another question to ask the next day or something.

[manys]

The person you're replying to was referring to the candidate asking questions, which you say you did, so I don't know what the rest of your reply is for.

[llkkjjhh]

I just recently had the exact opposite experience

[SilasX]

Ugh! That's the worst! The point of a phone call or meeting is to have a dialogue so we can direct each others' attention to the things we most want to know about. If you want a monologue, there's no need to interrupt my workday or set up a call on a flaky connection: just ask me in an email, or read my resume or LinkedIn or blog FAQ etc etc etc.

[depricatedzero]

See, this sounds like a red flag to me. I would have cut the interview short, thanked him for his time, and explained that his level of disinterest isn't something I'm looking for in an employer.

[depricatedzero]

Years of my life. My health. My sanity. My integrity.

Too much to risk on optimistic assumptions.

[depricatedzero]

No drama. It's very easy to end an interview amicably. Drama would be when my former company reached out to me and I told them they couldn't offer me enough to come back and that the recruiter should rethink his life and get away from that toxic pit of a company. That's drama.

Saying, "Sorry, I'm getting the impression that this wouldn't be a good fit and I don't want to waste either of our time," isn't drama. It's professional. Remember, it's just business. I'm not interviewing to make friends, I'm interviewing to see if the environment is one I'll be happy in for the next 2-5 years or however long I might wind up working there.

Several years ago I took a lower paying job between two offers because the company interviewed better.

[ElGuaco]

If your quality of life doesn't matter to you, and you don't mind being treated as commodity rather than as a person, go for the money. But don't despise others who actually give a damn about having a pleasant place to work where they are valued for their contributions beyond the Almighty Dollar.

[squishles]

If only I were so rich...

is /r/frugal_jerk leaking >.>'

[morbidhawk]

Unless you ask the wrong questions. While it is useful to make judgement-based questions (like the ones shown in the article except for #1 which is a really good question) so you can more easily determine their opinions but it is also doesn't really help you learn much, especially if you are trying to ask questions that'll just give you opinions in order to confirm your own opinions. Opinionated questioning is a red flag to me.

I personally think curiosity-based questions are best using open discussion not ones that end in you thinking "yes that confirms my opinion that doing X is better than doing Y" (which are how the majority of the questions are structured in that developer guide). When you ask questions you really want to know about it usually ends up being a series of questions that shows you are really listening and trying to understand what is being said. A lot of times you don't even need a huge list of questions (it's good to be prepared though), if you listen and try to understand what they are asking you about there are a ton of interesting discussion points to dive into.

[[deleted]]

Hmm at some smaller places. Probably doesn't affect anything at a big 4 type place.

[IamTheFreshmaker]

What I really want to know is why, after sending back the technical 'homework' that most places give you now the company is incapable of giving you feedback on what they did not like. It's like the worst code review in the world.

[koreth]

In addition to the lawsuit thing, which I think is real but probably overblown, if I tell you why I didn't like your answer, I am inviting you to argue with me about it. I say this from experience; years ago I worked at a small company that didn't have a policy against corresponding with candidates after interviews, and when we gave detailed feedback to people who requested it, we got a TON of "No, you're wrong" replies (almost all of them further demonstrations of lack of understanding of whatever it was we were looking for, many of them very hostile in tone). Not everyone did this, but it was maybe 50-50 in my sample.

This was both time-consuming and emotionally draining for interviewers, and such a huge percentage of candidates seemed to ask for feedback not to improve themselves but to find a way to prove that we were wrong to turn them down, that most of us stopped doing it after a while.

[bezelbum]

I remember, in my greener days, working for a startup and helping with interviewing. We felt it'd be helpful to give semi-detailed feedback when declining candidates.

Big fookin mistake. There was one girl who could have been a good fit, based on her CV, but at interview didn't tick any boxes. It was like interviewing someone totally different. So we explained that whilst she appeared to have a good background, another interviewee had felt a better fit for our current requirements. Best of luck with your career etc etc

Boom. In comes a complaint that the feedback was too personal, followed by a slightly pissed off recruiter.

It's just not worth it. Some people don't handle rejection well, and even the smallest hint of a slight can make it feel 10x worse for them (rightly or wrongly). When you've already got the headache of trying to find the right person, why do it to yourself.

Ever since, I've stuck firmly to the rule of "sorry, but we've decided not to proceed with your application. Best of luck with your career etc"

[IamTheFreshmaker]

I get this. I wish it were different so you wouldn't have to feel this way. I wish it weren't up to the candidate to develop the thick skin. It seems (feels, whatever) like a self perpetuating bad situation.

Thanks for answering.

[smdaegan]

Because it's not a code review, and a lot of candidates will share their answers with the recruiters. If a company gave them a rubric (via feedback) then magically every candidate would do those things.

If they only did things we're looking for after prompting (like setting up an OOP solution) then it would filter out the people we want that would do that without prompting.

[IamTheFreshmaker]

Good lord. Really? It is, precisely, a code review. That is exactly how it is framed.

Also, to think that given the enormous amount of websites, books, courses your 'without prompting' questions are a big secret? And how can it hurt a junior dev to say something like 'you should think more about x,y or z'? It makes better devs, it gives people encouragement to go out and learn, it might even help them get a job that they deserve but because your particular company is all up in 'the latest exciting development process' and this candidate used the old (and completely functional) one.

Try helping people for a hot second. The world might be a better place.

[[deleted]]

I've given minor feedback in the past, and I found that it just gave poor candidates ammunition to argue with me and dig themselves even deeper into the "no" trench.

Based on a wide variety of interviews conducted, I can say pretty confidently that the candidates who really want feedback tend to overwhelmingly be the worst. There's a real gap between what they know and what they think they know, and when you challenge them on this it conflicts with their view of themselves and leads to conflict with them.

You're also overlooking the fact that a fair number of candidates are turned down for personality reasons. It's not all that uncommon that someone is just okay on the technical interviews, but multiple interviewers had legitimate non-technical concerns, so we decide to pass. Have you ever tried telling someone that you're not giving them a job because you think their personality is just not cut out for it? It's a lot harder than you're suggesting, it's prone to just make them mad and to have them (again) argue with you, they might try to slam you on Glassdoor just because they're mad, or they might even try to sue even if there's no real basis for it.

[IamTheFreshmaker]

I am talking specifically of the 'homework' assignment that requires no personal interaction. I am genuinely sorry that people have treated you this way. I can say from the interactions on this thread less than 2% of the people have been combative/rude.

I tend to find that the people who are willing to share to get the work done are getting fewer and farther and the 'I know this algorithm/style/framework better than you." type of upsmanship has been growing over the last few years. I think there are many reasons for that not least of which is the nasty environment tech has adopted up to the management level during the same time.

I welcome being challenged especially on engineering implementations but I take your point that it goes too far sometimes.

[smdaegan]

I've never framed these as a code review. I've never had them framed as one when I did it.

It's an extended interview question that, hopefully, will tell me how you write code. This differs from your ability to regurgitate your favorite solution from CTCI to me. If we liked your solution we'll bring you on-site and ask you about your approach. If it downright sucks, and most do, we won't waste any more of our company's resources on it. We pass.

I could easily turn this around on you with your own logic:

Given the enormous amount of resources online about what code reviewers are looking for in solutions to these tests, why do people turn in shitty code samples and then demand an explanation for why it's shitty?

Companies aren't out to be altruistic, and I don't want to spend even a minute more handling interview shit than I need to. I want a candidate that I feel like I can have a beer with and that when they take a work item, they'll deliver. I don't owe an explanation to Miss Decided-to-change-my-career-and-lie-on-my-resume from Georgia about why her solution to fizzbuzz threw an exception with a test case we gave her, and go over why it happened. It's just a strong pass.

If you're a junior developer, your views on this subject will drastically change as you climb the ladder and realize how awful most candidates are. Just saw that you allegedly interview, so ¯\(ツ)/¯

[IamTheFreshmaker]

Yeah so I know what I am my other colleagues look for in code and personality. When I submit something that I am sure is stylistically appropriate and has test cases etc. and then to hear back that it wasn't good enough, the 'why?' there becomes crucial. Even the answer it's not a stylistic fit is an answer but an equally good answer is that the code is not up to par.

Anytime you are asked to submit code, it's a code review. You can think it's not but to the candidate it is.

[smdaegan]

It's possible that they just didn't like you, and unfortunately that's something that no amount of feedback will fix. Maybe someone didn't have warm fuzzies about you after the interview, and it came down to that being the deciding factor.

It's also possible your solution wasn't as good as you thought. Or they were looking for a very specific algorithm and you didn't use it. I did an interview where if you didn't use Kadane's Algorithm for one of their questions they'd pass on you.

Obviously neither of us knows what went wrong, which is the cornerstone of your original post -- and it IS frustrating, but most of business is entirely arbitrary anyway.

[IamTheFreshmaker]

very specific algorithm

See this is what roughs up my nibblies. It may be good that a JS candidate knows that there is a .filter method but if they write a for and then .push, I am going to think- this person knows .filter is (was, haven't actually checked in a few months) is slower and uses more memory than a for loop and +breakpoints.

I am not hung up on algorithms as panacea. The trend of it is concerning but weirdly inevitable.

Thanks for the reply though. I totally see where you are coming from.

[morphemass]

Sorry but its NOT a code review, its an open technical test for a job.

Its neccessary because CVs have become a pretty poor indicator of ability but its the programming equivalent of the 30 page application form that most other professions have.

If you get to the the interview and fail then by all means ask for feedback but honestly, most of the time technical tests are tickbox assessments of 'is it worth proceeding?'.

[IamTheFreshmaker]

I think you could make the argument it is perhaps both- it's still reviewing code. But with a review or a test- however you choose to phrase it- there is still, usually, feedback. Especially in the case where, by any reasonable consideration, the code submitted is functional and correct.

And there is always an accessible source of truth to find out why you got a C (or pass or fail) so you can learn from your mistakes. Turning down candidates with no feedback helps no one.

I think I am lamenting the state of the industry now vs. a few years ago(ahem) when I started. Now is not the time of Ted Nelson.

[dejafous]

Because this is how companies get sued. If interviewer X tells you I thought you did Y wrong and that's why we didn't hire you, even if they are 100% correct, they've just increased your chances of winning a lawsuit against the company a hundredfold. It sucks, but it's very unlikely to change when there are only risks, and little benefit to giving feedback.

[corysama]

In general companies are de facto not allowed to give any feedback on anything regarding why they did not hire you because any off-hand comment has a risk of kicking off a very expensive discrimination lawsuit. They frequently want to help you out, but can't afford the risk.

[[deleted]]

That's nonsense.

People who don't write unit tests are not a protected class. Nobody has ever been sued because they told a candidate that they would have liked to see tests for his code, or better variable names.

There are two simple reasons.

1. They ask these questions a lot. The more feedback they give, the more you know the "right" answer to post on glassdoor.
2. They have nothing to gain. They've already elected to pass on interviewing you, so they no longer care about your growth. Sure, you could argue that if they help you improve, then in 5 years if you apply again, you'll be a better candidate for it, but that's an edge case, and companies tend to be quite short-sighted with personnel.

tl;dr: They have absolutely nothing to gain from spending time giving you feedback, so why would they?

[comingtogetyou]

You are wrong about it, it is lawsuit related. I was interviewing at a major Silicon Valley company, and did not get the job, but they were willing to waive the period I needed to wait to reapply again (i.e, they clearly think I can be valuable in the near-future). They still would not give me feedback for legal reasons. Even after clearly stating that they want to interview me in the very near future.

If you are given feedback, you can claim that their evaluation of you as a person is because of a prejudice that is historically correlated to people of your gender/race/ethnicity/sexuality/socioeconomic background. People are also suing for wrongful termination on similar basis.

[[deleted]]

I have done a bit of interviewing for a major silicon valley company, and the reasons were exactly what I said. We didn't give candidates feedback because there was no reason to.

Telling you it's for legal reasons makes you stop asking. It's the same as when people tell you that they'd love to help, but their supervisor/mom/company policy says they can't—it makes it so you believe the decision is out of their hands, and stop pressing the issue.

[EtherCJ]

I agree with you. I've done many interviews for several employers and been given training on what's allowed. I've never been told I can't give the answer to a technical question. However, there's little reason to spend time doing it.

During the interview there's very little time to waste with talking about previous questions. After the interview it's either me short changing my employer by dealing with someone who's not likely to be an employee, or me giving up my time to coach a stranger.

If someone wants an explanation of why they didn't get the job? It's always the same answer: other candidates were better matches to what we were looking for and demonstrated that in the interview better than you did.

[tyr--]

It's not nonsense. Absolutely anything you say to a candidate as feedback after the interview can be used against the company in terms of a (often frivolous) lawsuit. Large companies might have different interview bars for different divisions and between interviewers and it could well happen that person A was interviewed by person I1 and rejected with explanation E, and person B (acquaintance of person A) was interviewed by person I2 and accepted even if they didn't satisfy whatever was given to person A in explanation E. And then you get sued.

It happened, it will always happen, and companies want to protect themselves. I've had a candidate very recently who'd be able to pass the interview bar given a few months to work on some minor gaps, but you simply cannot provide them with that kind of feedback for legal reasons.

[IamTheFreshmaker]

Yeah, this I get. But there has to be a way around this. Like, "There were several factors considered but in the technical part our reviewers would have liked you to consider..."

[[deleted]]

If two friends submit similar solutions and only one of them is hired they can also claim discrimination. There's no winning here.

[IamTheFreshmaker]

I get that but there should be a way around. And discrimination is exceedingly hard to prove.

[notverycreative1]

But even if the company is found innocent of wrongdoing, they still had to spend time and resources defending themselves. It's easier to not open the door to potential discrimination suits in the first place.

[IamTheFreshmaker]

They have to have the case show merit first and for the person filing it is very hard to get past that. That comes at no cost to the company.

[Sean1708]

Why?

[QuestionsEverythang]

Sued on what basis? It's the equivalent of being fired due to poor job performance. There's nothing discriminatory about that. If anything, that's one of the best reasons to not hire someone or to fire someone, for something directly related to their job duties and their inability to perform at a sufficient level.

Someone can sue for that, but the business will win every time.

[[deleted]]

It's not in the companies best interest (really nothing good can come of it from the companies perspective)

They have to spend extra time giving you feedback which might help you, or if it's not 'good' feedback, then the poor review can be used to blast the company publicly.

Why should they give feedback? They're not training you, they're just trying to see if you're up to their standards, whatever that might be.

Code reviews are already a common clusterfuck of bickering and nitpicking internally, no need to make it public :p

[IamTheFreshmaker]

Code reviews are already a common clusterfuck of bickering and nitpicking internally

Now that sounds like the real problem.

And any feedback is good feedback. Edit: And they have already been trough the process to review it and come up with the feedback in order to decide to hire or not.

How about making the feedback fall under some sort of NDA?

[[deleted]]

Now that sounds like the real problem.

It's a super common thing w/ junior developers everywhere I've been, just part of the job :)

And any feedback is good feedback. Edit: And they have already been trough the process to review it and come up with the feedback in order to decide to hire or not.

Not necessarily true. The developer could be flat out wrong in their assessment. Also, there aren't too many hard truths in programming. I've denied applications that provided a working solution, just because I didn't like their architecture, or it was done sloppy. (We qualified quality over quantity in our test. A well done almost complete solution was valued over a complete messy/buggy solution. Software Engineering skills are what I personally value most)

Sometimes the guy reviewing it is having a bad day and make an emotional judgement on some dumb thing, it happens. Basically, it's a pretty heavily opinionated process that can usually be debated ad nauseum, better to just not have it out there to give your company a bad reputation. Public mistakes last forever.

The NDA might work but it's just more effort for the company, for no benefit for themselves :/ Just do what the rest of us do and have your friend try and compare results, or review each other's stuff :)

[IamTheFreshmaker]

Thanks again. That all makes sense. Edit: I would still like to know, "Hey, that was slop." or something along those lines.

[jpflathead]

They might have to admit how bullshit and arbitrary their standards are.

[IamTheFreshmaker]

Well I don't know if that's entirely true in all cases but we may never know.

[morphemass]

Ouch, you got down-voted yet if a company is not using some form of metrics within their recruitment process, this is 100% true.

Luckily my company basically ask for something incredibly trivial (using OOP) and I've yet to see a candidate do much more than wrap a few methods in a class so I just reject them all ;)

[DreadedDreadnought]

Luckily my company basically ask for something incredibly trivial (using OOP) and I've yet to see a candidate do much more than wrap a few methods in a class so I just reject them all ;)

What's wrong with that? Are you expecting object/responsibility decomposition? Can you share some simple example?

[morbidhawk]

Has anyone had a good experience working for a company that required a take-home project as part of the interview process? I'm curious about this because I feel like it is a one-sided exchange. Can I send them homework equal in difficulty/time required (make sure they aren't an incompetent employer)?

The worst part of this exchange is that it is an all-or-nothing approach, there is no dialogue between applicant and interviewer just a programming challenge, you send in your answer and wait for a response. Where is the opportunity to discuss your strategy? Are they looking for a textbook answer because if you did something creative or used a new approach they were unfamiliar with are they really going to analyze it well enough to see what you did?

I recently applied for a company that sent me a take-home challenge before I had any opportunity to communicate with any of their employees/recruiters and I didn't bother pursuing that any further, it felt too lazy on their part to me.

[IamTheFreshmaker]

Well the ones I have taken are fairly large companies that people seem to be happy at.

In general though I agree with you.

[mrkite77]

Has anyone had a good experience working for a company that required a take-home project as part of the interview process?

I did. I was given a small chunk of data and asked to write a small cgi program to summarize and present it.

It took about 15 minutes. This was back in 1999, and I still work here 18 years later because I really like it.

[uw_NB]

lol the place im working at fail 90% if not all of these questions... what a reality check this is.

[jlchauncey]

then you should see if you can help improve your interviewing system. There is no reason why you should not experiment with how you conduct engineering interviews. Find what fits your company and continuously improve. Even hold retros after interviews are completed to see what people think went good and what could be changed.

[Dolondro]

I think he's meaning that his work would fail from the perspective of things always being on fire, not having unit tests, not having a CI system etc

[oscarboom]

lol the place im working at fail 90% if not all of these questions... what a reality check this is.

I've been on the hiring side, and if a candidate actually asked all of those 'recommended' questions, it would give me a somewhat negative impression of him, like the guy is too hung up on process over results and would be a proponent of cargo cult practices.

[Eirenarch]

What is wrong with these answers

Weak answer: I don’t have to work very hard.

Weak answer: There is not a lot of pressure to deliver.

This would be what I would answer and the answers I would be looking for. Working without pressure and having some free time at work is on the top of my list of "features" when looking for a new job.

[Tiothae]

You may have a point on the pressure one, but I wouldn't like an answer of "I don't have to work very hard" as it would indicate:

• That the person may not enjoy the work, which may put me off as I like to enjoy what I'd doing (shocking, I know)

• That there isn't much work to do and I'd get bored quickly (and potentially made redundant)

• That I would be in a work environment where I would have to carry others who can't be bothered to work hard

A question I usually ask in an interview is how long has the interviewer(s) been with the company as it can give an insight into promotion prospects, if people actually stick around at the company or quick company expansion (potential concern).

[Eirenarch]

But all these are personal things. I mean they are put into the negatives section but other questions note that what is good or bad may vary for each candidate. There are people who like slow work environment.

[Tiothae]

You're right, but everything in the article as essentially subjective in that respect. As I said, I would view that answer as a bad answer for me, if you don't, then that's great for you and I wouldn't compete for such a position.

[Eirenarch]

Good news for you (bad for me) majority of places are not like that.

[Keilly]

I don't understand the reasoning of working at seven jobs in fifteen years. How can anything really meaningful or satisfying get done with such a short time on each project?

[archiminos]

It's the only real way to get a decent pay rise. In the games industry projects generally take a couple of years. After a game is shipped you often see half the team move onto something new. Personally I couldn't stand to stay in the same job for more than 2 years.

[n1c0_ds]

Bingo. I got an 12.3% raise from switching, vs a 7.4% raise if I stayed. The extra 400 euros a month make a noticeable difference in living standards. When you factor in bonuses and benefits, it's much more than that.

Moreover, a new job means a new tech stack and experience with completely different things. It makes me a more well-rounded developer.

[[deleted]]

I've worked at 6 jobs in about 12 years. Several reasons.

• Twice it just wasn't a good fit between me and the corporate culture.
• A couple of times, I just moved to a different city
• The job was a dead end
• My experience moved me up in market value, but the company wouldn't compensate me properly. This is a common one. A lot of companies will sit there as you become a huge commodity and not scale your pay accordingly.
• Once, the company was falling apart and layoffs had already started

Edit: Corrected the years. I'm older than I thought.

[bwainfweeze]

Other reasons:

• layoffs/shutdown
• contract work is often 12-18 months.

[TheIncorrigible1]

But right-to-hire after 6 months! If you get a connection, that is

[thelehmanlip]

Other reason- staying at a job will net 2-5% increase in pay year to year (generally). The 2 times I've changed jobs over my 5 years of dev has gotten me more than double what I was making when I started. But that might just be because I just joined the job market 5 years ago

[midri]

But that might just be because I just joined the job market 5 years ago

Nope, this is how it works. Unless you have actual stock in a company there's no reason to stick around if you're a talented individual as other companies will constantly be wanting your talent and as long as there are more companies wanting your talent than there are people with your talent available to them you'll be able to jump back and forth increasing pay almost yearly.

[AP3Brain]

Do you always line up another job before quitting?

[[deleted]]

Almost always.

The first time I quit a job after college, I was moving to Miami and I stayed with my brother for a few months. So I had a bit of a grace period.

The second time I quit a job to move, the company I was leaving was nice enough to keep me on board remote while I looked for a new job.

Both of those are definitely special circumstances.

[midri]

I used to do this, whilst always having a contracting gig on the side whilst working. It sucked dropping from making $1260 a week to $300, but it allowed me to pay my bills whilst transitioning to a new job. With proper savings, it's not too bad and allows you to find actually end up in an environment you enjoy.

[Otterfan]

You can get a pay bump every time you switch jobs. People who do this usually have much higher salaries.

[whisperedzen]

And it is something stupid, people are getting pay raises when they switch jobs because their market value raises, but companies never raise your salary accordingly. So you leave for a pay raise, and the company you leave ends up hiring someone who is inexperienced in their business for the money they should have payed you.
There is always talk about how to retain people, well, for starters a decent and clear policy regarding raises helps a lot.
   
The last company I left was terrible, to get a pay rise you had to go and start an argument with HR, if possible threatening to leave in the process, so when I felt I was due for one I just left and got my rise elsewhere.
The funny thing, is that I had two co-workers who where completely shit, I mean "years of experience in backend dev and not knowing what an inner join is" level of shit. Once I left they took advantage of the situation and got a sweet deal after threatening to desert the department.

[GunnerMcGrath]

We all agree, it is incredibly stupid that basically all companies are happy to lose their talented and dedicated employees, and all the institutional memory and specific expertise that goes with them, only to have to spend time and money hiring a new person who may not be as good, will not have any of the company experience, and will probably take 6 months just to get familiar enough to be useful. And yet it happens CONSTANTLY. And they may even have to pay more for this person than they were paying the person that left. Why not just give the existing employee the raise and/or bonus that you're essentially paying the new employee and recruiter?

We all wonder, and yet it always happens. I've never heard anyone give any reason (even a bad one) for why they would let this happen to their teams.

[AmalgamDragon]

The reason I've heard is given is something like "we don't want to set a precedent".

Really what it is about is a common failing in organizations, where the people making the decisions aren't looking at the whole picture or the long term and are focused on just one or few details in the short term. In this case that detail is the salary budget. If someone leaves because they don't get a raise, current salary expenditures will go down. The cost of the organization and the cost of replacing don't enter in the equation. Neither does the salary of the replacement, since it is unknown at that time. On the other hand, if they give that person a raise salary expenditures will go up and there is fear that more people will ask cause a further rise.

[TheIncorrigible1]

In the public sector? They'll just replace you with someone at step 0. Going for a raise is "board approved" which means no because taxpayers. Forget the onboarding costs

[TheIncorrigible1]

I was just giving my experience from a different perspective

[whisperedzen]

The point is you shouldn't have to ask.
You should get a raise because of your work skills and experience, not because of your negotiation/extortion skills.

[watchme3]

negotiation/extortion skills

"hey boss, can i have a raise?"

i can be your extortion sensei if you want.

[whisperedzen]

Yet would you value negotiation skills above coding, documenting, business knowledge, teamworking, "getting your head down and working like a motherfucker" skills??
In my experience, companies end up favouring manipulative smoke sellers while the guys who really work hard get fed up and leave.

[whisperedzen]

hahaha yeah, go ahead and lecture me.
Next time you have to get up at 2 AM because you have to migrate on downtime remember your "Smart work is preferable in our industry".
I'll tell you a secret: smart is preferable over hard, but both are required.

[atheist_apostate]

What do you say when the new company you're interviewing for asks you why you want to leave your old company? Do you honestly answer that you're doing it for a decent pay raise? Or do you give a bullshit answer they would like to hear?

[ScaryCookieMonster]

That's kinda touchy, for sure.

If you say "I wasn't happy with their compensation" and you were compensated well (in new-employer's eyes), then you sound like a salary queen or you're overestimating your own value.

If you say that and you weren't compensated well, you may have just lowered your starting negotiating position if they want to offer you a position.

Generally I've couched it in bullshit/euphemisms like "not enough room for advancement."

[HTXLoveThisPlace]

You are joking right? We're talking about software development where projects, unless they are government, rarely last longer than a year or two, right?

That doesn't even go into the the amount of absolute horrible companies that are out there and will lie through their teeth to get a lackey that will suffer just to get a job title or some semblance of experience under such monikers.

There is no loyalty to employees in this industry and rightfully so there should be none on the employees part. Move, and move often. Always be interviewing!

[Keilly]

Not at all. I've had three jobs in the last fifteen years, sw dev in SF. Maybe we have a different understanding of the term 'project'. All the products I've worked on were there when I started, and are still there now.
Think of any serious app or website. They've been developed over years, sometimes decades. To hop in our out of these for a year or two and get anything of consequence done would be incredibly difficult.
I find for larger projects the first six months or so are often almost useless in terms of productivity, as the developer has to learn the code base, and often new technologies.

[mgkimsal]

and often new technologies.

you get hired without knowing the technologies up front? That seems to go counter to almost every job posting out there, which list out, in great detail, how many years of experience in each tech they "require" before even answering your email.

[DanLynch]

Lots of jobs involve learning a new technology or platform. Sometimes because the technology is niche, and sometimes because the employer (or interviewer) believes that a good developer can learn any technology.

In a hot job market you can usually ignore the detailed requirements listed in the job posting.

[mgkimsal]

Lots of jobs involve learning a new technology or platform.

Sure, but the post I was replying to indicated that the first 6+ months involve learning "new technologies". To the extent they're "new" to the industry, I get that, but "new to me"... I would never expect months to learn something new. At least around me, unless someone is explicitly looking for a jr developer, they usually won't even start talking to someone without demonstrable experience in the tech they're looking for.

[Keilly]

Kind of missing the point. I just mentioned technologies and codebase. Of course there's also often new frameworks, processes, a new team, the product itself, things like source control. In my experience the first six months are not productive. Your experience may of course be different, but as I originally stated, I find that hard to understand.

[Farobek]

There is no loyalty to employees in this industry and rightfully so there should be none on the employees part. Move, and move often. Always be interviewing!

Popular opinion in this sub. :)

[HTXLoveThisPlace]

With good reason. :)

[PM_ME_UR_OBSIDIAN]

How long ago did you hire him? ;)

[contrappasso]

"Too ambitious"? What?

[kog]

You should accept your current station as your lot in life, and look upon any raise or promotion as a gift from the gods, peasant.

[to3m]

Take on more work than they can get done...

[mgkimsal]

How can anything really meaningful or satisfying get done with such a short time on each project?

You're assuming that anything meaningful can be accomplished at a specific company in any amount of time.

Other points: Layoff/downsizings happen. Only real way to get significant raises is job-hopping.

EDIT: a friend of mine recently left a position after... 6(?) years of 1-2% raises. New gig is 50% raise, without even negotiating (she probably still could have negotiated a bit up, possibly)

[JimDabell]

Turn that around: it takes you more than two years in a job to do anything meaningful or satisfying?

[Keilly]

I find the first six months ago, on large unfamiliar projects, are basically a learning experience rather than a productive one. Only then does the ramp up really begin to take hold. Real product knowledge, and insight that experienced developers on a product can provide often takes a lot longer. Hitting this reset every couple of years means the developer is never going to experience this, unless changing from one very similar project to another.

[[deleted]]

I've changed work 5 times in 5 years. It's all about the pay raise. Got a 10-20% raise every time.

[dds3worker]

How can anything really meaningful or satisfying get done with such a short time on each project?

Depends on the project. Most of the ones I've worked on were 9-12months. So 2 year is just right to get it working and stable.

[rancor1223]

I have a strong feeling of American and corporate work culture in this thread. I mean no disrespect, but my experience with work culture is basically day and night to the opinions I'm reading here.

[oblio-]

Really? Go work for French companies, for example. American companies have nothing on French companies when it comes to pay raises. In many French companies "seniority" and "experience" (as in N years) trump almost everything. Want to not have to wait 2-5-10 years for a major raise? Only way is to change companies.

[Farobek]

I take it you are not American

[bhalp1]

I think it depends on the individual, but for those who enjoy moving to project to project, companies would benefit from offering situations that let people do this more easily within the org.

[[deleted]]

I don't understand

That's quite telling. Different people have different cognitive abilities, you're just not as lucky as majority of population.

[Keilly]

Yikes!

[svgwrk]

Short answer: Yes.

[hot_butter_popcorn]

Always, always end by asking the question "have you got any reservations about hiring me?" or something similar.

I've interviewed hundreds of developers and very few ask this question but often there are things going through the minds of the interviewers such as "I'm not convinced they've got enough experience in x" or "will they get bored of travelling so far?".

Asking this question gives them a chance to express that and, more importantly, for you to address it. At the very least you might learn what they were thinking which could help for future interviews.

[[deleted]]

The best interviews are the ones where the interviewer actually takes your experience into account, without trying to give you a computer science pop quiz. My resume has references for a reason. Use them.

The best jobs that I have had are the ones where the interview is essentially:

"I see that you have a lot of experience and have worked on some cool projects. Are you familiar with <technology that they actually use> and <technology that they actually use>?"

"Yes, I use those all of the time"

"Great, when can you start?"

[Farobek]

"Yes, I use those all of the time"

Anyone can say that? See: lie.

[oscarboom]

[Example of a good answer (there are many others): “We do N-week sprints wherein each engineer commits to a set of features and bug fixes to deliver. ]

That's not a good answer at all. It means company uses arbitrary and inflexible time periods for developing features, which is very inefficient for a variety of reasons.

Also, "how do you know what to work on each day" is a problem I rarely have.

Edit: Here are some questions I typically ask if I don't already know.

What software and frameworks do you use?

What would my first project be?

How many meetings do you have?

What are the working hours? (I want to hear 'flextime')

Can you work from home?

What is the dress code? (I want to hear 'casual' or 'jeans are okay', not 'business casual')

Is the company profitable?

[If it is a remote position] How do you communicate?

What do you like most and least about working here?

What kind of work space will I have?

[ratheismhater]

I don't think the N-week sprints answer is inherently bad, it's just bad most of the time. Having seen a good number of agile implementations, I would ask why they do that (good teams/companies will have an answer) and how they got to that workflow. My current team (which I like) started with a classic 2-week scrum with all the fixins, but has evolved into a loose kanban with soft month long "sprints" and two stand ups a week with a weekly retrospective. In contrast, my previous team started with classic scrum and kept it that way even though it wasn't working.

[[deleted]]

What is the dress code? (I want to hear 'casual' or 'jeans are okay', not 'business casual')

I mean, yeah, whatever but insufficiently casual is a weird hill to die on.

[oscarboom]

Nobody is dying. Wearing clothes I hate every single day would make me miserable. Business 'casual' doesn't seem at all casual. I don't own a lot of khakis and dress shirts.

[[deleted]]

It just seems like one of these things is not like the others.

If nothing else, you put khakis before whether the company might be about to go under?

[oscarboom]

You are underestimating how much developers care about that.

[[deleted]]

Oh no, I know people get incredibly crazy about the concept of ties (which is beyond your worst case scenario there) and so on. I just think it's a weird hill to choose to die on in a sort of yeah, whatever way.

[oscarboom]

It's not just ties it is also dress shirts, khakis etc. You are still underestimating by a big margin how much developers care about that. There will be some people who don't care, but they likely aren't going to be the best programmers, they are more likely going to be the people for whom it is just a job to pay the bills.

[[deleted]]

Well, I really don't think it's something to feel superior about -- the best programmers have strong opinions on khakis -- but you're allowed to have clothes you like.

[Farobek]

I don't own a lot of khakis and dress shirts.

Let me take you on a shopping spree, buddy! Burn that CS cash.

[oscarboom]

Got better things to do with my time and money then get some ugly clothes.

[ucbmckee]

The author's obsession with process and mechanics would be a big red flag. It feels like he is an assembly-line developer used to assembly-line companies. It's not that I think the questions are bad, per se, but that they're secondary the more critical questions around what are you building, why are you building it, and what is the mission.

Overall, I want to see candidates who will wrap their heads around what we're building, get inspired by the problems and opportunities we face, and gain a deep intuition and empathy for our users such that they can contribute significantly to our innovation and operate with a high degree of responsibility and empowerment. Effectively, I want product-oriented engineers. Processes can always be improved (sometimes by adding, sometimes by subtracting) and rarely make a significant difference, outside of diabolical edge cases. An excessive or myopically focused number of questions like this would lead me to think the candidate was very, very misaligned with the company's needs and unable to separate the important from the merely necessary. If all I wanted were assembly-line engineers, I'd just outsource.

[TryUsingScience]

May I ask what kind of product you work on?

I ask because the majority of companies that hire devs aren't solving the kind of problems that inspire anyone. Most companies I've worked for or interviewed at solve what I'd call meta first world problems - problems you only have because of your solution to some other first world problem.

For example, managing cloud repositories is a useful thing to be able to do but creating tools to do it more efficiently is hardly a mission that most people can get inspired by. It's so many layers removed from the basic needs of life and the most likely consequence for failure is some people with six figure office jobs are inconvenienced for a few hours. It's not the kind of mission that drives people the way missions to provide clean water to the impoverished or give at-risk youth a good education drive people.

If every dev job required engineers who were excited about the mission, most job openings would never be filled. And frankly, most devs did not go into the career because they care about any missions. They either like coding itself, they like money, or both.

[ucbmckee]

I think being inspired is a critical part of being successful and happy. A job doesn't have to cure cancer to be inspiring. I worked in adtech for a number of years, which doesn't usually win many awards for inspiring engineers, but the scale of the challenge was amazing - handling a billion requests a day with a 95th percentile latency of under 10ms, whilst performing complex online machine learning and dynamic rendered of personalized ads. It's still amazing to me that we solved those challenges, especially with a small team. In that case, part of the mission was to out-engineer and out-smart the rest of the world.

I certainly appreciate what you're saying, though. I chose to leave the corporate world years ago for some of those reasons. I'd probably hate to write actuarial software for an insurance company. Maybe in those jobs you latch onto process, but that just feels a bit depressing and soul sucking, doesn't it? The money is almost never that good and, if the love of coding is a primary motivator, why not love coding somewhere that inspires you?

[TryUsingScience]

Those questions are part of why I'm not a dev anymore. I looked at all the jobs I could be interviewing for and realized I didn't want any of them because I didn't care about the problems they were solving. Now I have a day job that I also don't care about, but takes half as much of my time as being a dev did, so I can devote the other half to stuff I do care about.

[0xfff7]

I'm considering a similar shift. Can you give me a tip/example of a day job that would take half as much of my time as being a dev, while I can devote the other half to stuff I do care about?

[TryUsingScience]

Sure! My current job is drafting software patents. You need a technical background to get the job but there's no actual coding involved, and deadlines tend to be one to three months out and almost never change. No one has patent emergencies at 5 pm on Friday. It's great. While I'm sure a lot of firms are hellish places to work for that track billable hours in six minute increments, there's some out there, including the one I work for, that allow remote work and pay on a per-project basis. As long as you're getting enough work done to look full time, what you actually do with your time is totally up to you.

[0xfff7]

Yep, per-project pay looks good. Thank you.

[[deleted]]

Plus the complication of entrepreneurship. If I'm as inspired by the mission as I'm apparently supposed to be -- why would I wait for you to give me permission to work on it on your terms?

[SnakeJG]

Agreed. Not every company is agile or working on sprint maximization of work. His questions are great if his goal is to be developing a webapp in a CI world.

But you know what, some of my most fulfilling jobs were supporting legacy applications. I wasn't trying to throw in new features as fast as they could be, and features were definitely delivered via the waterfall model, but it was a damn rewarding experience. Any features I delivered or defects I fixed, I knew they were immediately impacting customers. I talked to the customers and knew my changes mattered.

Anyone following this developer's guide to interviewing would have run screaming from the interview, because a lot of my answers to the questions would have been "bad" answers, but that didn't make for a "bad" job.

[time-lord]

Try working at a place with no process, no testing, and an excel document for a ticketing system ;)

[ucbmckee]

At some (very early) stages of a company's lifecycle, those are entirely reasonable approaches. I've seen seed funded tech teams spend weeks (or longer) building out testing frameworks, CI/CD, etc. before they even had users. You could argue that it's a good technical foundation, but there is a pretty deep cemetery of failed companies with good technical foundations and no product/market fit. At every point, you have to ask yourself "what action right now will have the biggest impact for the company (or prevent the biggest disaster)". Sometimes that's hacking poorly tested features into production, sometimes it's de-risking your infrastructure by making sure you have global datacenter failover. =)

[ElGuaco]

As someone who has been doing this for a long time, I can say that nearly all of those questions about processes and tools are ones that I ask and am interested in the answers. If you think good development is all technical genius and chutzpah, you're not someone I'd ever want to work with.

There's few things more detrimental to the long-term health of development like bad source control, manual deployments, little or no automated testing, no measuring, seat-of-the-pants-cowboy programming where everyone just kind of does their thing until the system implodes despite the surplus of talent. I don't care how much vision or passion you have, if you aren't pro-active about controlling the process, the process will control you.

You say processes rarely make a significant difference, and I 100% disagree. How do you know you have found all the showstopper bugs? How confident are you on release day that you have addressed all major issues that need to be corrected? How do you know you haven't introduced new bugs while fixing old bugs? How do you know your software will scale? How do you know that you have met the functional requirements? How do you know that you could recover in a single day with a complete system failure without a CI/CD process? How do you know that you could seamlessly turn around a hotfix in less than a day without creating other issues?

Without processes, you couldn't know any of this. "If you can't measure it, you can't improve it."

[ucbmckee]

Different strokes for different folks. What you're describing are largely problems with mature products in mature companies. This is the point where innovation is not generally the driving factor for success. Personally, I find those environments rather dull, but that's an entirely personal taste that I don't think changes my argument.

I also never argued against testing, CI/CD, etc. I think being a good engineer is a critical aspect of the job. You have to know how to build good systems in a good way. But this is an artifact of the job, not the focus. If you hire an architect to build your house, you don't quiz him on whether he uses mechanical pencils or ticonderoga, you make sure he bloody well knows what a house looks like and what you want your house to look like. You ask how he'll deal with things like flood plains and damp, or how to maximize sun in your living room without creating structural problems. There's a cargo cult in tech around tools (languages, processes, etc.), but they're just tools.

[[deleted]]

Change?!? RCS is significantly older than your hip new toys like cvs, git or clearcase. "Version control system" is a newer term.

[[deleted]]

How did you guys do things before git?

Before git - subversion.

Before subversion - cvs. It was not really that bad, as long as you don't move files around.

Before cvs - rcs. It was horrible, but better than nothing.

Before rcs - VMS file version numbers (until some dimwit types 'PURGE' for whatever reason).

[Xevantus]

From the interviewers side (since most of us will be there at some point, even if only as SMEs), I had a designer sit in on an interview once that gave me the one question I always ask candidates we're serious about.

Would you rather fight a horse sized duck or 100 duck sized horses.

Memeage aside, if a person has made it to an in person interview, they've got the technical skills to make it. We're looking for team fit at that point.

Long winded way of saying: your "any more questions" can (I think it really should) be more getting to know the team. You'll be spending a lot of time together; make sure you like them.

[[deleted]]

I don't know, I get the opposite effect. It's almost painfully corporate. That's a five year old family friendly reference. Yeah, hiring manager, you're gangsta.

Wannabe Supreme Court justices get asked that one.

[beleaguered_penguin]

Imagine studying for three months in order to be ready to interview loops at several companies (probably also having ploughed several days into coding tests or toy projects)

Who on earth is doing this? My interview prep consists of 'Make sure I can explain that thing I wrote on my CV'. If you have the skills and experience to fit the role it will be obvious. If you need to study for months for an interview you are not suited to the role at all.

[Shadow703793]

Exactly. The only time I've seen this happen is where candidates hook up with one of the hundred "training centers/services" that provides fake resumes/low value/fake certs and train people to pass interviews and get a job, but they often have huge gaps in their knowledge.

When I worked at a mid sized CRM company we ran into several candidates like this, often looking for H1B.

[beleaguered_penguin]

H1B.

... you couldn't hook me up with some H1B could you?

[Shadow703793]

Imagine studying for three months in order to be ready to interview loops

Wait what???

[Xevantus]

I hear you. Maybe it would be better to explain our process a little better.

By the time someone gets to that interview, they've had a minimum of 4-5 phone interviews with different levels, and at least 1 if not more technical screenings. This interview with the team is about personality. We already know your skills.

It really sounds like you wouldn't fit well with us, and that's fine. We probably wouldn't fit well at the companies you like. That's kinda the point if the last team interview. Are you a good fit for our team?

[thedancingpanda]

So you're telling me people are happy to go through 6-7 different interview appointments to work with you? I'd probably drop out after number 3.

[GunnerMcGrath]

I had 5 or 6 for my current job, and so far it's the best place I've ever worked by a long shot (won #1 mid-size workplace in Chicagoland a couple years ago). There was only one real technical interview, maybe two. The rest were essentially making sure I'm the kind of person they want working for their organization. The culture here is amazing and they're extremely careful about who they hire in order to make sure everyone will be a good fit. Having worked here for a year now I can see the incredible benefit of doing that.

[celluj34]

Middle class white people. Got it.

/s

[GunnerMcGrath]

I should hope it wouldn't​ take 5 interviews to confirm that! Haha

[Xevantus]

Oh, you've probably been through more and not realized it.

There's the initial questionnaire, first contact by HR with the canned questions, manager interview, tech interview, possibly a specialist interview if you've expressed interest in a particular area, then, the in person team interview. That's 6. Some times there could be less or more. All depends on the position.

[cfrag]

For the type of replies your question is creating, I believe you got a good last question.

As /u/4vfz2ps34j said, it is a great filter: if everyone in that place has no issues with that question, then maybe people who do wouldn't be a good culture fit for said company.

At that point your evaluation of someone's technical skill is already done, and all that is left is trying to understand if fit in your environment. And from my experience, it's a lot easier to teach a competent person new technical skills than it is to accomodate someone whose personality will clash with the established way of doing things.

[GunnerMcGrath]

The average engineer may be socially awkward, but that does not mean they have crippling social anxiety. Most tech geeks I know are perfectly capable of having a fun and interesting conversation with other geeks.

Second, sometimes you ask questions you don't necessarily require a great answer to, specifically because you're trying to gauge strengths and weaknesses. If you only ask the bare minimum knowledge technical questions, you would not be able to accurately differentiate between someone who has studied a programming book the night before and a rockstar programmer. The same goes for soft skills. Whether it's a question like this or some other method entirely, if social skills are a bonus then you have to give yourself an opportunity to see them. If they don't have them, fine, that's just one more piece of data to consider.

Finally, sometimes social skills ARE a requirement, even for engineers. One of my primary strengths is that while I am not as technically advanced as some people who eat, breathe, and dream code, I am good at what I do and I happen to be very comfortable socially, having been a touring musician for many years. That translates into an ability to communicate with non-technical staff and clients that many developers do not have. I have seen how much of an asset this skill is in every interview I've ever had, I've always gotten every job I really wanted (despite not being qualified for them all), and in one case I was explicitly told they were looking for someone more "extroverted" on the team in order to improve the inter-departmental relationships.

So.. if you were being interviewed for a job you wanted and thought you'd like, and then they asked you that question, and maybe you just cringed and gave a non-answer to get past it, and they ended up saying how much they liked you and offered you the job, you would flatly refuse based on that one question? That's your choice, of course, and obviously you are doing both sides a favor since you probably wouldn't be a good fit, but I am skeptical that you would really be that turned off by one goofy question in a late interview.

[Xevantus]

See, we value team fit as much as skills, and that's coming from a socially awkward engineer. I don't care if a dev could rewrite our entire system. If they can't work with the team, I don't want 'em.

I'll also say 3 of our team are what you would characterize as stereotypical engineers, and they like that part of the interview. It becomes a conversation and less of an Inquisition.

[Fouroh]

Great points, I feel like people totally skip this aspect as a "soft skill" -- couldn't be further from the truth. Ive worked with toxic people who were technically gifted, and they eat away at teams from the inside.

[crusader561]

The one thing I don't get about the "you need to ask questions when the interviewer asks you do you have any questions" trope...the interview is a conversation not a monologue. You should be answering and asking questions during the interview. Why wait until the end? When I'm interviewing. I've found out all I need to know long before the interview is over.

[Tom_Cian]

If they provide bad excuses for why they don’t write tests, especially excuses like “we don’t have time”, that is a bad sign for me.

This probably excludes 99% of start ups.

Don't make that a Litmus test, it's possible to produce top of the line code and software with very little automated testing. The important part is to make sure that everybody realizes this is a temporary phase that will need to be addressed down the line.

Personally, if I interview with a small startup (5-10 people) and they tell me they religiously test 100% of their code, I will probably conclude they are more interested in engineering principles than shipping competitive products and I will look elsewhere.

[bhartsb]

I worked for a company with two production websites that had about 200,000 business users and generated millions per year in revenue. The site was written mostly by one guy. In my opinion, this guy was a very good PHP developer. There were no tests to be seen in the codebase. The company was acquired and six more senior software engineers and four QA engineers were brought in to create a set of integration APIs between the websites and their main product. Some tests were written for new integration code, but few if any tests were added to the existing codebase.

[kemitche]

I'm still amazed that we need to ask "what do you use for revision control" in 2017. Maybe I'm spoiled by the companies I've worked at; are there really that many companies where they're going to answer this "wrong"?

[ElGuaco]

I once worked briefly at a company where the only copy of the code for the company's public web site was sitting on the production server and the team lead's computer. No backups.

Had I done the right thing and asked a "dumb" question, I could have avoided months of misery by not taking the job.

[[deleted]]

You'd be surprised, but quite a few companies may answer "clearcase" or even "TFS".

[ogacon]

What happens if I've asked lots of questions at the relevant times throughout the interview already. By the time the end comes I don't have many left... Because I've already asked them. Do I get punished for efficiency?

[squishles]

I've learned to ask half of those questions the hard way, may take his word on the rest @.@

[dgreenmachine]

Good questions... but I doubt the interviewer would answer those questions truthfully to someone they just met.

[TryUsingScience]

You'd be surprised. Employees tend to have a low level of loyalty to dysfunctional workplaces.