When hiring senior engineers, you're not buying, you're selling - <AUTHOR> https://hiringengineersbook.com/post/trouble-hiring/ <comment><USER2> A lot of this post seems pretty reasonable. But:

 _In my experience, it's fairly easy to judge technical skill. A friendly conversation about technical interests and recent projects can often be enough._

Bullshit. Sounding credible in technical interviews is a skill, not the same skill as actually being a good programmer, and might even (statistically, in the large) be close to orthogonal to it.

We found this out the hard way. At Matasano, we started our work-sample hiring process[1] as a way of filtering out the smooth-talkers. Before work-sample tests, we'd spent loads of time on carefully designed interview questions; interview design was something close to a hobby for some of us.

Of course, it was only after we started doing work-sample challenges that we discovered that not only were a lot of excellent-seeming candidates actually not capable of delivering, but an even greater fraction of the candidates our "friendly conversations" were selecting out _were_ in fact perfectly capable. It was a bad deal all around.

Whatever you do, don't fast-path "senior" developers. Everyone should run the same process for the same job. Not only do you risk hiring people who won't work out, but you're also depriving yourself of the most important data you need to iterate on your hiring process.

[1]: [https://sockpuppet.org/blog/2015/03/06/the-hiring- post/](https://sockpuppet.org/blog/2015/03/06/the-hiring-post/)

<comment><USER3> I disagree. If you can't tell the difference between a smooth talker and strong technical competence you are probably interested in the wrong qualities. I have interviewed enough now to see why some companies cannot figure it out. Ask yourself if you really actually want a senior or a strong junior.

It comes down to interest. A good senior got that way because they like solving challenging problems. They are not interested in trendy framework bullshit. In other words talk about the problems and potential solutions. Are things in place to make the job easier? Seniors don't need easier and this is a huge turnoff.

When I hear companies try to sell me with frameworks and process I know they are blowing smoke. At the very least they are boring and at worst you will be working with incompetent people who are as self-diluted as the company. I agree that filtering candidates is a good idea though.

The reason why some companies cannot figure this out is because they don't value the problems at hand. They need bodies to put fingers on keyboards and are willing to pay more for people who don't completely suck. Experience and competence are not the same as excellence but considering the candidate pool I can see why companies compromise on quality.

<comment><USER4> This is a good post. Have been in the UK startup environment it was crazy how many companies got funding but didn't had a strong senior in their software department.

Because of this their hiring process was aimed to hire more "strong juniors" even tho they didn't realize it. A strong senior is a person who completely changes how you are even approaching the problem or someone who shows you problems you hadn't seen before. They often see tech in the context of business as well.

As you said, usually, they can't be bothered about learning the new framework of the month or new backend language of the month, but, they have a set of battle proven tools to solve tech problems for businesses.

P.S: I do find it hard to distinguish between bullshit talkers and people who actually get stuff done in the interview process.

<comment><USER5> There's times when i think i'm coming across as the bullshitter. "Tell me of an accomplishment you're proud of". I struggle with this one, but I've given this example years ago.

Worked at a company which did nightly data imports. Things worked until 'companyx' became a cEient, and the imports were huge. They would take 18-20 hours. Then longer. eventually they were touching the 24 hour mark - unacceptable. Client's data would be more than a day behind. Granted it was a moderate amount of data, but shouldn't take that long.

I was 'new' there - only started a month before - and the rest of the team who'd put this together had been there a year or more. I reviewed what was in place, took a couple of days, and got it down to an hour. Then worked with the existing team and we got it down to under 30 minutes with some tweaking.

I do see some eyes rolling when I tell that, as I know it can sound terribly self-aggrandizing. However, I had a decade of experience at this point, and the rest of the team was just out of college; they'd never faced this problem before. I basically just took the data and imported in small chunks in to in- memory tables (to avoid hitting the disk), and copied those to disk every X rows, and dropped indexes until everything was done. It wasn't rocket science, but did take someone who had a deeper understanding of DB mechanics.

As I'm telling this, I always realize they have _no way_ of verifying this, and essentially I'm just another bullshitter. The more believable I sound, there's an equally high chance I'm either really good, or just a really good bullshitter, and nearly every time, the person I'm talking to has no idea how to tell the difference. It's worse as you get older, because the younger folks just think you're waxing nostaligic about the 'good old days'.

<comment><USER6> It doesn't help that in our field the context for many of these past achievements is quickly lost and forgotten.

You can't just say "I did X in Y by using Z": you need to begin by explaining that once upon a time there used to be a thing called Y, and on that thing it used to be very hard to achieve X, but in those ancient days there was also a tool called Z, etc.

</comment></comment></comment></comment></comment><comment><USER7> Isn't it just... mostly money? I mean, if you want to hire someone good, who presumably has a good job, you have to pay better than what they are getting now.

I think this is probably especially true in Europe; I mean, as far as I know, people get like a 2x-4x raise moving to silicon valley from europe. If you pay more than your local competitors, you will largely have your pick of the candidates.

I mean, yes, things other than money matter a lot, too. But as an employee? I think that's really, really hard to judge from the interview. The money is pretty easy to judge, and as far as I can tell, total comp is a good 'honest signal' that I'm going to be treated in other ways. How much money they offer is a better indicator that I'll be treated well, in my experience, than anything anyone can say at an interview.

I think as workers, we're not doing ourselves any favors by pretending that an employer can get the best people without paying the best rates.

<comment><USER8> Like I said elsewhere in this discussion, I disagree. Of course, salary is very important, but I (and many people I know) would easily choose (and have chosen) a lower salary for any combination of these perks:

\- Work fewer hours

\- Work from anywhere

\- Work in a specific location

\- Work in a certain environment

\- Work in a specific kind of organization

\- Work with specific technologies

\- etc.

People are very different and have very different wishes and needs. Salary isn't always priority #1.

<comment><USER9> For me it is:

\- the product is SW

\- great colleagues

\- challenging problems

\- cool technology

\- having users

\- good salary

\- good tools

\- max 40 hours a week

\- minimal bureaucracy

\- working remote when needed

[https://henrikwarne.com/2013/03/26/what-do-programmers- want/](https://henrikwarne.com/2013/03/26/what-do-programmers-want/)

<comment><USER8> Interesting article, thanks for posting.

</comment></comment></comment></comment><comment><USER10> Hands down, the number one problem in hiring and retaining senior engineers is being able to match the compensation level. FAANG-type companies have a huge difference to practically everyone else. Startups, especially, can't match the salary, and few make up for it in equity comparable to the risk level engineers take on by accepting the job. Senior engineers typically know better, and so you end up with mid or even junior applicants for senior roles, and out of desperation, they end up being the pick.

<comment><USER11> The difference being that the FAANG-type companies don't pay well enough to make up for the cost of living. Senior engineers seldom want to live in tiny apartments.

See if you can prove me wrong: find a 10-acre lot within a half hour commute, with a large single-family home, that is affordable to a senior engineer. Alternately, make it 1 acre, but within a 5-minute commute.

<comment><USER12> I understand what you're saying but I think you're underestimating how many people like city life.

I work in SF and most of the people here are here specifically because they DONT want to live on ten acres in some rural place, they love that the city is walkable and dense and interesting.

For most folks the issue of living in condos or apartments it's an issue at all until they reach a certain family size. At that point, most of the people in the city would be thrilled to live in a 3-4 bedroom townhome in the city — but THAT is where SF gets really difficult, because those cost $4 million or more these days.

Actually for many people they feel trapped because they'd like a LITTLE more space, ie. the Victorian townhome, but they specifically DO NOT want a car or a yard and do not want to leave the historic, walkable city. At that point you're really screwed because outside of SF there is basically nothing else walkable west of the Mississippi. So there's nowhere to go.

If somehow magically you could build a 1900s Victorian townhome city about 30' away by train I think you'd find a couple million urban Californians wanted to move there.

But of course the sprawl all around the job centers, and the regulatory environment, both make that impossible.

Oh well.

<comment><USER13>
      outside of SF there is basically nothing else walkable west of the Mississippi

What a sad perception.

<comment><USER14> So where is it?

Where can you live outside of SF that you don't need a car and can live a normal adult lifestyle?

<comment><USER13> First of all, SF doesn't really qualify. How many live in a neighborhood where their workplace, medical, grocery, and social needs are all _walkable_ to/from?

Car-ownership-hostile != "walkable". Using Lyft/Uber isn't "walking".

Anyway, as to your question: parts of Sacramento, Auburn, Carson City, Eugene, Bend, and Boise all qualify, and that'slimiting to cities I know firsthand. Other cities that I hear this from others include Salem, SLC, ...

Much depends on what you consider to be "normal adult lifestyle". If one's definition of that includes walking through waste and needles to the Folsom St. Fair, SF probably does have a monopoly there.

<comment><USER15> SF has decent public transit. Disliking public transit is fine, but ignoring it is something else entirely. Muni and Bart do make it possible to get around most of SF without walking or using uber/lyft.

And, given where I live, my medical, grocery, and a significant chunk of my social needs are truly within walking distance. The only one that isn't is work, and that would be accessible via public transit if I was willing to compromise on commute times a bit (or if I changed employers/offices).

Carson City has 4 bus routes serving 150 square miles, San Francisco has close to 100 serving less than 50. Those aren't remotely comparable.

<comment><USER13>
      Disliking public transit is fine,

... and is something I didn't write, nor feel.

The parent comment asserted _walkability_. If your environment is _walkable_ , that means you don't _need_ transit/carshare for everyday needs.

      Carson City has 4 bus routes

Again, _walkable_ means walkable without transit. My father lived there with daily needs within walking distance. SF is not only not the "only" walkable city, SF isn't generally walkable overall for all everyday destinations (especially hilly streets).

<comment><USER15> Walkability in the city-planning sense is defined by "lack of need for a car". Improved public transit improves walkability (see the walkability scores on pretty much any site ever), as does mixed use development.

Carson City has a walk score of 34 (although apparently there's a 4 block area in downtown that gets up to the mid 70s). SF has an average of 86. My apartment scores 99. Like I said, there isn't a genuine comparison to be had.

<comment><USER14> Exactly this. New York City is the very definition of a "walkable" city because you walk to the subway, stand on the subway, walk to work.

Not because you live within walking distance of work, which almost nobody does. That definition of "walkable" would be so tiny to render it almost meaningless.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Context: 15 years of experience, multiple public talks (including AWS reInvent), own chunk of infra serving hundreds millions users.

Got a message from yet another self driving startup. Agreed to do a phone screen out of curiosity. Interviewer is 6 months out of school and his first question - why do you want to work for us. My answer - I actually don't, I didn't even know you exist and it is your job to convince me. Thoughts - i'm wasting my time.

<comment><USER17> ha. i would have hung up. but then i'm pretty gruff.

<comment><USER16> I was very close to do it and I did a poor job hiding my annoyance. It didn't stop there. The coding challenge was standard bs done in a glitchy online tool. Yet another clone of coderpad which implemented poorly. I asked the interviewer why did he pick this specific question and how does it correlate to what they do - answer was not encouraging. As you guessed, I didn't pass he interview :).

</comment></comment></comment><comment><USER18> I think the article is reasonable but it suffers from the imprecision of "senior" as many things do. What is a 'senior' engineer in a startup, or at a mid-size private company, or a large public company? All of those companies have "senior engineers" but they aren't easily swapped out for each other.

These are my definitions, at a startup a senior engineer is one that is broad enough in their experience to have gone deeply into one area and at least lightly into several others. They understand what technical debt it and when to use it, and when to avoid it. What is more, they can communicate what needs to be done to a more junior engineer.

In a mid-size private company a senior engineer knows all of the forces that are being applied to their area of expertise, they know what the cost constraints are on the solution, they know what the time constraints are. They understand the area fully and can review other's work and participate productively in design reviews and product planning sessions. They can be an axis of excellence by leading by example and surfacing things that need to be fixed early.

At a large publicly traded company a senior engineer is one who can relate the business to the engineering effort to insure that they are doing the engineering that is needed and more importantly they are not doing engineering that is not needed. To paraphrase, "With great resources comes great re- invention." Large well funded engineering teams tend to re-invent the wheel because they can, not because they need to. And as a result can become mired in self inflicted complexity. It is the role of the senior engineers to see to it that it doesn't happen.

Very different jobs.

<comment><USER19> Why should not all those be together and be the bar for senior starting at the start-up layer? I think the only big difference is working/navigating in a small or large org, no?

<comment><USER20> If you look at the both extreme, large public company and a start up, in the former case, you already have customers, a viable business model, and a legacy product. As an engineer, your first requirements would be to "not break things" going forward. Sure you want to gain some market share from competitor but you already have some momentum, otherwise your job would not exist. So you need to upgrade or add features to your product in a controlled way. Your 20 years customer might not want to have to learn a new interface just because you can deliver it.

At a start up, even if you have your first customers, you want to deliver a product or more features as quickly as possible starting from scratch. Possibly, you also want to be able to pivot totally if the first idea does not stick.

It is great if you can do well in both environment, but usually, this is different skill set, and I would even say personal inclination. You'll likely have a hard time to convince a start up engineer to work on COBOL code base on a mainframe.

</comment></comment></comment><comment><USER21> The author is from Austria. As a dev who moved there 4 years ago I noticed it's probably some archaic Germanic cultural trait for any job postings to be very employer focused, acting like they're doing you a favor by hiring you and not caring about what the employee might want, even for senior roles.

Maybe a local is reading this and can explain why this is still a thing.

<comment><USER8> Author here, true, software jobs are a bit extra weird around here. I think it's because companies are run more "traditionally" here. Meaning that the people running the company are usually managers. They have a business background and don't understand what most engineers want and how they think. Even many self-proclaimed "startups" (which are often just consulting shops) are run this way.

The cause for this might be that it's culturally pretty unusual to start a company around here. I'd say people are extremely risk-averse and starting a company is almost frowned upon.

<comment><USER21> If the people running the companies have business backgrounds surely they understand the principles of supply and demand, no?

They want FAANG like employees but only if they work for peanuts. Then they cry to the press they _can 't find skilled engineers_.

The same way I also _can 't find Ferraris_, with a budget for a Hyundai.

</comment></comment></comment><comment><USER22> I agree with a lot of the points here. One specific pet peeve of mine is job listings that refuse to nail down which _specific_ technologies they're using.

Some will say things like "Front-end web development using a framework such as ExtJS, React, Vue, or Angular". Neat - which one? I'm happy to work with 1 or maybe 2 of those. Do you mean that you actually use React but you're fine with people who come from some other framework? Or do you mean that you are converting a legacy app from Ext.JS to React so you're hoping the candidate has used both?

Sometimes they'll bury the actual framework in the "Nice to Have" section but it's pretty common for it to be left vague. I _think_ what they're trying to do is widen the pool of applicants, but that strategy seems suboptimal for attracting folks who want to work with a specific tech stack.

<comment><USER23> While this is only my experience, when I write job requirements that cover multiple languages or frameworks it really is 'any of these are fine'. The theory is that you don't want to filter out people that would otherwise be a good fit - because for the most part smart people can learn new frameworks and languages pretty quickly. You are correct that it is suboptimal for people wanting to work on a specific tech stack, but if you're not getting any applicants because your requirements are unnecessarily strict it's not in anyone's interest.

<comment><USER22> It makes sense that you wouldn't want to prematurely filter people out, but in that case I'd think it might be better to explicitly state that. Something like "We use React, but experience with another framework (Angular, Vue, etc.) is fine. We assume you can learn React."

I think the unintended consequence of leaving it broad is that you might lose people who are specialized in the very framework you use.

In my own case, I'm pretty biased toward React, having written a book & been blogging about it for a few years. I definitely pass over job listings that leave the framework open to interpretation. The cost of finding out what they _actually_ use is too high, unless the job looks exceptional in some way.

</comment></comment></comment><comment><USER24> That's hilarious and so true. Last year I interviewed for a senior back-end engineering position at a well known mid-sized company in the Bay Area. They put me through 2 technical phone screens and a 6 hour onsite interview, grilling me in detail about system design, domain knowledge, personal experience, and of course doing endless exercises of writing solutions to algorithmic problems on a whiteboard. I really felt like I nailed the interview but they still rejected me because they thought my technical skills weren't good enough. 7 months later I start applying to jobs again via LinkedIn, and guess what, that exact same position on the same team is still open. It seems insane that during the past 7 months they couldn't find a single person to fill that role. Makes me wonder if they know what they're really looking for.

<comment><USER25> "senior engineer for team y" is a position that's constantly been hired for at most growth companies. The fact that they're still hiring for it probably doesn't mean much.

<comment><USER26> Exactly. We are hiring constantly for several positions: junior, senior, lead. We don't want to saturate job boards so we artificially limit listings.

</comment></comment></comment><comment><USER27> What I find hilarious is how every VC podcast about bootstrapping your startup has both of these statements 30 seconds apart:

1\. ALWAYS hire the best you can. Hire people smarter than you. Hire the smartest people in the world!

2\. It's always impossible to hire! We can never hire anyone!

Yeah. Ya think?

What I try to do is actually the opposite of their advice.

I don't look for the perfect hire. I look for people who are often overlooked but COULD become the perfect hire.

Just get them in at an affordable salary and build them into your best engineers.

They will be amazingly loyal (since you gave them chance when they needed it) and you can train them to become PART of the team.

You DO need senior people for this strategy though. They need mentors.

<comment><USER28> Don't forget to offer them the kind of raises they would get for jumping ship down this journey (20/50/100%?), or they will, well, jump ship.

</comment></comment><comment><USER29> The words 'pay' and 'salary' do not appear in the article. They want senior engineers at intern prices.

<comment><USER30> Pay as much as FAANG and trust me, you'll get your senior engineers.

<comment><USER31> I have to disagree. Money is not always all.

Sometimes it's also about expectations, role, office location, other bonuses, etc. When in 2019 you don't let people do home office... Byebye...

<comment><USER32> Money is not all but FAANG have benefits and work that are comparable or better than most startups/companies. The overall package is just better... It's obvious to the market at large. Only niche audiences are willingly going to choose startups/companies with certain perks. (fully remote work, for instance - it is a niche thing regardless of what people here say)

</comment></comment></comment></comment><comment><USER33> Great post! I can relate to that a lot.

One of my experiences was a recruiter for a startup (which plans to be leader in XYZ) reaching out for me on LinkedIn. Since I found the general domain quite interesting, I responded. From there on we have a short chat, but instead of getting really insightful information on the job I get forwarded to a bunch of URLs which aim to describe things. I get that it's convenient for the company to save time - but I don't want to spend hours reading through things.

Then there is an interview loop. 2 of the interviewers are apparently fairly junior, and spend the whole interview asking the typical graduate coding problems. One of them even wasn't sophisticated with having things 80% solved - it needed to be 100% - even though that meant the whole timeslot was used up. In the end of those in-person interviews I learned nothing about the job because there was no time left.

The main thing I learned was that there are people there who can be pedantic on interviews and can solve basic coding problems. If anything that gives me a negative impression. I want to work together with people who know interesting technologies, know how to write well-structured code, etc. The interview might give the impression that they don't know these things, because all they ask for is how to solve a leetcode problem.

After that the company asks for another interview loop at a different place - which obviously would mean spending even more time on this. At that point I'm giving up.

</comment><comment><USER34> Having spent a lot of time being interviewed recently, I've noticed a certain type of question asked in technical interviews that I think can sabotage perfectly qualified engineers. I'm not sure if my view is sound, but maybe someone can pipe in and tell me why I am wrong.

Imagine being asked this question in a technical interview:

> When do you decide to use frontend validation?

(yes, this is based on questions I've been asked IRL)

The problem that I have with this type of question, even though it _can_ be answered and _seems_ reasonable, is that it's not even how engineers tend to think most of the time. It's about a solution looking for a problem.

When I'm faced with this kind of question, I often stumble to come up with a hypothetical need for the solution being proposed. It's not that I can't come up with an answer, but I end up lacking eloquence and saying "ummm, well, okay, so..." a lot while using my imagination. It would be like handing a hammer to someone and asking them to find things to nail with it.

In essence, it's _backwards_ from how I would tackle most problems.

Here's the sort of question I would rather be asked:

> Let's say that we've built out a web form that the user can submit, and > there are a lot of inputs they have to fill in. They can only know if they > made a mistake once they've hit "submit", due to backend validation. How > could you improve this experience for the user?

I find this preferable because it's a lot more realistic and natural. Instead of looking for problems to fit the solution, I have a problem and need to come up with a solution. To extend my hammer analogy, this is like providing the pieces of a wood table and allowing the candidate to show how they would assemble that table. Anyone can memorize terms like "frontend validation" and what sort of problems they are associated with, but it demonstrates more skill to be given a problem and know where to go from there.

My guess is that there's a lot of good engineers out there, even senior ones, who get weeded out in the hiring process because they're being asked not to approach problems like engineers but like they're contestants on Jeopardy.

<comment><USER35> > How do you know if you need frontend validation as opposed to the backend?

You _always_ need backend validation. Never trust the client. You can then layer on frontend validation where it's needed to make a better UX.

<comment><USER34> I think that could have been a poor choice of words on my part. From memory, when asked nearly the same question, I don't think it was suggesting frontend validation exclusive to backend validation. Then again, maybe that _was_ how it was phrased. Ugh. Maybe I'll edit my original post.

You are definitely correct, however.

</comment></comment></comment><comment><USER36> The sheer amount of recruiters and interview requests that act they're doing you a huge favor for the opportunity is rediculous. My conclusion is they truly do only want to hire people who don't know what their skills are worth.

<comment><USER8> I think it's really just a question of mindset. A lot of recruiters don't have a background in tech. They don't understand that the market is completely upside-down. It's a huge change in mentality and it takes a bit of humility to see.

<comment><USER37> Also experience. Many recruiters I see are either part time contractors or recent grads that are just trying to get some (any) work experience before they move onto something else (like sales).

</comment></comment></comment><comment><USER38> While the definition of senior engineer is a bit squishy, I agree completely that as some one gets more senior they increasingly choose the company rather than the other way around.

I'm soft-launching a product to help companies recruit and I've done about a dozen customer development interviews with hiring managers (5 person companies through FAANGs) in the last two weeks. One thing I heard constantly was that referrals are their best source of candidates and that for roles with 7+ years of relevant experience they actually don't believe good candidates will come in by just randomly applying on their website/LinkedIn/etc. I had an engineering manager tell me "a senior engineer actively searching for a job is a negative signal of candidate quality" as opposed to going through somebody in their network or connecting with somebody at the company first. I had another manager tell me for the senior roles he's hiring for he only considers candidates explicitly sourced by his internal recruiter who searches LinkedIn for the specific skillset or people who are referrals for the specific job. This isn't some CTO level position; this is just a role for a ~10 years of experience individual contributor. Applications from the website go straight to the trash can. The implication was people with those skills aren't looking for jobs.

<comment><USER39> Whew, that is a hard thing for me to read, it actually really bummed me out (apologies if this comment winked in and out of existence...wanted this to not be one giant blob).

(Bear with me, gonna anxiety dump a bit here ;) feel free to skip to the end where I have a pertinent question...=) )

Background: I've worked as a high-level contributor both at the management and engineering levels for the last decade of my career. Decently respected software dev/leader/whatever, lots of big and small projects and teams, all successfully delivered. People like working with me! I've had friends ask me to come work with them. And I like my friends. They are great people.

However, I'm also known to be really picky about the things that I want to be doing with my time and my career. I'm really protective of it overall, so when I have the opportunities to "do things" with friends or whatnot I have generally said no, for a variety of reasons. They are great people and wonderful developers (legitimately wonderful, brilliant human beings) but in many cases they work for environments or domain spaces that wouldn't really be "my thing". Sometimes I've just pursued my own stuff for a while, since I have had that ability...but what you're saying above sounds like that has been hurting me.

At the end of December, I was in a work situation where the entirety of the technical team was laid off, including myself. I figured at the time, given my general "level" and experience I'd be all right when applying for work.

While I haven't applied to lots of jobs since then, I did apply to a few that seemed like a great personal fit on paper, and that I knew based on my experience I should probably at least get an initial interview.

No dice. 0% response rate. I was shocked! I mean, it's been a while since I've been doing the interview dance, but 0? So I had my CV looked over by people ranging from C-level guys to other software devs of varying levels and no one could figure out why I wasn't at least getting into initial discussions. "It's not you, it has to be them", I got told. But really after a few of these things happening, you stop thinking that "it's them". That can't be, right?

I made a comment to one person that I felt far more desirable to companies when I had much less experience/professional success than after I had more significant accomplishments under my belt.

I hate mysteries - and I hate the not knowing. It's one thing for me to go through an interview process and not be a fit, if such a thing were to happen; it's another for me to never even get to the interview process and not understand why!

So while reading the above is kind of dejecting, thank you for writing it...I guess it provides some illumination for me on what might be going on.

Now rather than hop into my shower and softly weep - do any of your engineering manager friends spoken about above have any advice for people who may have that experience but just happen to be picky about what they want to do, don't want to move themselves to the USA, and don't always jump at referral from friend X?

<comment><USER38> Sorry to bum you out. That's not my goal.

As one becomes more senior the hiring manager _expects_ a candidate to do their due diligence and ask some questions beforehand rather than hopping right into the application process. For a referral, that has already happened somewhat as the candidate already presumably talked to the the referrer about working at that company. You don't have to be a referral but a hiring manager expects you to do this due diligence. You don't necessarily need to go through a friend and you don't have to work with your friends. However, having an acquaintance at the company even in a different team is a massive help.

Think of it from the company's perspective for a second. They don't want somebody who just "wants a job". Money is always a factor but if somebody takes a job solely for money then they'll jump ship the moment somebody offers more. Companies want somebody interested in their space who wants to work there. You mentioned that you purposefully pursued some roles that looked like they'd be good fit for you. That's smart! Make sure the hiring manager knows it. By just clicking apply on the website, that may not be communicated clearly.

Here's two concrete pieces of advice:

\- Before going in the front door and applying for roles, reach out to the hiring manager and ask them some more details about the role and what working for the company/team is like. If you know somebody at the company who can put you in touch (even if it isn't the same team), that's better, but even if you don't that's ok. They will talk to you and if they don't you probably don't want to work there anyway. LinkedIn is useful for this.

\- If you're applying for a local job, try to meet the hiring manager or somebody else at the company in person if possible. Don't stalk them but to give you an example, I know that a CEO for a local security startup runs the local OWASP meetup and I told a person interested in working in security to go to the meetup and talk to him if she was serious about working there. I've been a hiring manager before and I looked way more closely at any candidate I talked to in person. Don't sound desperate but show them that you're interested and serious enough to go out of your way to talk to them. I had a couple candidates who I didn't know reach out to me via Meetup.com for roles posted to the company website and I had no problem meeting them for coffee.

On a related tangent, I help organize a local meetup and I get asked the question "how do I land my first dev job" a lot. I've helped half a dozen people land their 1st or 2nd tech job. Assuming they already have tech talent, I essentially offer them the above advice. It works at that level but it works for senior roles too! As a hiring manager, you want to talk to qualified people about your open role.

Good luck!

Edit: formatting only

<comment><USER38> A couple things to add:

\- The #2 source of candidates was almost universally meetups in my customer development interviews. Meeting people in person works! You don't have to be a referral although it does help.

\- It's pretty easy at a small company to figure out who the hiring manager is and contact them via LinkedIn/Meetup/etc. At a big company, this can be hard or impossible but you are much more likely to know somebody at a big company who can put you in touch. Absolute worst case, reach out to the big company recruiter on LinkedIn asking for some details on a specific role and they might put you in touch directly or they'll get your questions answered some way. The recruiter 100% will talk to you. They are paid good money to find qualified people like you.

\- While I said earlier it isn't a numbers game and you should only apply to roles/companies where you're a fit, to some degree it is a numbers game. Sometimes jobs are posted to a company website and the role isn't really available. Maybe they already have a candidate in mind. If you apply to ~3-4 jobs and don't hear anything, that isn't super uncommon. However, most people feel obligated to actually give you a direct answer if you contacted them directly.

</comment></comment></comment></comment><comment><USER40> "When hiring senior engineers, the company doesn't choose the candidate, the candidate chooses the company."

That's totally true. I also choose the environment where I will be working and what conditions will be.

I prefer working remotely and have flexible working hours. It keeps me motivated.

"Your job posting probably sucks". I agree with it too. Because some recruiters write me that their company offers free alcohol in their office for stressful situations. I told them it looks unprofessional and seems that they just drink at their office. She said to me that people hate boring descriptions and I'm wrong.

But you know that more people like a healthy lifestyle. Especially in Silicon Valley. Do you agree?

So, if you sell your company, find more information about a candidate (their interests, lifestyle, values). Instagram, Facebook, Twitter show you who a person is. It helps you to write the best offer to a candidate.

Currently, I'm using three ways to find a job: FB groups, Networking, and Freelance Marketplaces. I used to get projects on Upwork but right now I check job boards. BTW, if you want to save your time searching for projects, I found a service on Reddit comments that aggregates freelance projects from job boards ([https://periodix.net/](https://periodix.net/)). I like it because it doesn't sell me bad projects.

</comment><comment><USER41> If you pay low to mid six figures remote then you're back to buying talent instead of selling opportunities.

<comment><USER42> Can you elaborate?

<comment><USER41> In the article the author says there is more demand than supply for senior developers. I'm saying if you hire remote and pay a decent wage there is more supply than demand.

</comment></comment></comment><comment><USER43> All of these recurring interview threads makes me wonder: why are there only two interview preparation-focused boot camps right now? (Outco and Interview Kickstart)

It's one thing to take an algorithms course, and it's another to excel at competitive programming, and still another to use those skills on the spot in an interview. Surely like any other admissions process, one can train for technical interviews in a group setting.

<comment><USER44> The point that is being made by the original post is that the process is bad in many companies especially when hiring senior engineers who have a proven track record and have other options. These engineers don't want to spend time and money learning how to crack the coding interview in some bootcamp. They can find work and are put off by the process some companies use and such companies are missing out on good people. Suggesting bootcamps for leetcode and whiteboarding as a solution misses the point as these are not great interview practices.

<comment><USER43> They definitely aren't, but I wonder if their existence will force big tech employers to realize their interviewing process is being gamed and is even more of a sham.

<comment><USER44> I think it's ok for big tech companies to do this (from their point of view) because they have an endless list of candidates and don't care too much if many good people are put off or fail. They will get good people through the sheer volume of people applying and these processes do get good people if you can afford false negatives.

I think the middle and smaller companies need to change their processes more. If they just copy what the large companies do without understanding they don't have the same ability to attract candidates and pay high salaries they will just lose good people that they actually really need.

</comment></comment></comment></comment><comment><USER45> There is a lot of complaining about hiring processes these days.

I think both algorithmic questions and work samples have an important role.

Algorithmic questions are presented with a time lot, you get an idea of how the candidate thinks through problems. These questions I think reflect general intelligence.

Work samples reflect effort and experience, which is also important.

People like to complain about one or the other like they're entitled to a job. It's hard to hire senior engineers because there aren't very many good ones, a mediocre engineer who hangs on for 5-10 years is now a "senior engineer."

You're not special. If you want a high paying job of your choosing you have to earn it. Only a vocal whiny minority is heavily complaining online. If you think you're highly competent and the problem is with all of these companies, in whose best interest it is to hire good people, you should think again.

<comment><USER46> >I think both algorithmic questions and work samples have an important role.

I'm a senior engineer at one of the top tech companies. I hold the opinion the interview processed is heavily biased towards college grads or kids who are fresh on algorithms.

I think this helps us hire mostly kids who are book smart but aren't necessarily great (or even "good") employees... I'll do some hand waving here and define good as some combination of being driven and motivated, being able to work independently, and actually caring about what they're doing.

The question is then - well, how do we do this better? Honestly, I'm not sure. Hiring quality workers is a difficult problem. Technical interviews allow you to somewhat measure one of the key aspects of your hire. That being said, some people aren't made to stand in front of a white board and get judged. They don't handle that situation really well, and just because of that, they'll make mistakes that they might not otherwise make.

<comment><USER45> I think it varies by company, but at mine the questions are very much domain based for senior people. The focus is greater on algorithms for new grads.

The questions being asked aren't extremely challenging, they can be trained for. Willingness to learn new things (even if useless) and put in the effort to pass interviews is a positive signal imo.

On that note, it seems like HN has assumed the only work that exists is writing CRUD apps and not worrying about performance. There are many roles where you do need to have a strong understanding of performance and algorithms, and those are the difference between a smooth rollout and crashes in the middle of the night.

<comment><USER47> What aspect of performance though? Even that means a variety of different things to different people and it isn't just algorithms. I've met people who are bad at typical CS algorithms yet know their language of choice very well and write low-allocation high performance tight code that "does less". Or people that are used to handling concurrent code which sadly is still somewhat of a rare skill. Only the algorithms are touched on in typical CS courses; most aspects of performance tuning come from experience and persistence spending hours trying to get more performance and less resource usage out of an application.

</comment></comment></comment></comment><comment><USER48> > When hiring senior engineers, the company doesn't choose the candidate, the > candidate chooses the company.

Does that mean its the candidates fault when they can't find a job?

<comment><USER49> If you are truly a senior software engineer with all of the common skills living in most metropolitan areas in the US in 2019 and can't find a job, it most definitely is the fault of the job seeker.

</comment></comment><comment><USER50> The author is right that the firms are not selling enough and often they are too picky, have unreasonable slow and effortful hiring process with many stages of which some don't test the engineer but rather humiliate the person.

I am running a tech recruitment agency and this month I had TWO engineers who refused to take offers because the companies (two different ones) basically grilled them too much in the processes and showed off an insufficient company culture. I know both firms rather well and their environment is actually good. Seems like firms who aren't yet having a brand name like Google but who are sufficiently good tend to be arrogant enough to scare of engineers but not good enough to make them accept an offer.

The arrogance of some firms might seem irrational but it can be explained by "catastrophe avoidance". Most of the time, hiring a bad engineer is really much much worse than rejecting a good candidate - that is especially true in Europe, where it is hard to fire people. Also, every job description is a set of tasks that is supposed to be done by a person who'd better be REPLACEABLE. If you wait sufficiently long, YOU WILL FIND SOMEONE ELSE WHO FITS ALSO OR BETTER. Due to the nature of the employer-employee relationship, firms will still be "the ones on top".

</comment><comment> d--b 100% agree.

I am in a good place right now, and I get head-hunted a lot. Sometimes I answer the calls thinking "why not see what's out there?".

I can't be more annoyed when the guys in front of me just assume there is nothing else I want in life than to get into their company.

</comment><comment><USER51> There are a lot of comments in the thread claiming that there's some kind of "smooth talker" senior engineer candidate, but frankly that is preposterous and I simply don't believe all the impossibly perfect anecdata thrown around.

It is incredibly hard to talk clearly about complex projects you've solved before in the specific tradeoff circumstances of some past project or job. Someone who can do that with great clarity is extremely hard to find and valuable.

I saw one comment that said something along the lines of hearing a candidate talk fluently about tech details (at a very specific implementation level) of past work, but then put them in front of a keyboard and they go "hmm urr uhh" or whatever.

This is frustratingly dumb. First of all, senior engineers should spend way, way more of their time thinking and directing architecture choices or prioritization than writing code, _especially_ in early stage projects or companies.

Second, I'm absolutely certain that the coding question you're asking to generate this himming and hawing is some Cracking the Coding Interview bullshit trivia question that this senior engineer hasn't thought about in 20 years since their algorithms class in college because they were too busy actually solving real business problems for people (including a few rare problems that involved detailed deep dives into novel or complex algorithmic solutions).

We harass and haze people with bullshit trivia, then turn around and don't even ask them what problems they have really, actually solved before, or invent reasons to rationalize that if they solved a lot of problems before, they're just some sort of smooth talker and somehow the only proof is if they memorized Floyd's cycle detection algorithm or some other ludicrous bullshit.

What a deeply humanity-hostile industry it is!

</comment><comment><USER52> I definitely agree with some of the points (job descriptions and onboarding are generally dumpster fires, to highlight just two), but it has a little too much of a stereotypical young developer feel for my tastes. There are fine engineers out there who aren't overly concerned about the dress code, for example, but care deeply about diversity, social good, and/or benefits other than basic salary.

There is so much more to technical hiring that a leader has to know about and consider. If anyone would like to read a different perspective, I recently finished a long blog series (~60 pages if it were a book) that tries to consider a more complete human approach:

[https://medium.com/@productivitypinata/i-got-99-problems- and...](https://medium.com/@productivitypinata/i-got-99-problems-and-your- hiring-practices-are-all-of-them-cb1e6a5877ea)

<comment><USER8> Hi, author here, thanks for your feedback. I did mention that not everyone will care about these things, but I like your point about diversity and social good. Probably things I should've included.

Looking forward to reading your post!

</comment></comment><comment><USER53> I had an interview for an engineering manager role with a London fintech startup, from 11AM to 4PM, with each hour designed as a 'gauntlet' of some kind.

There were no breaks. When I went to urinate, it took time out from their quiz. Someone stood outside the door.

Interviewing is mentally exhausting: a couple of hours in I started to flag from lack of food. By the end of the 5 hours, after eating and regaining my abilities, I thought that an environment that didn't give me a moment to eat during the courting phase, wouldn't care that much for my welfare once I'd actually signed on.

After a couple of days they got back, assuming I was still interested, and told me feedback which consisted of "really knows his stuff, but is often a poor communicator". Yes, so is everyone when they're presenting for 5 hours.

</comment><comment><USER54> I might send this to the 1000's of clueless recruiters that spam me every day, and can't understand why I don't want a .net job in Wigan for £12,000 p.a

</comment><comment><USER55> On the subject of recruiter emails, I just recently got one for a job at my former employer, a clear indication that the recruiter didn't read my resume at all. Also I've gotten an offer for a 3 week contract senior developer position on the other side of the continent. I swear that recruiter must have been mental or desperate.

From my perspective as a job seeker, it's pretty obvious that recruiters really just don't care. And the weird mental games being played on applicants with increasingly stupid and inflated requirements only means you're going to have fewer applicants.

</comment><comment><USER56> Ssssh, don't let the secret out. The fewer great workplaces, the better for those of us who happen to have a great workplace and need to recruit!

<comment><USER8> Haha, author here, sorry about that. Can I quote you on that for the book? :P

<comment><USER56> Quote away. The great workplace in question is EPFL's DEDIS lab.

<comment><USER8> Awesome, thanks!

</comment></comment></comment></comment><comment><USER57> I have talked to several interviewers with a buying mindset, and the thing that annoys me the most is that they always ask why I want to work for $COMPANY_NAME, especially if it's a well known SV company.

They don't understand: I don't need your job, your recruiter called me, so what is it $COMPANY_NAME has to offer me that's better than my current senior level gig?

</comment><comment><USER58> One thing that employers should keep in mind is that the candidates they would like connect with probably already have jobs. Many people I know simply do not reply to recruiters if they are adequately paid and reasonably happy in their current job. The reason why is simple. If they did, they would simply be volunteering to spend a bunch of time doing take-home projects and coding exercises for free without even knowing if the company administering said technical assessments would pay them more or offer them a more fulfilling job!

So it's not just that you're selling (as opposed to buying) because the candidate is "senior", you're selling because you're trying to lure someone away from a job they already have. Asking someone how much they're making now so that you can offer them the same salary or a measly ten percent more and then giving a homework assignment is not exactly enticing someone to switch jobs!

</comment><comment><USER59> As a happily employed person who occasionally interviews for another job, I find coding samples a turn-off.

Why? Two reasons:

\- If the coding sample is in a language (or large framework) that I will learn on the job, I don't think I will have any success. Something that's a 20-minute job for one person could be a 5 hour "learning exercise" for me.

\- If the sample is something like a bugfix or enhancement where I have to go through the whole process, the time commitment is just too large. I have to come up to speed with new frameworks, conventions, idioms, layouts, designs, which is time consuming. Then, the review process itself may be time consuming, or slow to get feedback if company engineers don't see my work as a priority.

I prefer coding samples that require very little ramp-up and process. Let me use a language that I'm familiar with. (If I will learn a language on the job, let's agree on a language that I and the evaluating engineer are comfortable with.) The coding exercise should be fun, without assuming knowledge of extensive frameworks or processes.

In general, good coding assignments look like a high school coding competition, or a topcoder question.

[Edit]: What I've really liked, in the past, was a company that did a very basic coding sample instead of a phone screening. It took me about 90 minutes to write, and was rather fun.

What I had to do was write a small program that navigated a maze. Navigation occurred by loading parts of the maze through a web service. Other than that, there were no requirements for language, framework, process, ect.

In short, I didn't have to onboard myself, or have extensive domain knowledge, in order to do the exercise.

I find coding exercises that require extensive domain knowledge are only useful when screening subject experts. IE, we're hiring someone who has extensive knowledge in language X with framework Y and design patterns Z. Sometimes teams need domain experts, other times they need experienced engineers who learn the tools on the job.

[Edit 2] The statement "When hiring senior engineers, the company doesn't choose the candidate, the candidate chooses the company." is very important when choosing a skillset. Part of what sells a job to me is the opportunity to work on a new language, framework, ect. This is why coding assignments that require extensive domain knowledge are, ultimately, a turn-off.

<comment><USER60> My pet peeve is getting a coding assignment with a bug or syntax error or misplaced curly bracket that turns the coding exercise into a trick question. The compiler or editor would catch all that stuff so don't expect me to do it by hand unless you're paying me to work in notepad.

<comment><USER59> A good coding exercise has the candidate demonstrate that the candidate knows how to program a computer.

Stuff like that just means it's time to walk away from the interview.

</comment></comment></comment><comment><USER61> While I agree with a lot of the suggestions in this post, I disagree with the _" you're not buying, you're selling"_ part. It's just not that one-sided.

I think the proces of hiring or applying works best when it's a conversation between equals. Both the employer and applicant have something of value to offer, and both expect something of equal value in return.

Many employers and applicants act like the other side should be happy to talk to them (they're granting them a favor). If you really think the other side has more to gain from talking to you than yourself, why did you decide to have the conversation in the first place?

Sure, markets are not perfect, so the most popular employer in a city and the best engineer with nowhere-to-find expertise might both be able to act as a buyer. For the rest of us: _We 're buying, and we're selling._

</comment><comment><USER62> This is good and all, and many of the comments here explore the nuances. Something all of it seems to miss is that one persons "senior" engineer is not another persons "senior" engineer. This designation is meaningless and it usually is a failure of a company to properly assess their needs when creating a role. Some approach it by using a wishlist of framework and language knowledge (that quickly turns into a checklist). Others approach is by years of experience doing x,y,z. Fact is, a "senior" engineer is code for "person I want to hire who is right for the job and who needs little guidance". Many people fit that bill.

</comment><comment><USER63> Hot take: many (most?) startups don't need talented senior engineers and won't even pay for them. They have products that do not have performance constraints or that would benefit from mastery of any one specific technology.

What startups need is engineers who can show up to work, understand requirements, point out potential shortcomings, write code on an approximate timeline and be willing to fix their mistakes. As it turns out, you don't always need a senior engineer to do that. You certainly don't need a 10x rockstar ninja engineer.

Where I've seen startups struggle in the past is fostering a culture of mentorship. When you're hiring fresh grads or people early in their careers, your employees will want someone to give them honest and personalized advice. It's pretty hard for people that are early in their careers to fill that role, so you may need some senior engineers to do that.

Overall, I think this article is a bit fanciful in the expectations it makes around recruiting. Sharing stuff like internal processes, team size etc are definitely helpful to the candidate but are costly to the employer. This information may be confidential or provide a competitive advance. They may also vary by team will definitely vary over time. Overall I think it's unrealistic to expect the company to be very forthcoming about this type of thing until they make the offer.

The interviewing stuff also seems to come from a good place but represents wishful thinking. Companies (even startups) hold significant leverage in 99% of interview situations and therefore are strongly inclined to err on the side of false negative. Their thought process goes like this: "sure, you may be amazing but because you're not willing to jump through my arbitrary hoops (6 hour coding exercise, 3 rounds of onsites, etc) I'm willing to hold out for someone who is equally as good."

I'm not saying any of this is good for the candidate, but it's unrealistic to expect companies to start to treat senior candidates any better given the way the labor market is set up. In fact, I'd expect this kind of treatment to get worse as the bumper crop of younger engineers trained in the late 2000s starts to level up in experience.

</comment><comment><USER64> In my experience, one of the key ways to get an engineer interested in a role is to tell how much it pays up front, and make sure that number is appropriate for the experience level you're targeting.

</comment><comment><USER65> The blurred out job posting image is not very well blurred out. I could probably work out what it says if I spent some (tedious) time on it.

The point it gets across is very very clear and useful though.

<comment><USER66> It's not blurred out to hide who it is. It's blurred out so we don't get stuck in the details. It's a UX technique.

EDIT: Well...fuck. Don't know how I missed that. He actually says it's to hide the poster.

<comment><USER8> Author here, you were right though, that was the actual intention. I even cheated a bit on the highlights. I just wanted to get my point across and not get lost in details.

Not revealing the employer (without going through the work of unblurring as the HN detectives have already done) was just an added bonus.

</comment></comment></comment><comment><USER67> If you only start thinking about selling a candidate when you _meet_ one then you missed the bigger opportunity to build a corporate reputation of supporting developers in their careers (e.g. with open source, developer blogs, etc.).

With that in mind, focusing on the bits highlighted here doesn't make sense. Attract smart/experienced/motivated candidates and your boring hiring process or your flawed onboarding process doesn't matter as much.

</comment><comment><USER68> This is clickbait to sell a book. "Having trouble doing the thing? The problem doing the thing is you. Buy my book for $45, then you can do the thing."

<comment><USER8> Hi, author here, thanks for your feedback. What did you think about it was clickbait? I genuinely believe that most companies can improve a lot of things when it comes to hiring. And they don't know how to do it, because they have the wrong mindset.

If something about this was too flashy, please let me know.

</comment></comment><comment><USER69> Sorry, I see this at the end and I can't really take the article seriously any more -

> I have more than 7 years of experience in Software Development, Product > Management and Project Management

7 years is enough now, to be making industry recommendations about difficulty hiring senior staff?

I'm not saying you can't get a good idea of part of the industry in that time, but it seems a bit of a stretch to claim sweeping knowledge of the whole space.

<comment><USER70> Who knows, maybe he has valuable things to share. It's like that with any book. It also depends on the readership.

</comment></comment><comment><USER71> [Sarcasm on]I think the most shocking of this is that an engineer with 7 years is already a senior these days. I even heard more shocking things like people with 3-5 years are already seniors. So what about people with 15 years? How shall we call them? Super senior? How about 30? Call them mega-giga-super- senior? And 40? Principal-giga-senior?[Sarcasm off]

Having said that, I actually agree with everything the article says.

<comment><USER72> Senior is typically one or two promotions above the entry level. After that the titles resemble something like this:

Staff

Senior Staff

Principal

Senior Principal

Distinguished

Fellow

<comment><USER73> _Typically_, all those titles don't exist unless you're in IBM-size company.

At best, somebody might have a "tech lead" title but it's not what people hire for.

_Typically_, companies hire for grad, junior, software engineer and senior software engineer.

Maybe principal once in a blue moon.

</comment></comment></comment><comment><USER74> It's a solid, good article. But the repetitive 4 boxes to enter your email address to sign up for their newsletter, that annoyed me quickly.

<comment><USER8> Hi, author here, thanks for your feedback, I'll tone it down a bit next time.

</comment></comment><comment><USER75> I've Been fortunate enough since my first job to always find a place that wants me and sells themselves. Once in a while i ran into companies that tried the testing and other bs and i either just left or told them it would'nt happen and they accepted. Stuff like being allowed to use Linux in a Windows only organisation or not be locked in for x months was something i could talk through.

</comment><comment><USER76> You need to ask open ended questions and expect detailed answers that only an experienced engineer would be able to answer. And keep asking more and more details. Only another experienced engineer would know if that are bsing. Most companies put way too much on whiteboarding. Failing whiteboard guarantees you lose the job seem to be very inefficient.

</comment><comment><USER77> Agreed with this. There's a rebuttal on this regarding how similar this is for Senior Product Managers: [https://productmanagerjobs.com/blog/trouble-hiring- senior-pr...](https://productmanagerjobs.com/blog/trouble-hiring-senior- product-managers-it-s-probably-complicated/)

</comment><comment><USER78> I think that this should be true for any position. I find you can generally get better people working with you if you put effort into making them feel like they will be valued, compensated fairly and that the role will be meaningful. And then delivering on it.

</comment><comment><USER79> The author confuses buying/selling with supply/demand. There is no connection between them - the employer is always buying.

</comment><comment><USER80> I love how firms have an issue hiring senior engineers, when the last few firms I've spoken with deemed me "overqualified".

Another buddy with longterm CTO experience had 150 applications with a 2% hit- rate.

On the "better" AngelList CTO/Senior jobs we can clearly see that there's already 50-100 other applications submitted.

So is this really that big of an issue as presented?

<comment><USER81> constantly complaining about the job market being tough is a strategy for companies.

they could have a 1,000 perfect candidates lining out the door willing to work for peanuts.

At that point they would adjust their expectation from "peanut" to "half a peanut" and they would still moan about "skill shortage".

<comment><USER80> Similar to adding the words "bad economy" in discussions regarding performance evaluations and raises. Cop outs based on mostly arbitrary "market mechanics".

</comment></comment></comment><comment><USER82> This post was right on the money about a lot of things. Great Post!

</comment><comment><USER83> Curiously editorialized title submission?

</comment><comment><USER39> Thought I would add my own thoughts to the difficulty here and just talk about the process I brought into the last place I worked at. I came in as a Director at a time when the company had a...let's say not too great set of developers overall from a skill level perspective (the company thought they were amazing! That's maybe a story for another time). I'm proud of the process I introduced there because it led to my meeting and befriending some top tier gentlemen. While it may not work for everyone (and I understand it perhaps weeds out some candidates) it seemed to do all right. Here it is, for anyone to steal if you so feel it useful:

* Candidate applies * Within 24 hours, the candidate has a personal reply from our in-house recruiter. That E-mail explains the entire interview process in detail and sets up a brief 15-20 min phone screen with the candidate if they're okay with said process.

1) The phone screen is mostly nothing more than a brief "psychopath test" (is this person nice to talk to or are they rude or condescending?). The recruiter talks to them about their own goals, aspirations - if we approached them, we skip the "why do you want to work here" part otherwise we ask them what appealed to them.

2) The candidate is given a take-home assignment (which has no time limit but has been vetted against internal staff to take no more than really about an hour), with a note attached that says "Hey, you're likely a great and talented candidate and I'm well aware that you may be thinking that this is a waste of your valuable time. What I can assure you is that a) I'm only doing this because our industry is a sewer ;), with no real standardized screenings b) As discussed in the first E-mail, there are no further technical "screenings" coming forward - if we go to the next phase, we'll just discuss your approach to the assignment for a bit and then it's "getting to know you" time. Internally, this technical assignment is not one where two reviewers can have different "reads"; there are things we're explicitly looking for to determine overall "level", mainly with readability, approach, things like that (as just one example, a senior level candidate will know about unit testing and show something along those lines in their solution).

