Skip to content

HN Job Posting Thread

Person refusing bag of moneyIf you aren’t an avid follower of Hacker News, you might not be aware that once a month there’s a job posting thread on the site. This community has its rough edges, like any other, but this thread offers a great place to reach the audience–software developers, startup aficionados and technologists of all stripes. Here’s the April 2018 job thread.

I find this a bit more credible than the job sites because there’s community policing and because it expires there’s less incentive for recruiters or other bad actors gaming the system. Because it is free and specifies only employees of a company may post, I think that the job openings are more genuine. You often see hiring managers post their contact info, and an email to them is far more likely to get a response than submitting to an applicant tracking system. You can often find salary ranges, and the audience and posts are global. It’s also worth noting that this feeds into some other sites like

I have posted on behalf of a few companies for which I worked and have had a decent hit rate. Haven’t seen any real success numbers though.

Whether you are on the market, hiring, or just curious, more data is usually useful, which is why this is always a thread I peruse. If you want to look at previous months postings, you can see them in this bot’s submissions.

Remote work opens up the labor pool

PoolThis tweet from Justin Searls (from TestDouble) discusses how companies who hire remote developers don’t have any issue finding applicants (to the point where they don’t need to pay recruiting fees). This doesn’t surprise me at all. There are a number of reasons why remote work will lead to more job applicants.

  • There’s a larger labor pool. This is the biggest advantage, and accrues to both sides of the labor market. (There’s a larger labor pool, but there’s a larger set of hiring companies as well.) Even if you are in SF, the labor pool for a particular technical skill is going to be larger if you include remote work (because your pool will include everyone in SF as well as everywhere else). If you can handle the legal tangle, your labor pool can extend past national boundaries as well.
  • The remote developer has more time. Typically the “commute” for a remote worker is on the order of minutes or seconds, as they walk to a different room in their house. Compare this with tens of minutes or hours of driving, public transit or biking. A commute to an office is a hidden job expense which can total hours of unpaid labor every week (or you could look at it as the price you pay for living where you want to live, as opposed to where your employer is located).
  • Remote work promotes different, less intrusive communication practices. Meetings take place on slack. PRs are reviewed online, rather than code review happening by looking over someone’s shoulder. Aysnchronous communication is favored (although that can certainly happen within colocated companies as well). These processes are far better for knowledge sharing than anything else, especially as a team scales.
  • Similarly, flow is easier to achieve when you are a remote worker, as long as you turn off your notifications (and set up your office appropriately). Depending on your workload this can be valuable and/or appealing.
  • Remote developers in general have more control over their environments. Most people enjoy this control (which, by the way, is free or cheap to the company).
  • People don’t have to uproot their lives to work for an interesting company.
  • There’s a larger labor pool. This is so important it’s worth listing twice.

There are of course many benefits to being onsite.

  • Easy, free, higher bandwidth communication that doesn’t require downloading yet another video conferencing plugin. Humans have been communicating face to face for hundreds of thousands of years and are finely tuned communication machines. If communication is a wall of text, context can be lost and misunderstanding can ensue.
  • Interaction outside of work is easier. This can be more important for different folks at different times in their career.
  • Water cooler/serendipitous department cross pollination can occur when people are in the same physical space.
  • Some types of technical discussion are just easier in person (I still haven’t find a truly great online whiteboarding application).
  • Some folks have a harder time staying focused or being motivated at home.

There are of course solutions for remote workers for all of the above onsite advantages. Every company and worker needs to determine what works best for them.

But just like e-commerce changed retail and social networks changed keeping in touch with old friends and work colleagues, I expect remote work to remake the modern team organization structure.

PS For more on this, consider this subsequent tweet from Justin.

When you manage, do unto others as they’d have you do unto them

A famous person once said “do unto others as you’d have them do unto you”. That is, treat others like you’d like to be treated.

