Interview questions to ask your interviewer(daveceddia.com) |
Interview questions to ask your interviewer(daveceddia.com) |
> Do you have a favorite part of the job? Least favorite?
When I asked the "least favorite" question in my interviews a few months ago, the answers all fell into 2 buckets:
1) it's a big company, harder to get things done (I have only worked at big co's, I already know it's hard... so this is not an insightful answer)
2) COVID makes life/work harder (I understand it's hard, but some of these people just use this excuse to avoid talking about their job/team)
Thanks to my questions I doged some bullets when I was on the other end. Trying to understand if the company is a good fit for you is as important as it is for them to check if you're a good candidate.
A surprisingly large number of SWEs are really bad at statistics, which is kinda necessary when you're asking whether a service is fast enough.
(You may get a usable number if all servers are more-or-less equivalent and events are randomly distributed, but then you're basically assuming the thing you want to validate.)
I'm not an expert but I know two correct ways: collect the records of all individual requests and compute 90% just once on the whole set (doable if there aren't too many requests - modern machines are quite powerful), or generate per-server histograms which can be merged safely.
1. How does budgeting work with your group? Who controls the budget they get?
2. How are priorities set on the team?
3. Who is the customer of your team, not your company but your team specifically is it sales, ops, finance, etc?
It comes from the idea that if you can discover the incentives you'll be able to deduce a lot more about the position.
> If there was anything you could change about <company>, whether or not it is in your control, what would it be?
It has been effective in getting an idea of some of the problems that might exist organizationally - it might not be the worst things, but there's always something.
I'm sure recruiters will say yes. Go ahead and ask anyone old enough to have interviewed people for a decade or two and see what they say.
The answer is no - just be good, be pleasant, be on time. That's all anyone's looking for.
> Who supports the product once it's released? Pager duty? Monitoring email?
and this
> Typical working hours? Flexibility? Crunch times?
In my experience it’s a huge mistake to leave such questions in its vague form as the author has shown in his post, especially if you’re living in a third world country like India where the managers and centre heads often project “getting engineers to work at any hour” as one of their USPs to their bosses, who are - very often - CEO and CTOs in USA and Europe where engineers cost more and often refuse to work absurd hours (rightly so).
Rather ask specific questions like:
- clearly state your intended normal working hours and ask whether there’ll be a problem with that.
- what is the on-call frequency (if there’s one)?
- what is the on-call hours going to be for you whenever that happens?
- Is there a follow the sun policy or not? (It’s a red flag if the product is used around one timezone and engineers mostly live in another, far from it)
- ask whether there’s any requirement to have an app like PagerDuty active for your phone number or needed to installed on your phone and would you be expected to be reachable also during other than your “normal working hours” and your “scheduled on call rotation” whenever that happens?
- The point above is very important - my last manager tried to soft bully/pressurise me into activating pager-duty for my personal number 24x7 saying “anyway the call will be at most 2-3 times a quarter” (and I knew he was probably right) and “others are doing it”. Luckily he was my hiring manager also and I had already discussed all this with him - I confronted him right then!
- ask clear questions about how often you’d be asked to attend “scheduled/recurring” calls out of your normal working hours.
You don’t have to be available 24x7. You must not - under any pretext! You are made to do that only because you end up saying “yes”.
If you can, ask this questions on email preferably to your hiring manager keeping recruiter in CC - at least I do that.
Out of 7 verbal offers I had said yes to (around a year ago) 1 company demurred from issuing the final offer letter after these questions, others were very open and candid about it and didn’t mind at all (at least in the mail).
Goldman Sachs clearly mentioned I’ll be required to be ready whenever needed, others were reasonable, Cisco was semi reasonable but seemed skittish to me, Uber flat out lied which I later found out (and hence I left within a month).
"When you think about the person in this role doing really outstanding work in the future, say, one and five years from now, what does that look like to you?"
"What if after a 1.5 yr or two I get bored, burned out and I will want to switch teams / departments / ...?"
Why should one not work at your company?
Most interviewers are unprepared for this question and will give surprising honest answers.
Ah, HN, where "interview" always means "job interview" and "dependency stack" always means "for your web project".
1) My immediate manager was dressed in incredibly expensive clothing in the interview, 2) He said we didn't need Linux, we could afford to use Mac.
Barf
"Do you see this watch? Genuine rollex. Do you know what it feels like to own one? Probably not, because you don't work for me yet, so you can't afford one".
How do you manage employee performance evaluations?
How do you manage career growth?
What do you do for fun after work?
This is nice as a casual social question, but it isn’t related to the job and shouldn’t be relevant. If your goal is to understand if all they do is work, asking about working hours is more to the point.
> "Every company gets criticized. What's a piece of criticism your company has received that you felt wasn't really accurate? What about the opposite- any criticism that you agreed with?"
> "Does your company have any policy that enforces a specific minimum number of people let go per time period? IE: Stack ranking, 'Unregretted rate of attrition (URA)', etc"
> "What are the company's non-compete rules? If I wanted to make and sell an app in my spare time, is that allowed? What isn't allowed?"
> "How does promotion and career growth work? If hired, what steps would I need to take to get my next promotion? What holds people back in those situations?"
I got great answers though. I learned a lot about the companies because I asked these to a number of people at each company. Those answers lead me to pick a company that was offering less money, but was a better place for me to be.
I would not be surprised at all if the people interviewing me gave a nice answer and then on day one I'm asked to sign a contract that doesn't match what they said.
Ask if you can see the employment contract before accepting an offer.
Let’s look at it from a different angle. One does not file a resignation before receiving a countersigned copy from the company.
I'm a bit puzzled by this answer. What's wrong with:
"I read the contract and I don't like the terms sorry"
The developers have no reason to bullshit me. And they didn't.
This one's mathematically interesting. Orgs are generally shaped in a way that literally most people can't "get a next promotion" after a certain point.
Something like "what do I need to do to ensure a good review and good compensation adjustments" would at least work better hold up better in managerial roles where "the next promotion" is possibly the job held by the person interviewing you. :)
This one 'what steps would I need to take to get my next promotion?' - this is probably not the right way to ask the question.
The implication is that 'promotion' is kind of like progress you'd see in school, i.e. you get to stage 1, then 2 then 3 with increasing responsibility, experience and comp.
But reality is not like that, the company is interested in creating products, services, making money, and almost all organisations are pyramids in terms of operational structure.
This means that 'promotion' beyond just the lowest levels inherently competitive. Obviously it's political and nobody likes that part, but the reality is 'to get promoted to manager you need to be better than 80% of your peers and to director better than 98% of your peers' and what 'better' means is very subjective, and notably, not everyone gets promoted.
Also, instead of asking about the 'benefit to you' i.e. 'promotion' you might want to put it in terms of the value you can provide, and soften the question a bit by asking about 'career progress' etc. and avoiding the word 'promotion'.
It's a fair thing to ask about, but it's delicate.
In large organizations, typically, promotions come from proving you are working at a given level. It's not a competition at all.
Promotion also doesn't mean "becoming the manager"- I mean promotion to a higher level as an individual contributor. Junior Dev, Senior Dev, Staff Dev, etc.
And the question was very well received when I asked it.
Am I allowed to have side projects that I own?
Am I allowed to contribute to open source from work? ie bugfixes for libraries we use.
How many meetings are there in an average month?
Does your insurance cover my preferred doctors? (obviously more of an email question)
How strict are the requirements in whatever tracking software we use (jira,rally, etc)
How many required programs are there? Outlook? Slack? Teams? Jira? Timesheets? Confluence? sharepoint? skype? etc
How locked down are the computers/network?
Am I able to use whatever development tools I choose without asking permission?
Why did the person before me leave?
Also, the likelihood that a candidate will be informed of any non-public plans to sell the company are slim...
One thing I'd add -- don't be afraid to ask the company recruiter questions too. They should know about the training/conference budget, dress code, etc. That'll make better use of your Q&A time with the hiring manager.
Here's the full list - https://gist.github.com/autarch/6e7e25e85db62a359f91aa090033...
There's a few that are very specific to my future travel plans and my height, but the vast majority are potentially useful for everyone.
Note that my goal is to _get answers to these questions during the interview process_. I do not expect to sit there and ask _all of them_ in a single interview. In my experience, quite a bit of this comes about naturally. For example, I'll often find out about their dev process, tech stack, tools, and so on from the technical questions they ask me, and the conversations those questions lead to.
But my goal would be to have satisfying answers to all of these by the time I'm making my decisions about whether to accept an offer.
That piqued my interest enough to look through your questions. They are all great, but I didn't find anything related to height and can't think of any I would personally ask. (Ergonomics? Business class travel?)
> How is work travel handled? Will it be an issue if I want a somewhat more expensive seat for legroom?
I'm 6'7" (200cm), so flying in a regular economy seat is horrible for me. I want to make sure the employer won't balk at me paying extra for an exit row or premium economy seat.
Very informative. A lot of people did not have pat answers, and had to search their souls a little bit. I got different answers from everybody, but the same broad themes, and I interpreted that as meaning everybody was on board for the vision, but that there wasn't much top-down direction on how to get there. To me that was a plus, and it turned out to be the case.
It also gave me an idea of what I'd be hired to work on, and what I'd be working on after that. I recommend this question!
It also makes them feel like they are already working with you because that's what a good employee does when a manager gives him work: he asks questions about it throughout the process. He doesn't wait until the end when the manager says, do you have any questions?
Feel free to check them out. They also include questions to ask the recruiter. I hope they can be of use.
The only real questions to ask imo are:
1. How is performance/promos determined?
2. How are peoples interpersonal skills in other teams?
In the first question, look out for cues regarding inefficiencies or resentment about the performance process.
In the second one, the interviewer can discuss whether people are cooperative or assholes without being too specific about their own team dynamics.
That’s pretty much all you can expect a random employee in a company to be able to provide accurate information about.
The questions about wfh policy and org structure are best left to the recruiter.
The other questions about learning opportunities, flexibility of roles, working hours and how people get along are just going to be met with drivel about how the company is the best place to work at on all these categories.
E.g. I always ask about working hours, their flexibility and make sure the counterparty understands well I don't crunch or overtime unless on rarest occasions. Because those are the things that matter to me.
The other questions I stated give you information about more than just the immediate environment of the interviewer.
If those aren’t questions you care about, that’s fine. Though I find it impossible to believe you don’t care about the way your performance is measured or whether you will be working in a hostile environment. If you care more about the flexibility of your working hours than that, more power to you.
For example, it's common for a senior manager to say something like:
"We value input from all of our employees, ideas can come from anyplace"
For this just follow up with a sincere:
"That's something I really value too, can you give me an example of when someone who was not in a leadership role proposed a solution that influenced a major decision?"
I've found this surprisingly effective at finding out which values are real and which are bullshit. When it's real, you'll get answers like "certainly, why just last quarter Jen in customer support noticed..." and when it's BS you can immediately tell because the interviewer will freeze completely.
One thing though is that most interviewers don't leave a whole lot of room for a barrage of questions so you really need to pick the two or three that you really want the answers to. For example, you probably don't want to waste time asking explicitly about version control at a company that you know does open source on github. Open ended questions about engineering culture will give you a much better picture (e.g. what's the story w/ tests or deployments or design autonomy or whatever).
Or, what you can do in addition is ask the recruiter (or whoever the first point of contact is) if you could spend 30 mins to talk to someone on the team, outside of the interview window, just to have a casual chat. Some companies have this arrangement setup as an official transparency program, others are more than happy to arrange it informally.
As a hiring manager, I'm usually one of the first people new candidates speak with (perhaps right after briefly talking to a recruiter). Generally, I want to make sure candidates have all this information within the first interview or two. These days, I tend to open my interview with an opportunity for the candidate to ask any questions about the role and company that weren't answered by the recruiter.
I also try to leave time at the end, but I find that there's often so little time at the end, that it's better to start with any questions.
Some folks are surprised by this and I often have to help them along, but that's cool -- it is a bit different.
Don't burn your time with filler. Instead, make yourself stand out in the last moments:
The questions should be softball, but detailed and enjoyable for the interviewer to answer. Allow them to paint the role and company positively. i.e. don't dig into Google's stance on user privacy.
Use questions to show your enthusiasm-- that you're here for this job and not a job.
You should do research on the company and interviewer before the session. What they are involved in? (languages, concepts, methodologies). Usually blogposts, GitHub and LinkedIn content is useful.
Try to impress the interviewer with your knowledge about said role, company, or relevant topic. Mention a change or new beta product you've been testing. Ask for their thoughts on something you know they like to talk about.
Examples:
Does google have plans to expand the usage of Go in their cloud stack?
What benefits were there after switching from Borg to Kubernetes?
How do people get new ideas get onto the Pub/Sub team's radar when they are busy shipping features at breakneck speed?
How did the team architect the new protobuf API while maintaining compatibility with the old one?
1. What - from all the things you have accomplished while working here so far - are you most proud of?
2. What did they do for the last social outing?
(Look for their face reaction as they answer the two questions. If they look surprised, or don't have a good answer, you may want to look elsewhere.)
And, if not already covered in the interview (which they really should):
- How technical is the CTO? Can/does s/he program? Ph.D. Degree?
- Who (name and function) does the group (my boss' boss) report to?
- What does the company do for training its people? Is there an annual budget?
- What is the attrition rate in the team?
- What is the career path anticipated for the role under discussion?
- How technical is the CEO? Can/does s/he program? Ph.D. Degree? If the answer is anything yes to the former it bumps up by ~10% the salary expectations (12% if she's a music major).
- Who (name and function) does the group (my boss' boss) report to?
- How's internal accounting structured: is this division a profit center or a cost center (if cost center, bump up amount by 25%)
- What's the philosophy behind compensation? Somewhere serious will use a stock based comp. If they don't, or tell you it's not in the local customs, maybe they would be more comfortable with your consulting rates.
The rest (how they raised money) you should already have a pretty good idea before walking through the door (pitchbook is your friend or just ask around). Free drinks and admin rights on workstations are a given, of course, for any serious offer.
To better understand the attrition rate:
- Who is the team made up of - internal transfers or external hires?
- How long have the current team members been on the team?
- When was the last time someone on the team was promoted?
Delving into career trajectory and your questions about training:
- What does the path look like in 3, 5, 7 years for this role?
- What leadership opportunities does this role lead to?
- Will my professional goals be linked to the company's goals?
https://github.com/lkostrowski/job-interview-questions-to-as... https://github.com/viraptor/reverse-interview
1. How has the company changed in the past five years? How do you think it will change in the next five?
2. What was the biggest surprise about working here?
I like these because they force the interviewer to activate their brain a bit and really highlight differences over time and differences from expectation. The surprise question especially helps you figure out unknown-unknowns as a candidate.
I've asked a couple questions the past few interviews when looking for a job:
- What do like about working here.
- What could be better, or what are the pain points of working here.
They're been pretty honest about those things.
I suggest doing it anyway. I think I've learned more from failed interviews than I have from some jobs. Useful lessons anyway.
Yes of course, I'm not going to stop trying. Though my hopes of clearing the interview just hit 0%. I'll keep doing all preparations I can nevertheless
* What's your favorite thing that you've accomplished so far in your current role?
* What's a recent challenge that you personally faced? What challenges are you/your team/division/company/industry facing in the next few years?
* How does your team make big decisions (the article goes into this a bit, but I think it can be helpful to be explicit about whether engineering/PM/sales are on the same page)
* What time did you start work today? (Corollary to "what's a typical day like?", and a good segue to culture type questions)
- Can you give me an example of when a project took a major turn in another direction, and what was the cause of this change?
- (if applicable) How many heads is this role expected to support?
- What was the team's last achievement recognised by the whole company?
- When was the last time the team performed a disaster recovery exercise?
- Can you explain the process of "idea to feature retirement" starting with the request from the product owner?
I've got hundreds of questions from interviews over the years.I would also note that premium economy is usually 30-60% more than an economy seat. Typically this amounts to maybe $150-300 per trip, so I'm not asking for a huge amount of money here!
It's absolutely a competition. The thresholds for promotion resonate around capabilities designed at certain thresholds. The organization is a pyramid, they are not going to just promote everyone along a tract, even if it's not managerial.
And, very few companies have seriously well developed tracts for technical staff. There are 'bands' within every company surely, but most of the world is not like the FAANGS in this regard.
Your contract specifies that and other answers to other questions. Don't ask your interviewer this question, the only thing he/she can do is rely to HR. Best ask HR directly.
> Why did the person before me leave?
It is unlikely you are ever going to get answer to that and even if you get it, it will have low value.
First, there does not necessarily exist a link between your position and the person before you. If you are a developer then it is more like a pool with new developers replenishing losses over time.
Second, a lot of people do not really know why they leave.
Third, even if they do know, they do not give truthful answer. They might be saying something like "I needed a change", or they might be rationalising it in some way, where in fact they just got a better offer from FB.
Fourth, as an interviewer you might not be privvy to that information officially.
Fifth, even if, by accident you got to know this information privately, I still don't feel ok passing private information especially one that can be basically gossip.
As far as the person im replacing, that's more of a poker move to feel out if there is a toxic boss driving people away. Perhaps a better way to do that would be to ask about the turnover rate for the team/department/company?
These days half the job is convincing the candidate to accept an offer if it comes through.
Am I able to use Linux?
This tells you a lot about the company. I avoided some Windows-only jobs in the past :)
Since then, whenever I shifted teams, I'd pick ones where I don't have to use Linux. At least I can customize my Windows laptop easily, and Emacs works just fine on it.
My startup is mostly Windows, but that's because we're doing AAA game development and still have some tooling that is Windows only at this stage.
I find that with WSL2, I can do everything I need. A fair bit of my day is spent in emacs.
I'd take a job that let me use Linux, but I too am a Mac guy at heart. I had a short stint on Windows not long ago and hated it. Where I work now they'll give developers Macs by default, though getting blanket approval for data scientists has been an uphill battle, stupidly enough.
I got there eventually. It's one of those things you don't expect, having worked with smart and flexible software people your entire previous work life. These hardware people were smart, but also incredibly "square", for the lack of a better term. Everything was so insanely rigid.
So much more to tell, but in general: be aware that hardware company culture is very, very different. I don't think it's possible to change the culture unless you change the CEO.
I feel I really dodged a bullet there! Thank you, anonymous recruiter for being unusually candid in post-interview feedback!
They just lied to me. That was a painful year.
To continue working at a company, you are usually expected to sign every piece of paper that they put in front of you throughout your tenure. If you don't, the consequences could range from absolutely nothing, to being pestered every six months, to being kept off a project or not promoted, to being fired.
If at some point you become popular or are seen as critical, you may be able to spend some of your political capital to get around signing some of the papers that you don't particularly want to sign, but this doesn't always work, and you can't always get away with this indefinitely.
An amendment to your offer of employment that tries to prevent you from moonlighting could come after your first day, or after your third month. They get to choose the timing, and the more unscrupulous will absolutely use this to their advantage. They won't give it to you after the first day or week, so you don't just walk -- they'll wait until you've settled in and are more likely to concede in frustration.
It seems like the better question is: are there other documents than this contract on which this job depends to sign and can I see them. If yes, can you please put this in the contract.
If you've signed a complete contract already, and there are new things to sign, they're asking you to agree to a new contract. Which you don't have to agree to, and if you don't, then anything you've already signed is still in effect. To get rid of you after that they have to resort to the termination provisions in the original contract. Of course "refusing to agree to corporate policy" is typically something that they can terminate you for. So a big part of the law dictating how much they can make you sign later is found in termination provisions. If your original contract's termination clauses are written so broadly that they could fire you easily for refusing to agree to a new contract that essentially rewrites the old one, then there are things you should see a lawyer about before touching it. (This is a much bigger deal than policy changes. I'm talking "no we actually have 10 more onerous pre-conditions to exercising stock options that we hid from you, such that you will find it almost impossible to do. sign here".) Large swaths of contract law are devoted to invalidating terms that say versions of "I can dictate the terms".
So my guess is that the horror stories were not supported by the original contract using likely-invalid language, but rather purely on the threat of messing up someone's new job. Especially if you're e.g. moving for a job, your goal is to sniff this out before you sign. So insist on full pre-signing transparency, get assurances that there are no other documents that are considered mandatory, and watch the responses carefully.
You could also being a contract of your own for them to sign. They won't, of course, but it can help drive home the point why you need time to look at the contract.
Story here not too long ago of a Google employee being let go on his first day because he did exactly what you're suggesting. I'm sure my company would do the same. When you hire over a thousand people a year (let alone thousands), they're not going to modify their efficient procedures for you. It's cheaper to hire another person.
I'm sure they'll let you take the contract home, but your only option really is to quit.
Corollary: continuing employment may depend on adherence to policies you don't control, regardless of prior agreement.
Not all law is contract law, and this remains true of employment law.
Like I was going to sign, give notice at my current job, and if they're not happy I simply don't have a job.
I nope'd out of that process. Their HR was a mess.
If you don't ask to see the contract, it will almost certainly be a day one surprise. And even if you do ask, the legal department, who neither you nor the people interviewing you frequently communicate with, might still have some surprises in store.
How do you avoid this? It's a particular kind of institutional trickery that may not even be intentional but is very frustrating.
So there is some room for negotiation, although some things aren't negotiable for them. I've often had a non-compete clause of some sort in my contract, and I've always been able to get its scope reduced, but mever been able to get it dropped entirely. But if you ask up front about it, it's also to their benefit to be honest about it, because hiring you and then having you quit at the last moment because of their lie is not good for them either
The other option is to get the contract signed, or at least seen, before you quit your previous job. If it's a job for which you need to move and dramatically change your life, then you should definitely get some hard commitments from them before you do anything drastic.
Then I got radio silence, could see all the checks passed on their end. Didn't end up signing, kept my current job.
Glad I refused. I don't want to work for any company that tries this bullshit.
However I doubt it's easy to see a contract before signing offer.
Every company will negotiate the contract with you and they will frequently be happy to negotiate other things than just your bare salary. There might be things that you care more than others and the company will be happy to provide you with.
A lot of people treat the contract as a formality. Don't. The contract is there for you to feel safe and for the company to get what they need, too. This is the actual agreement between you, everything you had before should lead to writing down what you figured out in form of a contract.
As to asking for reasons of previous person leaving, I think turnover rate is definitely better question. One that can be followed with an actual discussion about the reasons for this or the actions that are being implemented, etc.
Actually, maybe the question I really want to ask is Can everyone have side projects?
They lied about that too.
I personally believe manager should be hiring their team. If only for the candidate to meet the manager and have a chance to make their decision based on the fit.
But I also was many times asked to stand in for another person. Maybe the manager was very busy and he trusted me I can do good job?
In any case, if you go for a large company and for a long haul it is likely you are going to be changing managers (but still it is good to get to know the first one).
Windows = managed, user account, pain (sometimes exceptions for developers, sometimes not)
Linux = you have root on your machine.
I can't make deep changes (e.g. reinstall the OS), and would likely get in trouble for disabling the antivirus, but there hasn't been anything I wanted to do on it that I couldn't.
May I ask why you're grateful? I'm pretty inexperienced with Docker/Kubernetes/containers in general. So there's probably a good reason I'm unaware of.
Docker Desktop was nice for me to run the one or two basic things I needed. I've moved away due to the licensing changes, but I'd like to understand why it was a problem.
People raising bugs against "production" wouldn't tell you that they found it their Macbook so you'd go on a wild goose chase thinking it was a real issue and not simply MacOS sucking.
Alternately, you'd write a script to do something (flash hardware, etc) and it wouldn't work because Certified Real UNIX(tm) doesn't have /proc or /sys. Now you're asked to port the script to Mac, which depending on the task might be wildly more difficult, but if you don't willingly bash your head against Apple's hatred for low level hacking, you're not a team player or something.
That day I changed my stance "there are no wrong answers", but I've also asked this in the past and it can yield some good conversation material.
I was hoping you were going to follow that up by saying you're working on a robot to clean vertical glass.
There was only one corporate laptop running windows 10 I've encountered during the pandemic that does not use policy to disable automatic updates and that is Microsoft. In my experience, everyone who pays for Windows Enterprise blocks automatic updates.
I think Windows Home still can't into Hyper-V and therefore you have to go through hoops to install WSL 2 and docker, right?
VSCode can run from WSL2 and have access to its file system
So there are many companies and many projects and i don't work with any Microsoft technology, for me it makes sense to just dodge any company that doesn't allow me any kind of Linux on daily driver, it's just that for me it makes sense, it's not a huge effort, it's not a huge sacrifice, it would be a sacrifice accepting a job with windows/mac when there are many more on linux
And yes you can move on, but you're still in an unnecessary position (looking for work while not employed) through no fault of your own.
Handle it before you leave your old job, then. Do what works best for you.
I have negotiated contracts while already working, and that has worked fine for me. If they back out, I'll find something else. At some point you may notice they won't move any further, and then you've got a choice to make. If this is just another job and there are plenty like it, you quit. If it's a unique opportunity, you suck it up and sign.
But the point remains that you should never sign a contract on the spot. Unless it's really something super standard, negotiated by your union, or otherwise something that you really can't get around. But in every other circumstance, you always have options open. Never forget that.
I'm not disagreeing with you. Set your boundaries. Just be aware that this will preclude you from working in many big companies.
And even with such an agreement, they might still ask you to sign something on day one. If you don't sign it, they may very well decided to "terminate the agreement" on day one.
Wsl is pretty terrible in my experience. your better off using a vm you manage yourself. Every vendor has shared folders. Each one can use a x server to display programs in your windows window manager.
My main personal notebook is a windows device w/WSL and my main work notebook is a MacOS device, because at the end of the day, I need my computer's to just work, painlessly.
WSL is great for alot of Linux userspace stuff and is a fantastic CLI for interacting with and managing remote servers, alongside the ease of Windows. Of course it's not as performance, and had some edges, but I happily accept the trade-offs due to great driver support and the flexibility to run almost any software on one device.
I use WSL everyday and it’s no different than using native Linux. What’s so terrible? It’s easy to setup and easy to add to windows terminal.
Vscode renders sharply without having to do extra work.
Both wsls are reasonably enjoyable. Much better than ssh-ing to a Linux host
Edit: Thinking about it some more, I believe I was able to get WSL1 to work but not WSL2, unfortunately.
It is most definitely not just like regular Linux.
I actually used it pretty extensively for years before I figured out it was causing more friction than it was worth. It's convenient, I'll give you that, but again, it's objectively worse than the other tools available. You should try them.
Your right about it being a tool. A tool which has better alternatives.
A virtual machine running in virtual box or some other vendor's VM has literally none of the limitations that wsl2 does.
WSL 2 Doesn't fully support all userspace stuff, I bump into that all the time.
You can ssh into other boxes using PowerShell.
It is objectively bad compared to the alternatives.
The same goes for programming languages and engineering problems. I train my team to identify multiple possible solutions to a problem then identify pros and cons and then pick the solution that optimizes for the most important goal. There is rarely a "right" solution.
Software dev is not in a design space where all things are broadly equivalent with small pros and cons to choose between. It's more a discontinuous surface with orders of magnitude of cost/benefit changes as one meanders over a given cliff.
I don't think vs code is running inside the wsl environment directly.
Opening vscode in windows and opening the Linux vm's file through the "filesystem"(it's a network share) is unstable. You really have to open vscode in Linux, or run it in windows and ssh into the virtual machine for it to work well.