3) Someone reviews the submission. We reply within 48 hours.

3a) If the candidate is a no fly we don't go forward, and tell them so. If the candidate asks why, I tell them explicitly what the assignment was looking for, provide links to get acquainted with those and encourage them to reapply at a later date (we hired someone who did exactly this - those are the kind of passionate ones you want to be working with).

3b) Candidate is a go-forward; the next step of the interview is simply a discussion about "The Alliance" (Reid Hoffman, great book, at least the first half) of what they'd like to do with their career and whether the company can harmonize that into something both parties are happy with, and a getting to know the candidate a bit deeply. I told candidates explicitly at this point not to stress, as this wasn't an interrogation but simply us understanding that - to tie this back to the original posting - they were interviewing us as much as we were interviewing them.

Our hire quality sharply increased after that. I left the company a year and a half ago but that process is still in place, relatively unaltered. In fact, one person left the company, went to another company and basically "stole" that interviewing approach because he thought it was so good for finding people but also treating them with respect (which is critically important and all too rare).

TL-DR; our industry, particularly around hiring, really sucks and it's an absolute crapshoot on both sides of the equation. It's sad and really depressing; I try not to spend too much time thinking about it and more time trying to mitigate it in my small corners of the world. =) I wish it were different.

</comment><comment><USER84> We just started hiring remotely. We've 1:4 ratio of local:remote.