As a manager, heck as someone who wants to get things done in an organization, that’s the baseline. If you can’t treat other people with respect and empathy, you’re going to have a hard time getting anything done. You might be able to get some stuff done by yourself, or via transactional behavior, or via fear. (By the way, if this is common in your organization, I’d look for new work because this type of motivation is symptomatic of a toxic workplace.) To really build a strong team, you need to, at a minimum, treat others as you’d treat yourself.

However, to be effective as a manager, this isn’t enough. Rather than treating others as you’d like to be treated, you need to learn how others would like to be treated. And then treat them that way.

What does that mean? Well, within the context of a software development team (where I have had direct management experience) you need to figure out what motivates each member of your team and, within the limits of your organizational capacity, give that to them. “Jane” may be motivated by the opportunity to work on the front end, whereas “Biyu” may want to focus on her algorithms. Some team members may want to start new projects, others may want to refine processes and make existing applications work really well.

This motivation changes over time, of course. This introduces additional complexity. When “Bob” joined the team, he might have been motivated by the opportunity to work with new technologies, but a few years in he may be more motivated by really impacting user experience.

The best way to figure out what motivates someone is to ask them. Hence the emphasis on 1:1s in the software business, where the employee controls the agenda. Another good way to decipher motivation is observation. Does “Olaf” spend extra time working on project A but is dragging his feet on project B? If so, why? Is one more UX focused, and the other more algorithmic? Such observations can also be starting points during the 1:1: “you seem to really be enjoying project A. What do you like most about that work?”

If your team or company can’t offer what someone wants, then it may be time for them to move on. The best managers I know were excited when I moved on because I judged it’d make me happier. This isn’t easy for the organization, but if you are playing the long game, the former employee will be an ambassador for you. Whether that is referring business or other employees, the goodwill can benefit the company. Contrast that with a company that holds on to a valuable employee even if they are unhappy (with golden handcuffs or other less savory mechanisms). When the employee finally leaves, there will be no reservoir of goodwill. Even before linkedin and glassdoor, this was no good. Now that folks can look up where people previously worked (and possible employees should do their research), the way you treat folks will be shared.

Overall, the key is to realize that what may excite you, or would excite you if you were an individual team member, or what might have excited you at a particular stage of your career, may not excite a team member. So, rather than put them in your shoes, put yourself in theirs.

When should you leave a job?

Saw a great post by Kathy Keating, on a slack of which I am a member. This is how she suggests thinking about whether to stay or go at a given position:

1) Are there ethical issues? Leave.

2) Are there leadership issues?


2a) Can I have transparent/open dialog and is there hope that the leadership issue can be addressed? Timebox length of stay.

2b) No dialog. No hope of addressing issues. Leave.


3) Are there systemic company process issues?


3a) Company knows and is addressing the issue. Timebox length of stay.

3b) Company is fine being a mess. Leave.


4) Do I have career growth?


4a) No. Leave.

4b) Yes. Stay if no other blockers.

This is a lightweight framework to consider when you have a bad day or week at work. It’s important to acknowledge that:

  1. I (and most other software developers) are very privileged when it comes to job expectations. (My SO worked in healthcare and the stories, oh the stories.)
  2. The grass is not always greener and if you stay you might have credibility to effect change.

I think there are other factors that might play in here like type of work, location of work, and compensation, but in general I love this flow chart of how to decide whether or not to stay in a job. If there are other items that are important to you, add them into the decision tree, but having something like this will make it easier to make a hard decision like leaving a company.

PS No post about deciding to leave a job would be complete without referencing Shields Down and Bored People Quit.

When is a senior engineer not a senior engineer?

The technology industry has been overloading the term ‘senior engineer’. A senior engineer is not a senior engineer is not a senior engineer.

What “senior” really means depends on what your organization needs and how it operates. Much of my experience has been in small organizations, so this list may be tilted more toward jack of all trades, but I’ve seen some of these patterns at larger companies as well. Here are a number of attributes that all seem to get wrapped up in the word “senior”.

Domain knowledge: sometimes getting up to speed on a domain can take too long. If you are operating in a highly regulated or intricate problem domain (real estate, finance, health care, government contracts), senior may mean “this is not their first rodeo”. In other words, someone who can jump in and understand complicated entity relationships and acronyms quickly.

