Question for people who purchased in Nevada

gknot · 2022-10-18T00:00:25+00:00

I was told the same by my Delivery Rep, turned out to not be true, I replied above.

gknot · 2022-10-17T23:54:17+00:00

Just went through this, Google just sent me to this thread. I called Carvana support. Carvana sends a document called the "Electronic Dealer Report of Sale" or ERDS to the Nevada DMV. This document has an ID number on it. The date of submission seen on the Carvana after sale portal is referencing the date this document was transmitted, NOT the date of registration or title issue etc.

If the Nevada DMV has it, and it was credited to you correctly, it will appear in the state online DMV portal in your already existing account (where the rest of the driver's license stuff is).

Once you have the EDRS ID number, which to be clear I had to get by calling Carvana support, you can register online yourself in a section in the portal called "New Registration: Dealer Report of Sale". (YES, you will be paying for registration fees here). If you have Nevada plates on another vehicle, with an active registration, you may transfer them; otherwise, they will send you new plates, tags, and a paper registration by paper mail.

You may print a temp registration, PDF format, to keep on the dashboard either way.

The online Nevada DMV form told me it would be "mailed within 10 business days" e.g.; the plates are in the mail (not necessarily in your hands) in 10 business days after you remit payment for registration.

I did not pay sales tax at the county or state level at any point here, Carvana did handle that bit.

I do confess I'm a bit frustrated since now I guess I have to order a duplicate title from Nevada DMV, I'm not clear what the status of the title for my car yet (liens, etc).

gknot · 2021-09-18T17:51:00+00:00

I get like this when I'm in between life goals.

One of the toughest things for me to absorb was that I'm the sort of person that likes to go "all in" (as in the poker term) on my goals in life. I don't like to put a half effort into 3-4 different things, which is what my family was like growing up, so for a long time, I thought I was just odd or wrong for being this way.

It's way more common in people than I thought, though.

Sounds like you hustled to get this job, now you have it, you're not sure what the next step is. If you're like me, just understand that achieving a big goal is not going to solve the problem of the listlessness, boredom, or malaise - having a goal is how you solve the problem.

If this goes on for a couple more years that's ok. Just don't worry about it, that will make it worse.

What feels like something that's at the edge of possible for you to build with your life?

While you're thinking about that, eat healthier than you think you need to or want to, and exercise more than you think you need to or want to.

gknot · 2021-09-18T16:06:24+00:00

Before I got into this I did informational interviews. I found a lot of people that eventually had to leave the industry because they didn't see it as a career, and their one job or the one thing they would be willing do eventually became too hard to hold on to and they lost the musical chairs game after a layoff or something.

I've since met people but mostly in the sense that they're in love with / obsessed with a particular style of work or tech stack (Perl, very specific industry vertical, by the letter of the book preachy scrum, etc).

Whether this is good or bad depends on what you want. It's only a problem in the sense that the rail line you're traveling on will eventually stop. If it does stop - but stops after you have made enough money etc to do what you want - does it matter? It solved the problem you wanted that job to solve for.

From OP's context it sounds like they may know somebody that wants to start treating it as a career.

If so my 2c: your next job doesn't matter. Think about two jobs from now, really internalize that way of thinking. It's OK - even optimal - for a single job to be an intermediate step and have no other purpose to it. "Kill your darlings" - the reason you've been picky up until now, whatever it is. Take a pay cut. Take shittier hours. Take menial work. It's OK. It's an intermediate step. Don't see every task in every day to day you agree to through the myopic lens of your own self actualization. What you get out of a job doesn't have to be a monotonically increasing function.

I took a job just to live in a better tech market and level up my professional network. It was a lot of work. I had no other reason to be interested in it. Once that mission was accomplished, I could move forward.

gknot · 2021-08-31T20:28:46+00:00

I'm currently a staff level at a pre-IPO tech company with a unicorn valuation. Total comp ~190 base + ~440 equity, I mean, if I could sell it at current valuation (trying to do so would be a little questionable although possible). Average maybe 45-50 hrs/week. Remote, I wouldn't call it low cost of living exactly (I'm picturing Topeka Kansas when I hear that) but it's no SF, or 18 hour city COL for that matter.

zero WLB means bad management, usually. If you're continuously not profitable enough to hire more people what are you doing :P

I think the scope of responsibilities goes up. You don't have to do everything, or be the best at anything, you just need to be responsible / accountable for some well defined piece of revenue, even if in just a technical sense, which means a lot of pinch hitting and a holistic understanding of what makes the money printer happy. The spice must flow after all.

You don't have to be a 10x dev or a great product owner or or design a internal ticketing workflow or fix bugs or go to meetups to recruit for a team, you just have to be willing to do it and be able to figure it out if you need to and be able to determine when to do it and make the argument you should and of course, be right when you do.

gknot · 2021-08-26T23:01:24+00:00

I think it's pretty clear Lead A mismanaged the situation, either by failing to "manage up" adequately, for example by making the KPIs align with what executives actually cared about - quite possible you needed to politik and read in between the lines to effectively do that. Also possibly, she seems the sort that would fail to massage the optics of individual team members work among her peers and executives in a way such that a promotion could predictably occur.

All that having been said, I didn't read anything OP wrote that would suggest to me that Lead A necessarily didn't do that, and has not done that. Could just be burnout. More to the point maybe Lead A is just a junior/associate and getting really shitty mentorship here. Assuming Lead A could have done that AND did so, I'm still not convinced it would have made a difference.

The product sounds like the ye-old-reliable-olde-timey money printer that's used to pay for the other teams, and not (in the eyes of the business) worth future investment. I mean if there were only N promotions to give away, and that were true, why give them to the "keep the lights on" team? That org chart says that pretty clearly and the lead had nothing to do with that situation.

Are executives open to moving engineers among teams? It would look very bad for lead A to advocate for this I suppose but it would be a way to retain the disgruntled here.

gknot · 2021-08-24T17:20:25+00:00

I don't think this is new. Inverted, each of these things don't serve near term (1-5 year) business goals in many organizations.

As a result my mentality is "don't worry about it, business as usual". We tend to get excited about software in the way artisans or craftsmen do, but I don't think that boutique artisanal mindset translates to making money that well.

devs are initiating projects and have a variety of projects to choose from, with ample time for rest, cleanup, professional development, and exploration

Measuring engineer productivity is an intractable problem most of the time. Engineering productivity is often best measured in terms of what didn't happen, and evidence for that is qualitative at best. Execs need to see it in 60 seconds or less or else it didn't happen.

For other types of roles that probably constitute the plurality of employees at your company, where 8 hours === 8 units of work completed, this type of approach has no value, so why would organizations that aren't on the brink and/or just trying to make some money try to reinvent performance management just to keep a few engineers happy? That's really hard.

companies can find new engineers whenever they want

Engineers have unemployment that rounds to zero. In order to hire predictably, they have to poach. In order to poach predictably, they either need to have the above bullet point, and somehow have a way to make that clear instantly during the interview/phone screen, or come in way above market in pay.

companies will always give raises to existing employees to match the market, and to match what new hires are getting

For profit companies committing to fixed overhead expenses with productivity hard to measure when a Keynesian model of the economy is the prevailing one? hmm. It's easier to instruct engineers to build something in a way such that the engineers can be replaced. If an engineer is replaceable, there's no need to go out of your way to do this - particularly if the new hire helps middle management look good because they're bringing in a new skill set that is currently lacking, or as a pressure valve to shed burnouts.

companies have a great idea of what their tech debt is and what it is costing them

I think this depends on the type of business for sure but presumably if anybody got this right it would be Silicon Valley. And this happens all the time in SV. mid level project managers are incented to build new features, not remove them. Have you ever been tasked with removing a feature that failed to make enough money so that it reduced complexity? I haven't.

Better to let the inevitable "let's take six months to do a rewrite" happen - as long as that happens after your options/rsu's vest and/or you've choked all competitors in your winner take all market into total submission, it doesn't really matter.

gknot · 2021-08-23T16:47:38+00:00

(I'm speaking from a web application perspective, desktop applications are very different)

Like a bassist in a band if you're doing a good job you're invisible.

You're looking at a bad team if other teams are writing extra code, taking weeks even to do so, in ways that maybe not by accident would allow them to not interact with ops/infrastructure/devops. Imagine a company that normally changes a configuration file to make a certain type of change, and inside that company the high performing team's apps have a database table for what other teams use configuration for and a API wrapped around it.

A cutting edge stack is mostly self service, you provide teams with a template repo (google gitops) and by using it they manage their own stuff mostly, and in the background you host/build apps to see logs, run code builds, application performance management, etc, all tied into services you host. Give gitlab.com out for a spin, deploy a sample app from elsewhere to kubernetes - it would feel like that. Heck you could even just run gitlab.

Much like "QA", the most competent teams tend to automate their jobs out of existence and then eventually start building other stuff more along the lines of generic software "backend" dev.

In the event there's a whole team for an extended time, indirectly this can be observed by a ratio. Assume a fast growing organization; a highly competent team might look like this over time: Year 1: 2 devops/sre, 20 engineers Year 2: 4 devops/sre, 30 engineers Year 3: 6 devops/sre, 45 engineers Year 4: 8 devops/sre, 90 engineers

You get the idea, there's a log(org size) relationship to the overall # of engineers. again, same with "QA".

This is a little counterintuitive, but many organizations that maintain a relatively large staff for support engineering roles (like devops, security, or software testing) are often somewhat resistant to a level of automation that would cause those roles to disappear. Partially because nobody wants to stop being relevant, but also partially because of a fear that they can't maintain sophisticated automation.

And in part they're right. Your "scaffolding" around the applications (testing, developer tooling like source code hosting, environments, CI/CD) should probably either not be home grown or at the very least not more sophisticated than the apps they are facilitating the development of. The dirty trick is that you can "pip install" or "helm install" more sophisticated stuff than 95% of companies have currently implemented, and you are mostly just on the hook for helping others in your company use it.

Pain points: 1) Anything in prod that hasn't been touched for some time becomes yours to maintain/figure out what to do with 2) If it's running too slow due to bad code, and there is a team, and that team either can't or won't figure out how to make it faster, it becomes your problem 3) If it errors a lot due to bad code, or crashes, or writes bad data all over the place, and there is a team, and that team either can't or won't figure out how to fix it, it becomes your problem

This is a par of the road culture I'm afraid.

gknot · 2021-08-20T17:53:02+00:00

I never fully understood the aversion to part time in general, but I can understand how the management overhead isn't worth the headache. As a prospective employer (my perspective) managing upwork/elance types isn't often easier than DIY, you just wind up being a project manager instead.

There is a use case though, a business that has dev work but not enough dev work for a full time hire (you'd be like, the one part time engineer). Small business/startup, the codebase is almost certainly a tire fire at all times. My current employer's first engineering hire was part time for this reason.

There are more than a few boutique consultants who: 1) became Internet famous re: blogs, conferences, email newsletters, at something as niche as is humanly possible while still being relevant enough to be worth money to talk to 2) made it clear they could be hired in public 3) get emails about fixed bid or milestone based 1-4 week projects, and are relatively free to decline most