<comment><USER70> Define "We".

</comment></comment><comment><USER85> Infrastructure. Not a single mention in this 700 thread. Thats where senior engineers are most required.

</comment><comment><USER86> i can't believe all of the replies to this thread. us nerds get a bit too myopic about the details and fail to see the forest for the trees. let's zoom back and look at the Earth from the Moon.

what other industry has hiring rituals premised on assuming The Candidate is a shape shifting imposter and then testing The Candidate using various Gom Jabbars to verify The Candidate is a human who can code? do attorneys and doctors and professors device elaborate exams and gotcha questions to spring upon The Candidate because The Candidate might be a total fraud? to be honest, this implicit assumption that The Candidate is an outright liar and con-man and that we have to "catch" them in their lies before we let them into The Club has been an enormous turn off for me in this entire industry. and i'm saying that both as The Senior Engineer put in charge of hiring developers as well as being The Candidate dozens of times and having to go through multiple Voight-Kampf tests to prove "yes, i can code."

why don't attorneys and doctors have the same problems we do? they pay more, so the incentives are there for The Candidate to rote memorize a bunch of text books and talk impressively while being unable to perform The Work themselves. is the problem that anyone can call themselves a Software Engineer and there is no way to prove it? is the problem inherent to the nature of software itself, in that the problems we solve and the solutions we apply are constantly changing ephemeral logical abstractions which cannot be repeated because every context has a totally different set of constraints, so it always reduces to Apples vs Oranges? is the problem inherent to the nature of Nerds and Autists and the personality types who tend to become software engineers? is being a Coder the Nerd's version of The Jock's hazing rituals? are we Nerds just as big of bullies and assholes as The Jocks, bullying our own and shaming each other against meaningless goal posts? we often hear now about how our Industry lacks "diversity" and how we need to be more "inclusive" to women and blacks. well how do you think women and black people feel about our bizarre and harsh hiring rituals of hazing and shaming and accusing of being The Imposter and your Interview test is to prove to us that you are not? i think we as an industry need to tone down our bullying hiring rituals if we hope to ever stop being an elite club of oppressors.