Deep technical skill in the problem space: someone who has been there before. ‘There’ is a technical area where screwing up is going to be very bad for the company, for example, scaling an application, running a database or securing an environment.

Deep technical skill in the exact technology: someone who has used your exact technology stack before. The idioms, the libraries, the warts, all of these vary enough and if you want someone senior in technology, a close substitute won’t do. If your app is in Django, you need a senior Django person, you don’t need or want someone with Rails or Laravel experience. Same for someone with PostgreSQL experience (as opposed to MySQL). I see lots of job applications where this was a belief, but fewer organizations where this is a reality. This is often just a simple way to filter applicants.

Broad technical skill in a related area: someone who has used something similar and can come up to speed quickly by making analogies between similar situations. Maybe you can’t find that exact match. In that case, you can broaden your search. At a hight level, MySQL and PostgreSQL have a lot of similar characteristics, and mapping knowledge of PostgreSQL into MySQL (or vice versa) can be effective. This senior developer works best when paired with a someone with “deep technical skill in the exact technology” person because then they can pick up idioms and libraries.

Utility player: this type of senior developer can fill gaps in your team. They notice what isn’t being done, whether that is setting up a build system, documentation, project management, user testing, design or something else, and either do it or advocate for it. Or both. Probably more important in smaller organizations.

Leadership: this is the ability of a senior developer to lead a team toward a business goal. This includes understanding why the goal is important, caring about the goal, communicating the goal to the team, and rallying the team when the goal seems unattainable.

Mentoring: this is the ability to develop other talent in your organization. Whether or not there is a formal mentorship program, skills transfer and teachable moments happen every day (and are not always performed by the more experienced party!). Doing this requires empathy. If your organization has a lot of less experienced developers, a more formal program may be useful.

Humility: senior developers are senior because they’ve made mistakes. This is the ability to acknowledge mistakes, learn from them, and try to figure out how to make only new mistakes.

Continuous learner: this type of senior developer is looking at new technologies and developments and seeing how they map into the current problem space. Often they are just “playing” with technologies on their own time. If they’re really good, they’ll acknowledge their “shiny object” syndrome and advocate for ways to explore new technology that don’t impact long term maintainability (spikes, hackathons).

Cross department communication: the ability to build a mental model of who knows/owns what in your organization. When hiring a new developer, they won’t have this map, but they may have built one for previous organizations. Someone with this knowledge knows who to ask to get something done, or who needs to be notified when changes are coming. This can prevent the significant pain of building the right solution to the wrong problem. Leveraging someone with this skillset cuts down on formal process, but eventually these communication channels may need to be formalized as the organization grows. Probably more important in smaller organizations.

Project management: depending on the size of your team or organization, a senior developer may need to be the adhoc project manager. They probably won’t enjoy this much, but someone has to do it. They’ve seen what happens when someone doesn’t (see “Humility” above).

Development support/operations/devops: this is the glue around your application that helps your application function. These tasks can range from developer focused tasks like a coding style guide or maintaining the developer docker image to operations tasks like setting up the monitoring system to devops tasks like debugging the failing jenkins job.

Deep knowledge of current application: this obviously isn’t a senior position you can hire for, but is one that a developer can grow into. This is the senior person that knows all the answers about the growth and path of the application code. If they’re really good, they document and share the knowledge.

When you are posting a job description for a “senior” engineer, think about what dimensions listed above matter. You can’t find someone who is good at everything, so what do you really need? What does your organization need?

Coding tests for interviews

Ahmed Fasih posted his proposed alternative to a HackerRank pre-interview test. This sparked comments in the HN discussion.

I think it is worth approaching these kinds of tests from both sides, as this topic has come up a lot in some email lists of which I am a member.

As an employee, you want to be assured of the best chance of finding a job that is a good fit, and of minimizing the time spent to apply to each job. You also want to maximize the number of jobs you get offered, so you have optionality (“well, I’d love to work for you, company XYZ, but I’m considering other offers and was wondering if you could give me more XXX” where XXX is whatever you desire, money, time off, health care, etc).