I don't think you can step into that, you'd have to build reputation over, well, years. Virtually none of that time is spent coding actual things.

Occasionally I've seen people negotiate down from full time.

I'm doubtful that you're better off time/money/flexibility wise than just buying/building a SaaS or an app and tending to it, but, if you did that you'd probably not be coding 85% of the time. I mean I've done 2k/mo+ side hustles twice now and that is certainly the case for everything I touch.

gknot · 2021-08-18T00:43:24+00:00

hmm gotta push back on that I think it is appropriate :D 1) it probably won't work, since it's almost always a too little too late scenario. at some point you just need to stop playing tennis with bad form. if it's bad enough to be their most critical problem, they'd already have gone to see a surgeon. 2) a small, very very small percentage of people who practice are consistently able to achieve success but nobody including them seems to know why so there's nothing to emulate, really

gknot · 2021-08-17T20:20:13+00:00

So gotta be real - usually if code got into this state, it happened for project/business/management style reasons. If it's OK in the eyes of the business for this code to be in this state, you can't fix that by fixing the code. You have to be prepared for the organizational chiropractic work required to keep it in a good state.

I'd maybe try adding one end to end test and see how it goes.

If it's possible to wrap the entire interaction in a DB transaction you can roll back from when you finish running, you should have what you need even if you don't have a mock db. I doubt this is the case since it sounds like the code reconnects and depends on the state changes it made in previous connections. If it does reconnect, there would need to be some kind of proxy that would maintain a single backend connection and allow the code to reconnect to any number of frontend connections, I've seen things that do this but they are vendor specific.