just last week i got rejected as The Candidate because i didn't have 10 years of React experience. "sorry, you're not senior enough", even though i had twice the number of years of raw dev experience than the punk kid over ten years younger than me who was in charge of hiring. i have seen this happen to me a dozen times, where i am rejected because i know too much about a Domain, and can go into gory technical detail about internals and implementations, which intimidates The Juniors who know one Javascript framework and think they are Seniors and who don't want a Real Senior around who might take their promotion slot away from them.

i don't even think in terms of "Junior" and "Senior" anymore. those are not useful buckets to divide the vast world of software development. instead, i think in terms of "what rad shit have you coded and what gets you excited about code and what kinds of things do you wish you could code or what do you code for fun on nights and weekends?" sadly, the vast majority of "professional coders" draw a blank at that question and they have zero answer, because for them coding is just a job. they never even knew it was For The Love of the Game. general interest and curiosity seems to be a better litmus test, because "interest is aptitude", and if you're the kind of brain who takes things apart for fun to figure out how they work and then try to put the system back together, then that proves you're a left-brain thinking INT(J/P) type of mind who is naturally suited for software engineering. the rest can be taught or learned on The Job as needed to fill in the gaps.

</comment><comment><USER87> Thought I would add my own thoughts to the difficulty here and just talk about the process I brought into the last place I worked at. I came in as a Director at a time when the company had a...let's say not too great set of developers overall from a skill level perspective (the company thought they were amazing! That's maybe a story for another time). I'm proud of the process I introduced there because it led to my meeting and befriending some top tier gentlemen. While it may not work for everyone (and I understand it perhaps weeds out some candidates) it seemed to do all right. Here it is, for anyone to steal if you so feel it useful:

