Skip to content

Jobs - 2. page

Questions to ask interviewers

Person in suitI’ve been doing a fair amount of interviewing lately (looking for work, not hiring) and there’s always that moment when the interviewer asks “so, do you have any questions for me”. Here are some of my favorite questions:

  • How long have you been working at company YYY? This helps me understand their perspective on the company. If they are new, they’ll have fresh eyes. If they have been at the company for years, it’s interesting to understand why they’ve stayed. This can also lead to a discussion of turnover.
  • What is a typical day like for this position? This helps me understand what the company emphasizes. This can also lead to a discussion of the development cycle (weekly releases, etc).
  • Who are your typical customers? When talking to a company, I always want to know who they sell to. This shows I have an interest in the company beyond just the tech work I’ll be doing. I want to hear words like “wide variety of clients”, “we find most of our customers by referral” or “we’re focused on niche YYY”. Of course I can always do research and see how the company markets itself and see if what I am hearing from the interviewer is consistent with how the company presents itself.
  • What do you do when folks are on the bench (if it is a consulting company)? “The bench” is where consultants who aren’t making money for the company are. What kind of projects are they working on? How often are folks on the bench?
  • Finally, what is the worst part about working at company YYY? This is the inverse of the “what is your biggest weakness” question that is sometimes asked. But every company has its warts. I’m probably going to find out anyway, but it’s good to ask and get the interviewer’s perspective.

What are your favorite questions to ask interviewers?

Jobs Lifehack | moore | | Leave a comment

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.

Jobs Recruiting | moore |

What is your BATNA?

When you are negotiating, you always want to be thinking about your Best Alternative to a Negotiated Agreement (BATNA). This applies in any negotiation, whether business, personal or even with yourself. When you have a better BATNA, you have more negotiating leverage and are more likely to get what you want out of it.

This is why when I was a contractor, I always had more than one client. Even if I was working with a good client who paid well, on time and was fun to work, I had more freedom if I had another client. Things might go south at the first client and I wouldn’t be out on the street. It’s also why I would always start looking for a contract 6-8 weeks before my current contract was finishing.

It’s why you should always get competing job offers. If you have a job offer and your best alternative is to keep job hunting, that’s not appealing. If, instead, you are choosing between two job offers, you are in a much better position. (No duh!)

It is also why it’s always easier to get a job if you have a job. The BATNA of declining a job offer when you have employment is, well, you remain your current position. Your current job may not be all that awesome (which is why you are looking) but for most folks being employed is a better alternative than being unemployed.

How can you use the concept of BATNA to improve your life?

First, be aware of the concept. Start to look at decisions in your life and think about the BATNA. Even small decisions, like ‘should I get coffee or nothing’? Or ‘what happens if I ask my wife to take out the garbage’? Or ‘should I ask for a raise’? In all of these cases, you can expect some kind of negotiation, and you can think about what the alternative is if that negotiation fails.

Second, take actions to improve your alternatives. If you are unemployed and want more leverage in the job hunt, start consulting. If your wife won’t take out the trash, can you improve your BATNA by making it easier to take out the trash yourself (maybe move the trash can into the garage)? Or building some kind of trash chute?

The concept of a BATNA is key to getting the most out of any negotiation. If you have good alternatives, you have more leverage to leave the negotiation, and if you don’t, you will need the negotiation to complete successfully.

More about BATNAs and salary negotiation here.

Business Contracting Basics Jobs Lifehack | moore | | Leave a comment

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.

Jobs Recruiting | moore | | Leave a comment

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?

Jobs Recruiting | moore |

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.

Jobs Programming Recruiting | moore | | Leave a comment

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.

Jobs Recruiting | moore | | Leave a comment

When do you earn your pay?

I was driving today and saw a bus driving in the snow. I’ve never driven a bus, but I imagine that snowy days are some of the most difficult. The roads are bad. People are crabbier. Accidents happen. You are still on the hook for making the schedule. I’m no bus driver, but I bet when the driving is easy, as in the summer during off peak times, the job is easier.

However, when things get hard, that’s when you earn your pay. Since software development is such a sprawling occupation, it’s hard to generalize about the most difficult moments, but I can mention some of mine:

  • When I face a problem that you’ve never faced before and have no idea how to tackle it (like setting up recurring bookings over daylight savings time changes).
  • When I ship a bug that costs your customers money and I have to analyze how much money was lost and a game plan to fix the bug and get them their money. Then I need to contact the customers to apologize as well as let them know what the plan is.
  • When I realize I’ve chosen the wrong implementation for a component.
  • When I realize I’ve made an architectural decision which made sense in the moment but will have maintenance and performance costs down the line.
  • When the system crashes and I know the reason, but I haven’t figured out a way to replicate it or to fix the issue.
  • When a system is slow and I am unsure where to start looking.
  • When someone on my team isn’t working out and I need to let them go.
  • When I watch a user navigate around your system and totally miss features that will make their lives much easier.
  • When I join a new project/company/team and walk into an existing system of software and personalities about which I have very little clue. And yet I want to be effective and move things forward, but need to be patient.
  • When I argue with someone about the best way forward, and then my path isn’t chosen, and I have to support the plan that was chosen.
  • When I argue with someone about the best way forward, and then my path is chosen, and I have to work with people who disagreed and may not fully support the new plan.
  • When I am at the end of a project and I just want the damn thing done, and yet I have to maintain the same level of attention to detail that I had at the beginning when the idea was all new fresh and exciting.

You don’t earn your pay for the easy stuff. It’s when the going gets tough that you really earn your pay.

Business Jobs | moore |

Founding Engineer or CTO, translated

If you wanted to re-read my post about the various technical roles a co-founder can take as a startup grows in Russian, you can, here.  Thanks to Vlad for the translation.

Bonus!  Here’s discussion on Hacker News, including my favorite comment:

Having been on both sides of the situation a couple times, the distinction is pretty simple for me: do you have a seat on the board?

If you have a board seat, great, you’re a real founder/CTO!

If you’re not interested in the board seat or you’re aware that you don’t bring enough to the table to earn it, you’re a good candidate for a founding engineer. You should be happy!

If the other founder(s) want you to be a founder/CTO without the board seat, run! They’re just using the prestige of the title to pay you less, and will revoke it at the first convenience.

 

Jobs | moore |