As so many employees say in the discussion, if you are a senior person, these kinds of tests can be a bit insulting and disconnected from the actual work. Who is going to transform a 2D array in their regular job? I’d reach for a library or stack overflow answer.

On the other hand, if you are at the point where you need to fill out an online test rather than talking directly to the hiring manager about how you can solve her pain points, maybe that’s a problem? LinkedIn is pretty magical in terms of finding this info out, though of course there may be corporate protocols that make this circumvention impossible.

As an employer you want to find the best person for the price in the shortest amount of time. Where best depends on the position, but is some mix of skills, culture fit, desire for the job, and perceived amount of time they’ll stay. You also want to be fair to all applicants and have some kind of apples to apples means of comparison.

As so many managers say in the discussion, these tests weed out folks who can’t code their way out of a paper bag. If you’re a senior engineer, you’ve probably worked with some folks like that, so you can see the need. They also do so relatively quickly and in a way that scales and is equitable across different candidates.

So, as a senior engineer, I’d:

  • seek employment where I could circumvent these types of tests through my network
  • avoid these types of employers unless it was a great job
  • if I had to take the test, try to have sympathy with the employer and take it as an opportunity to brush up on my algorithms

And if I were the employer, I’d think about these tests are a filter. Just like a GitHub profile, they’ll give you some information. Whether that information is relevant to the current candidate search, and is worth filtering out good candidates who don’t bother filling out tests, is an exercise left for the reader.

Absence of evidence is not evidence of absence

I am on a mailing list of engineering leaders and someone mentioned that they have found Github to be a very good indicator of whether a candidate is a good choice for them.

Of course, every company will emphasize different aspects of software development–for some technical expertise is more important than communication, while others have that ranking flipped. Some may emphasize ability to work in large teams, while others may prefer folks who are self driven.

But I see a fair bit of emphasis on Github profiles, which makes sense–you can actually look at the code someone has written, and how they developed it.

But here are some reasons why someone might not have a stellar Github profile.  They might:

  • prefer to use bitbucket so their code is private
  • have a restrictive employment contract
  • not want to program when they go home
  • want to learn about software by experimenting on their local computer
  • learn about other aspects of software development by reading rather than doing
  • focus on answering questions on Stackoverflow
  • not have time to have anything on their profile due to other commitments

If someone has a great GH profile, that’s probably an indicator they are a good developer. But if they don’t (full disclosure, mine is kinda weak), that’s no indicator of anything other than that they haven’t made it a priority.

Hiring: Apples and Oranges

I ran across this great article about hiring in my twitter feed.  (Incidentally, the author is seeking employment at the moment.)  Here’s the author’s take on what’s wrong with hiring in tech today:

Job postings focus on the current tooling and products rather than factor in future plans. Interviews focus on the immediate technical knowledge and abilities of candidates, rather than on the candidates’ capabilities for learning and adapting. Companies hire the wrong people for the wrong reasons, then are surprised to find they can’t scale or adapt to meet strategic goals.

It really resonated.  It crystallized what I’ve seen reading and writing job descriptions over the past 20 years, which is typically an over focus on hard skills and an underfocus on softer skills.  From a higher level, it’s a focus on immediate needs vs long term compatibility (perhaps the emphasis on ‘fit’ is a counter to that).  Job postings focus on current needs to the exclusion of adaptability because it’s a lot harder to measure adaptability.  After all, everyone is capable of change in some aspects of their lives, so how do you know if an employee can handle change in the particular manner you need?

The entire article is worth a read.  Next time you write a job requisition, think about whether you need someone to hit the ground running with a particular technology, or whether you can afford to hire someone who’ll have to either be trained up or transfer skills from a similar but not identical concepts (from rails to django or vice versa, for example).  If the former, do they need to be an employee, and if so, what will happen to them when the exact need is done?  If the latter, you’ve vastly expanded your talent pool.