* Candidate applies * Within 24 hours, the candidate has a personal reply from our in-house recruiter. That E-mail explains the _entire_ interview process and sets up a brief 15-20 min phone screen with the candidate.

1) The phone screen is mostly nothing more than a brief "psychopath test" (is this person nice to talk to or are they rude or condescending?). The recruiter talks to them about their own goals, aspirations - if we approached them, we skip the "why do you want to work here" part otherwise we ask them what appealed to them.

2) The candidate is given a take-home assignment (which has no time limit but has been vetted against internal staff to take no more than really about an hour), with a note attached that says "Hey, you're likely a great and talented candidate and I'm well aware that you may be thinking that this is a waste of your valuable time. What I can assure you is that a) I'm only doing this because our industry is a sewer ;), with no real standardized screenings b) As discussed in the first E-mail, there are no further technical "screenings" coming forward - if we go to the next phase, we'll just discuss your approach to the assignment for a bit and then it's "getting to know you" time.

Internally, this technical assignment is not one where two reviewers can have different "reads"; there are things we're explicitly looking for to determine overall "level", mainly with readability, approach, things like that (as just one example, a senior level candidate will know about unit testing and show something along those lines in their solution).

3) Someone reviews the submission. We reply within 48 hours.

3a) If the candidate is a no fly we don't go forward, and tell them so. If the candidate asks why, I tell them explicitly what the assignment was looking for, provide links to get acquainted with those and encourage them to reapply at a later date (we hired someone who did exactly this - those are the kind of passionate ones you want to be working with).

