[athenot]

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.

[overcast]

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?

[rconti]

Is this a "you" problem, or a job problem?

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.

[galistoca]

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.

[enraged_camel]

>>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?"

I hate managers who punish initiative-takers. I hope he got fired.

[galistoca]

Actually, no. He's been promoted to higher position now. This is another thing that made me disillusioned. At larger companies it's all about politics

[chris_wot]

Perhaps though it might be best to roll it back but keep it in a private branch for later?

[ultrasaurus]

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.

[galistoca]

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.

[CuriouslyC]

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.

[lazaroclapp]

> 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)

[danieltillett]

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.

[yeukhon]

> 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.

[Retric]

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.

[geebee]

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.

[p4wnc6]

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.

[jared314]

"It’s ridiculous, but most companies demand an astronomically higher quality of work experience than they give out."

Why programmers can’t make any money: dimensionality and the Eternal Haskell Tax - Michael O. Church [1]

[1] https://web.archive.org/web/20151221082425/https://michaeloc...

[danieltillett]

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.

[pdeuchler]

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.

[danieltillett]

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.

[p4wnc6]

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.

[danieltillett]

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.

[collyw]

If a decent developer gets bored or frustrated then they are more likely to leave, despite having spent a lot of time learning the system .

[danieltillett]

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.

[overcast]

God damn, I am stealing that quote.

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!

[coroutines]

I am a junior dev.

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.

[willwagner]

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?

[coroutines]

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. :(

[danieltillett]

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.”

[danieltillett]

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 :)

[chris_wot]

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

[coroutines]

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'.

[x0x0]

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.

[brown9-2]

How much time do you leave aside in your interview for the candidate to interview you?

[athenot]

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...