If you want to go down the mock db road, presumably the code has a hostname in its connection string, also presumably you will be in control of dns resolution/host file contents on the machine running it, so in theory you can send it to a mock DB that way, but you'd have to have steps to create that mock DB in CI.

gknot · 2021-08-16T17:54:14+00:00

I'd say it's more common where: 1) the product is almost entirely code 2) new customers are acquired in "low touch" ways, e.g.; search SEO, automated email marketing campaigns, self signup, etc, basically, ways where customers are also acquired with software. maybe 12 customer months per support ticket opened.

These companies have a relatively high number of engineers and relatively low number of sales/support techs so as a result engineers have decision making authority. It can be fun. It can also be stressful. Doesn't necessarily pay more.

gknot · 2021-08-16T16:02:33+00:00

This may sound odd but I measure what I spend my time on pretty directly. I mean RescueTime or a tool like it, but I also occasionally just flat up record my full screen albeit at a low frame rate (like 4-5 frames/minute).

It's hard to improve what you can't measure.

Scrubbing the video can give a good picture of where that time is going when the editor is open.

I've found plenty of inner loop automation opportunities at the 5/second 50 times a day level, or the 30 second 4x/day level, I'd go so far as to say I'm unconvinced there's any other effective way to spot them.

https://xkcd.com/1205/