3b) Candidate is a go-forward;

the next step of the interview is simply a discussion about "The Alliance" (Reid Hoffman, great book, at least the first half) of what they'd like to do with their career and whether the company can harmonize that into something both parties are happy with, and a getting to know the candidate a bit deeply. I told candidates _explicitly_ at this point not to stress, as this wasn't an interrogation but simply us understanding that - to tie this back to the original posting - they were interviewing us as much as we were interviewing them.

Our hire quality _sharply_ increased after that. I left the company a year and a half ago but that process is still in place, relatively unaltered. In fact, one person left the company, went to another company and basically "stole" that interviewing approach because he thought it was so good for finding people but also treating them with respect (which is critically important).

TL-DR; our industry, particularly around hiring, really sucks and it's an absolute crapshoot on both sides of the equation. It's sad and really depressing; I try not to spend too much time thinking about it and more time trying to mitigate it in my small corners of the world. =) I wish it were different.</comment>


Monitor anything and get free notifications on your iPhone (via notifo.com) - <AUTHOR> http://amix.dk/blog/post/19526#Monitor-anything-and-get-notifications-on-your-iPhone

<comment><USER2> This kind of server monitoring is exactly why we wrote and released <http://www.nerdkits.com/files/notifo/> two months ago (although our server monitoring component itself hasn't been released). We don't use it for payment notifications as the screenshot might suggest, as that would get annoying very quickly! Instead, my co-founder and I get notifo alerts when anything might be out-of-bounds: daemons not running, load averages, memory usage, DNS/web test queries, various queues, etc. This gets tied in with our internal business dashboard, so we can see warnings before they get to the "failed" state that triggers a notifo, or usually just see a bunch of nice green checkmarks underneath our sales stats!

