I've done a decent amount of hiring over the years. When I ask the candidates if they have any questions, I expect them to interview me as a potential manager. Everyone has their own set of criteria so there is not universal "good question to ask". Instead, you should figure out if you'd like to work with/for me? Do you feel you'd grow personally?
Perhaps you're in a phase of life where you just need the money to recover from an unfortunate situation. Still, you must figure out what are the criteria you won't compromise on, and make sure you're getting that. For some, it's work schedule; for others, it's communication styles. Maybe you'll be driven insane by my cheesy puns and so you'd probably want to figure that out ahead of time. Ask me what I'll do to ensure you'll be respected as an individual on the team.
When I'm a candidate, I like to ask how my failures will be dealt with. I will goof up at some point, the question is how is that managed. The larger point is there must be some discussion about potentially unpleasant situations.
Can your company offer a challenging environment where I learn daily, and look forward to walking into your building? That's the biggest issue I find with most employment opportunities. 90% of the jobs aren't stimulating me enough, and I'm thinking about being somewhere else.
Cheesy puns I can handle, are you adept at talking in movie references only?
I've worked with quite a few people who initially impressed me with how much they knew, but then they peter out and disappear after 12-18 months, because they can't be bothered to actually do work. Too often people want to be paid to enjoy their pet projects and work on whether component they feel like working on; not maintain their stuff when they get bored of it, and so on.
To be fair, you absolutely need to be able to learn and grow in a role to advance professionally.. But at the same time, some folks don't seem to understand that you're getting paid to use your existing knowledge to accomplish something you're already good at.
From my experience in a lot of cases this is the manager's fault or the system's fault, especially if the guy was initially enthusiastic. Here's an example: On my first day at work, I found some UX issue with our existing system and fixed and pushed the code. I told the manager what I did and he said "well this is not in the sprint, so why don't you roll it back?" That was my first commit and I rolled it back. Also I realized working too hard didn't do me any good. In the first couple of months I was super productive and just kept pushing out code, but nobody really cared and if anything I was being penalized for it because the more I commit the higher the chance that something will reopen, and I get even more workload--all without being much appreciated. Anyway stuff like this happened too much. After a while I started not caring at all and learned to become that guy you describe.
Boring manager PoV here: I love initiative, but bring it up in standup to minimize surprise. Sometimes one step forward conflicts with another 10 steps forward on another story.
On our team we have a bunch of fun stories with lower RoI at the top of our ready backlog, that may never get pulled into the sprint, but are there if we eat all our vegetables (e..g code reviews) and get the Sprint goal done early.
OK here's the situation: I was a new hire and the manager never assigned me any story for quite some time. Which means I had nothing to do with a "sprint goal". Of course it would be a weird thing if I have other tasks assigned but work on some unrelated minor issue instead of things I need to do for the sprint, I don't do that. But at the time I was literally idling away because I was never assigned anything. Leaving a new hire to do nothing for two weeks is a bad enough management. It's even worse when the new hire gets frustrated doing nothing and just fixes something that's obviously broken and is clearly something that doesn't conflict with other "10 steps forward". I forgot exactly what it was but imagine something like fixing a broken css. And I was made to revert it because it was not in the sprint. Anyway the point is not this singled incident. I mentioned how things like this happened all the time, making me care less and less over time.
Not necessarily. It is entirely possible to have a job where your role is to figure out elegant solutions to hard problems. If you hire someone ostensibly for that role, and they end up spending most of their time refactoring the code of junior devs, writing tests and tweaking the build process, they have a legitimate grievance and are fully justified in leaving.
On the other hand, if someone got hired on for a typical mid-level developer/engineer position without any promises of a research/advanced engineering focus, they need to man up and do their job.
> Not necessarily. It is entirely possible to have a job where your role is to figure out elegant solutions to hard problems.
Sure. But often when that's the case your title will say something closer to "Principal Researcher", rather than "Software Developer Engineer".
Don't get me wrong, a good thing about a job in engineering is that figuring elegant solutions to hard problems is a significant part of what you do there. Also, you can definitely optimize for that being a larger part of your time, if you aim for that when choosing where to work.
However, the jobs for which that is the only function you are employed to fill, and where you are expected to delegate maintenance of your elegant solution to someone else, are exceedingly rare. That's why the academic job market in CS is so much harsher (including industry research labs) than the software development job market. And, for the record, research work does end up involving either some amount of grunt work or some amount of management work at every place and level I have seen so far (universities, industry research labs, etc)
As a former academic I would say that there is more boring grunt work in academia than industry. Even worse a lot of it is totally pointless activity caused by the university bureaucrats needing to justify their position.
> On the other hand, if someone got hired on for a typical mid-level developer/engineer position without any promises of a research/advanced engineering focus, they need to man up and do their job.
I think this is a self-driven promise. Like another commenter said, this is up to your job description. If you work in the research department, you are more likely to do more "innovative" thinking than those who are hired to build a product because your primary job won't be building CEO a search box. "Product" can be interesting or totally banal, whether you are hired to build public-facing application, or internal application.
I say research focus is self-driven because unless you work in an extremely "do what I say or you are fire" environment, normally you can tell your lead or the product team how to build or enhance a feature. If you think your automated testing infrastructure looks broken, offer ideas to folks who are paid to build that part of the infrastructure. Sometimes, overstepping into another team's boundary is actually a good way to tell people you are capable of doing more than implementing a stupid drop down menu. IMO a good software engineer begins with you giving a clear analysis of the problem and providing a clear and competitive solution (pros/cons with other solutions). That's research, that's "leading", that's architectureing. As simple as building a drop-down menu, well, are you tired of writing a whole new menu every single fucking time yet? Well, here is a research, here is an architectural change - make that shit reusable and make your template whatever resuable, convince your colleague your suggestion is better than theirs and that they are idiot this whole time. No not that hash, but along that line.
And most real research job spend a good portion on writing and doing presentation.
Yeah I keep saying implementing a drop-down menu. But why? Because a lot of the tickets will be around enhancing user experience and that can either be very interesting to some, or extremely boring just because.
Boring programming jobs often relate to bad code bases. Is adding feature X tedious? Why is that not automated? Novel bugs are usually interesting, seeing the same thing crop up 10 times is a sign of brittle code.
Are deployments a single click, or do you go down a 30 item list every time?
Users often push systems in new ways and have interesting issues; the 5th redesign because some manager got a new idea is not.
ah yes, the ol' bait and switch. It's fair to point out that employers aren't the only ones who do this, employees are guilty of it too. I've certainly seen it happen where people were hired to write code for a particular project and instead try to do an entirely different job ("what we really need to be working on is a mobile site!", "what we really need is a scrum master!").
However, employers sure do promise autonomy and a creative role, only to attempt to turn that new developer into someone who is supposed to check JIRA in the morning and fix bugs or implement a narrow set of features defined (with little to no creative input), often with a corrupted form of agile that turns the daily standup into a daily application of deadline pressures and demands for status reports.
I've come to realize how valuable some of those stuffy old bureaucratic pratices really can be for me, as a developer. For instance, I have gotten a great deal of value out of formalized, written job description with everyone's signature on it, filed away with HR. Once you're in a relatively senior technical role, you will almost certainly have language like "determines technical requirements", "aligns software architecture with business interests", "makes technology choices", and so forth. These will often have a little percentage next to them, as if we can somehow explicitly state how much of your time these things will take. "Writes code to implement features" and "performs other IT duties as required" will probably also be in there, but it's unlikely, if you're in a senior role, that these will be more than 50% of your job description (certainly not that last one).
This works well, because if you're accused of "not doing what you were hired to do" when you refuse to maintain an old pile of crap without a clear path toward a better code base (where you determine the technology, business alignment, and architecture), or if people tell you the project that you believe clearly aligns with the needs of the business is your "pet project" and what you really need to do is complete those JIRA tickets, it's usually pretty easy to point to your job description (with everyone's signature on it) and make a very compelling case that you are in fact doing exactly what you were hired to do, and that someone else (often a project manager or business unit manager) is trying to grab job authority that aren't in his or her description, but are clearly in yours. You can also make the case that while you're always willing to pitch in and do what is needed, random tech tasks have greatly exceeded the percentage of your time they are supposed to be taking.
One thing I've slowly learned - the looseness and casualness of the software industry doesn't necessarily favor developers. Sometimes a formalized set of rules can really help us.
I always liked Michael O. Church's way of phrasing this from his post on "the Haskell tax" (I think it's been taken down).
Paraphrasing, he said something like, "most jobs require you to have work experience that is exponentially better than the work experience they will give out."
That is a huge red flag for me. If a place is straining itself to "hire the best" and put candidates through the paces of a very difficult interview process, but then the actual job is some full-stack bullshit where your specialty or past experience is completely disregarded and you just do whatever random work happens to someone's misguided priority this week (which is almost every start-up job) it's just a bad, bad deal.
Developers need to get away from the idea that it is the companies responsibility for your career development. You are responsible for your own career development. The company has hired you to do a job and they pay you for doing that job. Do not expect anyone else to invest in you unless it is in their interest.
It is in their interest. You want the best people at their best positions so you can leverage them to make more money. If your company doesn't care about making sure people are empowered to make the business money then I'd be worried about how they're going to pay your salary in the future.
If empowering and training is in their interest then the company (if it is smart) will provide it. The problem is that because you can leave at anytime the ideal investment for the company is likely to be less than what is ideal for you.
If they provide less than ideal for you, then you leave. Providing less than ideal is less than ideal for them, unless they don't care about losing you, in which case you probably don't want to be there anyway.
Out of the four jobs which I have voluntarily chosen to leave, three of my four resignations were because the employer stopped giving me meaningful work that prevented skill atrophy in my primary areas.
Preventing this skill atrophy on my own time, such as with side projects, is (a) ridiculous and (b) a physical impossibility because of the burden of working hours and exhaustion demanded by the employers I had at the time.
It's absolutely unreasonable to say that someone must find a way, outside of work hours, to effectively perform an entire second job's worth of practice and development, because their job isn't giving them work that exercises them.
It's like hiring a super model, asking him or her to sit on a sofa eating candy bars all day as the work you are paying them for, but then telling them to use their personal time to remain fit for supermodeling. It's a patently absurd idea.
You're free to say the words "developers should take control of their own career development" if you want to, it's just absurd. I mean, in once sense of course you're in control. Even if the career development happens at work, it's you doing it, so you (by definition) are in control.
But you aren't just saying "you're in control" in the obvious, tautological sense. You're going further to say that you should place no expectations whatsoever upon your employer to match up real-world business items to your skill set in any way that is related to appropriateness or which factors in your goals. That's the absurd part. You're saying "don't expect your manager to actually manage anything ... just resign yourself to the idea that they will randomly throw undifferentiated business concerns at you like a dartboard."
Real management acts as a double-sided adapter, with bespoke, unpleasant business realities on one side, and well-fitting tasks that are matched up to employees on the other side. Converting bespoke, unpleasant business needs into appropriate, on-topic tasks for specialized employees is managing. Saying an employee shouldn't care about this, to me, is among the worst advice I can think of. This should be one of the primary things any employee cares about.
Because the one thing that absolutely won't happen, simply by physical limits of exhaustion and life responsibilities, is for you to personally cultivate or exercise those skills during non-work time. Yeah, maybe you can read a tech book here and there. Maybe you go to a conference. Maybe you occasionally do some open-source work. And all of that put together amounts to maybe 5% of what's actually necessary to stay sharp and competitive in the employment market.
Instead, you absolutely should hold the employer accountable. They are asking you to bear an insane opportunity cost of lost time whenever you're working for them -- so much lost time in fact that if that time is not actively dedicated to building competitive skills, you will quickly become unemployable and you'll be so atrophied that you'll have no option but to stay at that employer because no one else will want the shell-of-a-former-expert your current job will have morphed you into.
There are a lot of good reasons to quit a job. You might not be paid the amount you prefer. You might not receive benefits that enable the life you prefer. And you might not be asked to perform tasks that cause you grow in skill, solve challenges, or learn new things in the way you prefer.
For me, these are not tradeoff-able. An employer either satisfies all of them adequately, or else it's not really an employer but just a thing wasting my time that I quit from.
For me, these are not tradeoff-able. An employer either satisfies all of them adequately, or else it's not really an employer but just a thing wasting my time that I quit from.
I think you might be missing that you have a total compensation and any costs to the company comes out of your salary. You could get lucky and the cost of the company providing you training and new skills is less than its value to you, but this normally doesn’t happen.
Think about it another way - if you lose a day a week of productive work because of training that means your employer is paying you for 5 days and only getting 4 days of work from you. This reduces your value to the company and hence how much they are willing to pay you. All things being equal you can choose to take a job at lower pay with more training or higher pay with less company provided training.
The things you depict as "training" ought to be business-value-additive tasks that happen to be both my daily work and also tasks that facilitate the career growth I desire. If the business can't do that, then they hired me for the wrong reasons. If they can't fix it, but are happy with my performance on tasks not related to my goals, they may be disappointed when I leave, and hopefully learn that it's necessary to structurally build into the concept of hiring someone the need to empower their personal goal achievement, just as their labor empowers business success.
Also, there is no reason why compensation must be conserved when decomposed into some traditional monetary part and some part from goal achievement. It could just be that I become more costly to employ as time goes on while at the same time I never reach a degree of costliness that motivates my employer to end the relationship. In fact, that seems obvious and surely something businesses plan for when investing in a long-term hire.
Also, my value to the company is not only my short-term labor, but also my future stream of labor. If they want me to stick around such that they profit from that future stream, they may have to do things that reduce my short-term output. It all comes down to what is their discount factor.
Expecting zero support in this regard is the same as assuming a hyperbolic discount function (or an extremely low probability that you'll choose to continue with that firm).
Finally, some of this is simply non-negotiable biology. Self-Determination Theory and theories of heteronomous vs autonomous goal satisfaction are just biologically at odds with what you describe. Wise companies would factor this in rather than trying to shoehorn humans into non-human situations and require them to attempt to sublimate away the basic need or drive.
Yes there is some friction in the process of wage determination, but in aggregate anything that reduces your productivity will reduce your income.
I think we might be talking past each other a little. It is not that companies should not provide training (most good ones do as it is in their interest for many reasons), but that each person should take responsibility for their own career development and not expect this is something provided by their employer. Apart from the fact that any employer is unlikely to invest the ideal amount in your development (since you can walk out the door), the training provided by the company reflects the skills they want you to have, not the ones that you might most want to have.
Letting anyone else set your training almost certainly is sub-optimal for you. Developers need to get out of the mindset that it is the company that grows them and into the mindset that it is their own responsibility. Sure you might take advantage of the opportunities offered by the company, but don’t expect that someone else will be responsible.
> the training provided by the company reflects the skills they want you to have, not the ones that you might most want to have.
This usually means you should leave if they won't fix it. They either bait-and-switched you into a job different from the job you signed up for, or else they did not understand their own needs and hired a wrong-fitting person.
I agree that developers are responsible for their own growth -- in the sense that they should quit jobs that are not imparting experience to them that helps them to reach their goals.
They should not, however, work that demanding yet not-goal-empowering job and also perform overly burdensome self-study, second jobs, night classes, etc., to make up the gap created by their employer's lack of ability or willingness to plan or manage correctly.
> but that each person should take responsibility for their own career development
> not expect this is something provided by their employer
The best way to take responsibility for your career development is to insist it is provided by your employer and to find a better employer if/when that's not the case.
I only have X hours of high productivity a week. I need the high productivity hours to effectively learn but they are also the hours that really justify my high income.
Think about it another way - if you lose a day a week of productive work because of training that means your employer is paying you for 5 days and only getting 4 days of work from you.
You can look at it in different way.
If company buys a car, it starts loosing its value. There is certain proportion you can write off each year and finally you can write off the car completely.
You are in fact suggesting the same to be applied to human beings.
I think that human beings can not afford that, they have to be as new also after 5 years of work, or even 10 and more.
This does not happen by itself, one has to put time and money into it and this should be fairly compensated.
There are two ways for it - it happens as part of work and is therefore compensated as salary, or it happens after regular work hours and is compensated as overtime.
There is no other way how it would be fair to the employee. They are not cars that can be used and thrown away.
That's like saying developers need to get away from the idea that it is the company's responsibility to pay them salary, offer retirement benefits, provide them shelter from the weather while working, etc.
The company may not have any literal obligation to provide such things, and no one cares. If they don't provide such things, reject them, move on, life's too short.
No it is the companies responsibility to pay you a salary (and any other conditions negotiated or legislated) in return for your labor.
Of course companies invest some resources in career development as part of their salary package, but it is likely to be less than what is ideal for you as an individual since you can walk out the door at anytime. Every developer needs to take control of their own career development because they gain the most out any investment.
This does not mean that you always take the highest salary, but you need to look at training and career development as an extra that is part of your overall salary package. In some cases the training offered to you is more valuable to you than it costs the company to provide and in other cases it is better to take the cash and invest it yourself. The important thing is take control of your own career development and don’t expect it to be handed to you by someone else.
Yes this is one of the difficulties of management. You need to balance the desires of the employees with the needs of the company and try to achieve the right balance. It is not easy.
In regards to those "hire the best", where the application process is more drawn out than top secret government clearance. Those just aren't for me. I'm not looking for top tier(I'm not), but I am looking for intellectual stimulation, and being involved in something that someone will actually be using. I get the majority of my satisfaction watching others use something I've created. My rant is over!
It is hard for me to get in that dating mentality that I should be testing to see if my interviewer and I are simpatico. I feel a lot of pressure to fill in the blanks on what I want to know without asking, so I don't seem like I'm still deciding if I want to work there.
I know that sounds ridiculous.
The only time I do well is when interviewing for roles in faraway Australia because I feel like I have no chance of getting picked up.
Or maybe Australians are just great at no-bullshit interviews and put me at ease like talking to a friend? Confusing.
I think you are selling yourself short by not asking questions particularly as a junior dev. Depending on the role, people are hiring you for not only your current skills but your potential to grow. Write some questions down in advance - no one is going to ding you for having a cheat sheet for asking questions.
Here's some questions I'd ask:
- what sort of training or growth opportunities do you have?
- do you offer any aid for continued education or online courses? What about conferences?
- do you have a buddy or mentor program to help me get moving quickly?
- Are there any books or resources you recommend so I can hit the ground running?
- If I got the role, what would make you feel you made a great hire in 6 months or a year?
I thank you for your kind and very welcome advice.
These are great questions - I think I probably have trouble locating more junior dev opportunities.
I always do research on the history of a company but because of turnover it doesn't score me any piñatas to know where they started if the interviewer can't engage with the stuff I'm mentioning. :(
Just doing the research puts you in the top 20% of candidates.
I have lost track of over the years how many time I have got the answer “nothing” to the question what do you know about the company.
I personally find it amazing that people don’t make the most basic investigations into the place they are wanting to spend most of their waking hours. It is like waking into a car dealership and saying to the first salesman you meet “I have $30,000 - just sell me any car as I don’t care.”
Or maybe Australians are just great at no-bullshit interviews and put me at ease like talking to a friend? Confusing
Australian are notoriously bad managers of non-Australians. We are often far too blunt and say things that we think are trivially minor that the non-Australian takes as hugely serious. We also expect and give far less praise than others for just doing our job. We do have a nice climate though :)
Not really. Australian managers can be just as bad as any other managers anywhere in the world. I should know, I've worked in Australian companies all my life and there are good firms and bad firms :-)
P.S. If you are from the UK or US they might treat you with a bit more respect... Put it down to cultural cringe
It's just really hard for me to view an interviewer as a friend usually. A couple weeks ago I had a really amazing interview experience with a company called Volantio because the first screening was a 'get to know you' sort of thing. Dude made it easy saying he wasn't yet interested in my qualifications/education and just wanted to talk about my interests.
We must have talked for over an hour about how great we think Coffeescript is.. (I'm a zealot).
Anyway, I wish I could make more interviews like that. I've actually started putting it in my cover letters that I'd appreciate going for lunch or something just to hang out and talk about frameworks.
It's great when I can detach myself from 'needing a job'.
I like that question (how will failures be dealt with)
Other questions I like:
* what are you looking for this position to do?
* what does success in this role look like?
I do data science so success is a little harder to define than in a software engineering role. It's a warning sign when employers want you to come in and spread some machine machine learning on things to generate profits in a business that so far is not doing so, or when you hear different descriptions of the role from most interviewers. It makes me believe that the business doesn't have consensus on what they want someone to do, and therefore, I will have a very hard time succeeding.
It's not so much time as it is getting all the important questions answered. If we're meeting face-to-face, there has already been an investment in each other so there's no point cutting it short. But in practice, it rarely lasts more than 10-15 min.
Another way to look at it, is I want to project reasonable expectations in their mind. Mismatched expectations is the root of many issues down the road...
One of my faves to ask my interviewers is, "Given a month of time to work on it, what would you work on in your current product?"
The question is worded such that it's not offensive and doesn't sound like a "trying to find out the bad stuff" kind of question, so it puts people at ease. But it still gives people a chance to talk about the "bad stuff", to air out the things that frustrate them about the job. Those aren't necessarily red flags that prevent people from working at the company, but it's given me a pretty good picture over the years of what the day-to-day is like working on that product.
> q: What do you use for source control? a: We use $NAME but we forbid branching because merging is too hard.
Where I used to work, and the first place I wrote software full-time, we were not allowed to commit code to our system (Synergy) until after our code review. I ended up creating a parallel SVN repository so I could do incremental check-ins.
I don't think we are supposed to either, but it's never been an issue for our company because there's always shelvesets with TFS, so you can shelve your work at different stages and retrieve it later.
If you're using a DVCS like git, though, that seems silly.
Mostly, only companies with cushy government contracts with unlimited time and expense accounts on their hands (think defense) don't want to fire their customers.
Unlimited time-and-materials (T&M) contracts are a rare beast. There is almost always a cap that cannot be exceeded without a renegotiation
As for not wanting to fire the customers, upper management may not want to fire them, but those of us actually doing the work sure did. We hoped they would take their so-called "experts" with them.
I mean or just view them as html. https://doctorj.gitlab.io/interview-questions/ I agree that the system he is set up is almost absurdly complex for what should just be a markdown file.
That misses the answer, followup, and reference. Unless I'm missing something...
- q: Would you say your colleagues are good at reading your emotional state, or still learning? # TODO: Better wording so the answer is not so obvious
a: Research shows the most important factor in team effectiveness is psychological safety, a "shared belief held by
members of a team that the team is safe for interpersonal risk-taking." One component of this is high "average social
sensitivity," or that everyone is good at reading the emotional state of others.
followup: Do you feel like your opinion is heard, respected, and valued?
ref: http://www.nytimes.com/2016/02/28/magazine/what-google-learn...
pri: 1
tags: [culture]
Haven't we all been there? We want to setup some great polymorphic abstraction that allows us to adapt it deeply and effortlessly in the future. Then half way in we're like "fuck I actually just needed x, not the whole alphabet". I actually give props that he finished it rather then revert it to something simpler bug uglier (as I would've done).
But one question. What was thinking behind setting up the extensive YML structure instead of just using simple markdown? I see some reasoning with printing through a script, but will that be a significant use case?
This structure just seems complex for doing a quick PR with a question that I'd like to see added, and would keep me from contributing.
Yeah, probably a bit over-engineered; just having a little fun. The idea is that you can filter and sort based on metadata, merge multiple lists, make mashups, and render/style it how you like. Feel free to just open an issue with a question, or post it here!
In the YAML, you can get away with just:
-q: Your question here.
My thought was that it would be useful to have it in machine consumable form if you want to collect data and report on things. You could turn it into a "debriefing" program that makes it quick to go through after an interview and note which questions you asked and rate your satisfaction on their answers.
This is everything thats wrong with (web)developers today.
Why is this available in more than one format?
Why on earth is there a filter.sh and render.py?!? This is just awful. If you can't read through a simple text list and select the appropriate questions then you're already doomed.
YAML's a weird choice for this kind of application. I once explored different markup languages for maintaining my resume, ultimately just went back to using LibreOffice.
There's a temptation to use a structured, machine-readable formatting language for anything that has structure, because you might one day want to use machines to work on it.
But for an application like this, those times are the exceptions, most of the time, it's humans that are going to read and modify the text. It makes way more sense to use a human-oriented format and simply use a convention so that it's easy to use a tool to convert it when you need to. I see no reason why Markdown can't be used.
I use LibreOffice for my resume too. However, I'm the only person who maintains my resume, so it works for me. For something that's going to be touched by a lot of different people, a text-based language is far better because you can diff the changes easily. Such tools exist for office documents within those programs, but they're clumsy and don't integrate with source control systems.
But otherwise, Markdown does seem like it'd be a better choice. Everyone's using it these days, it's simple, whereas YAML is obscure.
The interviewer is trying to recruit you and also filter you out, but usually will not honestly respond to questions about what they don't like, or will hold some of those against you.
Ergo, you really have to ask "what is it like to work here" (and also culture questions, etc) and leave open ended questions, and then learn to read between the lines. Asking multiple people the same question can also be good.
Attempting to gauge enthusiam is good.
I find places that really want to invest in new hires and make them feel part of the team are the best (i.e. people that want to take you out to lunch and help go over code with you), but those are in my experience also a bit too rare.
You also need to figure out if the folks are smart, not burned out too much, and whether there's a lot of politics -- but it's really hard to filter that out from an interview, just in the same way it's hard for people to tell how a candidate is really going to be too.
Don't be afraid to ask it. You can phrase it in a more wishy-washy way, e.g. "what's the work-life balance like", but this is a common question. If someone DQs you for it, you didn't want to work there anyway.
The thing is, a lot of people think they "do it right", even if they are coding without source control and releasing 1 time a year. So worried this won't tease out enough unless you drill down into what they are view as right.
This has also a lot of wiggle room. I'm not sure where I'd put myself, since it depends a lot on the situation. Do I have time to do the proper thing? Then I try to do it right and nice. Is it incredibly urgent to finish A, B, C and Z just exploded? I'd hack a solution for Z, get to (properly, hopefully...) solving A, B, C and hopefully next sprint we can properly fix Z for real.
You know, sometimes you have to join a company and get the s*it done yourself. The failure to answer some of this questions also shows the areas where you can be most valuable. Overall, I find fitting well in a team is of way more value than anything else. Good teams succeed even in bad companies.
I would politely submit this whole interview system is wrong. Why not slowly get to know tech workers and interview them over the corse of many days to understand what they are capable of? This idea comes from http://officecrashe.rs
I wouldn't work on someone else's project for "many days" for free. I strongly suspect most other candidates wouldn't either. If you start paying them for their work, then it seems the decision to employ has been made and the interview is in actuality over.
If you keep someone at work for this long, you should pay them at contract rates.
I would really like this as an option. If I wake up tomorrow and have no job, it would be neat if there were companies out there willing to pay me contracting rates for a few days, because it would let me pay my bills.
this is a complete mind shift for the process. Step 1, people currently employeed and happy with their job get permission to work from anywhere. i.e. a Self Contained Tech Worker. I work from any coffee shop I want to, my employeer is happy with my work. Step 2. I start crashing offices and working else where, still working for my current employeer. They don't care where I work, coffee shop, or some other office. Step 3. Over time as I work at new places I'll get to know new people. Leads to my next job when I'm looking for a switch.
At this point in my life, if I work in a tech firm that pays me a reasonable amount (when I say reasonable I don't mean top dollar, average or slightly below is fine for me as I have relatively low levels of debt and my wife works also) and treats me fairly I'm not that worried about other issues like aging tech stack or legacy code base.
Reasonable management allows you to work towards fixing this, although might not always make what you consider optimal technical decisions.
If you can get along with your colleagues, get paid on time and not have the boss breathing down your neck I think that's a pretty good job!
This is a great resource. As a junior developer I didn't have much experience or confidence in this area when interviewing for my current job. The big red flag for me should have been the way they answered my questions. "what is your development process?" "Oh, hmm, I dunno, I guess agile." asking about technical debt would have been a good one, too. Hint: there's lots.
I conduct a lot of technical interviews, and I always make "Do you have any questions for me?" the first and last question that I ask every candidate.
Mostly this is to provide an opportunity to just answer a question, of course. But it's also true that a candidate's questions, or lack thereof, can affect my evaluation of them.
So, my advice: have a couple of good questions on tap. If you don't, you run the risk of seeming unprepared or lacking confidence.
How much time do you typically allocate for this? I generally feel frustrated when an interviewer hammers me with difficult questions for 55 minutes and then leaves me with less than 5 minutes to ask questions. I don't think I have even one single question that matters to me which an employer could answer in less than 5 minutes of discussion. For example, my top question would probably be "how is my performance evaluated / does your company have direct or indirect stack-ranking, etc.?" That's a critical question, but not one that can be easily answered in 5 minutes. And that's only one out of about 10 or so such questions for which I would require detailed answers before considering taking a job.
In an hour interview I'll do about 30 minutes of asking them questions, then give them a little 5 minute spiel about either the company in general or my team in particular, depending on what position I'm interviewing them for and who they've talked to already, and after that I'll take questions. I certainly do not have an upper threshold for this, and if they ask so many questions we can't get to the coding part of the interview, then we can't get to the coding part.
No, it's too critical to make sure you're not wasting time with open-plan office nonsense, stack ranking nonsense, or many other other kinds of systematic dysfunction that are frequent in tech jobs.
If you only focus on tech details, you waste your own time and the interviewer's time.
There are other people who are better targets for your non-technical questions than the senior engineers with whom you have a brief opportunity to talk. Use that time wisely.
The HR staff will say misleading things and present a rosier picture than the technical staff. The technical staff are the ones who know what the sociological issues are really like, and the degree of happiness you experience in the job is likely a lot more related to how the other technical staff answer the questions than non-technical staff.
Saving all this stuff for HR is a huge mistake. You won't get any useful info.
The interviewer controls the use of time, so don't worry about imposing a burden. In my case, anyway, I'd rather have a fascinating technical conversation than ask my usual programming challenge and algorithm design questions, so your great question might seem more like a gift than a burden. I'm serious! With me, anyway, ask big questions like "what should/will HPC hardware and programming languages look like in 10 years?" and then tell me why you think my answer is crazy.
As a hiring manager I can never get too many questions from a candidate. If there's something specific I want to ask you, I'll make sure I get my question in.
let me ask you a serious question, notroll -- have you ever been asked more than 15 minutes of questions by a candidate, in an interview? i have not, and i've interviewed probably 300-400 people in my life.
i interview almost exclusively over the phone, and we don't fly people out to waste days of their life, or have more than 3 rounds of phone discussions, so maybe that's where this disconnect.
That seems like a really odd way to interview. If you really are relying on phone interviews to make a decision, then you bet my ass I'm asking you more than 15 minutes worth of questions over the phone (if I have them).
why is this odd? we hire remote workers. after 90 minutes of conversations (30 mins. x 3 rounds typically), it pretty much covers everything just fine. more than 15 minutes is half the scheduled time for each call.
occasionally a very good candidate will talk for an hour or more, but that's an actual conversation, not a Q&A session.
also, i didn't ask "theoretically would you ask more than 15 mins. of questions", i said, have you been asked more than 15 minutes by a candidate, that you were interviewing.
in the real world, most people don't ask any questions. it's exceptional that we'll get thoughtful questions, and those are usually the people we hire/offer. and of those people, nobody has more than 15 minutes worth. and people who can't even answer basic questions like "how do you list the network connections on a linux machine" aren't given the opportunity to ask questions, because the call is over.
again, a long-winded technical discussion is a different thing, i'm talking about "tell me about your enterprise ticketing system and how many pointless meetings per week you have" type of questions.
I do the same. And I contextualize it by saying, "this is a two-way process - we both have to decide whether this is a good fit," specifically to help candidates feel at ease to ask questions and that I am honestly interested in answering them.
"What is your favorite thing about working at company x?"
This is a simple but great one to end with. If they smile genuinely in their answer then that's good information for you and its good to leave them on a high note to tilt things in your favor.
Thank you so much for putting the work in listing out exact questions. I have been maintaining my own list and I am glad to find some really good additions from this list.
If you have anything you are curious about, ask away. If no, asking questions for the sake of it does not improve your situation one bit, it won't come across as clever or thoughtful.
I realize this is geared towards the end of an actual job interview, but many of the questions that really hit home for an employer are: Questions that demonstrate 1)technical ability and 2)culture fit. If you can ask questions that show an employer that you can do your job well and that you will fit in with the team, you are that much further ahead of the competition.
Questions serve as an opportunity to "fill in" the employer on areas they may have forgotten to ask you. If they are not 100% that you can do your job (or are teachable) and that you will fit in with the company, it is your job to ask the questions that eventually give them certainty.
Shameless plug: Just released a book on informational interviews with a huge list of questions and walkthroughs on how to do them. Best way to get a job!
The primary use of questions during an interview is to actually determine if the employer is a good fit for you.
Your advice seems to take a different approach -- that you shouldn't use questions as a means to ensure you will be happy in the job, but rather as yet another opportunity for status signalling.
Even the first sentence depicts a totally alien attitude to me: "questions that really hit home with the employer are..." ... What? I have no obligation to ask questions that "hit home" with the employer. If the employer doesn't like the questions I do ask, well that right there is a good indication that I would be miserable working for them and should just work elsewhere.
By approaching even the part of the interview where you get to steer the topics of discussion (your questions) with an attitude of infinite pliability and fealty, it makes the process even more about subjugation and hoop-jumping than it already is.
I agree you are also trying to determine if the employer is a good fit for you. I think this is implicit in the interview process. You absolutely should ask questions that tick your own boxes!
What I have found in my own career, though, is that you can't turn down a job or company if you are not offered. If you get an offer, and the company isn't a fit, it is your own prerogative to turn it down. Until that point, though, you are selling yourself and trying to get the job.
Perhaps you're in a phase of life where you just need the money to recover from an unfortunate situation. Still, you must figure out what are the criteria you won't compromise on, and make sure you're getting that. For some, it's work schedule; for others, it's communication styles. Maybe you'll be driven insane by my cheesy puns and so you'd probably want to figure that out ahead of time. Ask me what I'll do to ensure you'll be respected as an individual on the team.
When I'm a candidate, I like to ask how my failures will be dealt with. I will goof up at some point, the question is how is that managed. The larger point is there must be some discussion about potentially unpleasant situations.