Interview with a boot camp grad

Lots of folks are moving into development and technical fields these days.  I remember that happening during the dot com book, but back then folks just read one of those “Learn Java in 24 Hours” books.

Nowadays there are a profusion of boot camps that help people gain the skills they need to be a developer. I have interacted with a few of these grads and was interested in learning more about their experience. Noel Worden, one of the organizers of Boulder.rb and a blogger, agreed to an interview.

– what was your background before you were a developer?

I got my degree in fine art photography, spent 5 years working in NYC as a Digital Technician in the photo industry, then moved to Colorado and was a cabinetmaker for 3 years.

– how did you land your first job?

I found the posting on the Denver Full Stack meetup whiteboard (

– what surprised you about the software industry?

How willing everyone is to help. It’s very different in the photo world, [which is] much more competitive, it’s hard to find guidance and mentorship.

– how did you pick your boot camp?

Bloc had one of the longest curriculums I could find in an online program. I figured when push came to shove, having more experience under my belt couldn’t hurt when competing with other junior [developers] looking for that first job. Bloc also has a part-time track, which allowed me to still work [a] full-time job while going to school.

– what is good about the job? What is challenging?

I appreciate the balance of being challenged but knowing I have the full support of any other engineer on the team if I need to reach out for assistance. Canvas United [ed: his current employer] has a lot of projects that I’ve been maintaining lately, and all are running different versions of Rails, which makes for interesting challenges. 

– what do you see current boot camp students doing that you’d advise against?

Not getting out and networking while going to school. This industry is all about networking and if you’re hoping to capitalize on the advantages of a good network you have to be building it while still in school.

– why did you want to transition into technology and development?

I wanted/needed a career path where the leaning curve wouldn’t plateau. I’m not a ‘cruise control’ kind of person, as soon as the challenge isn’t there for me anymore I lose interest.

– how can employers help boot camp grads in their first job?

Be ok with answering questions, and be transparent with the employee about the proper channels to ask those questions. Also, be upfront about the fact that it’s ok to fail (assuming that’s the case) a few time before you get to the best solution [ed: if it isn’t ok to fail, find a new job!]. Also also, a healthy balance of low hanging fruit and multi-day problems. Nothing kills my morale faster than ticket after ticket of problems that grind me into the ground.

– should employers have any different expectations of a boot camp grad vs someone who just graduated from college or high school?

I definitely think that it takes a particular type of management style to successfully level up a boot camp grad. If you’ve hired them you must have liked something about them, play to those strengths, but also sprinkle in challenges to help that developer evolve.

[This content has been edited for grammar and clarity.]

Gluecon 2015 takeaways

Is it too early to write a takeaway post before a conference is over? I hope not!

I’m definitely not trying to write an exhaustive overview of Gluecon 2015–for that, check out the agenda. For a flavor of the conversations, check out the twitter stream:

Here are some of my longer term takeaways:

  • Better not to try to attend every session. Make time to chat with random folks in the hallway, and to integrate other knowledge. I attended a bitcoin talk, then tried out the API. (I failed at it, but hey, it was fun to try.)
  • Talks on microservices were plentiful. Lots of challenges there, and the benefits were most clearly espoused by Adrian Cockroft: they make complexity explicit. But they aren’t a silver bullet and require a certain level of organizational and business model maturity before it makes sense.
  • Developer hiring is hard, and it will get worse before it gets better. Some solutions propose starting at the elementary school level with with tools like Scratch. I talked to a number of folks looking to hire, and at least one presenter mentioned that as well at the end of his talk. It’s not quite as bad as 2000 because the standards are still high, but I didn’t talk to anyone who said “we have all the developers we need”. Anecdata, indeed.
  • The Denver Boulder area is a small tech community–I had beers last night with two folks that were friends of friends, and both of them knew and were working with former colleagues of mine. Mind that when thinking of burning that bridge.

To conclude, I’m starting to see repeat folks at Gluecon and that’s exciting. It’s great to have such a thought provoking conference which looks at both the forest and the trees of large scale software development.