Honestly, after running it for 2+ months, the problem is that it's been _too_ sensitive, so recently the progress has been in adding logic to make it ignore and/or fix and/or retry without notifying us at all. For example, if one of our secondary nameservers is unreachable, my script knows that I don't care, but it will let me know if two or more are down -- and only after trying a few times. And if our Asterisk instance can't talk to our SIP provider, then it will instruct Asterisk to try to reconnect. Another example is in our Django FastCGI processes restarting after serving a bunch of queries (to reduce the effect of process memory growth / leaks): if our script does its checks at that time, it may notice one extra or one fewer process running, so it will wait a few seconds and then check again.

At the end of the day, while notifo is only a small piece of the code at this point, it's a core feature that motivated this "autotester" server monitoring script and makes it a must-have for us. We've had it running for long enough that we have fairly good test coverage for all of the moving parts of our server, and over the last few weeks have been able to write some smarts into it so that the frequency of Notifo alerts is small enough that they're usually worth looking into.

From a business perspective: This lets my co-founder and I sleep much better and have our mind off of server operations when traveling. That's a real benefit. Thanks, Notifo!

<comment><USER3> Great to hear about a Notifo use case like this - thank you for sharing!

edit: on the subject of electronics, we (chad and I @ notifo) have had an idea for little project for a while. So we work in a garage and think it would be neat to hook in RFID + arduino + solenoid + wishield or wifi yellowjacket + notifo for garage access logging/notifications. IE, one of us gets a notifo when the other tags his RFID to get into the office. I guess we're just looking for an excuse to dust off our arduinos..

