So linkedin has been bombarding me with HR fluff pieces about what you should ask candidates, and conversely what candidates should ask potential employers.
I ignored them until my subconscious coughed up the answer.
This is what you should ask any potential employer….
What is your null process?
ie. If someone (anyone) spots a trivial obvious customer visible flaw, that literally has a one line fix….
What is your process from the defect being spotted until the fix is delivered into the customers hands?
More than anything this will tell you what sort of shop you’re dealing with.
ie. Whether you dealing with a bunch of cowboys or process droids so heavy that nothing can get done.
That’s a pretty good question, I’ll have to keep this in mind!
My own go-to questions (mostly to weed out the real red flags):
That’s a pretty good one.
This is great to catch imposers. I’ve used it to filter out academic job offers from incompetent groups. When they said yes, of course, I asked to see the code. It was always a mess or no code at all just cloned repos.
Other favorites of mine:
The last one sounds weird, but some organizations insist on denying me the permissions to do anything useful on my own machine. They want me to call an admin for everything. It’s an immediate no-go.
Why does it matter whether they contribute back to open source or not? Do you mean to ask do they contribute fixes when they find bugs back to open source libraries they are using? Or that they spend a portion of their time working on open source libraries/projects?
Let’s put it this way, if they have culture of taking and not contributing in any way or form… that culture won’t stop at source code.
If they are not willing to contribute back fixes to open source software, they are either willing to maintain their own private forks of it (waste of time, poor security culture), or are more likely to work around it than to fix the source of the problem, which is indicative of poor engineering culture.
IMO whether they do these things or not is the most important. How they do them is not terribly critical. (If you are hung up on how they should be done, that’s a different issue you’ll need to work on yourself)
Which version control or unit test framework isn’t the issue, it’s the whether it’s there and how heavyweight it is.
Sure, in fact a complete set of cowboys may be hiring someone to fix the problems of the lack of process. (Hint: If the role doesn’t come with the authority to make it happen, say thank you, but no thank you. Really good way to burn out.)
I have heard of shops where the answer is the on other end… the process is so heavyweight the answer is “If no one is yelling, don’t fix”. Again if they aren’t hiring to fix that and the role lacks the matching authority to make it happen… Run away, don’t walk.
I interpreted @sjamaan’s questions in two categories, culture and practice. I think this is especially important for small / startups. My realization is that, you really want to work in a place that both culture / practice aligned with yours. Some of these I won’t call it “red-flags” so much as “preferences”. But preferences alignment is great if one thing you work to optimize for is happiness. In that spirit, how they do them is important as well.
I would also add (of course, these are really about QoL questions, not about the profitability prospects of the said companies):
Again, none of these have the “right answer” or “red flags”. It is about alignment and make you happy when these process were aligned to what makes you productive.
BTW, if you are not the first 5 people hired, or hired as VP and above, don’t think about that you can change the culture / practice. May be you can, but that will make your life miserable in the process.
At one stage I was transferred to a role to implement good practices in a team. By being “helpful” and being good at scripting (A ruby-ist in a world of C programmers has super powers. ;-)) I made a fair amount of progress.
By taking control of the build system I made a lot more. (You can slowly ratchet up the code quality and pin it, and get a CI system started.)
Hiring two excellent like minded programmers helped a lot leading to a fairly good CI setup.
But ultimately short termism by project managers stifled all further progress and I gave up the role. I would not take on such a role again unless it included authority block serial cowboys. It’s the pig wrestling rule, if you trying to pull a pig out of the mud and you find the pig enjoys both the mud and wrestling… Stop.
I do what I can to notch quality slowly upward, but I try hard to avoid pig wrestling.
I agree with that. Asking how they do it allows them to expand on their answer and allows me to get a better feeling for how sophisticated their thinking is about the topic. For instance, if they’re telling me they’re doing only manual testing or that they’re using CVS for example, that could be cause for concern.
The specific tooling they’re using matters in the sense that you have to deal with that stuff on a daily basis, so if it’s truly arcane and painful I’d like need to know what I’m getting into in advance.
Wouldn’t most employees in other professions dislike a job/employer if they required that employees use terrible tools to do their work? There’s obviously some “process” questions implied in what was asked above, but I think considering what the company mandates employees use to do their job is also 100% valid. You, as a new employee, are not going to be in a position to get anyone to change any of that, so you better be happy with what they force you to use to do your job.
The absolute meanest question I’ve ever gotten from a candidate was:
“What question did you wish you had asked when you were interviewing here?”
The other interviewer and I just kinda segfaulted, and complimented them on a good question.
I like asking business-oriented questions, since most of the development questions are usually just boring things (“What ticket tracker do you have?”, “Tabs vs spaces?”, “Do you all have CI?”, etc.) that, if bad enough, I’m probably being hired to fix anyways.
The really interesting questions you can’t really expect to get an honest answer for:
Like, the really good stuff you won’t know until it’s too late.
I know that you’re (half :-P) joking about the really interesting questions but honestly, in my experience, you’re spot on about them. Before I did my own thing, I eventually fine-tuned the questions I ask at interviews for ticking the “asks follow-up questions” checkbox of the interviews’ list without being a complete bore, but nothing more. Because I found them to be pretty much useless for weeding out the really bad things. Some of the things I’ve seen in 15 years of interviews include:
i, usecurrentCollectionIteminstead” (I wish I were kidding). Since nobody actually read the source during reviews, glaring buffer overflows were discovered months after they’d been introduced, sometimes as a result of the entirely pointless refactoring hastily done during the “review”.If the company you’re interviewing for is, indeed, ran by people who are utterly incompetent, you will inevitably figure it out by the time you get to the “do you have any questions for us?” stage.
If it’s not, and the people who are interviewing you aren’t entirely incompetent, they can tell a red flag when they see one. They’re not comfortable about the embarrassing lack of version control, about the borderline useless ticketing practices. They know if the engineering manager is a narcisistic, compulsive liar who cracks under the tiniest amount of pressure. They just can’t tell you. Maybe they’ll drop hints if you’re lucky but if you ask them point blank, especially with another interviewer around, they will, at best, paint a “nothing’s ever perfect but we’re committed to improving it” picture.
tl;dr My experience is that any reason why you wouldn’t want to work someplace will get dusted under the carpet. Don’t count on these things to weed out the really bad places. Trust your gut.
I always like: talk to me about the last time you got paged into an issue. You can find out a lot about the uglier side of what you’re getting into with 15 minutes and that question as a lead.
“paged”? Last time I carried a pager was nearly 20 years ago. Do you want an answer from the distant past?
Paged is still frequently used in some circles and is tied in and reinforced with the branding of the common PagerDuty product. In my circles, people mostly just say there were called. Some companies have bespoke incident management tools so they say they were XYZ’d where XYZ is some obscure tool. Paging may not translate as well internationally.
And the verb “paging” existed well before pagers were invented. The term is more generic that you seem to be suggesting.
Can confirm I’m from the present. Emoji for proof 😉.
There’s a bunch I like to ask, but the most valuable one I’ve found so far is “What problem are you trying to solve with this hire?”, because it gives you a bunch of valuable follow-ups to dig into based on their response:
If this is a new position: how well fleshed out are their expectations for this role? What makes it different, why do they need it now and not before? What does success look like for the person stepping into this role? – I don’t know that there’s a single “right” answer I’m looking for here, but ime companies that haven’t really put any thought into what they want out of someone, how they’ll do what they’re expected to do, or what success looks like for a hire tend to be frustrating/stressful to work for.
If they’re trying to backfill a position after losing the person in the role: Why’d they leave?
If they lost them to XYZ opportunity and were sad to see them go: what made them successful in this role? What does success look like for a new person stepping into this role? – This can be a tricky situation to be in. When a team’s lost someone they absolutely loved, sometimes they can develop an unconscious hope that the new person will be an exact clone of the old person, with the exact same strengths, weaknesses, habits, etc. Good teams will have clear-headed expectations around the new person needing a good amount of time to ramp up in the org, to bring their own strengths to the role, etc. Bad teams will just end up in a lot of frustration when New Guy isn’t an exact replacement for Bob in a week, leaving the new hire frustrated with a lack of understanding of why they seem to be failing to meet the invisible standard they’re being compared against.
If the person wasn’t the right fit: why not? What steps are they taking this time to make sure the fit is right? What qualities are they looking for in me that would make me a better fit/what qualities was that person lacking? – helps me judge on my own whether I’m a good or bad fit for their wants, regardless of what they think. Good way to try to gauge whether they view a hire-and-fire as a learning opportunity to improve their pipeline to minimize the chances of future firings, or if they’re happy to churn through people. Lots of toxic teams will hang themselves on any rope you give them here re: letting people go.
If everything is on fire and they just want more bodies because they think this will make the pain stop: this imo is just a huge red flag so at this point I’m going to start slowly wrapping up the interview and fire off a “thanks but I’ve decided to go another direction” email afterwards. You can’t fix a lack of coordination by throwing more uncoordinated bodies at the issue (but many companies try to do this).
If they don’t even know why they’re trying to hire (happens more often than you would think!): red flag for a clown organization, imo.
I collect those if you’re interested in more: https://github.com/viraptor/reverse-interview/
Lately I’ve been at startups. In addition to the other comments offering excellent advice for any software-engineering interview, here are some startup-specific questions:
Decades ago I interviewed at two startup companies… Afterwards I phoned my wife and said, “They’re nuts here. One company only has “marketing visionaries” and the other only engineers, no salesmen.”
I didn’t take either job, the only marketing bunch chewed through an amazing amount of venture capital and then sunk without trace.
The engineer only place chugged along for about a decade and then sold out to a larger but fairly like minded bunch and are still going.
https://www.keyvalues.com/culture-queries has an excellent set of questions that are tuned to different people’s needs; different people want different things.
I always ask:
That will get them talking and reveal potentially problematic things.
When talking to people above the hiring manager I also tend to ask abou the financial outlook of the company. If it is a start-up/scale-up I ask how long their run way is. I would never join a company where the financial outlook is uncertain. Version control or bug tracker or contributins to OSS are all fine and dandy, but tbh I go to work to earn a living and life the life I want. That life requires a stable income.
I don’t have specific question for it, but I’d discuss autonomy in detail. So like, “do I have the power to do my job the best as I can?”. Which could shine light to potential struggles others have right now, e.g. lack of tools, privileges, processes, management, whatever -> can I change them to serve my needs?
But I’m typically a person who sees problems as challenges. If there is no proper version control: I’d propose one. Awful ticket tracking? Suggest something more suitable. No testing at all? These are the methodologies I used and proved good. If these discussions lead to somewhere, let’s go, I don’t mind if everything is suck right now if I have the support for change for better.
I appreciate your youthful enthusiasm (said the old timer). And I agree, introducing some of these things in existing projects can be very rewarding indeed, but it can also be a huge time and energy sink. For instance, if your colleagues don’t see the value (why else haven’t they implemented it?) or somehow feel they’ve been bypassed they might actively sabotage your efforts. Without buy-in from everyone, you’re just setting yourself up for burnout. Most of the things on my list are not just a matter of setting up, but the mindset of maintaining it is essential to their success.
Cannot agree more.
If you want to pick a fight on some of the established processes, try to do only one, and the one that people complained most, and the result is measurable. Measure before you introduce your process changes and then get buy-in from everyone (or at least everyone that matters). And even that, put some generous time estimates for the work, don’t ever over-promise. Then it might work.
Getting the buy-in from everyone is also a good excercise to train my communication skills. If nothing succeeds, I still gain a lot of experience on discovering current system, plan a better, convince people about my ideas, etc. Even if I quit to not waste more time on it, I grew and part with more experience than I arrived.
My fav questions:
What good does your company’s existence do for humanity (or the community, depends on the type of compny)? Conversely what bad outcome for humanity are you willing to accept for the financial success of the company?
In the past I weeded out quite a bit of that by making it clear to the recruiter I refused to do any military/defense only projects.
That’s a great question. At my last BigCo job we discovered such a bug in our first week or two. After many false starts, it was not solved 4.5 years later…
This is only tangentially related, but during an interview for an internship I asked the prospective employer what a typical day would look like at their company. The interviewer was quite surprised; they said that (paraphrase) “nobody has ever asked us that before”. I’m not sure to this day whether that was positive surprise but I think it was. They gave me a generous offer despite my lack of practical experience or higher ed. qualifications.
So, that’s probably a good question to ask; but also, asking questions itself, especially if they’re well thought-through, is good for the employer’s image of you, as well as finding out more about the employer!
This is so interesting to hear, because as someone who currently applies for internships, “what does a typical day as an X at Y look like?” is talked about as one of the standard reverse-questions to ask during an interview.
I like to ask vague questions that require them to either elaborate or ask me for clarification. This isn’t completely necessary, but I try to get them to talk so I can pick up little tidbits that they might not otherwise share. So, questions like:
Not trying to do any gotchas. But, trying to just get a feel for how things work in the company versus getting answers on how things work at the company.
The main question I’d ask is some variant of: Why do you like working here?
I always ask “what constitutes an emergency here, and what is considered an appropriate response?”
Usual follow up, “when was the last time you had an emergency, and how was it responded to?”
Oh, so much this, and I’ve been pondering the same thing.
Does fixing a spelling error in the UI really require prioritisation in your backlog so that it can be fixed this year, or can it be fixed today — or at least in the next monthly release without so much procedure?