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.
I often get some very candid feedback, and have passed on couple roles because of what I've heard.
What sorts of signals do you look for in these answers?
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.
"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.
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.
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.
Bonus is if you reach out to former employees on LinkedIn and ask what it’s like to work there.
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?"
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.
An aside, I say the above now, but damn, I wish I'd had understood it 10 years ago.
This will help you determine if projects are mismanaged, how stable their prod environment is...etc
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.
Obviously, it's up to management if they want this to be a part of the interview.
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.
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.
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.
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...
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.
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 ;-)
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.)
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.
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.
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 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.
I'm happy to be adding a few more questions to my list now :)
Most I've had in EU was 3 rounds.
3 technical+personal then offer
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 tempted to say that the questions they ask carry more weight for the final result than the ones that I did.
"How long has this position been open?"
is useful to subsequently ask
"so why is this offer letter expiring in 48 hours?"
Back in the beginning of that time period, I used to ask (fairly jokingly) the same question: "How many servers do you have?" I would use the response to gauge the interviewer, and mostly just for fun.
Of the dozens of Google interviewers I've spoken to over the years, only one responded with a number range, and the rest of the responses were largely grouped into either active playful discomfort.
In my last two rounds of interviews (with various companies, including Google), I asked three questions:
1. What brought you here?
2. What keeps you here?
3. What keeps you up at night?
The responses to those three have been illuminating.
That's because most employees don't know, and the ones who do, know that it's a company secret.
Please do share.
Either that or someone else is going around with your questions.
As to the specific responses, I'd have to check my old notes, which I don't have handy at the moment. For "tier 1" companies, such as Google, common responses to "What brought you here" and "Why do you stay" are excellent comp, being able to work with many very talented people, and the ability to move around in the org.
I've found the "what keeps you up at night" question has the most diverse responses.
In general, I've been pretty surprised at the amount of apparent honesty I get. It's hard to verify the responses, of course, but any time I get a response that's not completely positive or 'canned' in some way, it seems pretty legit.
> In general, I've been pretty surprised at the amount of apparent honesty I get. It's hard to verify the responses, of course, but any time I get a response that's not completely positive or 'canned' in some way, it seems pretty legit.
Could you please give a few high-level examples?
He said there were cases where the pipeline had effectively failed early, but continued to run throughout most of the normal run period. If they had some in-pipeline monitoring, they could have intervened earlier and helped it succeed.
Reading commentary on the HN links I read during the day
Instead of: Are you friendly to remote work?
Ask: Will I be working with anyone who is remote, or who works from home on a regular basis?
Instead of: Is the work life balance good?
Ask: How responsive are people to emails/Slack over the weekends and after 6pm?
Instead of: Can I have a good career path?
Ask: Did any of your senior engineers start out as junior engineers here?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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!
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.
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.
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'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
> 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.
Why not? That's a prevailing opinion.
SWE: Works for a startup.
SWE: Works for FAANG.
SWE: Works in an industry that's not related to the web.
HN: Wait, what? I don't understand.
SWE: Works anywhere else.
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.
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.
(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)
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?
How long ago did you give raises?
How long before that was the last time you gave raises?
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.
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.
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.
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.
At least you can put the title on your resume!
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.
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).
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?
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 ... :)
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.
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.
> 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.
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.
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.
> 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.
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.
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.
You offer letter should have the title in there, what did that say?
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.
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.
By the way, didn't you get that memo? mmyeah...