</comment></comment><comment><USER4> Very cool, Amir. We're flattered that a busy hacker such as yourself would take the time to write this up :)

<comment><AUTHOR> I think you guys have a cool service. I was about to setup nagios+Clickatell for service notifications, but 30 mins into the configs from hell I dropped this idea and started to work on a custom solution.

Happy hacking, I am keeping an eye on notifo :)

</comment></comment><comment><USER5> You can do this with Femtoo.com (it's already listed on the Notifo homepage as a recommended service). Try it - it's cool!</comment>


Mark Cuban Says Major in Philosophy, English or Sociology - <AUTHOR> http://www.cnbc.com/2017/04/21/these-college-majors-are-the-most-robot-resistant.html <comment><USER2> Mark is also the that recently tweeted a picture indicating that he as working through an "into to python for machine learning" book. He may have been successful in tech 25 years ago, but I don't place a premium on his opinions of where things are going. Advising someone who does not intend to go into the academic field to major in any of those is pretty poor career advice. Either you want to work in academia or you just love the subjects and will figure out money through other means... only plausible reasons to pursue those majors. Of course you don't have to worry about automation impact on degrees that have little to no correlation to job-placement anyway.

</comment><comment><USER3> I would imagine that jobs that combine a high degree of fine motor skill with judgement and technical expertise, such as plumbing or dental work, will be some of the last to be automated. To make a robot that can do those jobs as quickly and safely as a human is going to take a while and cost a lot.</comment>


Ask HN: How to get feedback? - <AUTHOR>

After submitting a pair of Show HN (SHN) stories I was a bit dismayed to see they received zero interest, particularly as I got up at 6am to post one. ;) http://news.ycombinator.com/item?id=4196039
I wonder what's wrong?  Surely the site must suck (first release should be embarrassing right?), but even so a few "this sucks ..." replies would be much preferable to the deafening indifference I received instead.
Looking over hnshowcase for the last few days I see that the majority of SHNs get 0-1 votes or 40+.  I haven't seen a clear division in site quality between the two groups though, as many of the interesting are the ignored.  At risk of sounding like a whiner, should I have enlisted a network of employees or upvoters first?  I'm just a single guy and this is my side project so I unfortunately don't have those kind of resources available.
What can I do to turn this around?  Would appreciate any comments. <comment><USER2> Uhm i can feel your pain. I do not have a clear answer for you. But i can make assumptions.

People know each other. A lot of people on this site are in the startup scene from SF NY etc... many know each other personally. This is a huge help.

People cheat. i do not have any proof but sometimes i notice that something that might not be totally worth gets boosted by many points in a short time period. This can be by bot or maybe even being in a small company can help. Everyone gives a vote from the pc and the smartphone and the number goes up.

Sometimes it takes very little. I think that if a thread get a couple of votes in the first 30 minutes it is more likely that people will open it and will vote it. Generating an exponential effect. Same with comments. It takes very little to distinguished your thread from the mass. If you do not abuse it do not be ashamed of resubmitting your thread a week later. Maybe with a new title. Title is also very important.

I usually look mostly at the new section just to find threads that are worth an help. And i am sure there are other people that do it. You just need to be a little lucky. Keep in mind what might be the most interesting hour to submit for you target audience and try. But please don't abuse.

About you submission, you did a good job. You learnt something new, that's the most important thing. You might want to work maybe a bit more on the design, especially the colours, it feels, old. But really liked that hovering an event would highlight it on the map ;)

<comment><AUTHOR> Thanks, I'm having the same realization. It helps a lot to confirm that others are too.

Re: the design, yeah I'm a programmer not a designer. I liked the Japanese color scheme and thought it looked unique. My two design goals were simply uniqueness and to avoid images/bandwidth costs, so there are some "old school" elements such as the clipart.

Thankfully there is a provision built in for theming. There are a few choices already, but I can make one with blue.

</comment></comment><comment><USER3> I thought of an idea similar to this a few years back but a VERY different implementation. Unfortunately the project was finished (in code) but never launched due to limitations of other platforms at the time to support the overall way the solution worked. Its a good problem to solve.

</comment><comment><USER4> my take: a nice demo/tutorial would be nice. i went to <http://lax.kpasa.co/> and didn't know what i was supposed to do. how do i use it?

+1 if you can demonstrate _within the demo_ why your service would add value to me as a user. sell the service to me. tell me what i can get if i use this service.</comment>


US Gov Requests Feedback on Open Access – ACM Gets it Wrong (Again) - <AUTHOR> http://www.realtimerendering.com/blog/us-gov-requests-feedback-on-open-access-acm-gets-it-wrong-again/

<comment><USER2> What a golden quote:

"How would U.S. voters react to a Senator claiming that a given piece of legislation (say, one reducing restrictions on campaign financing) "strikes a fundamental balance between the needs of the Senate and those of the United States of America"?

In my minds eye, I saw Joe Lieberman giving a press conference: "The health- care bill now strikes an appropriate balance between the interests of Joe Lieberman and those of the United States of America".

<comment><USER3> Well, that actually seems more reasonable than the ACM situation. I _expect_ Lieberman, as an individual, to have interests that are not the same as his constituents'. (He may be derelict in his duty as a Senator if he puts his own interests above those of his constituents, but that's a discussion for another day.) But there's no reasonable expectation, in my mind, that Lieberman's interests as an individual and my interests as a voter are going to be the same.

Likewise, I wouldn't expect the interests of one of the ACM's directors -- as individuals -- to be the same as the ACM's membership. (I'd want them to set aside their personal interests while acting in their official capacity within the organization, but that's different from saying that their personal interests don't exist.) But I would expect the ACM _as an organization_ to reflect the interests of the membership.

When an organization that supposedly exists for the benefit of its membership starts doing things that are almost certainly out of line with the best interests of the membership, it's a good sign that the organization has been subverted and is being used for some other purpose (e.g. simple self- perpetuation).

</comment></comment><comment><USER4> I just left the following comment on the OSTP blog: (We submitted an NSF proposal yesterday, so this is particularly well-timed.)

As a graduate student and researcher in Computer Science I would welcome the application of NIH's open publication policy to NSF funded research as well. I just helped submit an NSF proposal and would welcome such guidelines on our research. We already follow them for the most part, and it would help us ensure that conferences and publishers won't object to the dissemination of the results of our research if it's not just our own desire, but an obligation from our funding agency.

I would also appreciate if you look into the feasibility of establishing open data and open source requirements for the CISE division of NSF where funded projects would be obligated provide data generated as part of the research (this isn't always reasonable, so some care will be necessary in formulating this policy) as well as source code used. Right now, especially in computer science, it's extremely difficult to replicate the results of experiments and often we find that researchers have to invest time in reverse engineering someone's experiment simply to be able to compare the results one research got with the results of another or their own work. In addition, university technology transfer departments sometimes get in the way of researchers who try and open up their work. Making this a firm requirement from the funding agency provides the researchers with the credibility and leverage they need to ensure technology transfer departments stop interfering with dissemination efforts.

It's rare someone ever asks for a requirement, but in this case I think extending these types of requirements to NSF programs will give us the power and leverage we need to overcome the obstacles in the way of disseminating our work in the fashion we'd like to be doing anyways.

</comment><comment><USER5> Article is spot on.

This makes me want to cancel my ACM membership. Which I only got in the first place so that I could get access to their digital library of published papers.

</comment><comment><USER6> I'm sure they're worried about a membership drop, but you really would think that the ACM of all people would understand that false scarcity is not a business model for information-based organizations in today's world.

</comment><comment><USER7> The ACM have always been a bucket of dicks -- their Digital Library index pages dominate Google search results but have no content.

They used to have some intentionally confusing text like "Please login with your free ACM Web Account to see the full text". Sure the account itself is free, but the subscriptions required to see anything ain't. All that happened is that I get spammed by them regularly with _Join ACM today and receive a 15% discount plus an ACM Free World Clock Calculator!_

A desk calculator! I don't see how they could be more out of touch.

</comment><comment><USER8> As much as I'd like to see open access to ACM and other journals, I wonder how much it would benefit anyone? Surely almost everyone doing that work has a subscription. If not an outright membership, at least the University library will get them the articles.

</comment><comment><USER9> Screw ACM, glad I ignored all their spamming to get me to renew my membership. Never again.

</comment><comment><USER10> Good thing my ACM membership has just expired.</comment>