But I do ask things that show if the technical recruiter actually knows what they are talking about.
"What strategy do you use to complete Pull Requests?" There are many ways to answer that question that will show you don't know.
In general, I ask things that make me see if the other person is reasonable, and I can talk to one-to-one, but also that they make conscious decisions and don't just carry around cruft.
This might involve asking "What ORM do you use?", then responding to their answer with "Oh, why didn't you use <other ORM>?".
Because unless you are some sort of celebrity engineer, "interview is a conversation between both parties" is nonsense.
Company is interviewing the candidate not the other way around, no matter what we like to think.
Edit: Sorry I should've clarified. I am specially referring to companies that don't really have to care about your feelings towards their interviews. FAANGs for example. They simply don't care and there are million others who are willing and happy to go though whiteboarding. They just don't have to put up with your stuff.
Ofcourse you have leverage when you are interviewing at your local java enterprise shop. But who cares about those jobs, pointless to interview them with your smartass questions, we all know they are pretty much all the same more or less.
This was true in my first job out of college. After that I definitely was interviewing the company. I've had the fortune to always be interviewing while having a stable job so I never needed the job I was interviewing for and it's wise to be picky if you can afford to be. There's a lot of risk associated with changing jobs and I do what I can to either minimize that or at least know what it is. I've said no to two companies. One because I got a better offer and another because I didn't want to do the kind of work they were doing which was really only evident after going through their sample project.
Strong disagree; it is not always this way. I'm no celebrity, and I flail at adversarial technical whiteboard exercises, but I've been paid well to do software-related things for over 20 years. Maybe in part because I insist on treating every interview as bi-directional. It is not necessary to accept a "please may I have this job" attitude towards a potential employer. Software developers are radically more empowered than many of them (us) realize, and IMHO part of the reason so many corporate hiring processes for technical roles are so brutal is that it reinforces the mindset of subservience and is an effective way to assert and maintain dominance. [In the US some of this is a structural problem tied to larger concerns like health insurance being tied to employment, which tips the scales of power, putting employees in a position where they may actually need the employer more than the other way around...]
TLDR if you don't think you're interviewing the company too, you're doing yourself a big disservice and selling yourself short.
if you don't think you're interviewing the company too, you're doing yourself a big disservice and selling yourself short.
Absolutely.
But outside of places like SV or NYC, there may not be a lot of jobs available. For someone with a similar length of career, I'm not as flexible about being able to move to where there are more jobs. Is one just SOL when trying to improve their career; take what you can get?
In the top 10 metro areas in the US outside of SV or NYC, there are still plenty of openings at any given time - speaking as someone who has spent 20+ years in Atlanta.
I only found this true when I was young and inexperienced. These days, I dig into what matters to me - the team environment, the corporate ethics, the quality of their leadership, and especially their end goal - are they trying to build a stable operation to last decades, or pushing for an acquisition/exit?
I can deal with most tech problems and flawed companies, but the above list are my deal-breakers, and I absolutely am interviewing them to find out the answers.
I am not a celebrity engineer but after 2 job changes I realized that I have more leverage than the company wants me to think I have. Since then I have always interviewed the company just as much as they have interviewed me. I've turned down positions based on the interview.
If you assume you have no leverage then you will have no leverage, but that's more because you choose not to exercise it than because you couldn't exercise it.
Company is interviewing the candidate not the other way around, no matter what we like to think.
I’ve worked for 20+ years but have only gotten serious about job hopping and interviewing for the last ten.
At any given time when I am job hunting I usually have three or four offers within three weeks. Not saying I am a special snowflake. That’s just the reality of the market. I’m very much interviewing the company. I usually have a BATNA of just keeping my current job.
Ofcourse you have leverage when you are interviewing at your local java enterprise shop. But who cares about those jobs, pointless to interview them with your smartass questions, we all know they are pretty much all the same more or less.
Despite the HN bubble where every developer lives on the west coast and works for a FAANG or the next unicorn, that’s the reality for most developers. But there is definitely a difference.
> Because unless you are some sort of celebrity engineer, "interview is a conversation between both parties" is nonsense.
I disagree. Unless the candidate desperately needs this job, he/she can walk away. The candidate is free to consider "company won't bother to answer my questions at the point when they have most reason to be nice to me" as a bad signal.
> I am specially referring to companies that don't really have to care about your feelings towards their interviews
"This company doesn't have to care about my feelings because they are huge and have lots of applicants and a giant incessant interview machine chugging through them efficiently" is certainly something I'd consider in whether I want to work for them, because it tells me I'd be a cog in a machine. (And if enough people consider that, perhaps they will have to care.)
To the parent question: I wouldn't ask a whiteboard question exactly, but I would certainly ask some questions about existing architecture and rationale so I have an idea what I may be working on.
Aren't you a cog regardless though. Why would one work for half the salary just because of an interview. If one can get over the interview part, he/she can retire 10 yrs sooner.
Well, to take the metaphor too far, there's cogs that are greased and used only within spec, then there's cogs that are never greased and deliberately run beyond spec, rust ignored, etc., and in the worst cases, cogs that are used as, err, bulletproofing or something. Metaphors. Never trust 'em, they always turn on you.
For what I'm paid, I don't mind being a bit of a cog. Work is a means to an end for me, not my identity. But I would like to be kept greased and worked within spec, not constantly in crunch time. And while I am fundamentally disposable, I prefer to work in a place that sees I'm lot more valuable not being disposed of. (Again, metaphor breaks down here; planning on your personnel being routinely disposed means you are planning on nobody ever actually developing any skill in your systems.) It's not all the same thing.
As an occasional interviewee and mostly an interviewer, I would agree that the company has the leverage. However, the interviewee should be using the interview to find out what they need to know, to the extent that's possible.
Is tooling important to you? Ask about that. Do you want to push to prod like a cowboy, or does that repulse you? Ask about that. Whatever frustrates you about your current job, you can try to find out before you take a job where it's worse.
Framing those questions to get usable answers is a skill, of course, but if you've got a few areas to ask for, you can use lists like these to find different ways to ask. Just like interviewing, asking leading questions gets you 'right' answers that don't tell you what you want to know, so you want to get the interviewer to go off script and probably be truthful.
> Is tooling important to you? Ask about that. Do you want to push to prod like a cowboy, or does that repulse you? Ask about that.
So at FAANGs for example, there are hundreds of teams that do all of kinds of stuff. You aren't necessarily interviewing directly with people from that team.
Yeah -- so if knowing you're going to do before you accept a job is important to you; maybe they're not a good place -- or maybe you can ask enough people during the interviewing to be comfortable you'll find an appropriate team during the post hiring interviews; or ask about being pre-allocated to a team.
Ask their own whiteboard question? That would be strange, as I'm a manager and don't write much code these days. But, if I ask a whiteboard question (or any tech question), asking me related questions as a means to further the discussion would be a good signal.
> That would be strange, as I'm a manager and don't write much code these days.
I'm a manager that rarely codes as well, but was still asked coding questions in an interview. It's a bit annoying, but having had managers that have never written a line of code ever, I understand wanting to verify that the manager could theoretically do the work themselves.
I can theoretically do the work and I certainly understand the technical problems my teams are solving. I'd happily write some pseudocode to prove I know general things, but asking me to write the fastest version of X isn't going to prove I can manage people. Heck, that's not even a good question for most developer positions.
FWIW, I recently interviewed for a manager role and there was a coding element. It required a small amount of cleverness and some knowledge of basic data structures. It felt appropriate to me, at least to establish that I would have some clue about how things work.
That said, it was the only one of my four interviews that actually included any coding.
FWIW, I make a white-board available, but don't require it's use. I'm not looking for syntactically correct code. I want to know how a candidate would approach a problem. If that involves them drawing or writing pseudo-code, that's fine with me. If they can talk through the questions without the board, that's fine too.
During the last interview, I've had similar thing happen to me -- after we discussed whiteboard design question, the candidate asked, "how would you solve this?". This resulted in a pretty nice exchange of opinions.
In a somewhat related point, last time I was designing the coding question, I tested it on my teammmates. They all solved it, and their response was very helpful, and it allowed me to clarify some points in the problem.
But did they all solve in under the interview conditions? ( time pressure, coding infront of strangers, possiblity of not getting the job that you need etc).
I can pretty much solve all leetcodes on my own computer with noone staring at me like hungry wolf eyeing its next meal.
I usually allocate up to 20 minutes for that problem during the interview, maybe extending this to 30 minutes if they are not doing too well.
My goal was that the co-workers solve it under 10 minutes -- that 3x length factor is trying to compensate for harsher interview conditions.
As for leetcodes -- I just looked at the site, and my interview question would be rated 'easy'. In fact, I'd say that most of the 'easy' questions there are too hard for the programming interview.
Because it's a poor source of information about experienced candidates, and more about cargo culting and/or hazing.
I suppose that briefly turning it around on the immediate interviewer could be constructive, with some people, but I doubt I could pull that off even half the time.
My impression, from HN comments and firsthand, is that people still doing it seem to be thinking one-sided about it (i.e., they want to assess and/or manipulate "the candidate", and they seem to assume it's implied that everyone at the company is good). They probably also think this is convention, and perhaps resent or are suspicious of anyone not complying.
Personally, rather than turning the tables with the hazing, which can come across as hostile or combative, my natural inclination is to have a candid and thoughtful discussion about it.
(Warning: I've had poor success with trying to discuss with people who want to do the leetcode/puzzle-style whiteboard coding hazing. Maybe partly because the conversation only has occasion to happen with people who are still doing it, so it's not a representative sample of the field. I also suspect that, when it's with the more HR/recruiter-type people (not engineers or managers), they tend to not be participating in the discussion in the same way I am, but instead are performing the right head nods, while focusing on their normal modes, such as looking for red flags in what "the candidate" says, formulating how they'll report this, and being careful what they say.)
That's not very useful tbh. If you want to question their technical knowledge, ask for their road-map, what technologies they're looking into to adopt, what their tech-stack is, if and how they plan to migrate their legacy stuff, and their idea of an ideal dream setup.
I also ask 'company culture' related questions, my go-to question is ask what the team I would end up in did as a teambuilding event last year, and follow up with who decided the type of event. It tells you a lot on the freedom you'll get, the company's attitude towards people working there, and how healthy the company is.
Because in a two-sided interview the interviewer is trying to evaluate you, but you're trying to evaluate the company and its processes, not the interviewer as an individual.
Usually it literally does not matter how the interviewer thinks and what they believe is right, you want to know the actual company policy, which often will not be the same as the interviewer might want to.
However, if you're being interviewed by your future direct manager, then you do want to get a perspective on how they think, as their individual attitude towards various aspects of work life will be relevant to you - but usually most interviewers aren't that relevant.
Hmmm, I did discuss some of the technical questions from the list and I have to admit that it's not easy to make a decision based on them. It's a great start for discussions, and definitely something to consider but your time is limited, the other side will beautify the answer, the same as you do, and you might end up in another totally different team than this of your interviewer.
Remember that things tend to be fluid, re-organizations happens often, having a bug tracking system doesn't make bug handling efficient and CI/CD doesn't mean your time to deliver is necessarily short.
Completely agree. Would you mind if I stole your second paragraph? (Or could you submit it as a pr?)
Those are definitely seeds of conversations rather than something you can 100% rely on. But if you have doubts about the organisation and then hear "no bug tracking, we don't need it" without explanation, then something's definitely fishy. That's one of the red-flag questions. Then again if they don't but have an explanation, maybe there's something really interesting behind it.
Interviewing the interviewer has been THE best way to get the job. It just oozes a confidence that you already know you're good enough to get the job, and you're trying to figure out if they are good enough for YOU. Figure out questions before hand that describe the type of good working environments or fixes for bad ones that you've had in the past. The interviewer will quickly shift and try to sell the position to you (harder than normal). It sounds silly, and like something they'd probably be used to by now, but in every case I've done this it's landed me an offer. This is coming from someone who needs to interview well because my degree/experience doesn't usually perfectly line up to the jobs I'm applying for.
> The interviewer will quickly shift and try to sell the position to you
I wonder if that's often how it's perceived on the other side. I love when the people I interview ask me questions. If they're interested in something, not only am I going to answer as best as I can, I'm going to be interested in why you it's important to you. It can be a great conversation, and I'm not even trying to sell the position :-)
People really don't do it often enough - that's why I decided to post my own list.
The best interview I ever conducted, the candidate not only aced the technical questions, but was able to ask solid follow-up questions on those topics. "I solved it this way, what would you have done differently?" "This solution was quick to write and simple to understand, would you prefer a more performant solution?" And during the "social" part of the interview, he asked detailed questions about the company and our niche, not just generic "how big is the team" stuff.
At my job, we have "do you have any questions for us" part as a standard part of every interview -- and my experience shows that most people always have at least one question.
I think there's nothing wrong with what you're talking about here, but I also think it's different from the comment here. You really need to be asking questions throughout, taking any questions directed at you, answering them, and then using that as an opportunity to learned related things about the company, the team, and the environment you would be spending all your time in. It should be continual engagement and back-and-forth, rather than a one-directional quiz (until it's time to ask your questions.)
I suspect most candidates have at least one question because it's pretty widely known that many employers will ask "do you have any questions for us" at the end of an interview, and so will have prepared something that makes them sound interested in the employer in some way, even if they don't necessarily actually care that much about the answer. (For instance the advice on https://www.wikijob.co.uk/content/interview-advice/interview... suggests "Have two or three interesting and intelligent questions prepared before the interview, to show that you are interested in the job and eager to find out more" etc.)
When I used to not have any questions after the interview - I got rejected what felt like a weirdly high amount and definitely a weird tone from the interviewer.
When I started asking questions - the interviewer seemed to have a much more positive outlook on me and my acceptance rate went up.
I've interviewed a lot and there are people you have to ask questions to or else they will reject you.
As an interviewer and hiring manager, a candidate not asking questions indicates a lack of interest in the company/role. I appreciate when a candidate interviews me about the role, the team and the company. It demonstrates a desire to take advantage of an opportunity to gather more information about whether this is the right opportunity for them.
When I interview that's my first question, because it helps set the stage for being it a dialog instead of a Q&A barrage. It's much easier to also wash people out at this stage (depending on what # you are in the interviewing sequence) when they have strong opinions of on call rotations, remote work, etc. Questions often come to mind as you go along through an interview process and I'd rather you ask up front then have it sit in the back of an interviewee's mind as something they want to remember to ask.
As a freelancer (SRE/devops/'cloud native' architecture etc), this is what I do. Not all questions in original article apply to me though, but I get quite a few offers, and I only try to accept interesting-ones.
In my experience, when interviewers don't switch to selling the position, this is a bad sign. I'm confident I know my job, am open and honest about what I know and don't know, I don't need a 101 quiz of whatever tech they have in mind. If this happens I usually cut the interview short and just tell them this is probably not a good match.
When I'm scheduled for a technical interview, I've got some time for questions, but not a lot. If the candidate controls the interview to the point where we don't have time to get into the harder technical stuff, that's a red flag from experience with previous candidates; but I also will try harder to push back to the schedule to make sure I get the technical signal I'm looking for.
Your advice is correct, but depressing. These body-language games people play with each other are manipulative, and sometimes deceptive. Even if there's truth behind the assertion of confidence, the assertion was made to manipulate the outcome.
No doubt, the most obvious rebuttal is that the interviewer will be doing their best to manipulate no matter your tactic, so you either circumvent them or acquiesce to them.
I take "manipulation" to be somewhat similar to "lying." The distinction is intent. So, you have at least three scenarios:
- 1) You earnestly express a belief, and it happens to have the desired outcome.
- 2) You express a belief primarily because you know what outcome it will create.
- 3) And the grey area: You honestly hold a belief, but you're also well informed about how that belief must be presented to modify your outcome.
Realistically, most of us live in that third option. The distinction between a job interview, and say, a dinner out with a friend, is that you're highly incentivized during a job interview to present yourself in the best light possible. Most of us are aware of how we'll come off when we make a statement, and there's always some incentive to come off in a better light. But, a job interview generally removes the possibility for blunt honesty. "Well, of course I'm excited to work here. If I don't express that excitement, you won't hire me!" Such a frank appraisal isn't really possible in a job interview. But in another (ie, a social) context, you could make a sarcastic quip, or even just an honest appraisal of the situation. "I'm excited to see you, but being in this crowded restaurant is giving me a bit of a panic attack." Maybe that's not the best social tact, but the option is much more available in a social context.
I'm meandering a bit here, but I hope my point comes through. When we're stuck in that grey area of option #3 in most situations in every day life, we can generally chose to go with honesty if we prefer. In a job interview, our success and survival depends on forcing us toward option #2.
Lying, manipulation, and violence share the same underlying theme: depriving someone else of their free choice. Either by withholding truth, playing on their subconsciousness, or threatening harm.
At a smaller place, sure. If you know the job would require working with the interviewer. But in places like Google, who you're interviewing has no relation to where you work within the company; team placement comes after hiring committee deciding they want you.
I totally agree and, anecdotally, the last time I was interviewing for a position, the thing I was terrified of the most was running out of questions to ask (which happened eventually, after 5 rounds of interviews with ample time in between).
I'm happy to be adding a few more questions to my list now :)
>the thing I was terrified of the most was running out of questions to ask (which happened eventually, after 5 rounds of interviews with ample time in between).
Why? Usually by the last interview if I have questions they're personal getting to know the person type questions, because I've got everything figured out by then.
I'm okay with this as as interviewer as long as they allow me to ask my own questions. There have been a few candidates over the years that swamp you with their own questions that you don't have time to ask them your own. In this case it just leaves doubt in my mind.
That's a really good list. I really wish I'd asked a few of those in the past.
"Where do you plan to be in 5 years" is actually a really good question to ask a company. Many have no idea (which is possibly fine, but good to know)
Interviews can also be a fantastic place to get real feedback - but you have to do it during the interview; almost nobody gives real feedback after the fact.
"What would give you concerns about hiring me?"
"If you could have your dream candidate for this role, what would they look like?"
"What in my application caused you to call me in for an interview?"
I would change the part:
```
Do you use source control?
Do you test code?
Do you use bug tracking?
Do you use CI/CD?
```
to
```
How do you use source control?
How do you test code?
How do you perfrom bug tracking?
How do you solve CI/CD?
```
For really good companies asking if they test code seems insulting :P
That also moves the question from being closed to being open - potentially leading to a secondary question that will highlight your ability to ask insightful Qs.
> For really good companies asking if they test code seems insulting :P
Well that's the general expectation anyway for 'tech companies' to be testing and adopting best practices these days. There are even companies nowadays that are tech enabled with apps, engineering departments, etc and they call themselves 'tech companies', but they don't have any tests, code reviews or a CI and take the shiniest tool for the job.
So if I was interviewed at any company, startup or large corp for a software engineering role and they don't have any of the above, I would gently terminate the interview. Imagine if hardware engineers were to tell us that they don't do verification or tests on components that they ship.
It depends - I know plenty of companies that believe in the Mechanical Turk style of testing - just hire more QAs (usually outsourced). If they are okay with that, I’m not going to push back.
But for the bad companies, the answer might really be NO and you want to avoid them! I joined a place once without any of these. No source control, no bug tracker, no QA or testing, failing builds were the norm, and people worked to make things compile just before releases happened. Releases, by the way, were cut from whatever happened to be on the lead developer’s workstation on the day the Eng manager decided to release. It was a circus.
As much as we’d like to believe tech shops are at least all run by grownups, things like source control and working builds are NOT to be assumed!
I'd focus your questions to only the ones where answers might make a difference as to whether you accept the job. Are you really going to turn down a job because their on-boarding process isn't optimal? Or to a bad tech answer... would you turn down the offer, or help them improve from the inside?
I do like this list, but filter it down to what you need to respond to an offer. And that filter will be different for everybody.
Typically when I am in an interview, I explicitly draw that line with the interviewer, saying, "I have more questions, but I also have the answers I need to make a decision if you extend an offer, so we can get the rest answered later if we move forward together."
Turn down an interesting offer because of onboarding? Maybe not. Choose between two roughly equivalent companies, because one has a good onboarding process which likely means both investing in growth and caring about documenting things for people who didn't have lots of existing context? Definitely possible.
Like I said, everyone's filter will be different. There are probably valid reasons to ask every question on the list. And also valid reasons to skip every question. We all have different goals and preferences with our careers.
One I am going to start to ask is "Are all developers allowed to have local admin access of their computers?" I've struggled against this in my last 3 positions. This is a dealbreaker for me, and should be for all developers.
I agree. I have never been at a place where developers don't have admin access and seen development be successful in anything they've created. This seems to be a decent indicator of overall culture towards development and removing obstacles to getting things done.
From an infosec professional perspective, this one is always a challenge for security sensitive places.
I agree with you that developers need admin rights on their development machines, but I have witnessed first hand why many companies attempt to take away local admin rights.
When I'm responding to security alerts where developers have downloaded random .dll files from the internet, or some "troubleshooting utility" that is actually malware, it doesn't take long until the local admin conversation comes up.
This is one of those classic "technical solutions for bad human behaviour" scenarios where a small number of idiots ruin it for everyone. If you want local admin as a developer, then we need to be able to trust that you aren't going to do something stupid.
It seems the best way to do this is to issue developers multiple boxes (corporate laptop + dev box only for dev), and or use a good software whitelisting program that tracks elevations & the reasons for them, instead of just blanket giving everyone local admin on their own PC.
qubes-like solutions are great at preventing malicious code from accessing your internal websites, but pretty useless from "code leak" perspective.
If you have downloaded a trojaned "super library" and put it to your build process, it will, by definition, be in the same security domain as your source code.
Unless you audit all file accesses and outgoing internet access, you won't be able to prevent code exfiltration.
Maybe the better question is: how do you prevent your lowest-bidder corporate antivirus marks from marking git-bash as malware, stopping all work for the team for two days?
Developers don’t need admin access, they need ways of getting their jobs done with the best available tools. That’s a damn difficult balance to find!
Or corporate firewall tools that block Android SDK zips as "hacking tools" for daring to include such evocatively named "black hat" files as a "traceview.bat". It's not my fault as a developer that Android Studio needs me to download such a zip quite regularly to keep working on Android stuff.
It's an interesting hygiene problem. Semi-related, I love UAC, and taking UAC seriously. It's the closest thing we have to "good handwashing habits" for admin access. I don't understand how many corporate GPO defaults/admin "standard images" I've seen where if someone has admin access at all they default to UAC off. (I make sure to turn it immediately back on as a matter of instilled corporate habit. One job I had to remember to do that after every restart/full relogin because of GPO overrides. Gross.) Sometimes I wonder if there is some oath I just could sign as a developer that starts with something like "I promise always to at least wash my hands / pay attention to UAC prompts" and "I swear I usually have good reasons to authorize admin access when I reply to a UAC prompt". (And/or you know, use the GPO for what it was meant to do and enforce a minimum UAC, rather than disable it.)
(I also find it peculiar how many Windows IT admins and developers I've met that disable UAC in a corporate environment but then personally use macOS and are so happy that is has SUDO prompts and wish Windows had something similar but somehow don't realize UAC is the exact same thing. It's a strange cognitive dissonance that I don't think I will ever understand. Yes, I've heard all the arguments that Vista's first usages of UAC confused them and they gave up learning it before it settled down and they didn't want to unlearn decades of bad habits from 95 to XP, but I guess I find that a really poor excuse because I was a heavy Vista user by choice, partly specifically for UAC. Washing your hands is great, and very professional, and decades of a habit of not washing your hands isn't an excuse I'd expect anyone reasonable to expect, but especially in a hospital. Anyway, I digress.)
You're absolutely right regarding UAC in Windows environments. Windows 10 has even more awesome security features like credential guard and device guard that a lot of IT departments don't even know exist.
If UAC is disabled by GPO it's probably because of incompetence, apathy, or maybe the IT admins have just been browbeaten into avoiding anything that could inconvenience anyone.
There are also tons of companies with 15 year old Active Directories with tons of kludgy GPO configurations that nobody has looked at for 5+ years.
Developers can have local admin because it's expected that you can trust them. If they betray that thrust, then they lose that privilege, and depending on the nature of their work that might mean they cannot work. Bad for them, but surely it was written in their contract.
It's never actually in a contract, these are always policies since employment is at-will.
But "they cannot work" is implying that person gets fired. I agree that serious breaches of security are a firable offense, because it's plainly a fact that people get fired over them.
Generally, though, developers are fairly hard to replace and anyone who is hard to replace is equivalently hard to fire.
So most security policies have to work out some kind of compromise between those competing interests.
Some of the US might be at will employment, but it's not like that everywhere. In Denmark employment is not at will, but you can only fire someone if there is just cause. This particular scenario is in the security policy, and in my contract it's stated that I will follow that.
> If you want local admin as a developer, then we need to be able to trust that you aren't going to do something stupid.
Issues with trust imply greater problems in the workplace. Unless you're in a high-risk (of hacking) industry, like military, treating adults like children is a huge problem.
Granted, there are plenty of ways around these limitations. By now, all of my "I need admin rights" development is performed within a VM.
As a person whose straddled infosec and development, I always struggled with this. The multiple development machines is probably the best approach, but I've never truly seen it implemented correctly. I would love to not need admin access to my machine, but each time the companies I've worked for try this, it's always a struggle to do anything. This is everything from, "I need to modify/monitor core components of the operating system" to "The development tools came out with an update that needs to be installed." Most of the time, the response I've received was, "Enter a ticket, and we'll get to it." Often management seems to understand, "I'm waiting someone else" as "I'm behind, I'll work the weekend." You're right the downloading random things from the internet is an issue. Sadly I think a lot of this can be solved by the organization spending the money to buy all the needed tools and evaluate the correct open source ones, but there always seem to be budget and time constraints.
I think a lot of this stems from the fact that most of the managers in infosec for companies aren't developers and haven't ever been one. They really have no idea what developers really do. I'm not belittling them. It's just not the career path they took to get where they are. It's difficult to explain to them how frustrating being hindered is, and this causes a lot of good people to just leave an organization like that to find something better.
Multiple machines approach can work if you have an IT person dedicated to a development team, located in the same office, with a low ratio of IT-to-other-staff.
If the process for getting something like IntelliJ IDEA installed on an airgapped machine involves less than an hour with their help, it's workable. If it is not, forget it.
Unfortunately, it takes a lot for management in most companies to see why this is a good idea, and why spending that much on staff ratios is a good idea.
IT security people also have different incentives. If developers got bonuses for uptime while being compliant with all security policy requirements, while security and operations got bonuses based on features reliably delivered, you would have different results.
I have an airgapped network for power plant control system development. A USB drive is used when I need to get data in or out. I know it's not perfect but it protects me from being negligent.
What problem are you solving by making work for devs range from "incredibly hard" to "outright impossible" via taking admin privileges away? Surely you must understand that all things should be in balance, that security isn't the sole goal of an organization but rather an important consideration in the overall structure.
Are you attempting to create a tech "solution" to a hiring problem? You aren't going to succeed.
> use a good software whitelisting program that tracks elevations & the reasons for them, instead of just blanket giving everyone local admin on their own PC
You can propose such a thing. If you're in charge at a company, you might get to implement it. But if you do, know that it's a huge black mark against your company. I've seen how these whitelists work in practice. They're massive wastes of time. They get in the way of actually doing one's job, as creative work can't be constrained and approved in advance by some committee with a ten-business-day turnaround on getting some damn file conversion utility to run.
The golden rule of "security product" culture is this: inconvenience is a feature, not a bug, since friction reminds people that the infosec group exists. When it comes to stuff like this, all the incentives are lined up to just inconvenience people, not protect them. We ought to protect data, not code.
Code is more dangerous than data. Personally, I'd be most worried by someone getting a virus that hacks into other computers and encrypts them and/or wrecks the network. Both can be protected against, first by cold backups and second by resilient / disaster recovery network, but both would also severely affect the company for a few days, so I'd rather avoid them.
even setting up a new box might take one day of a productive person's time... unless, of course, if you standardise the dev setup... again many devs will complain, probably more than if you just remove local admin :D
I worked at one place where instead of giving us root access to our machine, gave us one that was offline (with access to an air-gapped local network and a dedicated IT guy to ensure we had access to tools/IDEs/licenses etc) and another, shittier one that had internet access side by side. This worked fine.
I went somewhere else where we had locked down machines. I am never, ever, ever going back to a place like that. Fuck working in that kind of environment.
I've never seen a clear separation between production environment (machines, network) and the dev. Air gap the two and a lot of problems might go away (not all, of course, but the most common ones).
I / we are in an interesting position in that regard, in that there is a policy installed on our laptops that gives us admin access on the one hand, BUT forces encryption and allows our employer to trigger a remote lock / wipe in case of theft. I think that's a good middle ground myself, I mean what if I get murdered and robbed abroad? I don't expect it but it's a possible scenario that might put our customers' code at risk.
I don't think I'm alone in having to switch between multiple machine configs from day to day. The only way I could avoid using VMs would be to physically swap hard drives, at which point why not just work in VMs...
As long as one has admin access in the VM of course!
Important followup: "Am I allowed local unconstrained root without a usually-performance-killing daemon interfering with my work?"
At a few places, I experimented with running Windows. Every time, the Windows machine came with Bit9 or some other performance-killing compatibility-breaking security "solution" that made the system unusable. Windows is a great operating system. What IT departments do to Windows turns it into a nightmare.
These same places all had a much lighter touch on Linux VMs, desktops, and laptops, so clearly the invasive "security product" mindset was just contained to the Windows (and in one instance, macOS) groups.
> Windows is a great operating system. What IT departments do to Windows turns it into a nightmare.
That's a great bumper sticker.
There are so many cases you find of people's Windows complaints where the questions are "Why does Windows even allow GPO to hurt users that badly?" and "Why does your IT staff hate you so much personally that they configured Windows into that particular contortion?"
The Unix world has decades of tales of the "sysadmin from hell" / BOFH, of course, but something about Windows administration just seems to elevate to almost universal "art form" across every company, but at the same time has managed to make it "business as usual" rule rather than the to-be-irked-by exception. On no other operating system would that level of IT micromanagement and terrible "security products" be accepted, and on just about no other platform would people just as easily assume it to be OS "bugs" or "inabilities" rather than the forced masochism of some local BOFH.
> "Why does Windows even allow GPO to hurt users that badly?" and "Why does your IT staff hate you so much personally that they configured Windows into that particular contortion?"
Typically its because the GPO configuration has 15 years of kludge and your IT department is under resourced and doesn't have the ability to spend 6 months sifting through and testing all of it.
In Windows environments group policy is often one of the biggest piles of technical debt.
I think that is certainly a part of it, but I think there is a part of it that is much, much worse than that. Every time Microsoft reduces the number of user-hostile GPOs, there are certain Fortune 500 companies that complain (presumably in a lot of cash). Almost every GPO probably has at least one BDSM fetishist of IT Admin with too much corporate budget cash and not enough sense.
But a big problem is how cult-like certain GPO setups have become. Asking my IT Department casually, 90% of the worst GPO settings we enforce at my current job are "mandated" in the agreements and contracts with a certain, supposedly prophetic (but unarguably profiteer) vendor of over-priced databases and accounting software "to keep their software working as intended". (Which may be quite accurate if their software is truly intended for the slow torture they provide from a user's perspective.)
A previous company I worked for had installed some company wide security software. It basically installed a root kit that scanned every executable, adding 250ms to boot time for any app. The problem manifested when shell scripts that used to take seconds started taking minutes or hours.
When this started happening, I thought that I had installed some malware. In the process of debugging the problem, I ended up finding & disabling the root kit through trial and error. When my machine started working properly again, I came to understand I had disabled the corporate security "malware". I reported the problem to corporate just as others started to report having the same slowdown error. They told me the vendor of the software was impressed I had been able to find it, let alone disable it. I believe their words were "you shouldn't have been able to do that".
I didn't get into any trouble. By reporting the problem, I actually helped kickstart the removal of that software from anyone's laptop where shell access was required. The vendor never could fix the performance problem, and eventually our company resorted to trusting the developers again.
Are all developers allowed to have local admin access of their computers?
These are the same devs who install random things with curl|sudo bash right? Or write code that can only run as root in production?
No thanks. These days of virtualenvs and similar, only incompetent devs insist on being root too. In fact, this will make an excellent interview question, thanks!
When you're not allowed to install applications and tools to your own, that gets in the way of productivity and happiness at work.
I've worked at companies where even being able to install something simple like Notepad++ or VSCode was turned into a major chore or made impossible thanks to the locked down environment.
Locking down trivially important system preferences like your desktop background is another example of just plain annoying management that I've witnessed.
Don't forget corporate network content blocking, and I don't mean the obviously not safe for work content, but companies acting as the productivity police e.g. blocking Twitter and YouTube just because they don't trust you enough to not slack off at work, and furthermore not trusting your supervisor to be competent enough to determine whether or not you've been productive enough lately.
As both developer and a systems administrator, I am constantly on both sides of the fence. I have seen developers who cannot even maintain their machines and download any random thing to streamline their job to the detriment of security. Yet, I have seen other organizations where it takes months to get something like VSCode installed (try keeping that up-to-date on an air-gapped machine, that isn't connected to the internet... or ... Node.js or... full Visual Studio...)
Ah yes - gotta love the HN pedantry - you are of course technically correct, however - a library used by Notepad++ was compromised for a period of time.
> a library used by Notepad++ was compromised for a period of time
Nothing at the referenced URL corroborates how you are representing the referenced URL.
According to the URL, the CIA was replacing one of Notepad++'s components w/ another in order to run code on the user's system and stay hidden. Nothing in that links indicates that that replacement is done through any breach in security in Notepad++ itself, and AFAICT, they're using it merely as a good hiding place. The Notepad++ announcement fixes no particular bugs, but merely signs the code.
> Ah yes - gotta love the HN pedantry - you are of course technically correct, however - a library used by Notepad++ was compromised for a period of time.
No, it wasn't either. The security "issue" was that a shared library loaded by Notepad++ could be replaced with a compromised one. At no point did either Notepad++ or the library authors distribute a compromised version of that library.
Being able to replace shared libraries is not a security issue, it's the number one (or number two, depending on who you ask) reason for having shared libraries in the first place. It's like saying that if I compiled a custom version of glibc and installed it on a computer, the entirety of the GNU ecosystem was compromised.
That is a wide brush you are using. Once you start needing to prod the operating system internals or do any sort of devops work it is prudent to have root access.
Actually it wasn't supposed to be about a startup only. Established companies also grow through external funding, whether it's a loan, partnership, selling shares, or something else. Each of those may change how the company works and whether you're comfortable working that way.
For many years I gave a talk titled "Questions Engineers Should Ask"
This list is missing the two most important [busines] questions:
1. How do you make money?
If you can't understand, or the interview can't explain, then I'd run away. This can also lead to interesting questions about risks, competitors, etc.
2. What's preventing you from making more money?
The answer that you want to hear is engineeringeffort. If not, you're (at best) a wallflower at the party. Don't be the chump that's at Goldman Sachs acting as a code monkey for the traders. Don't be writing code at a company (like Enron) which has its success based on digging holes in the ground.
I'd love to include those questions with links to the talk if you can find it!
(Like the siblings comment, I may disagree with "The answer that you want to hear is engineering effort", but the questions are definitely valid in some situations)
That's highly disrespectful to software engineers working outside of software companies. There are many of them and they are not necessarily less smart than others.
Working in the profit center of a company is often enviable, but let's not forget that cost centers in large companies can also offer benefits in things like work/life balance.
I don't think the GP intended to call engineers at those kinds of companies lesser. I think the point that was made was that working at companies where the company makes more revenue by having better software is a better company to work for. If your role is a cost you're treated (explicitly or implicitly) as such. It's a lot easier to show your value to a company by being part of the revenue side of the equation. Reducing costs is great but there is a bias towards investing to generate revenue vs investing to reduce cost.
I've been at companies that were "engineering-driven" that were total disorganized messes and totally immature workplaces.
I've also worked somewhere at a "lesser" company where I was firmly on the cost-center side of things, but my work was seen as absolutely business-critical, I was treated well, I survived all reorgs and department layoffs and had my salary tripled from the time I started.
Working in unsexy companies is a tremendous opportunity because if you're good at what you do, people literally think you work miracles.
This. I've worked for an ISP as a software engineer for almost 3 years and even though the company doesn't directly make money from what we do, we are quite respected for the value that we provide.
Also that last statement hits way too close to home.
--companies where the company makes more revenue by having better software.
You can get vibe of a company by asking if IT is seen as a cost center. If software is a competitive advantage you know that it's green pastures for your and yours. But places where culture holds back engineering, like being slow on the uptake of GIT or CI/CD which is often talked about online, these are places to be wary of. Those latter companies are either going to have growing pains or will die out as digitization starts to take them on.
I think this may be a better way to phrase what I was thinking. It doesn't have to be directly related to revenue. The revenue relation just makes it easier to be counted as core to the business model. I think it's important to say business model too. IT is core to essentially every business now, but when IT is core to the how the company fundamentally positions itself in a market it really changes things.
Though in the context of this thread, I don't know a good question to ask in an interview to tease out that information when it's not already clear. If you simply ask "is IT/engineering considered to be vital to the business model or core to company success", everyone will answer yes regardless of how the IT/engineering is actually viewed.
A version of this line of questioning that in hindsight I sort of wished I had asked interviewing at one previous employer is something along the lines of "How much do you think your executives believe that you do in software they could go back to doing entirely on paper if they had to?" I don't know the precise wording yet, and I know it's not a universally necessary question for every "all of IT is a cost center" firm. IT can be a cost center, fine. Software development can be rolled up under IT for a number of reasons, sure. But IT shouldn't be seen as an "optional" cost center, "software" as some accidental by-product of a business dealing with a lot of "paper" when the company scaled to millions in annual revenue on the back of software-based productivity. There's entire industries, such as Insurance, that have some weird delusion that if they lost all their software overnight they'd just go back to do everything on paper and imagine they'd have zero re-scaling nightmares, brownouts, burnouts, or profit loss. It's so weirdly out of touch with reality, and I think a huge part of the disconnect (including the pay gap) between the ~post-70s C-Suite and the day-to-day operations of the majority of modern corporations.
I'm not even sure had I figured out exactly what that question should be if it would have helped that younger version of myself in the place that I was at, but it's still a useful lens moving forward if I have to stay in the "dark matter" parts of software development in the parts of corporate America that don't consider themselves software development companies.
Why does it matter? You negotiate your salary and in a couple of years if you find your salary not matching with your market rates you find another job. Salary compression is real regardless. A job is like dating not a marriage.
Fair point. There is a better way to phrase things if there was no intent. And is evident in this thread, intent doesn't change impact. Having colleagues, that I respect, who work in similar roles I perhaps should have considered this better.
Seems very rare that it will be the case that engineering effort is what’s stopping a company from making more money ... almost all companies will have sales pipeline or finding pmf as the answer to that. (If they know the answer.) Trading firms actually seem like one place where there is often a direction connection between code = money.
I often see your response to #2 brought up, and I would generally agree with it.
With that being said, in my experience of working at companies that actively sell software, whether it's as a product or a service, you are still incredibly likely to be as much of a wallflower as you are at a non-tech company. Your perception of freedom is higher, but ultimately your time and budget is limited by whoever manages you.
I'd be interested in the slides to see if your questions dig into one of the most common issues I see at tech-centric companies - micromanagement? Is it a thing - and if you say no, would a random selection of three of your developers tell me the same thing?
Financial markets companies are now engineering and quant driven. Machines place 80% of orders in US equities exchanges, not humans. The company you mention just announced a $100M project to rewrite its core equities trading platform to optimize latencies at scale across markets. Great engineering culture too. Meritocratic, respectful, and you won't find people there going around referring to developers in other industries with the disrespect you do, for example.
In response to folks feeling that I'm being disrespectful of developers in other fields: you're right. And I apologize.
By way of explanation, this phrasing came out the slide deck itself, which was used as part of a recruiting effort at colleges for new hires. In many cases we were competing with offers from finance firms and felt the need to distinguish ourselves to compensate for their salaries
Having said that, I stand by much of my statement: assuming you have a choice between those two types of roles, you'll end up in a better place where your job is a path to more revenue rather than a cost to be minimized.
I think, the "source control question" comes from the Joel Test which is 19 years old. Almost every company uses source control now so it doesn't make as much sense.
A better question would be "why do you use [the source control they use]". The answer, if coming from a knowing person, may tell you quite a lot about how the technical decisions are taken in the company.
There was definitely a time when that was an important question, because the answer could be "CVS", "nothing" or even "what is that?". Nowadays the answer is practically always "git".
Indeed. But why git? I worked for 3 companies that adopted git for completely different reasons.
The first was open sourcing parts of their code so they just started using GitHub. Makes sense.
The second used to work with Subversion, and they stayed with it. The process was built around having one and only one server with all the CI, and the hooks, and the locks. Git was used with the SVN gate purely for developers' convenience. Makes sense.
The third one was on TFS, and they couldn't quite align their process with it. So they thought "our process is a mess so let's do git". This is a red flag. If you can't get your process straight with relatively simple tool, some more sophisticated tool will (and it did) only make it worse.
Honestly? Because it's become accepted as the industry standard. People who need to make the decision without having knowledge about the topic just go with whatever everybody else is doing. In the past, that used to be whatever IBM was offering, then whatever Microsoft was offering. In that respect, git is a lot better. It's flexible enough to adapt to different kinds of workflows, at least.
This is also role specific. Almost every developer is using source control. But it is not yet standard that operations and infrastructure teams are using it.
I assume the author meant that since those teams will be speaking a lot to people as part of their daily work they add a lot of ambient noise to a workplace. That could matter to some people in open office plans or cube farms where you can't separate yourself from that noise.
I am now a Mr Manager Person, so I have a different but related set of questions:
1. What is the demographic breakdown of the engineering team? And, what does the company affirmatively do to foster diversity?
2. What resources do the founders have available — investors, board, mentors, for instance — to help them as the company grows?
3. What is the near term vision for the company? 1yr/5yr?
4. What resources are available for professional development for managers/directors?
5. At $CURRENT_COMPANY, the company is serious about reviews upwards — as a manager, my direct reports are consulted in a formal process at review time. Is there a similar process at $POTENTIAL_EMPLOYER?
Demographic diversity, diversity of backgrounds, diversity of experience. Monocultures are actively destructive of successful outcomes, and lead to miserable working environments. The question is asked open-ended in that fashion because I want to discover what a potential employer thinks is important.
I'm lucky though. I see recurring conversations about it on /r/devops and I'm aware not everyone is in the same situation. Some even wear it as a badge of honour that they improve reliability so they shouldn't be paid for things breaking. (Which I completely disagree with) But working after hours is working after hours - if it doesn't feel right, maybe you should have a conversation about it.
When I have seen this done, the amount is often inconsequential in relation to the amount of effort to be on-call. I don't love this incentive structure because the cost of being on-call is somewhat fixed up front. Needing to avoid being out of page coverage / availability and having a computer available is a high cost paid by the employee regardless of actual page-out workload. Paying for standby certainly helps, but I haven't seen standby pay match well with the perceived effort. Maybe some companies do this right, but higher negotiated upfront pay has appeared more effective in my experience.
Where devops works is that there's shared call-out responsibility when things go wrong at 2am. It won't happen again because they'll take the time to fix things.
If management don't also share in the responsibility, it -might- will happen again because they won't allocate the time (and-a-half) to fix things.
In the UK at a large company, I took TOIL for out of hours working at OT rates 1.25 up to 8pm 1.5 up to midnight and Saturday and I think it was 2x plus a day on Sunday.
Google in the US does this. I was on call for my team about once a month and at the end of the year, the bonus for merely being available was quite large. (I think it was something like $1600 a week, but I could be misremembering.)
I believe that is for SRE teams. SRE teams are much more reasonable about on-call, having enough staff to have the on-call person on-call during their workday, not at 3am their time.
SWE teams often don't have the global coverage that entails, so they just pay you extra to be close to your phone.
A problem that I've had is that every company says that they value code quality, emphasize developer growth, value developer's technical feedback, etc. even if they don't in practice. I've debated taking a page from old school behavioral interviewing and asking questions like:
Tell me about a time that you made a decision to improve code quality or architecture at the expense of a deadline.
Tell me about a time that you invested resources into an engineer's technical development even though there would be no immediate, short term benefit to the company.
Tell me about a time that you pushed back on a decision from business or design because one of your engineers said that it was the wrong technical decision.
Indeed. The labor market is quite illiquid from the point of the laborer, with a lot of ugly sunk costs and worse opportunity costs. There's not enough safety nets if you buy the wine-and-dine sales pitch but find the reality is a lot more of a lemon than you were sold. (There are no lemon laws for the labor market, sigh.)
It's happened to me twice now. I'm loving the ideas in this thread about asking the, "tell me about a time when ..." style questions because I've always delved deep into the culture and values philosophy, and have found that so far each company was describing their aspirational ideal, which did not reflect practice at all.
As an engineering manager I try to answer truthfully to these probing questions because (1) If someone quits after being hired under false pretenses it's more work for me, (2) I'm relatively new to the position so naive/earnest enough to speak the truth (I was a developer too!)
This seems like such common sense to me that I'm surprised it isn't more common. At this point I think most managers are just too disconnected and don't realize how it really feels. I guess most people will also put up with a lot of pain before they go back out to the job market. I know I do.
I guess this should be motivation to me to get back to work on one of my crappy ideas that could turn into a startup ;-)
This only works if you're interviewing with decision makers. At a larger organization, I don't think the person you're interviewing with would have any capacity to answer these (which could be a red flag for you, but also a very limiting one).
M doesn’t really do that for anyone but new grad hires. I’m not sure either A does that either (the A closest to M doesn’t, I know from personal experience). F and G definitely do, they are notorious for it.
I'm not entirely sure why, but here on HN especially I've seen a lot of the use of FANG with one A [Apple] used to mean Bay Area super-powers, as opposed to GAFAM for general tech majors, because some believe the Bay Area to matter more than the rest of the industry and Seattle-focused Amazon and Microsoft somehow "outsiders"/"foreigners" to the Bay Area.
It's also fascinating to me from an anthropological/sociological view point because Microsoft has had some sort of Bay Area campus (almost continuously) for longer than several other members of GAFAM have even existed (with PowerPoint headquartered there from its acquihire in the 1980s until a reorg shuffle in the mid-90s and HoTMaiL/Hotmail/Live Mail/Outlook.com and other "web properties" carrying the torch up until a lot of recent acquihires expanded that campus again to more Office-relevant tools beyond just "web stuff").
I didn't invent the FAANG acronym myself, but, having a lot of [ex]colleagues in those companies I can see why people want to work for the interesting and somewhat innovative "FAANGs" and don't put Microsoft (or IBM, Dell, Oracle) in the list.
What if as a condition to accept a job offer you request a meeting with the CEO? Would the company refuse or do they value you enough to make it happen?
I have never taken a job without talking to a top executive. You get a view of the company bigger than your team, you get to ask those business questions your manager may not know, and you have a head start on making good connections with upper management.
Who's the CEO? At my last company (fintech with customers from Google to Exxon) CEO would absolutely meet you even if just for a second if you asked, but I doubt CEO at Google or Exxon would.
You can cross off any company over 1000 people from your list, if you had that as a requirement. My company is over 80,000 people, if our CEO met with each potential employee, he would never sleep.
And also, I have to say, it's a bit arrogant to think that you deserve the attention of top executives. You can't expect them to prioritize your interview over all of the other activities their company does.
It's also a bit arrogent for a top executive to think a request for meeting/conversing with a top executive from a potential new employee in a subordinate role is a demonstration of arrogence. I don't suggest making it an absolute condition depending on the organization's size but for a job seeker wanting to evaluate the potential company just the reaction/responce to this question may serve as a useful litmus test
The last company I worked for was hiring around 20-25 people a week for a couple years. Do you honestly think the CEO would agree if a random potential new hire asked to talk to him?
That question reveals a very, very specific set of assumptions (applying to very small companies); which may be relevant to the most active HN audience, but by strict numbers, is not applicable to majority of actual employees.
I've worked in some companies under 300 people size and the CEOs had no problems meeting you to discuss. And talking to a senior VP was almost standard part of interview for a experienced role (but maybe less so for junior roles.)
I just feel that most interviewers when pressed on these are just going to lie unless the company truly does it, which will make it hard to tell whose telling the truth. I guess that's what the whole interview is, detect who is telling the truth about themselves. I think more detail on these questions, and to press on follow ups for specific examples.
I think the nice thing about the "tell me about a time when..."-style questions is that it makes it harder to lie, or at least harder top lie believably. None of the interviewers will bat an eyelid answering "do you value developer growth" with a one-word lie "yes," but I think most interviewers would feel uncomfortable making up a story whole-cloth, and that would show.
The risk, of course, is that you'll seem rude and high-handed asking interviewer-style questions yourself. If you have the upper hand (the job market is hot and they need you more than you need them), that's fine, otherwise not so good.
I love the table-turning style of these questions; but the fact is, they can always answer "No, we can't think of any such examples. Are you going to walk away from the job?"
That is to say, hiring is usually a buyer's market.
Maybe I’m weird, but I wouldn’t find a question like that rude. I’d think the interviewee is very thoughtful, and is pretty darn interested in our company if they took the time to think that up. (even if it’s a canned question)
It seems to me that offense at such questions being asked back is itself an indication of a misunderstanding of the meaning of the word "interview". The "inter-" part of the word denotes mutuality or reciprocity[1], that the questions and answers go both ways, so both parties may learn more about each other. An interview is not supposed to be solely an inquisition wherein the potential employer evaluates the applicants worthiness of the privilege of employment. It's supposed to be an exchange wherein both evaluate if this is a mutually beneficial business deal. And if a company considers it rude for you to want it to be anything other than a one-way inquisition of you, I think that's an indicator that management culture at that company will make for a work environment that's more stressful and less fulfilling than the rose-tinted one they present in the interview.
An aside, I say the above now, but damn, I wish I'd had understood it 10 years ago.
I agree. It took me a long time to learn that I'm interviewing them as much as the other way around. I learned a lot watching football (soccer) and the behavior of players with respect to their contracts. They are paid up front for services they are expected to provide. Sometimes their salary is low but they agree to high performance bonus. In the past my attitude was that I just want a job that pays the most money. I was taught in school how to interview. But, I learned that there is more to it.
Asking these questions a lot in interviews to candidates most people lie by either talking in generalities, or back off and are honest like "were going through that now" both give you an answer. I have not asked this directly in an interview but my normal tactic is to have lunch with the engineers and no manager which gets you lots of examples.
We often (twice in the past 3-4 months) sent desirable prospective hires for coffee with a current employee to allay some of their fears. Both accepted jobs shortly after this, and likey would not have if we didn't give them relatively "unfettered" access to the real deal.
Sometimes sending the interviewee to lunch with potential co-workers is an optional part of the interview. I've been on many such lunches (mostly as a potential co-worker, only once as an interviewee)
Obviously, it's up to management if they want this to be a part of the interview.
definitely is but I've found that if the manager wants the hire (esp post the company deciding to move forward with an offer), then you have leverage and this is a very sane ask.
I came here to say basically this. I've worked at enough companies to know that their ideas of what their values are may not be accurate.
Instead of asking about values, ask about behavior. No one is going to say no to "Do you value code quality?" Aking what they've done (and sacrificed) to support code quality will give you a better idea of what their relative values are.
Asking about their tech ladder will get you an HR answer. Asking "Who was the last person promoted to X? When?" will give you a better answer. And if they can't remember the last time, that's an answer in itself.
I listened to a podcast recently [1] that talked about "embodied knowledge", which is basically the idea that what we know is often very different from what we think we know.
The idea being that you will learn much more about someone / something if you ask questions that are anchored to a time and place rather than generic "unembodied" questions.
So the first question you list "Do you value code quality?"
is an "unembodied question" and there is no hook for the person to dig into reality and give you an honest answer.
The second, "Who was the last person promoted?" is "embodied" in that it is anchored in time and place. And because of that, a person is going to use their memory, rather than their rehearsed "value system" answers.
Anyway, it's basically exactly what you said, but I just wanted to recommend that I thought the podcast was a worthwhile listen.
Without having listened to the podcast, another way to frame this is using the concept of yes/no questions, who/when/what/why/how questions, and open-ended questions.
Y/N questions are not very revealing and are likely to lead to dead-ends in the conversation.
WWWWH questions reveal a specific bit of information, but can also lead to dead-ends.
Open-ended questions ("Tell me about...", "What do you think of...", etc) will foster good conversations and uncover new threads to pull. In my experience, this is by far the best way to interact with other people, whether they are interviewing you or not.
Coming up with good/relevant questions on the spot is a skill that can be difficult to master, but is extremely valuable.
To expand on this, people will commonly give you unintentional "hooks" for where you can go to increase the depth of the conversation.
For example, people use common words as short hand for many things ("Work was stressful", "The kids are being a pain", "We had a really nice weekend"), and a mistake people run into when talking with others is that they assume the person they are talking with meant they same thing they themselves would have if they had used that phrase. This leads to lots of people "listening but not understanding".
So basically, offhand comments and common phrases are a great place to get a person to dig in deeper into their feelings on a topic. Usually they indicate something that is on the person's mind but that they probably haven't worked through enough to put into words. That means you will get a much more raw and unfiltered response from them.
Also it's always good to remember that people love to talk about themselves, even if they say they don't.
Hanging out with permaculture people (going on 6 years now) gives me an idea of what it must be like to hang out with famous artists. How can someone be so right and so crazy at the same time?
"The inflammation in my body"? Sounds like a dopamine response in someone whose sympathetic nervous system is strung tighter than a kettle drum.
The charitable way to put it is that the stated values of most companies are aspirational, not descriptive.
But it's hard in some cases not to feel lied to when you see the gap. At least in dating when this happens you can get out early. You don't get the same trial period with work arrangements.
I've learned this the hard way twice now. I hope people reading this pay very close attention to your comment.
In fact one of the hardest lessons I've learned is that the companies who are the most vocal/passionate about their "values" are often the ones that are the farthest from them.
I like to ask about recent promotions and reasons, or conversely, asking who's been promoted based on the stated values in response to the direct question. Basically: how do you track and credit for this?
Do your homework before the interview and check LinkedIn for promotions. Then ask them about that specifically... why have only x People in the team been promoted in the past few years? Why was Jane Soe promoted to y role?
Bonus is if you reach out to former employees on LinkedIn and ask what it’s like to work there.
(I got answers like we have certification amount re-reimbursement policy(turns out for only pre-approved/ business significant courses). We have internal Community Of Practice sessions, etc.)
In my own experience I have found that small (usually before market fit and series A) Bay Area tech startups tend to be fairly earnest about what the programming role would be like. I've had no shortage of interviews where I was told plainly that experimenting and shipping quickly is prioritized over having ideal code quality and architecture. Granted, I make sure to ask these questions of the most senior non-founder programmer at the company.
One question I like to ask is "Tell me about the worst day (work-wise) you've had in the last six months." Most of the answers I've had gotten generally have to do with escalations and I find that answers are quite honest and unpracticed. I think the way a team/company handles an unusual high-stress situation is in many ways telling of the team/company dynamic in general. And as a bonus, there's usually a good anecdote about a buried body or two in their codebase, process, you name it.
"Firing the responsible" may be an overly-strong comment -- putting pressure on the line rather than improving line management is the upshot of what I'm getting at.
Though truly boring can be a good sign if it's the result of good planning, drilling, practices, and rewarding competence. If it's from complacency, failure to recognise problems, or the ability to push fault or failure off on others (clients, customers, vendors, suppliers, other departments), not so much.
The good sign then is understanding why and how they got to boring.
I'd be hard-pressed to name any notably bad days at work in the last 6 months, and it's definitely not because every day is stressful. I'm not even sure why you think that's unusual unless you've had jobs exclusively in very unpleasant workplaces.
(The latter especially for a first instance, though if you've got repeat instances, I'd look first to management, then to staff, for cause.)
Another bad sign is if the cause for the stress is internal, and a pass sign is if it's either management or a major (or the only) client.
If you cannot find ways to eliminate internal causes of stress, or buffer those created by the commercial environment in which you exist, it's going to be somewhere on the continuum between toxic and fatal to me.
I actually don't mind it. I'm a noob, it's a small shop, and i'm not sure I'd like a pure "agile" environment anyway... or would want to risk it going wrong.
My manager does this. He is incredibly wary of adding process so he tries to automate it and it never gets implemented. For example, every quarter he tries to come up with some automated system for assigning code checks. It usually has some jank that causes it to go unused and we fall back on just asking one another as needed until he tries again.
hahaha I love it because its true, but you do assume that your manager reads the answers right?
One thing I didn't notice for a few quarters was that the slack bot was not automatically configured to show the other people in the standup what was written. This is very important to the standup concept so you can discuss and help others on a task if it seems relevant, and everyone is aware.
We're a small shop with a lot of "heads down working on stuff" going on. We actually usually know what everyone is doing to some extent. I'm not sure my manager is seriously concerned as much as he wants words to say when someone else asks ;)
I did work with one team that managed to make a compromise around status reports.
If the team could commit to updating their stories at the end of the day, then we could cut 15 minutes out of standup by leaving out what we did and just talking about blockers and what we learned.
There's supposed to be some osmosis around hearing what everyone else is working on. But practically if you split into separate scrums, you're only hearing about what people you're already collaborating with are working on and odds are you already know what they're going to say.
If the team is big enough you can't have a combined standup than most of the value of these conversations is already lost. You have to use the tools to telegraph your actions anyway, so why chat about it every morning? Discuss time savers and time wasters instead.
I can't recall the last interview when I was allowed enough time to dig into these sorts of questions. I'm gonna have to sort this out soon, and it's probably going to involve practicing my delivery at the risk of tanking the interview.
It's like they're selecting for people who make major decisions based on little or no information. I'm sure that will end well...
I'm slightly bothered by the "reverse-interview" concept. To me interviews should be bidirectional you are there to find out about the company as much as they are there to find out about you. It should be treated as the starting phases of a negotiation where you gain information about the value of the asset you are going to acquire.
I'm certainly happy that viraptor shared this valuable resource, don't get me wrong, every little step in the right direction is a good thing. I simply would have liked it to have a better name in order to convey a different message.
It's very much a tongue in the cheek name. I completely agree with the bidirectional conversation idea, but wanted to concentrate on the part I found lacking.
Interviews already are bidirectional, even if the interviewer thinks they’re not. If you’re so keen for the job that you don’t ask any questions, then you look a) desperate and b) like you’re trying to bs your way through the interview, which isn’t great. My only objection to these questions is a some of them are essentially negotiating the terms of employment, which isn’t appropriate for most interviews.
How much annual / personal / sick / parental / unpaid leave is available?
This is a great question; when I have searched for jobs, it's one of the more important benefits to me.
Sadly, however, I've found most places have gone to "PTO" -- combining time off for illness and vacation into one bank -- how have others successfully negotiated an appropriate level of time off?
(Context: For a very long time, I worked for companies where sick time was essentially a non-issue; it was essentially unlimited, with appropriate rules around requiring a doctor's explanation or having to switch to short-term disability after a protracted period, but the occasional day or two to recover from a cold and not spread virus to the whole company without having to choose between that and visiting family.)
I just tell them how much time off I'll need during salary negotiations. I know you offer two weeks PTO and 3 weeks after 5 year, 4 weeks after 10 years etc. But I'm not restarting my PTO every time I switch companies. So I will come in with PTO equal to my experience at a minimum.
Has this approach actually worked for you? In all places I have worked, PTO is a non-negotiable, other than "I already have this vacation/trip lined up for two months from now and require the time off," which is okayed even if it's outside of their normal new-hire policy.
PTO is nothing special. It’s just another benefit you can place a monetary amount on. If they won’t give you more than two weeks paid time off and they will let you take unpaid time off, add the amount that week of unpaid time off is worth to your required salary - of course take into account that PTO is a non taxed benefit.
For nice round numbers. Say you’re making $140K (above the social security maximum to make the calculations slightly simpler).
A 5% match is $7000. But since it is an untaxed employee benefit and if I think I can already max out my 401K plan, I would have to take into account the 24% Federal 6% state (GA), and 1.4% Medicare tax - 31.4%
That means I would need to negotiate at least 7000/.686 = $10,204 extra.
Employer contributions are tax deferred, not untaxed. Assuming you don't trigger penalties, you'll pay ordinary income on that down the line. I wouldn't expect to retire into a 0% tax bracket, especially if you're maxing the employee contribution.
You can put the employee contribution into Roth, but the employer contribution is almost certainly going into traditional; I don't believe there is a provision for employer match into Roth.
Unlike the employee's contribution, however, the employer's contribution is placed into a traditional 401(k) plan, and it is taxable upon withdrawal. The employee's into a Roth 401(k). Therefore, many employers have found the additional administrative demands of offering the Roth 401(k) outweigh the benefits to their employees and do not often offer one. This is the reason for the perception, or misconception, that employers cannot provide a match to Roth 401(k) employee contributions, when in reality, they are simply not providing the option for the plan at all due to the administrative hassle.
Capital gains are taxed as ordinary income when withdrawn from the 401k. The timing is better (since you're not taxed on sale, you can rebalance at will), but the rates are worse than a taxable account.
I'm just saying, if you count employer 401k match in your all-in comp figure, it doesn't make sense to treat it as untaxed; it will be taxed, the rate might be less, but it might not be that much less.
yeah sure but depending on the company it's easier to take PTO than UPTO. People expect you to take all your PTO generally. That's not always true if it's unpaid.
If you make 140400 a year and are getting 2 weeks of vacation. You are making $2700 a week. If you took another week off of unpaid time off. You will lose $2700 for that year.
If they gave you an extra week of vacation. Your taxes wouldn’t change. If instead they gave you an extra $2700 in salary and you took a week off of unpaid time off, you have to pay 24% in Federal taxes on that income + 1.45% in Medicare (you are already over the social security maximum).
You would need to make $3621 more just to start breaking even ($2700/(1 - .24 - .0145)). But even then you are paying taxes on the extra 3621-2700. I’m sure there is some formula to break even but I would just ask for an extra $4000 and call it a day.
What you're saying is that your net income after taxes is less than your gross income. Of course that is true, and the exact numbers will vary for every individual. Naturally you should always take the difference between gross and net into account in any financial decisions.
That wasn't what I was addressing, I was only commenting on this: "PTO is a non taxed benefit."
Someone could misinterpret that and think "I pay taxes on my salary, but PTO is not taxed."
But the money you're paid for PTO is salary. If you have accrued PTO and leave a company, when you get your final check you will find that the PTO payout is taxed as ordinary income, just like all of your other paychecks. And while you are at a company, the income you receive from any PTO days is also taxed as ordinary income, no different from a day that you actually work.
I agree it is terrible to reset the seniority clock after 10 years! I found it very difficult to negotiate this as well, but if you're hiring a senior position do you expect applicants to be happy about losing 1-2 weeks vacation time??
It's worked for me by treating this as a given (given that I will be working for them, I will be at least maintaining the PTO that I had at my previous company) and by offering alternatives for HR. Sometimes companies have personal time that is separate from PTO. You often won't get this time paid out to you if you quit and still have hours but since I plan on using it all every year that's not a big problem. Some companies can give you extra floating holidays or other types of time off to make up the difference.
You usually only have to resort to that if the HR system is inflexible and someone is making a big deal about it. A blanket statement that we don't do that, can't do that and won't think about doing that is usually a bad sign.
You generally have to offer the same benefits to everyone in a company (at least in MA). The easiest way to do that is to offer "PTO" as a bucket to everyone. The new "cool" way to do it is to have "unlimited PTO" ... which I have pretty mixed feelings about.
Unlimited PTO means you're at the mercy of the company, pretty much. I am lucky to work for a company with unlimited PTO where most people take 4-6 weeks off per year. Other places are far less lucky.
I work for a place that has "unlimited PTO" and must say I'm not a fan. You have employees like me who fear taking off too much getting yelled at by HR to take more time off (but how much more??). And on the flipside the higher ups make snide remarks about people who take 20+ days off. From my understanding unlimited is code for in the high teens.
Standard here in Spain is 30 days off (including weekends and bank holidays).
Most companies just offer 22 working days. I worked for one that offered 24.
I don't work for a company with an unlimited time off policy, but I've read (and agree) that the best middle ground is unlimited PTO with an enforced minimum.
> Is there a support / marketing / other call-heavy team close to my new team?
This is so important.
I can probably live with most open plan set ups, sure there will be annoying times, but if there is a call-heavy team nearby, forget it.
I refuse to wear noise cancelling headphones all day long.
FWIW, interviewers will blatantly lie.
I asked at an interview about equipment quality and was told that they'd not heard any complaints.
This was 100% bullshit. I was given an ancient laptop, which seemed to re-ignite complaints about the quality of the equipment and were taken up with, none other than my interviewer.
> I refuse to wear noise cancelling headphones all day long.
May I ask why? Even when I work at home alone, and there are no stray noises at all, I'll still wear my headphones when I want to really focus. Years of mental conditioning has led me to a place where it's much easier to deeply focus when I'm wearing headphones listening to white noise.
Not the op, but also wouldn't wear them. Weird ear shape means earbuds start hurting after a while, while the over-ear solutions make me sweaty/uncomfortable.
Noise cancelling, at least the Bose version I've experienced, gives a feeling of pressure in the ears. I've read that others experience this, though obviously not everyone. I can only handle it for short amounts of time before I'm tearing them off my head.
Some folks have problems with their ears. Noise canceling headphones feel like they are exerting constant pressure which kills focus and concentration. Head in vice feeling is not fun.
It's uncomfortable for me as I have relatively big and slightly weirdly shaped ears. This in effect means that two hours is around the maximum I can wear headphones for.
If I take more frequent breaks I can stretch it to about 3 hours.
If we're losing the AC war, then it's normally the heat that does it.
Yeah, the correct phrasing of that question is "Show me the place where I'll be working." They should be able to lead you down the corridor and show you potential future co-workers at work.
I think asking something like “when people don’t work out and end up leaving the company what are some of the typical causes of that mismatch?” wouldn’t raise a red flag.
I always ask about staff turnover numbers, especially in ratio to new hires. If they're not prepared to discuss or don't know the answer then it's not important to them.
I remember in my first job interview I asked "have you ever hired someone who didn't work out?"
I got a genuine and thoughtful answer. It helped me to establish quite clearly what value systems wouldn't fly in the company which guided me on how to behave.
It worked out well.
Essentially you're trying to figure out "if you hire me and what is true about me then things won't work out?". You want to know if you have those qualities. If you do, you shouldn't accept an offer if you get one. It's a reasonable and good question.
I've known excellent people flame out in weeks because the companies values just didn't match their own. They weren't bad employees either. It was just a difference of opinion.
I wrote this[1] a few years ago. Since then I changed these questions quite a lot (I need to write a new post) but the concept is still the same. Whenever I'm going to interviews I never go as I will be the interviewee.
For quick reference:
- What will my job be? At first and after few months?
- What is your work policy for employees?
- Software/hardware that I will get?
- Can I participate on/run side projects?
- Is there a budget for conferences, further education, bonus?
- What is the history of this company and how do you see the future?
I created a short questionnaire with TypeForm that asks some of these questions and linked it to my LinkedIn profile. Now any recruiter either answers ten or so qualifying questions or skips the questionnaire and goes straight to trash for not even reading my profile.
I once interviewed with a company that brought me into a new, shiny, well-appointed building on the corporate campus for an interview.
I did well answering their questions. And they answered my usual questions correctly. Stuff like "Can developers here choose their own tools?" and "My title is going to be Lead Engineer, will I actually be a Lead Engineer?"
After I was hired, I found out everybody uses Eclipse, no exceptions, and I was absolutely not going to be leading anything (I was basically going to be used like an overpaid junior engineer).
The best part: "Oh, you won't be working in the new building..." and was taken to an old, windowless, leaky, mold-smelling building with peeling paint and flickering fluorescent lights (think the opening scene from "Joe vs the Volcano"). My office was a supply closet that was being converted into an office (by that I mean, "we just pulled most of the stuff out of here, but otherwise just rearrange the furniture however.") I was given an old 70s vintage desk that was too low, a sort-of broken chair, and a laptop and left to my own devices for three weeks while waiting for my new project to get started. Then I was suddenly moved to even worse accommodations - a cubicle, which belonged to an employee who had recently died (his stuff was still there, and it was a month before anyone came to take it away).
I started looking for a new job about 2 days in. Took me a year to find something else (I eventually had to move to a new city).
At first, I was like, it's crazy that this company did this. And then as I was reading through the description, I realized this actually happened to me. It wasn't identical, but there are similarities.
First, the project was described as "green-field, we're doing cool stuff writing MVC apps from the ground up." I was assigned to build SSRS reports.
Second, the shiny building with the sales people, recruiters, executives - I did work there, on a second or third floor, corner office with windows! For about a week. Then I was moved a mile down the road to the building they got through an acquisition. I was on the ground level (I think?) and I had a whole office! But the office was small, dark brown and had no windows. Even the door was solid dark brown. (The office wasn't all that old or terrible - the kitchen was kind of awesome. But the actual area where I worked was pretty dreadful.)
I don't exactly feel like it was intentional, or at least, it didn't occur to me at the time. But looking back, of course they didn't want to highlight that they really wanted someone to grind through reports. And they clearly didn't intend for me to spend my time occupying a corner office with windows!
I worked at a place that had decided to increase office space in an unusual way. They once had done their own power generation with an oil boiler and had a very large underground concrete oil bunker. They eventually tore down the power plant and "cleaned" out the bunker. So, someone, bless their soul, came up with the idea of putting a cube farm in the bunker. Well, even cleaned and sealed, concrete 'bleeds' oil for a while. No problem, they just built a box in the bunker and vented around it to remove any fumes. So, the cubes are in a box in an underground bunker with a constant wind between the bunker wall and box wall.
Had an office with a nice view and plenty of sun. Got moved into a cube that neither cellphones nor radio got a signal with this constant wind noise since I was up against the wall. I left in 8 months (for other reasons amazingly enough). I dearly wish that there were transcripts of the meetings that went into that project.
Because it wasn't on the west coast of the US? Because the ancestor poster is older than 30? Because that company had some secret non-poaching agreements? Because companies were preemptively binning the resume for not staying at the previous company long enough?
> my usual 1-2 years
A genuine question...(I am not from USA.)
Is this 1-2 years period normal for many people/IT companies? Is it similar to contracting- benefits and tech/business exposure wise?
It's a nice balance between not having to run the job search gauntlet for a while, and not getting significant pay increases or advancement opportunities unless you get a new job at a different company.
I've found 1-2 years is also about the time it takes for me to become bored and want a new project, new responsibilities (promotion), etc (I've only asked for a raise once during my entire career, so it usually isn't about the money when I leave, though I do usually get a nice pay bump for switching companies).
I'll ask for what I want, invariably get told some version of "no", and start looking for a new job.
I'm not sure where the impression that it's easy to find a tech job comes from. Like the parent commenter, I started searching on day 2 of my current job and it's been over a year with around 200 applications/cover letters, dozens of interviews, some offers, but no good fits. I graduated 2 years ago with ~120 others in my class - not a single person is working in our domain (biomedical engineering), they're either in the same undergrad lab, in some corporate code monkey job they hate, or in grad school/med school and given up on the industry. Finding a decent job is possibly the hardest thing I've ever had to do and most days it feels like it will never happen.
> I'm not sure where the impression that it's easy to find a tech job comes from.
A lot of it is just the usual Internet bragging mixed with the “shortage of engineers” meme that just wont die. Everyone can get a new job in 7 days, just like they all make $250k, drive Porsche 911 GT3s, and have supermodel partners. It’s just part of the Hacker News zeitgeist.
Now back to the real world, my experience is close to yours. My last job took 1.5 years to find, with about 100 applications sent, 10 phone screens, 3 companies seriously interviewing, and 1 offer. So you’re not doing too bad, really.
I totally concur. It took me over a year, after being the lead developer for a decade with tons of technical and business experience. Thank goodness for digital resumes cuz I sent out at least 200. If it weren't for the fact that I had my current job down to a science, giving me a lot of free time to interview, it would have been impossible to find a new job.
Hey! That was my experience. New product direction; needed some designers.
Show up, and everybody is working on firefighting old bugs with a fake Agile approach. The kind where the manager hands out tickets to folks and the only metric is how many trivial bugs have been closed this week.
Every time I spent any time looking into the code (million lines of crap) to see if anything could be done, I'd get widely criticized.
I'm trying to get out, but not having much luck. I wonder if recruiters are turned off by the fact that I'm looking for another job again after just a few months.
Across the major markets in the USA and Europe I’ve never seen a hotter market. If you aren’t getting responses I would ask someone for help with how you are marketing yourself.
I'm in a rather isolated place (I work remotely) so I need to find another remote gig. I'm also a UX designer, not a developer, so the market isn't quite as hot.
The nice thing about remote though, is that it's easy for me to disconnect emotionally from how shitty my current job is.
I mean, one could say my city is also hot by the number of search results from the keyword software in the job portals but after closer inspection, if you've been around the block a few times, you can easily tell that over 90% of those jobs are shitty micromanaged fake scrum-driven burnout meat grinders.
Therefore, the remaining 10% are spammed to death with resumes so they can afford to be incredibly picky and wouldn't even look at you without seniority in other prestigious places that do exactly what they're looking for. And they don't care for leetcode either so the barrier of entry remains prestige.
How long were you at the job before this (crappy) one?
3.5 years at gig X and then 5 months at crappy gig Y isn't an issue -- new gig wasn't a fit, easy to play that off. "I tried to make it work but it felt like a bait and switch" would be an acceptable answer.
But a track record of ~1 year or less at places says that you're the problem or you make a lot of bad choices.
Breach of contract is not illegal. It's a tort, and you might be able to seek recompense through the courts, but I don't know how they would determine damages.
Most employees (at least in the US) aren't given a contract, they're given an offer of employment. This provides no guarantees as to what work you'll do, or the conditions you'll do it in, and both can change at any time.
In the UK, your contract is formed by: the thing you signed, any statutory law stuff, and any custom and practice stuff in your workplace. Generally speaking however, it's the same as what other people in this subthread have pointed out: you probably can't do a lot if the employer changes your contract, either officially or unofficially. Continuing to go to work implies acceptance and well. You could attempt to take the employer to an employment tribunal,but they're expensive (even more expensive thanks to the recent Conservative governments)
Source: used to be a trade union official. If there was a union for tech jobs, they might be able to pay for tribunal costs, but when I did it we only took them on if there looked to be a greater than fifty percent chance of winning.
I am a member of the Digital Division Committee of Prospect/Bectu Committee. We do take cases for existing members.
Unison has few places it represents at (probably more for historical reasons).
How ever apart from the costs we would only take a case to tribunal if it was a good chance of winning - as the pressure on the member going through a case is considerable.
An offer of employment is a contract, if there is an exchange of benefits involved in the agreement (you work for us X days a week, we pay you Y).
Even if it's only verbal, it's a contract; contract law applies, and if you can prove the conversation happened, you can enforce the contract in law.
This is the same in the USA and in the UK. But of course, it's much better to get a written contract before starting work (or moving home, if that's what it comes down to).
And (of course) it's much harder for an employee to enforce a contract against an employer than v.v. Contract litigation can be very expensive.
It is very common for employment offer letters in the US to clearly specify that employment is offered at will. This status has slightly different exceptions by jurisdiction, but in general, it means the agreement can be terminated at any time by either party.
Most people summarize this as "you can be fired for no reason", because that's the most commonly discussed scenario. But, your employer doesn't have to terminate your employment to terminate your employment agreement.
> At-will also means that an employer can change the terms of the employment relationship with no notice and no consequences. For example, an employer can alter wages, terminate benefits, or reduce paid time off.
Now, they can't do this retroactively, but they can do it with zero notice.
Mostly it's just the risk that you'll be found out and fired (which is similar to the risk on the other side of the table— that the employee will find out and quit).
At least in the UK I'm pretty sure that lying on your CV is fraud by false representation [1]. CIFAS (UK fraud prevention service) produced a suitably scary leaflet [2] to try to discourage recent grads from doing this.
I thought they were exaggerating about things like jail time for lying on a CV but it has happened in the UK - six months for saying she had 2 A-levels!
>which is similar to the risk on the other side of the table
In principle but not magnitude, especially if you've relocated.
Usually you cancel any other pending offers once you've accepted a position if you're nice, and that could close some doors because someone else takes those jobs. Might even get you red-flagged if you go back to them and say "this company lied to me so I quit" (the other person has no way to verify that's true or you blew up on someone verbally the first week and got canned).
Someone correct me if HR can give the termination reason, I don't remember.
In the US at least, legally HR can tell them whatever they want. However if the supply anything besides employment dates, title, and whether or not they are eligible for rehire, they'll be open to a civil suit if the information given negatively affected their job prospects
> if the information given negatively affected their job prospects
Asking a prospective employer what your references said about you if they pass on you sounds like a tall order. I'm lucky if I can even get a response to a cover letter + resume, definitely have never been given feedback about a sample project solution or interview (other than hired or not).
Am I wrong and it's actually one of the easier pieces of feedback to get?
> (which is similar to the risk on the other side of the table— that the employee will find out and quit)
Someone more left/anti-capitalist might argue that this is disproportionately in favor of the employer. The employee is depending on this job for food/shelter. Replacing the employee is much less disruptive to the employer than the employee. Especially considering the employee may have had to move to the area for that job.
The reason the market is so hot is precisely because so many shops are like this. If they were better managed then they could get away with fewer technical resources.
It sounds like they stayed there for about a year and had to move cities, so apparently the market in the area wasn't too hot for this to work. There are probably other people who stay longer, especially if they're not willing to move cities.
I don't think it's the case for the parent but the "golden handcuffs" of RSUs+bonus as a major part of total comp is a pretty real problem. I used to think the very idea of "golden handcuffs" was ridiculous but by the time you realize the depth of the mistake you've made (2-3 months) you realize that you just have to fake it for a few more review cycles and then you get leave with an extra $100k in your pocket.
It helps that places that are awful also usually can't imagine that you would want to leave. Good places, ironically, worry a lot more about employee satisfaction. Bad places typically believe that everyone is really worried that they might not get promoted/have a long career at company XYZ so are very weak at spotting employees that have checkedout. The stick they wave is usually "you won't get promoted next year if you don't play the game!"
Of course this depends a lot on how much energy the job drains from you, but if you can still learn some stuff during the day and don't feel drained when you go home, a year is not such a bad sentence to serve for a nice bump to your savings... just don't make a career out of it.
Exactly what I came here to say, albeit quite a bit softer.
Without having had the benefit of reading TFA yet, the problem is that you are never asking "the company" questions. You are asking your interviewer questions. Their answer, like all non-sociopaths, will be internally true or mostly true to themselves[+], but be colored.
The mitigation for this is that you have to ask every interviewer the same few questions.
[+] Read any book on how to suss out liars and you'll see that everyone who is not a sociopath, has many "tells" that they actually cannot resist. ie, normal people are uncomfortable with lying.
At my last job, I was told several lies (even during negotiations) that made the job sound far far better than it was. And this wasn't just from HR/recruitment. These were answers that I got from the many levels of upper management that I had to interview with.
I tried to reconcile those lies after settling in and having outstanding performance reviews. No dice. Ultimately ended up just leaving the company.
Lesson learned - Don't let them negotiate you into their range. Companies will lie to make their company sound like the shiniest, best place to work in the world.
Sometimes they’ll tell lies that their boss tells everyone willing to listen. Everybody knows these are lies, but they won’t always give you that “read between the line” interpretation during an interview.
The most obvious one is usually “we’re on an agile process”, but there’s so many other ones more subtle and hard to get a grip on, short of reading interviewer’s clues when they answer the canned answer.
Sometimes the same words just don’t mean the same things to them. Sometimes they don’t realize how bad their situation is.
“Reality shock” in the first days at some workplaces is a thing.
1. Workspace/office not the one you were shown/told. This is the most common one, in my few data points. I think people know it's a factor in appeal of the job, so it's mentioned, but the followthrough doesn't always happen.
2. Person you interviewed with is leaving. (One of the people I hit it off really well with in interviews was a tech co-founder of the established company. When I arrive as a new Architect, he apologizes and says he had been looking forward to working with me (which is not something I normally hear), but he just got an offer for a supercomputer startup that he couldn't resist. Fortunately, some other great people remained, and I ended up working directly with one of the other tech founders. I supposed I might've been hired due to the company knowing that some people were looking to transition out.)
3. Job not as described. (I've mostly avoided this common pitfall, but once got bit by it. I was recruited as the Research Scientist who'd execute on an idea that was sorta outside the scope of two professors who'd come up with it, but that they wanted to see it done, and it was up my alley. But, subsequent to discussion, when I'd been told I'd be the sole person leading&doing, one of the professors' grad students decided to do the idea for their dissertation, and I didn't find out until the first day on the job. It got worse from there, but the saving grace was that an all-around great 3rd person was also an "assistant" on the team, so, morale-wise, I was able to complete the entire year-long appointment I'd agreed to. I declined when the PI renewed the appointment for another year, and both us assistants asked not to have our names on the papers. It was unfortunate, because we did some good work, and the PI was willing to help me get my own ideas funded, but I couldn't commit to another year of the accidentally-bait&switch project.)
4. Famous culture broken. (My anecdote wasn't a first-day reality shock for me, but first-year. A successful with-revenue early Web tech company in a university town had a locally well-known policy slogan about how you advance, which seemed much more widely quoted than the "don't be evil" of another company, and was repeated to me when I interviewed. Long story short, while I was working there as a Senior Engineer, someone in company leadership was willing to spoil culture and morale, to let someone's nephew (or similar) break the slogan. I went and talked with the head of engineering, who normally had amazing poise and charisma, but he had no good explanation for that one. This was when other dotcoms were hiring the then-rare experienced developers like crazy... but companies sometimes do things that employees don't understand, creating new reality shocks.)
5. Representative from new parent company, walking around with representative from offshoring company, talking to employees about what they do, for multiple days. A bit like in "Office Space", but at an advanced Web tech company. (Also, I was concerned when they started asking me about an elaborate 3D puzzle that someone had assembled near my workspace before I was hired, they seemed skeptical when I said I didn't know anything about it, and then one of them asked where they might buy such a 3D puzzle, which I happened to know, and I couldn't resist being knowledgeable/helpful, even as I suspected it was just a trick.)
Reality shocks like these are another reason I'd rather talk with prospective employers, and get as much sense of the team and company as I can, rather than get distracted with one-way leetcode whiteboarding.
I've never flat out lied to a candidate, but I know part of my job as an interviewer is to sell the company/position, so I put a positive spin on things. Same thing the candidate is doing.
It's not even uncommon to be hired for one role and end up in another role for whatever reason.
Another thing is, policies change. Your interviewer could be grandfathered in and not know it (or know it, but don't mention it...). Or they could simply mention the last policy they remember, which isn't the current policy.
Some people also would rather just make up an answer rather than say "I don't know."
>It's weird that you didn't get the title in the contract
Job titles are not always correlated with job responsibilities. Hence we have "senior engineers" with a year experience. Title inflation is a real thing.
Technical interviewers aren't going to know HR policies as they apply to other people - its HR's job to give them that information. I don't know how much time off a new hire might get, for example. But a helpful technical interviewer might say "oh we start off at five weeks a year" because that's what they started out with four years ago.
>But when talking to your future peers/team mates, I think you can expect a lot of honesty if you ask the right questions about how things really are.
I've been lied to by every manager I've ended up working for. Too be fair, they've all been soft social questions, so I am partly to blame on that front. I've been terrible at identifying company culture until after I've taken the job.
I came in here to basically say that all these questions are great, but being able to just simply walk around the office and its departments (if it's that big) is also really important. You got bamboozled to a pretty extreme extent, but at least I know from my last employer that I'll be making damn sure that my future software development team isn't using older, slower computers than the marketing department.
I once has the most honest interviewer ever ask me:
> Where do you see yourself in 3 to 5 years?
I gave my typical response of technical lead, driving projects from the engineering side of things. His response was interesting.
> What would you think about not working here after 5 years?
The way they were able to run their shop was to use turn over to their advantage. They were custom software/hardware company that basically used as contract workers to make the widgets a company either has no time to make or doesn't know how to make. Their business model was to have you work on the project to the point where the contractor decides to hire you on full time to support the thing you helped make.
It was an interesting idea but showed they had no concept of stability for anyone besides upper management. Opted not to work there.
Yep. It's happened to me as well. Based on the questions they were asking me in the interview and based on the folks who were interviewing me I got the impression I was going to be working on a certain technology very interesting to me. It took them a while to actually make the offer (2 months), by the time I started they indeed had me working on that interesting technology... but then about 2 weeks in it was like "There's been an urgent change, we now need to shift you over to working on some other [much less interesting set of tasks mostly involving writing documentation]." I figured, OK, this is just a temporary thing and after the urgent project blows over I'll get back to what they wanted me to work on originally. I'd often ask when I was getting back to work on the original project and they'd always hem and haw. Eventually it became clear that it was a bait&switch.
> and I was absolutely not going to be leading anything
This scenario has been basically my life for the past several jobs. Companies will lie just to get you in the door. Never ask "Will I ...", because the answer is always yes. NEVER trust what a company offers.
> "Oh, you won't be working in the new building..." and was taken to an old, windowless, leaky, mold-smelling building with peeling paint and flickering fluorescent lights
Got similarly cat-fished. Companies always conduct interviews in their best offices, not the ones you'll be working in.
I've always ended up with on-sites on the shiny, clean, well-stocked sales floors. When I ask to see where the engineers sit, it's usually a pretty abrupt downgrade.
I've found that a fairly reliable litmus test for the degree of influence and technical contribution you'll be in a position to make is the comp package they offer you. Your management will need to justify what they're paying you to their management, and having you be in a prominent and visible position helps them make that case.
I'd like to see a section specific to large projects. It's not uncommon for companies to hire for specific projects, especially in the contracting world. ERP, SAP, and other projects come to mind.
Something I wish I asked during my last big interview: Do you have a project schedule? Can you show that to me?
If there is no schedule, or a very ambiguous one, that's a big red flag.
467 comments
[ 199 ms ] story [ 631 ms ] threadWhy would you not? You're taking the risk of wasting a few months until you find out that the fit is poor.
But I do ask things that show if the technical recruiter actually knows what they are talking about.
"What strategy do you use to complete Pull Requests?" There are many ways to answer that question that will show you don't know.
In general, I ask things that make me see if the other person is reasonable, and I can talk to one-to-one, but also that they make conscious decisions and don't just carry around cruft.
This might involve asking "What ORM do you use?", then responding to their answer with "Oh, why didn't you use <other ORM>?".
Company is interviewing the candidate not the other way around, no matter what we like to think.
Edit: Sorry I should've clarified. I am specially referring to companies that don't really have to care about your feelings towards their interviews. FAANGs for example. They simply don't care and there are million others who are willing and happy to go though whiteboarding. They just don't have to put up with your stuff.
Ofcourse you have leverage when you are interviewing at your local java enterprise shop. But who cares about those jobs, pointless to interview them with your smartass questions, we all know they are pretty much all the same more or less.
TLDR if you don't think you're interviewing the company too, you're doing yourself a big disservice and selling yourself short.
Absolutely.
But outside of places like SV or NYC, there may not be a lot of jobs available. For someone with a similar length of career, I'm not as flexible about being able to move to where there are more jobs. Is one just SOL when trying to improve their career; take what you can get?
I can deal with most tech problems and flawed companies, but the above list are my deal-breakers, and I absolutely am interviewing them to find out the answers.
If you assume you have no leverage then you will have no leverage, but that's more because you choose not to exercise it than because you couldn't exercise it.
I’ve worked for 20+ years but have only gotten serious about job hopping and interviewing for the last ten.
At any given time when I am job hunting I usually have three or four offers within three weeks. Not saying I am a special snowflake. That’s just the reality of the market. I’m very much interviewing the company. I usually have a BATNA of just keeping my current job.
Ofcourse you have leverage when you are interviewing at your local java enterprise shop. But who cares about those jobs, pointless to interview them with your smartass questions, we all know they are pretty much all the same more or less.
Despite the HN bubble where every developer lives on the west coast and works for a FAANG or the next unicorn, that’s the reality for most developers. But there is definitely a difference.
I disagree. Unless the candidate desperately needs this job, he/she can walk away. The candidate is free to consider "company won't bother to answer my questions at the point when they have most reason to be nice to me" as a bad signal.
> I am specially referring to companies that don't really have to care about your feelings towards their interviews
"This company doesn't have to care about my feelings because they are huge and have lots of applicants and a giant incessant interview machine chugging through them efficiently" is certainly something I'd consider in whether I want to work for them, because it tells me I'd be a cog in a machine. (And if enough people consider that, perhaps they will have to care.)
To the parent question: I wouldn't ask a whiteboard question exactly, but I would certainly ask some questions about existing architecture and rationale so I have an idea what I may be working on.
Aren't you a cog regardless though. Why would one work for half the salary just because of an interview. If one can get over the interview part, he/she can retire 10 yrs sooner.
For what I'm paid, I don't mind being a bit of a cog. Work is a means to an end for me, not my identity. But I would like to be kept greased and worked within spec, not constantly in crunch time. And while I am fundamentally disposable, I prefer to work in a place that sees I'm lot more valuable not being disposed of. (Again, metaphor breaks down here; planning on your personnel being routinely disposed means you are planning on nobody ever actually developing any skill in your systems.) It's not all the same thing.
Is tooling important to you? Ask about that. Do you want to push to prod like a cowboy, or does that repulse you? Ask about that. Whatever frustrates you about your current job, you can try to find out before you take a job where it's worse.
Framing those questions to get usable answers is a skill, of course, but if you've got a few areas to ask for, you can use lists like these to find different ways to ask. Just like interviewing, asking leading questions gets you 'right' answers that don't tell you what you want to know, so you want to get the interviewer to go off script and probably be truthful.
So at FAANGs for example, there are hundreds of teams that do all of kinds of stuff. You aren't necessarily interviewing directly with people from that team.
I'm a manager that rarely codes as well, but was still asked coding questions in an interview. It's a bit annoying, but having had managers that have never written a line of code ever, I understand wanting to verify that the manager could theoretically do the work themselves.
That said, it was the only one of my four interviews that actually included any coding.
I don't write much code on a whiteboard, so that makes two of us.
But I agree that having a discussion about such problems can be productive. It may help separate legitimate problem-solving from mere hazing.
In a somewhat related point, last time I was designing the coding question, I tested it on my teammmates. They all solved it, and their response was very helpful, and it allowed me to clarify some points in the problem.
But did they all solve in under the interview conditions? ( time pressure, coding infront of strangers, possiblity of not getting the job that you need etc).
I can pretty much solve all leetcodes on my own computer with noone staring at me like hungry wolf eyeing its next meal.
My goal was that the co-workers solve it under 10 minutes -- that 3x length factor is trying to compensate for harsher interview conditions.
As for leetcodes -- I just looked at the site, and my interview question would be rated 'easy'. In fact, I'd say that most of the 'easy' questions there are too hard for the programming interview.
do you have an example of this? I have hard time imagining solving algortihm qs under 10 mins.
I suppose that briefly turning it around on the immediate interviewer could be constructive, with some people, but I doubt I could pull that off even half the time.
My impression, from HN comments and firsthand, is that people still doing it seem to be thinking one-sided about it (i.e., they want to assess and/or manipulate "the candidate", and they seem to assume it's implied that everyone at the company is good). They probably also think this is convention, and perhaps resent or are suspicious of anyone not complying.
Personally, rather than turning the tables with the hazing, which can come across as hostile or combative, my natural inclination is to have a candid and thoughtful discussion about it.
(Warning: I've had poor success with trying to discuss with people who want to do the leetcode/puzzle-style whiteboard coding hazing. Maybe partly because the conversation only has occasion to happen with people who are still doing it, so it's not a representative sample of the field. I also suspect that, when it's with the more HR/recruiter-type people (not engineers or managers), they tend to not be participating in the discussion in the same way I am, but instead are performing the right head nods, while focusing on their normal modes, such as looking for red flags in what "the candidate" says, formulating how they'll report this, and being careful what they say.)
I also ask 'company culture' related questions, my go-to question is ask what the team I would end up in did as a teambuilding event last year, and follow up with who decided the type of event. It tells you a lot on the freedom you'll get, the company's attitude towards people working there, and how healthy the company is.
Usually it literally does not matter how the interviewer thinks and what they believe is right, you want to know the actual company policy, which often will not be the same as the interviewer might want to.
However, if you're being interviewed by your future direct manager, then you do want to get a perspective on how they think, as their individual attitude towards various aspects of work life will be relevant to you - but usually most interviewers aren't that relevant.
Remember that things tend to be fluid, re-organizations happens often, having a bug tracking system doesn't make bug handling efficient and CI/CD doesn't mean your time to deliver is necessarily short.
Those are definitely seeds of conversations rather than something you can 100% rely on. But if you have doubts about the organisation and then hear "no bug tracking, we don't need it" without explanation, then something's definitely fishy. That's one of the red-flag questions. Then again if they don't but have an explanation, maybe there's something really interesting behind it.
I wonder if that's often how it's perceived on the other side. I love when the people I interview ask me questions. If they're interested in something, not only am I going to answer as best as I can, I'm going to be interested in why you it's important to you. It can be a great conversation, and I'm not even trying to sell the position :-)
People really don't do it often enough - that's why I decided to post my own list.
I’m tempted to say that the questions they ask carry more weight for the final result than the ones that I did.
When I used to not have any questions after the interview - I got rejected what felt like a weirdly high amount and definitely a weird tone from the interviewer.
When I started asking questions - the interviewer seemed to have a much more positive outlook on me and my acceptance rate went up.
I've interviewed a lot and there are people you have to ask questions to or else they will reject you.
In my experience, when interviewers don't switch to selling the position, this is a bad sign. I'm confident I know my job, am open and honest about what I know and don't know, I don't need a 101 quiz of whatever tech they have in mind. If this happens I usually cut the interview short and just tell them this is probably not a good match.
No doubt, the most obvious rebuttal is that the interviewer will be doing their best to manipulate no matter your tactic, so you either circumvent them or acquiesce to them.
- 1) You earnestly express a belief, and it happens to have the desired outcome.
- 2) You express a belief primarily because you know what outcome it will create.
- 3) And the grey area: You honestly hold a belief, but you're also well informed about how that belief must be presented to modify your outcome.
Realistically, most of us live in that third option. The distinction between a job interview, and say, a dinner out with a friend, is that you're highly incentivized during a job interview to present yourself in the best light possible. Most of us are aware of how we'll come off when we make a statement, and there's always some incentive to come off in a better light. But, a job interview generally removes the possibility for blunt honesty. "Well, of course I'm excited to work here. If I don't express that excitement, you won't hire me!" Such a frank appraisal isn't really possible in a job interview. But in another (ie, a social) context, you could make a sarcastic quip, or even just an honest appraisal of the situation. "I'm excited to see you, but being in this crowded restaurant is giving me a bit of a panic attack." Maybe that's not the best social tact, but the option is much more available in a social context.
I'm meandering a bit here, but I hope my point comes through. When we're stuck in that grey area of option #3 in most situations in every day life, we can generally chose to go with honesty if we prefer. In a job interview, our success and survival depends on forcing us toward option #2.
I'm happy to be adding a few more questions to my list now :)
Why? Usually by the last interview if I have questions they're personal getting to know the person type questions, because I've got everything figured out by then.
Most I've had in EU was 3 rounds. 1 HR/recruiter, 2 technical, 3 technical+personal then offer
"How long has this position been open?"
is useful to subsequently ask
"so why is this offer letter expiring in 48 hours?"
"Where do you plan to be in 5 years" is actually a really good question to ask a company. Many have no idea (which is possibly fine, but good to know)
Interviews can also be a fantastic place to get real feedback - but you have to do it during the interview; almost nobody gives real feedback after the fact.
"What would give you concerns about hiring me?"
"If you could have your dream candidate for this role, what would they look like?"
"What in my application caused you to call me in for an interview?"
Are a few that I've found helpful.
For really good companies asking if they test code seems insulting :P
Well that's the general expectation anyway for 'tech companies' to be testing and adopting best practices these days. There are even companies nowadays that are tech enabled with apps, engineering departments, etc and they call themselves 'tech companies', but they don't have any tests, code reviews or a CI and take the shiniest tool for the job.
So if I was interviewed at any company, startup or large corp for a software engineering role and they don't have any of the above, I would gently terminate the interview. Imagine if hardware engineers were to tell us that they don't do verification or tests on components that they ship.
As much as we’d like to believe tech shops are at least all run by grownups, things like source control and working builds are NOT to be assumed!
I do like this list, but filter it down to what you need to respond to an offer. And that filter will be different for everybody.
Typically when I am in an interview, I explicitly draw that line with the interviewer, saying, "I have more questions, but I also have the answers I need to make a decision if you extend an offer, so we can get the rest answered later if we move forward together."
Like I said, everyone's filter will be different. There are probably valid reasons to ask every question on the list. And also valid reasons to skip every question. We all have different goals and preferences with our careers.
I agree with you that developers need admin rights on their development machines, but I have witnessed first hand why many companies attempt to take away local admin rights.
When I'm responding to security alerts where developers have downloaded random .dll files from the internet, or some "troubleshooting utility" that is actually malware, it doesn't take long until the local admin conversation comes up.
This is one of those classic "technical solutions for bad human behaviour" scenarios where a small number of idiots ruin it for everyone. If you want local admin as a developer, then we need to be able to trust that you aren't going to do something stupid.
It seems the best way to do this is to issue developers multiple boxes (corporate laptop + dev box only for dev), and or use a good software whitelisting program that tracks elevations & the reasons for them, instead of just blanket giving everyone local admin on their own PC.
Also, if a compromised machine on the internal network destroys your company's security assumptions, then there must not have much defense in depth.
If you have downloaded a trojaned "super library" and put it to your build process, it will, by definition, be in the same security domain as your source code.
Unless you audit all file accesses and outgoing internet access, you won't be able to prevent code exfiltration.
Maybe the better question is: how do you prevent your lowest-bidder corporate antivirus marks from marking git-bash as malware, stopping all work for the team for two days?
Developers don’t need admin access, they need ways of getting their jobs done with the best available tools. That’s a damn difficult balance to find!
It's an interesting hygiene problem. Semi-related, I love UAC, and taking UAC seriously. It's the closest thing we have to "good handwashing habits" for admin access. I don't understand how many corporate GPO defaults/admin "standard images" I've seen where if someone has admin access at all they default to UAC off. (I make sure to turn it immediately back on as a matter of instilled corporate habit. One job I had to remember to do that after every restart/full relogin because of GPO overrides. Gross.) Sometimes I wonder if there is some oath I just could sign as a developer that starts with something like "I promise always to at least wash my hands / pay attention to UAC prompts" and "I swear I usually have good reasons to authorize admin access when I reply to a UAC prompt". (And/or you know, use the GPO for what it was meant to do and enforce a minimum UAC, rather than disable it.)
(I also find it peculiar how many Windows IT admins and developers I've met that disable UAC in a corporate environment but then personally use macOS and are so happy that is has SUDO prompts and wish Windows had something similar but somehow don't realize UAC is the exact same thing. It's a strange cognitive dissonance that I don't think I will ever understand. Yes, I've heard all the arguments that Vista's first usages of UAC confused them and they gave up learning it before it settled down and they didn't want to unlearn decades of bad habits from 95 to XP, but I guess I find that a really poor excuse because I was a heavy Vista user by choice, partly specifically for UAC. Washing your hands is great, and very professional, and decades of a habit of not washing your hands isn't an excuse I'd expect anyone reasonable to expect, but especially in a hospital. Anyway, I digress.)
If UAC is disabled by GPO it's probably because of incompetence, apathy, or maybe the IT admins have just been browbeaten into avoiding anything that could inconvenience anyone.
There are also tons of companies with 15 year old Active Directories with tons of kludgy GPO configurations that nobody has looked at for 5+ years.
But "they cannot work" is implying that person gets fired. I agree that serious breaches of security are a firable offense, because it's plainly a fact that people get fired over them.
Generally, though, developers are fairly hard to replace and anyone who is hard to replace is equivalently hard to fire.
So most security policies have to work out some kind of compromise between those competing interests.
Issues with trust imply greater problems in the workplace. Unless you're in a high-risk (of hacking) industry, like military, treating adults like children is a huge problem.
Granted, there are plenty of ways around these limitations. By now, all of my "I need admin rights" development is performed within a VM.
I think a lot of this stems from the fact that most of the managers in infosec for companies aren't developers and haven't ever been one. They really have no idea what developers really do. I'm not belittling them. It's just not the career path they took to get where they are. It's difficult to explain to them how frustrating being hindered is, and this causes a lot of good people to just leave an organization like that to find something better.
If the process for getting something like IntelliJ IDEA installed on an airgapped machine involves less than an hour with their help, it's workable. If it is not, forget it.
Unfortunately, it takes a lot for management in most companies to see why this is a good idea, and why spending that much on staff ratios is a good idea.
What problem are you solving by making work for devs range from "incredibly hard" to "outright impossible" via taking admin privileges away? Surely you must understand that all things should be in balance, that security isn't the sole goal of an organization but rather an important consideration in the overall structure.
Are you attempting to create a tech "solution" to a hiring problem? You aren't going to succeed.
You can propose such a thing. If you're in charge at a company, you might get to implement it. But if you do, know that it's a huge black mark against your company. I've seen how these whitelists work in practice. They're massive wastes of time. They get in the way of actually doing one's job, as creative work can't be constrained and approved in advance by some committee with a ten-business-day turnaround on getting some damn file conversion utility to run.
The golden rule of "security product" culture is this: inconvenience is a feature, not a bug, since friction reminds people that the infosec group exists. When it comes to stuff like this, all the incentives are lined up to just inconvenience people, not protect them. We ought to protect data, not code.
Code is more dangerous than data. Personally, I'd be most worried by someone getting a virus that hacks into other computers and encrypts them and/or wrecks the network. Both can be protected against, first by cold backups and second by resilient / disaster recovery network, but both would also severely affect the company for a few days, so I'd rather avoid them.
Losing data is bad for the business. A random box had software crashing? Just replace the box.
I went somewhere else where we had locked down machines. I am never, ever, ever going back to a place like that. Fuck working in that kind of environment.
And bring some cookies for the grumpy security guy that will make himself heard shortly after the request is permitted by the boss.
As long as one has admin access in the VM of course!
At a few places, I experimented with running Windows. Every time, the Windows machine came with Bit9 or some other performance-killing compatibility-breaking security "solution" that made the system unusable. Windows is a great operating system. What IT departments do to Windows turns it into a nightmare.
These same places all had a much lighter touch on Linux VMs, desktops, and laptops, so clearly the invasive "security product" mindset was just contained to the Windows (and in one instance, macOS) groups.
That's a great bumper sticker.
There are so many cases you find of people's Windows complaints where the questions are "Why does Windows even allow GPO to hurt users that badly?" and "Why does your IT staff hate you so much personally that they configured Windows into that particular contortion?"
The Unix world has decades of tales of the "sysadmin from hell" / BOFH, of course, but something about Windows administration just seems to elevate to almost universal "art form" across every company, but at the same time has managed to make it "business as usual" rule rather than the to-be-irked-by exception. On no other operating system would that level of IT micromanagement and terrible "security products" be accepted, and on just about no other platform would people just as easily assume it to be OS "bugs" or "inabilities" rather than the forced masochism of some local BOFH.
Typically its because the GPO configuration has 15 years of kludge and your IT department is under resourced and doesn't have the ability to spend 6 months sifting through and testing all of it.
In Windows environments group policy is often one of the biggest piles of technical debt.
But a big problem is how cult-like certain GPO setups have become. Asking my IT Department casually, 90% of the worst GPO settings we enforce at my current job are "mandated" in the agreements and contracts with a certain, supposedly prophetic (but unarguably profiteer) vendor of over-priced databases and accounting software "to keep their software working as intended". (Which may be quite accurate if their software is truly intended for the slow torture they provide from a user's perspective.)
When this started happening, I thought that I had installed some malware. In the process of debugging the problem, I ended up finding & disabling the root kit through trial and error. When my machine started working properly again, I came to understand I had disabled the corporate security "malware". I reported the problem to corporate just as others started to report having the same slowdown error. They told me the vendor of the software was impressed I had been able to find it, let alone disable it. I believe their words were "you shouldn't have been able to do that".
I didn't get into any trouble. By reporting the problem, I actually helped kickstart the removal of that software from anyone's laptop where shell access was required. The vendor never could fix the performance problem, and eventually our company resorted to trusting the developers again.
These are the same devs who install random things with curl|sudo bash right? Or write code that can only run as root in production?
No thanks. These days of virtualenvs and similar, only incompetent devs insist on being root too. In fact, this will make an excellent interview question, thanks!
I've worked at companies where even being able to install something simple like Notepad++ or VSCode was turned into a major chore or made impossible thanks to the locked down environment.
Locking down trivially important system preferences like your desktop background is another example of just plain annoying management that I've witnessed.
Don't forget corporate network content blocking, and I don't mean the obviously not safe for work content, but companies acting as the productivity police e.g. blocking Twitter and YouTube just because they don't trust you enough to not slack off at work, and furthermore not trusting your supervisor to be competent enough to determine whether or not you've been productive enough lately.
https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hac...
As both developer and a systems administrator, I am constantly on both sides of the fence. I have seen developers who cannot even maintain their machines and download any random thing to streamline their job to the detriment of security. Yet, I have seen other organizations where it takes months to get something like VSCode installed (try keeping that up-to-date on an air-gapped machine, that isn't connected to the internet... or ... Node.js or... full Visual Studio...)
> It's not a vulnerability/security issue in Notepad++
Outcome from a security perspective was the same.
Nothing at the referenced URL corroborates how you are representing the referenced URL.
According to the URL, the CIA was replacing one of Notepad++'s components w/ another in order to run code on the user's system and stay hidden. Nothing in that links indicates that that replacement is done through any breach in security in Notepad++ itself, and AFAICT, they're using it merely as a good hiding place. The Notepad++ announcement fixes no particular bugs, but merely signs the code.
"It rather involved being on the other side of this airtight hatchway": https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
I'd also say that the CIA is probably not within the threat model of most companies. (If they had one.)
No, it wasn't either. The security "issue" was that a shared library loaded by Notepad++ could be replaced with a compromised one. At no point did either Notepad++ or the library authors distribute a compromised version of that library.
Being able to replace shared libraries is not a security issue, it's the number one (or number two, depending on who you ask) reason for having shared libraries in the first place. It's like saying that if I compiled a custom version of glibc and installed it on a computer, the entirety of the GNU ecosystem was compromised.
This list is missing the two most important [busines] questions:
1. How do you make money?
If you can't understand, or the interview can't explain, then I'd run away. This can also lead to interesting questions about risks, competitors, etc.
2. What's preventing you from making more money?
The answer that you want to hear is engineering effort. If not, you're (at best) a wallflower at the party. Don't be the chump that's at Goldman Sachs acting as a code monkey for the traders. Don't be writing code at a company (like Enron) which has its success based on digging holes in the ground.
I can dig up the slides if anyone is interested.
(Like the siblings comment, I may disagree with "The answer that you want to hear is engineering effort", but the questions are definitely valid in some situations)
Thank you!
Working in the profit center of a company is often enviable, but let's not forget that cost centers in large companies can also offer benefits in things like work/life balance.
Why not? That's a prevailing opinion.
SWE: Works for a startup. HN: RESPECT!
SWE: Works for FAANG. HN: Respect.
SWE: Works in an industry that's not related to the web. HN: Wait, what? I don't understand.
SWE: Works anywhere else. HN: Crickets.
I've also worked somewhere at a "lesser" company where I was firmly on the cost-center side of things, but my work was seen as absolutely business-critical, I was treated well, I survived all reorgs and department layoffs and had my salary tripled from the time I started.
Working in unsexy companies is a tremendous opportunity because if you're good at what you do, people literally think you work miracles.
Also that last statement hits way too close to home.
Also I used to work at an ISP too! :D
You can get vibe of a company by asking if IT is seen as a cost center. If software is a competitive advantage you know that it's green pastures for your and yours. But places where culture holds back engineering, like being slow on the uptake of GIT or CI/CD which is often talked about online, these are places to be wary of. Those latter companies are either going to have growing pains or will die out as digitization starts to take them on.
Though in the context of this thread, I don't know a good question to ask in an interview to tease out that information when it's not already clear. If you simply ask "is IT/engineering considered to be vital to the business model or core to company success", everyone will answer yes regardless of how the IT/engineering is actually viewed.
I'm not even sure had I figured out exactly what that question should be if it would have helped that younger version of myself in the place that I was at, but it's still a useful lens moving forward if I have to stay in the "dark matter" parts of software development in the parts of corporate America that don't consider themselves software development companies.
> I don't think the GP intended to call engineers at those kinds of companies lesser.
Yes, they did - bit difficult to argue good faith when you are calling people chumps.
How long ago did you give raises?
How long before that was the last time you gave raises?
With that being said, in my experience of working at companies that actively sell software, whether it's as a product or a service, you are still incredibly likely to be as much of a wallflower as you are at a non-tech company. Your perception of freedom is higher, but ultimately your time and budget is limited by whoever manages you.
I'd be interested in the slides to see if your questions dig into one of the most common issues I see at tech-centric companies - micromanagement? Is it a thing - and if you say no, would a random selection of three of your developers tell me the same thing?
Financial markets companies are now engineering and quant driven. Machines place 80% of orders in US equities exchanges, not humans. The company you mention just announced a $100M project to rewrite its core equities trading platform to optimize latencies at scale across markets. Great engineering culture too. Meritocratic, respectful, and you won't find people there going around referring to developers in other industries with the disrespect you do, for example.
By way of explanation, this phrasing came out the slide deck itself, which was used as part of a recruiting effort at colleges for new hires. In many cases we were competing with offers from finance firms and felt the need to distinguish ourselves to compensate for their salaries
Having said that, I stand by much of my statement: assuming you have a choice between those two types of roles, you'll end up in a better place where your job is a path to more revenue rather than a cost to be minimized.
A better question would be "why do you use [the source control they use]". The answer, if coming from a knowing person, may tell you quite a lot about how the technical decisions are taken in the company.
Cause if the answer is "source safe" or something like that...
The first was open sourcing parts of their code so they just started using GitHub. Makes sense.
The second used to work with Subversion, and they stayed with it. The process was built around having one and only one server with all the CI, and the hooks, and the locks. Git was used with the SVN gate purely for developers' convenience. Makes sense.
The third one was on TFS, and they couldn't quite align their process with it. So they thought "our process is a mess so let's do git". This is a red flag. If you can't get your process straight with relatively simple tool, some more sophisticated tool will (and it did) only make it worse.
Honestly? Because it's become accepted as the industry standard. People who need to make the decision without having knowledge about the topic just go with whatever everybody else is doing. In the past, that used to be whatever IBM was offering, then whatever Microsoft was offering. In that respect, git is a lot better. It's flexible enough to adapt to different kinds of workflows, at least.
What does that mean?
1. What is the demographic breakdown of the engineering team? And, what does the company affirmatively do to foster diversity?
2. What resources do the founders have available — investors, board, mentors, for instance — to help them as the company grows?
3. What is the near term vision for the company? 1yr/5yr?
4. What resources are available for professional development for managers/directors?
5. At $CURRENT_COMPANY, the company is serious about reviews upwards — as a manager, my direct reports are consulted in a formal process at review time. Is there a similar process at $POTENTIAL_EMPLOYER?
6. What is the cadence and process for reviews?
I’ve never been in a position where we were paid for on-call (i.e. fix prod at 2am) work. Is that not typical?
That gives me pause. It makes absolute sense, but it never occurred to me.
If management don't also share in the responsibility, it -might- will happen again because they won't allocate the time (and-a-half) to fix things.
We had a quarter of big router changes and I got enough comp time to take a decent vacation (padded by PTO days, mind you)
Some data center techs I knew would get time-and-a-half for any on-call work they had to do.
And 66.6% time for every hour you are on-call with a 5 minute response time.
SWE teams often don't have the global coverage that entails, so they just pay you extra to be close to your phone.
* Do you do batch and/or streaming computation?
* What kind of access do you have for querying/accessing the data this role will predominately be working using?
* Do you have dedicated data engineers and data infrastructure people
* What's your workflow orchestration engine?
* What is the data access pattern for historical data (there had better be at least SQL access here).
* Do you have built-in feedback loops for your machine learning products?
* What is your serialization format of record for production and for OLAP?
* How often do schemas change in your databases?
Tell me about a time that you made a decision to improve code quality or architecture at the expense of a deadline.
Tell me about a time that you invested resources into an engineer's technical development even though there would be no immediate, short term benefit to the company.
Tell me about a time that you pushed back on a decision from business or design because one of your engineers said that it was the wrong technical decision.
Extreme case but ...
I guess this should be motivation to me to get back to work on one of my crappy ideas that could turn into a startup ;-)
This happens at FAAMG companies.
It's also fascinating to me from an anthropological/sociological view point because Microsoft has had some sort of Bay Area campus (almost continuously) for longer than several other members of GAFAM have even existed (with PowerPoint headquartered there from its acquihire in the 1980s until a reorg shuffle in the mid-90s and HoTMaiL/Hotmail/Live Mail/Outlook.com and other "web properties" carrying the torch up until a lot of recent acquihires expanded that campus again to more Office-relevant tools beyond just "web stuff").
I have never taken a job without talking to a top executive. You get a view of the company bigger than your team, you get to ask those business questions your manager may not know, and you have a head start on making good connections with upper management.
And also, I have to say, it's a bit arrogant to think that you deserve the attention of top executives. You can't expect them to prioritize your interview over all of the other activities their company does.
The risk, of course, is that you'll seem rude and high-handed asking interviewer-style questions yourself. If you have the upper hand (the job market is hot and they need you more than you need them), that's fine, otherwise not so good.
I love the table-turning style of these questions; but the fact is, they can always answer "No, we can't think of any such examples. Are you going to walk away from the job?"
That is to say, hiring is usually a buyer's market.
In the US, in the tech industry, right now? That's not even close to true.
An aside, I say the above now, but damn, I wish I'd had understood it 10 years ago.
1. https://www.dictionary.com/browse/inter-
This will help you determine if projects are mismanaged, how stable their prod environment is...etc
Obviously, it's up to management if they want this to be a part of the interview.
Instead of asking about values, ask about behavior. No one is going to say no to "Do you value code quality?" Aking what they've done (and sacrificed) to support code quality will give you a better idea of what their relative values are.
Asking about their tech ladder will get you an HR answer. Asking "Who was the last person promoted to X? When?" will give you a better answer. And if they can't remember the last time, that's an answer in itself.
The idea being that you will learn much more about someone / something if you ask questions that are anchored to a time and place rather than generic "unembodied" questions.
So the first question you list "Do you value code quality?" is an "unembodied question" and there is no hook for the person to dig into reality and give you an honest answer.
The second, "Who was the last person promoted?" is "embodied" in that it is anchored in time and place. And because of that, a person is going to use their memory, rather than their rehearsed "value system" answers.
Anyway, it's basically exactly what you said, but I just wanted to recommend that I thought the podcast was a worthwhile listen.
[1] https://www.thepermaculturepodcast.com/2019/1912/
Y/N questions are not very revealing and are likely to lead to dead-ends in the conversation.
WWWWH questions reveal a specific bit of information, but can also lead to dead-ends.
Open-ended questions ("Tell me about...", "What do you think of...", etc) will foster good conversations and uncover new threads to pull. In my experience, this is by far the best way to interact with other people, whether they are interviewing you or not.
Coming up with good/relevant questions on the spot is a skill that can be difficult to master, but is extremely valuable.
For example, people use common words as short hand for many things ("Work was stressful", "The kids are being a pain", "We had a really nice weekend"), and a mistake people run into when talking with others is that they assume the person they are talking with meant they same thing they themselves would have if they had used that phrase. This leads to lots of people "listening but not understanding".
So basically, offhand comments and common phrases are a great place to get a person to dig in deeper into their feelings on a topic. Usually they indicate something that is on the person's mind but that they probably haven't worked through enough to put into words. That means you will get a much more raw and unfiltered response from them.
Also it's always good to remember that people love to talk about themselves, even if they say they don't.
"The inflammation in my body"? Sounds like a dopamine response in someone whose sympathetic nervous system is strung tighter than a kettle drum.
But it's hard in some cases not to feel lied to when you see the gap. At least in dating when this happens you can get out early. You don't get the same trial period with work arrangements.
In fact one of the hardest lessons I've learned is that the companies who are the most vocal/passionate about their "values" are often the ones that are the farthest from them.
I like to ask about recent promotions and reasons, or conversely, asking who's been promoted based on the stated values in response to the direct question. Basically: how do you track and credit for this?
EDIT: and "Imagine I've been working here for 3 months and you are very happy with my performance: what am I doing?"
Bonus is if you reach out to former employees on LinkedIn and ask what it’s like to work there.
Do engineers have access to safari books?
Did you sponsor any conference passes/ training?
(I got answers like we have certification amount re-reimbursement policy(turns out for only pre-approved/ business significant courses). We have internal Community Of Practice sessions, etc.)
What sorts of signals do you look for in these answers?
"Firing the responsible" may be an overly-strong comment -- putting pressure on the line rather than improving line management is the upshot of what I'm getting at.
Though truly boring can be a good sign if it's the result of good planning, drilling, practices, and rewarding competence. If it's from complacency, failure to recognise problems, or the ability to push fault or failure off on others (clients, customers, vendors, suppliers, other departments), not so much.
The good sign then is understanding why and how they got to boring.
Good: Addressing the problem, fixing the process.
Bad: Assigning blame, firing the responsible.
(The latter especially for a first instance, though if you've got repeat instances, I'd look first to management, then to staff, for cause.)
Another bad sign is if the cause for the stress is internal, and a pass sign is if it's either management or a major (or the only) client.
If you cannot find ways to eliminate internal causes of stress, or buffer those created by the commercial environment in which you exist, it's going to be somewhere on the continuum between toxic and fatal to me.
I often get some very candid feedback, and have passed on couple roles because of what I've heard.
Apparently that meant that occasionally a slack bot asks me what I did recently.
I actually don't mind it. I'm a noob, it's a small shop, and i'm not sure I'd like a pure "agile" environment anyway... or would want to risk it going wrong.
One thing I didn't notice for a few quarters was that the slack bot was not automatically configured to show the other people in the standup what was written. This is very important to the standup concept so you can discuss and help others on a task if it seems relevant, and everyone is aware.
Not sure how "agile" it all is but it isn't the worst system as in it isn't as disruptive as everyone chatting all the time.
It's probably some measure of micromanagement going on. Don't buy it if you know what's good for you.
If the team could commit to updating their stories at the end of the day, then we could cut 15 minutes out of standup by leaving out what we did and just talking about blockers and what we learned.
There's supposed to be some osmosis around hearing what everyone else is working on. But practically if you split into separate scrums, you're only hearing about what people you're already collaborating with are working on and odds are you already know what they're going to say.
If the team is big enough you can't have a combined standup than most of the value of these conversations is already lost. You have to use the tools to telegraph your actions anyway, so why chat about it every morning? Discuss time savers and time wasters instead.
I tried running a scrum of 12 and indeed it was clear from the first standup that it wouldn't fly.
It's especially jarring when systems that claim to be self-aware are so unaware.
It's like they're selecting for people who make major decisions based on little or no information. I'm sure that will end well...
I'm certainly happy that viraptor shared this valuable resource, don't get me wrong, every little step in the right direction is a good thing. I simply would have liked it to have a better name in order to convey a different message.
I'll improve the introduction to make it clearer.
Sadly, however, I've found most places have gone to "PTO" -- combining time off for illness and vacation into one bank -- how have others successfully negotiated an appropriate level of time off?
(Context: For a very long time, I worked for companies where sick time was essentially a non-issue; it was essentially unlimited, with appropriate rules around requiring a doctor's explanation or having to switch to short-term disability after a protracted period, but the occasional day or two to recover from a cold and not spread virus to the whole company without having to choose between that and visiting family.)
I feel the same way about 401K matching.
For nice round numbers. Say you’re making $140K (above the social security maximum to make the calculations slightly simpler).
A 5% match is $7000. But since it is an untaxed employee benefit and if I think I can already max out my 401K plan, I would have to take into account the 24% Federal 6% state (GA), and 1.4% Medicare tax - 31.4%
That means I would need to negotiate at least 7000/.686 = $10,204 extra.
(Working on the link)
https://www.irs.gov/retirement-plans/retirement-plans-faqs-o...
And if I had kept reading the link I found (but didn't post)
https://www.investopedia.com/ask/answers/102714/are-roth-401...
Unlike the employee's contribution, however, the employer's contribution is placed into a traditional 401(k) plan, and it is taxable upon withdrawal. The employee's into a Roth 401(k). Therefore, many employers have found the additional administrative demands of offering the Roth 401(k) outweigh the benefits to their employees and do not often offer one. This is the reason for the perception, or misconception, that employers cannot provide a match to Roth 401(k) employee contributions, when in reality, they are simply not providing the option for the plan at all due to the administrative hassle.
Capital gains are untaxed in a 401k.
Depends on the person and how they handle their finances.
Capital gains are taxed as ordinary income when withdrawn from the 401k. The timing is better (since you're not taxed on sale, you can rebalance at will), but the rates are worse than a taxable account.
I'm just saying, if you count employer 401k match in your all-in comp figure, it doesn't make sense to treat it as untaxed; it will be taxed, the rate might be less, but it might not be that much less.
I'm not sure what you mean by that, but income from PTO/vacation/sick leave is taxed the same as any other income.
If they gave you an extra week of vacation. Your taxes wouldn’t change. If instead they gave you an extra $2700 in salary and you took a week off of unpaid time off, you have to pay 24% in Federal taxes on that income + 1.45% in Medicare (you are already over the social security maximum).
You would need to make $3621 more just to start breaking even ($2700/(1 - .24 - .0145)). But even then you are paying taxes on the extra 3621-2700. I’m sure there is some formula to break even but I would just ask for an extra $4000 and call it a day.
....and they will let you take unpaid time off....
That wasn't what I was addressing, I was only commenting on this: "PTO is a non taxed benefit."
Someone could misinterpret that and think "I pay taxes on my salary, but PTO is not taxed."
But the money you're paid for PTO is salary. If you have accrued PTO and leave a company, when you get your final check you will find that the PTO payout is taxed as ordinary income, just like all of your other paychecks. And while you are at a company, the income you receive from any PTO days is also taxed as ordinary income, no different from a day that you actually work.
That was the only issue I wanted to clarify.
You usually only have to resort to that if the HR system is inflexible and someone is making a big deal about it. A blanket statement that we don't do that, can't do that and won't think about doing that is usually a bad sign.
Standard here in Spain is 30 days off (including weekends and bank holidays). Most companies just offer 22 working days. I worked for one that offered 24.
This is so important.
I can probably live with most open plan set ups, sure there will be annoying times, but if there is a call-heavy team nearby, forget it.
I refuse to wear noise cancelling headphones all day long.
FWIW, interviewers will blatantly lie.
I asked at an interview about equipment quality and was told that they'd not heard any complaints.
This was 100% bullshit. I was given an ancient laptop, which seemed to re-ignite complaints about the quality of the equipment and were taken up with, none other than my interviewer.
May I ask why? Even when I work at home alone, and there are no stray noises at all, I'll still wear my headphones when I want to really focus. Years of mental conditioning has led me to a place where it's much easier to deeply focus when I'm wearing headphones listening to white noise.
If I'm in an office, nominally for intellectual work, no motherlovin' way.
(I've done both. Equipment case can be tolerated and acceptable. The desk/office situation absolutely is not.)
If I take more frequent breaks I can stretch it to about 3 hours.
If we're losing the AC war, then it's normally the heat that does it.
I got a genuine and thoughtful answer. It helped me to establish quite clearly what value systems wouldn't fly in the company which guided me on how to behave.
It worked out well.
Essentially you're trying to figure out "if you hire me and what is true about me then things won't work out?". You want to know if you have those qualities. If you do, you shouldn't accept an offer if you get one. It's a reasonable and good question.
I've known excellent people flame out in weeks because the companies values just didn't match their own. They weren't bad employees either. It was just a difference of opinion.
For quick reference:
- What will my job be? At first and after few months?
- What is your work policy for employees?
- Software/hardware that I will get?
- Can I participate on/run side projects?
- Is there a budget for conferences, further education, bonus?
- What is the history of this company and how do you see the future?
- Will you measure my productivity and how?
[1]: https://kostasbariotis.com/interviewer-vs-interviewee/
I once interviewed with a company that brought me into a new, shiny, well-appointed building on the corporate campus for an interview.
I did well answering their questions. And they answered my usual questions correctly. Stuff like "Can developers here choose their own tools?" and "My title is going to be Lead Engineer, will I actually be a Lead Engineer?"
After I was hired, I found out everybody uses Eclipse, no exceptions, and I was absolutely not going to be leading anything (I was basically going to be used like an overpaid junior engineer).
The best part: "Oh, you won't be working in the new building..." and was taken to an old, windowless, leaky, mold-smelling building with peeling paint and flickering fluorescent lights (think the opening scene from "Joe vs the Volcano"). My office was a supply closet that was being converted into an office (by that I mean, "we just pulled most of the stuff out of here, but otherwise just rearrange the furniture however.") I was given an old 70s vintage desk that was too low, a sort-of broken chair, and a laptop and left to my own devices for three weeks while waiting for my new project to get started. Then I was suddenly moved to even worse accommodations - a cubicle, which belonged to an employee who had recently died (his stuff was still there, and it was a month before anyone came to take it away).
I started looking for a new job about 2 days in. Took me a year to find something else (I eventually had to move to a new city).
First, the project was described as "green-field, we're doing cool stuff writing MVC apps from the ground up." I was assigned to build SSRS reports.
Second, the shiny building with the sales people, recruiters, executives - I did work there, on a second or third floor, corner office with windows! For about a week. Then I was moved a mile down the road to the building they got through an acquisition. I was on the ground level (I think?) and I had a whole office! But the office was small, dark brown and had no windows. Even the door was solid dark brown. (The office wasn't all that old or terrible - the kitchen was kind of awesome. But the actual area where I worked was pretty dreadful.)
I don't exactly feel like it was intentional, or at least, it didn't occur to me at the time. But looking back, of course they didn't want to highlight that they really wanted someone to grind through reports. And they clearly didn't intend for me to spend my time occupying a corner office with windows!
I was there for about 4 months.
Had an office with a nice view and plenty of sun. Got moved into a cube that neither cellphones nor radio got a signal with this constant wind noise since I was up against the wall. I left in 8 months (for other reasons amazingly enough). I dearly wish that there were transcripts of the meetings that went into that project.
Yes, oddly enough I left because I started dating someone and looked for a job closer to her.
The only people who could really say, won't.
I've landed a fairly good spot now, might actually stay longer than my usual 1-2 years.
I'll ask for what I want, invariably get told some version of "no", and start looking for a new job.
A lot of it is just the usual Internet bragging mixed with the “shortage of engineers” meme that just wont die. Everyone can get a new job in 7 days, just like they all make $250k, drive Porsche 911 GT3s, and have supermodel partners. It’s just part of the Hacker News zeitgeist.
Now back to the real world, my experience is close to yours. My last job took 1.5 years to find, with about 100 applications sent, 10 phone screens, 3 companies seriously interviewing, and 1 offer. So you’re not doing too bad, really.
Show up, and everybody is working on firefighting old bugs with a fake Agile approach. The kind where the manager hands out tickets to folks and the only metric is how many trivial bugs have been closed this week.
Every time I spent any time looking into the code (million lines of crap) to see if anything could be done, I'd get widely criticized.
I put up with it for a few months and bailed.
I'm trying to get out, but not having much luck. I wonder if recruiters are turned off by the fact that I'm looking for another job again after just a few months.
Across the major markets in the USA and Europe I’ve never seen a hotter market. If you aren’t getting responses I would ask someone for help with how you are marketing yourself.
Post your LinkedIn profile if you’d like
The nice thing about remote though, is that it's easy for me to disconnect emotionally from how shitty my current job is.
I mean, one could say my city is also hot by the number of search results from the keyword software in the job portals but after closer inspection, if you've been around the block a few times, you can easily tell that over 90% of those jobs are shitty micromanaged fake scrum-driven burnout meat grinders.
Therefore, the remaining 10% are spammed to death with resumes so they can afford to be incredibly picky and wouldn't even look at you without seniority in other prestigious places that do exactly what they're looking for. And they don't care for leetcode either so the barrier of entry remains prestige.
IMHO that's not really hot.
3.5 years at gig X and then 5 months at crappy gig Y isn't an issue -- new gig wasn't a fit, easy to play that off. "I tried to make it work but it felt like a bait and switch" would be an acceptable answer.
But a track record of ~1 year or less at places says that you're the problem or you make a lot of bad choices.
Source: used to be a trade union official. If there was a union for tech jobs, they might be able to pay for tribunal costs, but when I did it we only took them on if there looked to be a greater than fifty percent chance of winning.
Unison has few places it represents at (probably more for historical reasons).
How ever apart from the costs we would only take a case to tribunal if it was a good chance of winning - as the pressure on the member going through a case is considerable.
Even if it's only verbal, it's a contract; contract law applies, and if you can prove the conversation happened, you can enforce the contract in law.
This is the same in the USA and in the UK. But of course, it's much better to get a written contract before starting work (or moving home, if that's what it comes down to).
And (of course) it's much harder for an employee to enforce a contract against an employer than v.v. Contract litigation can be very expensive.
Most people summarize this as "you can be fired for no reason", because that's the most commonly discussed scenario. But, your employer doesn't have to terminate your employment to terminate your employment agreement.
http://www.ncsl.org/research/labor-and-employment/at-will-em...
> At-will also means that an employer can change the terms of the employment relationship with no notice and no consequences. For example, an employer can alter wages, terminate benefits, or reduce paid time off.
Now, they can't do this retroactively, but they can do it with zero notice.
http://www.shakelaw.com/blog/lying-on-your-resume/
Mostly it's just the risk that you'll be found out and fired (which is similar to the risk on the other side of the table— that the employee will find out and quit).
[1] http://www.legislation.gov.uk/ukpga/2006/35/pdfs/ukpga_20060...
[2] https://cdn.prospects.ac.uk/2.0.9/pdf/Graduate-Employment-Fr...
https://www.dailymail.co.uk/news/article-1260901/Woman-lied-...
Normally they probably get around with:
And any other duties, bla, bla, bla
So it's hard to see a shift in the onesidedness of the relationship
What about what they say on the interview? Verbal contracts are valid in some circumstances ... Record the interview ... :)
In principle but not magnitude, especially if you've relocated.
Usually you cancel any other pending offers once you've accepted a position if you're nice, and that could close some doors because someone else takes those jobs. Might even get you red-flagged if you go back to them and say "this company lied to me so I quit" (the other person has no way to verify that's true or you blew up on someone verbally the first week and got canned).
Someone correct me if HR can give the termination reason, I don't remember.
Asking a prospective employer what your references said about you if they pass on you sounds like a tall order. I'm lucky if I can even get a response to a cover letter + resume, definitely have never been given feedback about a sample project solution or interview (other than hired or not).
Am I wrong and it's actually one of the easier pieces of feedback to get?
Someone more left/anti-capitalist might argue that this is disproportionately in favor of the employer. The employee is depending on this job for food/shelter. Replacing the employee is much less disruptive to the employer than the employee. Especially considering the employee may have had to move to the area for that job.
It helps that places that are awful also usually can't imagine that you would want to leave. Good places, ironically, worry a lot more about employee satisfaction. Bad places typically believe that everyone is really worried that they might not get promoted/have a long career at company XYZ so are very weak at spotting employees that have checkedout. The stick they wave is usually "you won't get promoted next year if you don't play the game!"
Of course this depends a lot on how much energy the job drains from you, but if you can still learn some stuff during the day and don't feel drained when you go home, a year is not such a bad sentence to serve for a nice bump to your savings... just don't make a career out of it.
Exactly what I came here to say, albeit quite a bit softer.
Without having had the benefit of reading TFA yet, the problem is that you are never asking "the company" questions. You are asking your interviewer questions. Their answer, like all non-sociopaths, will be internally true or mostly true to themselves[+], but be colored.
The mitigation for this is that you have to ask every interviewer the same few questions.
[+] Read any book on how to suss out liars and you'll see that everyone who is not a sociopath, has many "tells" that they actually cannot resist. ie, normal people are uncomfortable with lying.
By the way, didn't you get that memo? mmyeah...
At my last job, I was told several lies (even during negotiations) that made the job sound far far better than it was. And this wasn't just from HR/recruitment. These were answers that I got from the many levels of upper management that I had to interview with.
I tried to reconcile those lies after settling in and having outstanding performance reviews. No dice. Ultimately ended up just leaving the company.
Lesson learned - Don't let them negotiate you into their range. Companies will lie to make their company sound like the shiniest, best place to work in the world.
But when talking to your future peers/team mates, I think you can expect a lot of honesty if you ask the right questions about how things really are.
I know I'm always 100% honest, because if they get hired, we'll be coworkers, and they'll know if I lied!!
PS It's weird that you didn't get the title in the contract
The most obvious one is usually “we’re on an agile process”, but there’s so many other ones more subtle and hard to get a grip on, short of reading interviewer’s clues when they answer the canned answer.
Sometimes the same words just don’t mean the same things to them. Sometimes they don’t realize how bad their situation is.
“Reality shock” in the first days at some workplaces is a thing.
1. Workspace/office not the one you were shown/told. This is the most common one, in my few data points. I think people know it's a factor in appeal of the job, so it's mentioned, but the followthrough doesn't always happen.
2. Person you interviewed with is leaving. (One of the people I hit it off really well with in interviews was a tech co-founder of the established company. When I arrive as a new Architect, he apologizes and says he had been looking forward to working with me (which is not something I normally hear), but he just got an offer for a supercomputer startup that he couldn't resist. Fortunately, some other great people remained, and I ended up working directly with one of the other tech founders. I supposed I might've been hired due to the company knowing that some people were looking to transition out.)
3. Job not as described. (I've mostly avoided this common pitfall, but once got bit by it. I was recruited as the Research Scientist who'd execute on an idea that was sorta outside the scope of two professors who'd come up with it, but that they wanted to see it done, and it was up my alley. But, subsequent to discussion, when I'd been told I'd be the sole person leading&doing, one of the professors' grad students decided to do the idea for their dissertation, and I didn't find out until the first day on the job. It got worse from there, but the saving grace was that an all-around great 3rd person was also an "assistant" on the team, so, morale-wise, I was able to complete the entire year-long appointment I'd agreed to. I declined when the PI renewed the appointment for another year, and both us assistants asked not to have our names on the papers. It was unfortunate, because we did some good work, and the PI was willing to help me get my own ideas funded, but I couldn't commit to another year of the accidentally-bait&switch project.)
4. Famous culture broken. (My anecdote wasn't a first-day reality shock for me, but first-year. A successful with-revenue early Web tech company in a university town had a locally well-known policy slogan about how you advance, which seemed much more widely quoted than the "don't be evil" of another company, and was repeated to me when I interviewed. Long story short, while I was working there as a Senior Engineer, someone in company leadership was willing to spoil culture and morale, to let someone's nephew (or similar) break the slogan. I went and talked with the head of engineering, who normally had amazing poise and charisma, but he had no good explanation for that one. This was when other dotcoms were hiring the then-rare experienced developers like crazy... but companies sometimes do things that employees don't understand, creating new reality shocks.)
5. Representative from new parent company, walking around with representative from offshoring company, talking to employees about what they do, for multiple days. A bit like in "Office Space", but at an advanced Web tech company. (Also, I was concerned when they started asking me about an elaborate 3D puzzle that someone had assembled near my workspace before I was hired, they seemed skeptical when I said I didn't know anything about it, and then one of them asked where they might buy such a 3D puzzle, which I happened to know, and I couldn't resist being knowledgeable/helpful, even as I suspected it was just a trick.)
Reality shocks like these are another reason I'd rather talk with prospective employers, and get as much sense of the team and company as I can, rather than get distracted with one-way leetcode whiteboarding.
At least you can put the title on your resume!
It's not even uncommon to be hired for one role and end up in another role for whatever reason.
Another thing is, policies change. Your interviewer could be grandfathered in and not know it (or know it, but don't mention it...). Or they could simply mention the last policy they remember, which isn't the current policy.
Some people also would rather just make up an answer rather than say "I don't know."
>It's weird that you didn't get the title in the contract
Job titles are not always correlated with job responsibilities. Hence we have "senior engineers" with a year experience. Title inflation is a real thing.
I've been lied to by every manager I've ended up working for. Too be fair, they've all been soft social questions, so I am partly to blame on that front. I've been terrible at identifying company culture until after I've taken the job.
> Where do you see yourself in 3 to 5 years?
I gave my typical response of technical lead, driving projects from the engineering side of things. His response was interesting.
> What would you think about not working here after 5 years?
The way they were able to run their shop was to use turn over to their advantage. They were custom software/hardware company that basically used as contract workers to make the widgets a company either has no time to make or doesn't know how to make. Their business model was to have you work on the project to the point where the contractor decides to hire you on full time to support the thing you helped make.
It was an interesting idea but showed they had no concept of stability for anyone besides upper management. Opted not to work there.
> and I was absolutely not going to be leading anything
This scenario has been basically my life for the past several jobs. Companies will lie just to get you in the door. Never ask "Will I ...", because the answer is always yes. NEVER trust what a company offers.
Got similarly cat-fished. Companies always conduct interviews in their best offices, not the ones you'll be working in.
You offer letter should have the title in there, what did that say?
Something I wish I asked during my last big interview: Do you have a project schedule? Can you show that to me?
If there is no schedule, or a very ambiguous one, that's a big red flag.