One of the best metrics I've found for determining the overall satisfaction level of a department is turnover rate.
If you ask the interviewer about their turnover rate and they hedge, be cautious. Sometimes they won't know what the turnover rate is because they're too new, or don't pay attention to it, so you can ask about the average number of years that the developers have been there (which they should know).
There are so many factors that figure in to developer happiness that it's hard to build a good checklist of things to ask about. But if you look at the evidence (how long do developers stay here?), it's very easy to tell if it's going to be a good place to work.
Of course, this doesn't work when you're talking about getting a job at a startup, but the hope there would be that you already know it's somewhere you want to work; that it's not a job that someone referred you to just because you need a job.
I personally do not feel that question will help you too much. You will be stuck within a team, say 5-10 people reporting to someone, and that is the environment you truly care about, and it's something the recruiter will not know much about. Those are the people you'll be sharing most of your time with for years and it's truly the one area you have to get right. The satisfaction level within the department is strongly secondary to that.
Right, but if there's high turnover there's got to be an underlaying cause. (Which maybe the business itself doesn't know).
Maybe they don't pay enough, or have too many deathmarch projects, or office politics gets in the way too often, or maybe a few rounds of layoffs
Regardless, if a lot of people have left before you, there might be a reason for that, or at least it will have a factor in your environment there. (Example: A recent round of layoffs might mean a 3 person department is asked to do the work once handled by a department of 10)
What is the incentive of the recruiter to tell you the truth? What if he says: "Everthing's great!!!", you can't really hold him accountable after you signed up for the job. They're salesmen. Is the idea to look for subtle indications of not everything being great?
Recruiters are salesmen, But the OP suggested asking the interviewer. Developer interviews often have multiple rounds with different interviewers, so you get a chance to ask the same question to multiple people. If their answers don't match, beware! :)
Not so sure about this. Good programmers can change jobs very frequently. I know many people who have never stayed at the same company more than a couple of years. That's just part of their ambitious, challenge-seeking nature, the will to improve and take things to the next level - it's not really an indictment of the places they stayed before.
I'd be suspicious of a departmnt with a turnover rate around 6 months, sure, but if it was 5 years I'd be equally worried, because unless working for that company was the shit then I'd be concerned with the kind of developers the company had hired in the past and what kind of culture such a bunch of unambitious seat-warmers had developed, and I'd be expected to fit into.
The sweet spot that I've noticed seems to be around 3 years average. Anything more than that doesn't appear to make a difference in overall happiness levels. Lower than that and I start to have concerns.
This was a question I used to ask my consulting clients to get a feel for what sort of department I was going to be walking in to. The higher turnover places always had the worst development practices in place (or none at all, like a complete free-for-all), and the places with less developer turnover tended to have fewer people focused on guaranteeing themselves job security & more people focused on efficiency.
Yep, matches up with my experience pretty well. Around 2 or 3 years is a good sign that the place isn't a terrible place to work, and also that it's not full of make-work existence-justifying lifers.
A bad place to work can actually be fun for a while, if you have good coworkers. It can be a bonding experience, a rite of passage, friendships forged in the fires of mt doom etc. But indifferent management and ashen-faced zombie coworkers determined to cling to their mediocre jobs until they rot to death in their seats? It's a different type of poison, but just as deadly ..
This is absolutely wonderful timing for this thread to come up. I've recently started at a start-up in Beijing and have been put in charge of making a filtering system for technical applicants.
One thing I was never prepared for was the sheer number of people who just lie on their CVs! After somewhat reluctantly starting to ask senior app developer and web developer applicants to write a fizzbuzz program, I was shocked to see that less than half could. This is from a group of people who claimed to be experts.
Since that discovery a couple of weeks ago, I've been building an automated grading system similar to the great FB's old puzzlemaster app. That way I can screen out those who can't do fizzbuzz and another trivial program or two before wasting our one iPhone dev's time interviewing them.
Those who do at least decently do get a chance to interview, but I'm hoping to add more puzzles to the auto-grader in the hopes of spotting applicants with stronger skills than is clear from their interviews. Any suggestions?
What is your approach for asking (supposedly) senior developers to write such a rudimentary program? Having interviewed "senior" developers with "10 years of experience" that could not tell me the difference between an int and a char pointer, I know this type of interview question is, unfortunately, very important.
Implement an iterator for a data structure (you can choose which structure).
Write a simulator for lottery number drawings.
Write a basic cash register API that keeps track of a total balance as well as denominations. Bonus points if it makes change appropriately (largest bills first).
These sound idiotic, but someone who can't do FizzBuzz probably can't do these either.
I'm sorry, maybe my comment was unclear. I'm writing the tests. I was looking for suggestions for programming questions (i.e. is giving them a problem that requires implementing a binary search or a graph useful?).
That link is useless to me since the site is in English and nearly all my applicants are Chinese who don't have the language skills to read it. Throwing 200 weak applicants at it would just be a waste of $600USD/month.
It's not that hard to come up with programming questions. It's harder to come up with relevant ones. What sort of algorithms do your devs actually use?
Do you need to know if they can write parameterized queries in SQL? Do you need to know if they can do simple web crawling or scraping? String manipulation? Or do they need to know how to do linked lists, hashes and binary searches?
I think you'd do better if, rather than making them redo old CS assignments, you focused on job-relevant tests.
Do better at what? The kind of test we're talking about here is just a bozo filter. It's designed to keep out the flagrantly awful candidates who can't even write a simple program, not to test for actual job suitability.
I'd be interested to see the results (email in profile). But I suspect the answer to this question will depend a lot on what your startup is doing and what skill level you are looking for. We have different programming tests for different roles, but they're all tailored to what each candidate will be doing if they get the job, and give them an idea of the kind of work they might do if they are successful in their applications.
Scroll up and read the FAQ entry right above that one.
They're only partially translated, and unfortunately the quality of those translations has been spotty from what I've heard others here in Beijing say.
It also doesn't hurt to simply practice programming problems and revisit old academic excercises.
Make some flash cards with datastructures on them and use them to try and recall as many of their useful properties as you can (eg: Binary Heap, binary tree with x constraints, O(n) search, O(log n) insert in worst case; etc).
The advice in the article about honestly answering, "I don't know," is key -- don't pretend to know. You'll get called out and blow the interview. Instead, explain what you do know and think out loud when you walk through the problem with them (or how you'd go about solving it).
One way I've practiced "thinking out loud" is to get a white board and pretend you're a professor. Try to explain the solution to some problem you are familiar with in layman's terms to your pretend audience -- but do it out loud. Then find a problem online that you're not familiar with and do the same thing. Pretend you're a professor or engineer or some sort of brilliant person and walk through the problem with yourself -- out loud. Write diagrams on the board, explain your every step to your pretend audience, and really get into it. I found it helped me quite a bit and I frequently use the technique to walk through problems I'm not familiar with in my own studies.
> One way I've practiced "thinking out loud" is to get a white board and pretend you're a professor.
This.
I'd never done "whiteboard testing," and I still hate it, but a lot of people use it apparently. I remember the first time having to do it, and I was so focused on the white board, and having my back turned to the interviewer, and just the odd sensation of everything (not to mention very little sleep the night before) that I was drawing blanks on the most basic of questions.
Don't even get me started on the practice of writing code on the whiteboard. Who even does that in real life? By the time, a line of code I wrote on the board extends to the right, I forget what I have written on the left. Is it too hard to provide a fraking computer to type on?
I guess here's one advantage of trying to get a job coming out of academia: We do that kind of whiteboard discussions all the time. I'm actually surprised that you wouldn't have done this ever at a normal job either. I mean, how do you hash things out with your coworkers?
There is a big difference between hashing things out with coworkers and trying to write that will run without a typo. I have no problem using a white board, and throwing up examples, etc. But actually writing out variable declarations, assignments, etc?
Also, be aware that it is OK to bomb an interview. The point of interviewing is to find a match. If you and the company do not have a cultural fit, it is better to find out and both go your own ways. So I recommend above all to simply be yourself.
> Also, when they do ask you about how much money you want, give them a range or a baseline (ex: I had X at my previous job, so I expect at least X or from my research people doing this job receive between Y and Z, so I’d expect something in that range). Let them come up with a number.
I don't understand this advice, if I say I expect 'at least X', then it's me coming up with the number, not them. I have always just said I'll comment on what is offered.
I have given people more than they've asked for a couple of times (usually if they've asked for something that I know to be under market rate and I don't want them jumping ship in a year). But yeah... as a hiring manager I want to know what your expectation is because that's what I'm going to take into consideration when I compare you against other people I've interviewed.
i.e. Dev A has everything but costs 20% more than Dev B, who I think can pick up everything we need within a year's time. Or, Dev C has claimed to have done all of these different things, but is asking for an amount that is suspiciously low.
If you have only one offer, then that could happen, but it's unlikely if you have more than one offer or at least several interviews (and I would always mention this).
I don't know man, the interviewing process is just so broken. Maybe because interviewing in general is so broken or maybe it's because software development is such a new industry.
Either way, isn't it strange that the best advice for doing well at interviewing is to practice. Practice so you become better at interviewing, not necessarily better at your job.
I think it's a byproduct of the education system. When you are young, you are taught to do well on exams instead of having a deep understanding of the material.
Interviewers who explicitly phrase the 'how would you move Mt. Fuji' or 'here's a development task outside of your stated competencies, how would you do it?' as hypotheticals or thought exercises, could save a lot of heartbreak. I can see the rationale behind those questions, but any experienced interviewer should know how tense people get during an interview: allowing interviewees to perceive those questions as being about the literal answer, rather than about the process, is kind of a jerkface thing to do. Besides, people who can't coherently explain their thought processes are going to bomb on that question anyhow - have some courtesy and give a leg up to people who are merely nervous. I'm grateful to the interviewers I've had in the past who have come out and said "this question is about the process, not about the result".
I think it's very important to reduce the tension level, because if you're asking someone a question intended to show how they think and reason, especially with some level of creativity, you risk getting a useless answer if they're tense and antsy. Nervousness and pressure often kill creative thinking: this is well-established.
Or interview at companies that aren't software giants that will actually spend time getting to know you and your past work rather than processing thousands of developers each year through standardized programming tests that do not prove anything about your capabilities as a software engineer.
I'm going to an interview this week. One thing I think that's missing in topics like this is that you are going to work for a company. This means that you need to look beyond the immediate position and take a large view to the business. I'm going to ask questions like "Why did your last custom stop using your product", "What is the company's vision for the next 3-5 years", "What are your revenue streams and how stable are they".
Knowing what dev process they use, tools, etc are all really good questions. But don't forget that the money they pay your salary with comes from somewhere. Knowing this internal information is just as important as knowing how Git works.
The bottom line, in the interview process you need to adapt to the people you are talking to.
The possible pitfalls are endless for both the interviewer and the interviewee.
And sometimes the interviewer will bomb the interview more than you. You don't see people often write about making sure the person doing the interview is any good at it.
Getting good people is really important. Possibly one of the most important things you can do for a business.
With some of those "un-answerable" questions that come up in interviews I've had good mileage from just turning them around back on the interviewer. After all, a lot of the time these interviewers just ask the question because it's part of the "process" or something without fully understanding the question themselves.
However, you have to read the situation well in order to get away with this!
People are on their best behavior with they are being interviewed. My manager suggested that if you notice any rude or peculiar behavior during the interview, multiply it 100x and consider whether you would want to work with that person one year from now. I've interviewed people who would arrogant or would talk over the interviewer. Needless to say, those hires did not work out. <:)
I guess that depends on your powers of observation. But even if you trust in your powers of observation, it is an excellent opportunity to compare what you observe with what they say. If things don't mesh, you have to wonder.
Agreed. And remember you're only seeing a little snapshot in time, so there are probably quite a few questions you could ask regardless of your observational powers.
Do you eat lunch together? Is dress always this casual? How often do you refresh your equipment? How often do people work in groups vs solo? Do you encourage working in pairs? How geographically distributed are project teams, typically? Do people take personal calls at their desks? How do you manage shared resources like conference rooms? At my last job, everyone stood up and belted show tunes for a 1/2 hour at tea--do you have such a program?
What you see visually doesn't tell you anything about the team's thoughts on testing, automation, how/if they do code reviews, what their thoughts are on working remotely, if they care about what hours of the day people work, etc.
If you ask the interviewer about their turnover rate and they hedge, be cautious. Sometimes they won't know what the turnover rate is because they're too new, or don't pay attention to it, so you can ask about the average number of years that the developers have been there (which they should know).
There are so many factors that figure in to developer happiness that it's hard to build a good checklist of things to ask about. But if you look at the evidence (how long do developers stay here?), it's very easy to tell if it's going to be a good place to work.
Of course, this doesn't work when you're talking about getting a job at a startup, but the hope there would be that you already know it's somewhere you want to work; that it's not a job that someone referred you to just because you need a job.