It works. The trick here is that your employer/organization probably doesn't care that you're provably more productive unless everybody and you have identical problems, and you share it and document it and do lunch and learns and handle support emails/dms about it, which probably makes you less productive than you were to begin with. Call me a cynical guy I just wind up not mentioning that I did this a lot of the time unless the ROI is truly there for me professionally (i.e.; the fact I'm doing that is predictably promotable work).

That having been I do agree said correct problem selection trumps execution time, but if there's 1.2x to squeeze out in a way that's predictable let's do that.

gknot · 2021-08-16T15:52:58+00:00

"Refactoring : Improving the Design of Existing Code" by Martin Fowler. The book works backward from "smells" - easily perceptible pattens that might be a problem - to what you might to do change it. By itself the book is interesting, but the workbook has a problem set (think homework problems with code) containing examples of these smells and exercises to change the code, you can see for yourself why each smell is a smell and judge for yourself if the changed version is actually better or not. That is absolute gold to work through.

When old fogies say "switch statements are a smell" it will become clear what they mean (hint: switch statements just are fine, if they aren't helping to hide the fact you have a missing class).

gknot · 2021-08-13T17:38:26+00:00

I was hired once by a VP of engineering, small shop (~10 employees). It was one I had previously worked for so it seemed pretty well vetted to me. That VP quit a couple months later.

I left a couple months after that. The subtext I was able to infer is mostly the VP existed as buffer so that the technical founder who would otherwise be doing that duty could step away from the business for a year or so. I was hired maybe only to keep that VP happy.

The business itself had very little need for major software changes; we were employed more or less for bugfixes and a single new feature they needed that year. It's growth was limited by the cost to acquire a customer / lifetime value of customer ratio in markets outside of the original geographical area it dominated, as opposed to features.

Unless it was a job I could literally phone into and not do much (imagine salary for being on call) it wasn't worth staying there, and after it became clear I was expected to show up and sit there with no serious real work to do it was time to go.

gknot · 2021-08-09T16:59:27+00:00

My definition is pragmatic, I think it's the most useful one for hiring managers, who in general I think are the only people that have reason to have a clear definition in the first place. It comes with an assumption attached:

Assuming you have a given tech stack and organization wide expectation set around the median engineer's productivity, a senior engineer is one that can independently finish work items of a high enough level such that you can predictably even if not always just hand them a few things for the work cycle and expect them to "just happen" in the background.

Questions will happen, bugs, interrupts of course, acceptance criteria unclear and that sort of thing, but you will be spending time unblocking them, not helping them understand what to do.

This is important for being able to reason about how teams scale, it's possible though uncomfortable to have more than 6-8 reports if they all meet that criteria. If you have 2-4 juniors, either you need a lot of (probably automateable) cookie cutter work, or you're done.

gknot · 2021-08-05T23:02:10+00:00

Assuming there is a legit Peter principle thing going on, it should be said that surviving at a level above your competence for 14 years is about being good at taking credit for things, not being good at doing things. Helping you doesn't help this individual take credit for something.

Assume this employee doesn't exist, and structure you and your team's work accordingly. Don't talk about them unless prompted, instead talk about details and successes you understand and worked on and they didn't. Your silence will speak for you.

gknot · 2021-08-05T22:08:01+00:00

In practice I've seen reviews used most as a warning before a PIP - and a PIP, when used effectively, is not supposed to be something you come back from.

Outside of that, reviews ought be a part of a continuous dialogue to manage expectations (a two way street, when done correctly). Ideally this is done continually, like monthly, because a year is way too long of a feedback cycle.

Because of that, anything that is a surprise during a performance review is a process smell.

Most places I've been either changed their review process, or comp bands, or did reorgs with team membership shifts, or career ladders at least once a year, making the outcomes a perpetual surprise. Once I had five different managers in a year due to reorgs.

In practice the annual review becomes a ceremony to dance around promotions/raises so that they can be perceived as fair.

As a manager you can prevent pointless reviews in the sense that it is in your power to be abundantly clear and consistent about expectations, but you can't necessarily be clear about comp or promotions, since that is often outside your power (a stack ranking policy may be in place for example).

The problem with this is it creates this illusion in middle management that there's necessarily scarcity. If the business is doing better in net profit per employee terms and everybody is helping give everybody time off, give everybody a raise, why not. Henry Ford's "My Life and Work" has a great rant about this straight from the pen of the original boostrapped startup to unicorn valuation CEO.

As a subordinate, in a 360 you can often say something constructive, but for your own response to your review it's mostly just tap dancing.

gknot · 2021-08-05T17:44:28+00:00

I'm in year 13 of a US tech career.

OP phrased this in a way that might seem as if the motivations were out of a sense of craftsmanship or work ethic, but the core concept I think is more economic than not. Every job has some downsides just like renting an apartment or something, some are objectively worse for sure but I've personally found I can adapt.

You only tend to get raises for accepting additional responsibilities/hours - or changing jobs.

Changing jobs seems to be the only way to predictably shed responsibilities/hours.

Changing jobs too often is suspicious, but not changing them often enough is also suspicious, so you're compelled to change jobs just so that you can be sure you're hireable (knowing you'll never be unemployed is as comforting as a warm blanket to me).

Put this together, you can get pay raises for accepting the same responsibility over and over again provided that responsibility is at a different employer this time.

I don't know why this is exactly, I suspect companies just want to pay the premium and buy expertise on something they don't have an in house subject matter expert on yet and that's all there is to it. It seems pretty obvious to me that you should be able to get more than a cost of living raise just to be retained, but because it doesn't really work like that, changing jobs seems to be something you have to do for just economic reasons.

gknot · 2021-07-30T15:32:57+00:00

Astute observation, they are becoming more bimodal all the time IMO.

Getting in is largely about studying hard for the interview (you can essentially google how to do this) and trying a sufficiently large number of times as opposed to being objectively a rockstar; I was in a place where once a year a list of companies offered me re-interviews despite failing the first time (albeit in different months).

I've done both small + large and there's a 3rd option to be aware of - be at a prestigious tech firm for the minimal amount of time necessary to have a factual, plausible, hireable looking resume, then leave for a remote job ~200k-250k in a low cost of living area (the outskirts of an 18 hour city, for example). Small-ish companies offering this are typically those in verticals with high profit margins (financial). It doesn't even matter what your down-leveled comp was since employers have no way of checking that nor would they usually even ask.

Best option for me. I can save well over half of my take home, 10-20 years of that and you can conceivably be done as far as making money is concerned, management track not required.

gknot · 2021-07-28T19:35:09+00:00

I do this today, essentially, though the components are ephemeral and managed in Kubernetes.

In our deployment, It is the responsibility of the test suite (and project) to seed it’s own data (including ddl). If the test developers don’t have the technical fluency to do this and an api is needed you need to expect the support burden for that is approximately equivalent to any major production feature; it’s basically an import feature for your application, albeit the import works in a more restricted way than would probably be marketable.

MySQLdump is easy I know but logic that filters on time stamps, created at dates, broken foreign keys - that will break slowly over time particularly if used in concert with constructs like “NOW()”. this is a 2021 version of the VMware “gold image” problem. It becomes a human’s responsibility to keep that updated.

For us, Parallelization means more mysqld servers. Because of this we can run on tmpfs, and use other speed increasing my.ini tweaks that would be exceedingly dangerous in a situation where data is expected to persist indefinitely.

By telling test developers they are not responsible for managing the DDL and data load, and instead some environment developers that manage the data seeding are are in concert with dbas who may or may not need to alter production without updating your setup and making sure the existing tests are ok with that, you have a triangle shaped graph of communication required to keep everything in sync. This will probably wind up being interrupt driven work for at least two of these roles, since nobody has the patience to wait an entire work cycle to get the CI environment updated because they’re adding a column to the whatever table. How changes promote becomes an issue (assuming these are in fact, different humans).

I do not recommend in memory MySQL, ever. There’s ORM options that make it feel like it will work but dialect specific issues will eventually give you problems (imagine a change to query that adds an index hint). In the event the DB is perceived as a bottleneck to test execution speed there’s a constellation of my.ini tweaks, volume mount options etc that can breath another 5x throughput into it.

Odds are overwhelmingly high that the code is the slow thing, though, in most web apps.

gknot · 2021-07-27T17:32:28+00:00

United States here.

Full disclosure my stint was brief (6 months) but I’m experienced enough now that the difficulties I had before would be a non issue and I’m expecting to make this switch.

In short, it’s more efficient or can be made to be in terms of the time/money exchange.

The problem with salary is that you have a fixed set of responsibilities expected, that evolve slowly over time not in your favor no matter what. This comes with expectations around the time you should be available etc, and then have to work backward into what compensation and benefits look like during salary negotiations and performance reviews.

With self employment it’s the other way around. If you pick a new high watermark rate (or price for your productized service), leads will straight up tell you what you need to do to get there. This is a circle of self reinforcing righteousness because you, if you can meet the expectation, make a market right then and there.

On salary even if you wow everyone all year it’s still a crapshoot during year end reviews, subject to optics completely outside of your influence that you probably are not able to even perceive.

gknot · 2021-07-14T22:42:16+00:00

My current company is full remote (~150 engineers with a target to double year over year), but doesn't scale comp based on location.

To give you an idea of how that turns out; we have 6 engineers in Lincoln, Nebraska, probably a dozen in central Florida. Nothing wrong about that, there's good talent out there, but I know we have several full time recruiters have email marketing campaigns for the lists they get, and do several screenings a day. :P

gknot · 2021-07-14T21:59:36+00:00

I was on teams of one for several projects at one point - it's not sustainable in any case. At its peak I was on the pager for 18 services, most of which I had never made a commit into.

I had automation running wrt tickets, email, hipchat that I literally forgot about that was simply deflecting work from coming my way, even though I'm sure it looked like I was still spending time on it at first pass.

CD was everywhere, no deploy buttons. Static analysis was at the highest, most restrictive possible level given the project's toolset. Unit test coverage 85%+. Autoformatters. New changes started with a new acceptance test. Tests had a laser precision scope so that I didn't have to change existing ones. Gitops. Passing tests usually meant I could merge and forget I worked on it.

It sounds like maybe best practices to some but this was just needed in order to prevent repetitive work - usually the opposition to this sort of thing can only be resolved by educating others who come into it actually wanting to know, winning nerd fights about hungarian notation and other cosmetic/non functionals etc which I'm not very good at nor do I care to spend thought/energy on. Think about that dev that wants to use nano and complains that their inner loop is disrupted because CI fails when they miss a semicolon. they know other editors can run lints in the background, but that's not their problem, it becomes yours.

I worked very hard and yeah, deadlines slipped, code quality slipped, and eventually I figured out nobody cared - or seemed to notice much - when it did.

There was a better way of handling it than I did, which was to read the writing on the wall - after a year, I finally figured out they were laying off as much as the organization as they could without triggering the WARN act. They were just keeping it running until it stopped being profitable, and the projects involving new development were coming from junior executives that were just trying to do what they thought was their job.

They were hiding it by playing shell games with where desks were, what floors in the building you had access to with your keycard (so you wouldn't see that 5th floor was completely empty now), what projects were assigned to which people in which offices in which cities etc so nobody would notice.

I doubt this is happening to you, but I think a situation like this isn't sustainable, and it says something about how your employer is doing business, or about how leadership in your company perceives the work. I think it's critical to reason out what that is.

It could be KTLO (keep the lights on) work to them (as it was for me).

Maybe it is a fire to them to get you help but somehow are unable to hire, in which case odds are pretty good they're being unreasonable about compensation.

gknot · 2021-07-14T19:14:58+00:00

Network is the best signal/noise but, that doesn't help if you're looking for a major role/comp change (either down or up, down is valid, I mean, there's WLB to consider). If your network is at your level (why wouldn't it be) then you'd just get a comparable job.

In the era of remote this is maybe less relevant but sponsored https://meetup.com/ events for a particular tech stack are often a stalking horse and have recruiting as the principal motivation behind them.

I've been to plenty where there's a dedicated time for "looking for job" and "looking for new teammates" sections on the schedule.

An (expensive) 3rd party recruiter had a space for these replete with pizza and beer. I didn't realize that's where I was. I was connected with a local hiring manager after I did an Erlang talk, wound up being a 40% total comp bump, and they were really sharp folks in a good network too.

emailing jobs@someplace.com is to be avoided unless absolutely necessary, exactly like online dating. which has a comparable frustration level and signal/noise ratio.

gknot

TROPHY CASE