Why you're having trouble hiring developers
jeremyphelps.com
jeremyphelps.com
She then went on to tell the CEO that she took an intro to javascript class and she felt that doing that gave her great insight into how long things reasonably ought to take developers to finish.
It's amazing that this kind of mindset exists today. While it often makes sense for startups to take on technical debt (as well as management debt and other practices that don't scale well) the issue is rarely that developers are clueless, it's that the project cycle does not include a proper accounting of tech debt and the compounding interest that it generates.
The simple answer is to first establish the minimum guaranteed lifespan of the business based on funding that is guaranteed, and work backwards to determine what milestones are necessary to extend that timeline and create a profitable (or venture backed) business. If the only option is to take on technical debt, plan for when it will be paid off.
I've seen many cases where an early team rallies to ship a product and takes on technical debt so that it can be viewed as having shipped successfully, only to find themselves mired in the debt a few weeks after launch, during which time they lose a lot of credibility and some may even end up burning out and quitting the team.
If you are hiring junior engineers, that may mean you are taking on technical debt... maybe even architecture debt. This may be a smart decision, as long as you are aware you are doing it and have a plan to pay it back before it becomes too costly.
At the moment I'm working on a story that requires a massive refactor of a core process, I'm loving the process of cleaning up the spaghetti but I'm not sure if the business will accept the risk of the changes.
This has got to be the most stupid thing I've ever heard in an interview. Okay then, I'll act like an owner. Make me an owner. Oh, wait, you didn't mean it like that?
Couple of examples of this:
1. Speeding up a test suite by identifying the slowest parts and optimizing it so every developer that runs the test suite benefits.
2. Making deploys more stable or getting them to zero down time so you're not forced to deploy during off hours and impact your customers.
Wanting people who will do things like this is often expressed as "ownership", but I think it's the wrong term. It's more about making the team more efficient and productive.
The reason people have trouble finding good developers is because they don't want to pay for them. Owners aren't driven by only doing as well as the market average. If you want people who want to beat the market, offer them something better than the market rate.
I find that's rarely what they want. I've often seen cases where there's some fundamental architectural flaw that will make future development extremely difficult, only to be told, "Don't worry about these things - just ship something!"
Yeah, that's going to break really soon, and we'll be running around trying to put out fires because of your incompetence. If I were the owner of this, I'd fix it immediately, or at least prioritize it reasonably so we don't screw ourselves in the future.
And I assume they schedule time for such activities? Or do they expect you to do it on your own time? Or do they expect you to do that in addition to what you're already being paid for? Will they reward you for your effort or will you just kick off a round of bullshit on why you made an unnecessary and un-requested for change?
Everyone wants their devs to take ownership, but very few create the right business structure to make it possible.
Totally agree on this point. In most companies, this work is not glorified and ends up being done on "stolen time" from the employee, or not done at all. It's a sad state of the industry.
I'd say this is where the more engineering-focused companies tend to excel a bit more since they are more likely to schedule the time and reward folks for doing it.
If you're evaluating companies for fit, its a good idea to ask questions around how this work gets done (asking for specific examples) to see if you glean if it's valued or not.
"Why do you want to work for Acme Corp?"
Employers need to remind themselves that the interview is a date - the company needs to let the candidate know why they might want to work for ("marry") Acme Corp, not the other way around. What would you think if you were on a real date and the other person said:
"Why do you want to marry me?"
If you ask it with the attitude of trying to find people who are 1000% in love with the concept of working at your very specific company then I think you're deluding yourself. Unless you're a world-famous company or your company has a very niche mission, it's unlikely that the applicant cares about working for you specifically.
If, however, you ask it in the context of "why are you looking to leave your current job and why does this one interest you" then there's a lot of room to figure out where the applicant's expectations don't align with reality.
I work for a small enterprise SaaS company in NYC. We get a lot of people interviewing who are coming from a long career working in banks. I always ask why they want to go from working in a bank to working at a company like ours. Sometimes it turns out that they won't get what they're looking for if they come work with us and that's a discussion worth having.
It's all about managing expectations
> So why isn't the question phrased "What are your expectations of how we work here?"
Because it's not the same question at all. I don't know what to expect from your work practices yet, but (a) you work at a big scale and I'm interested in that, or (b) you use Erlang/Ada and I'd like to use that professionally, or (c) you make CNC machines and I'd like to move to writing industrial hard-realtime code, or a number of similar reasons before you even know what the company looks like from the inside.
No, I'm not talking about enumerating all the products and the website wasn't good either, but I was shocked how someone would turn up to an interview without having done the minimum amount of research.
I would say that a hiring process is about starting what both parties should hope to be a "long-term working relationship."
Although the analogy isn't great - a marriage could also be described as a long-term working relationship. But the expectations are vastly different.
The thing is, perhaps from years of being conditioned to expect desperate applicants, some companies haven't internalized that candidates aren't desperate enough that they want to work for your company even before they've talked to you. It's when the question is phased with an implied assumption that "You would totally work for us if we let you, wouldn't you?" that it bugs me.
I was not offered the job.
Like most interview things, it's essentially random as to what happens however you respond.
"Christmas contract"
"a few outstanding issues that need ironing out"
"Critical Path web app"
"system is reflective of an Excel spreadsheet"
"two junior and one senior developer"
"senior developer is cutting down his working days"
"mentoring element"
"based in the office to help out the junior developers"
"3 years + experience"
"Experience mentoring"
"for 3 months"
"terrible pay"
"interviews immediately on Skype"
"start immediately"
In particular, stay away from anyone funded by Vista Equity Partners because they enforce IQ tests during hiring for all of their companies. That's overlaid on top of a whiteboard assessment.
Here's another kind with (broken) word association problems from FirstBank looking to hire developers: https://imgur.com/a/QXlKC
No. Any filter in hiring that adversely impacts a protected class and is not closely adapted to the work being done is illegal as a violation of the law prohibiting discrimination against the protected class.
The case in which this legal principle was established involved an IQ test being adopted as a direct replacement for an overt policy of racial discrimination, but IQ tests as such are not illegal (indeed, a much more recent case has upheld a police department using such a test and treating a too-high score as a negative factor in hiring.)
Of course, the pervasive mythology that IQ tests are prohibited itself makes them riskier, because an applicant who is turned down is likely to have encountered the myth or talk to someone who has, and seek legal help to challenge an IQ test, where they would be less likely to do so for other tests.
I consistently do well on them and if a company give me one I feel it increases my chance of getting the job as I like to think I'm quite a lot better at figuring out stuff than I am at smalltalk :-)
It might help though that none if the serious IQ tests I see here include any writing: they all consist of pattern matching and other puzzles.
In fact thats a major point for a good IQ test I've been told: ideally it should give the same result for equally smart persons even if they were raised in vastly different environments.
At least in Brazil, a significant amount of candidates are out of the market developers who simply are not very good.
Some of them might be good at selling themselves in an interview but will be bad performers. In many ways a bad hire will cost a lot more than no hire at all.
Similarly developers bad at selling themselves on interviews might be good performers. If they have public code that can be looked at we can decide for ourselves, but that is also hard to compare to other candidates, specially since a lot of them do not have public code.
I believe a bite sized on site (with internet)/online/homework coding task within the required skill set will actually help filter out some red flags and will help drive the following interview since it's easier to talk about something concrete.
As long as the task is close to actual work that will be done and not gimmicky, won't take an absurd amount of time, and the candidate can have access to all resources they would usually have (mainly and IDE and internet access), I think it's a valid proposition.
I simply refuse to do these anymore, which has unfortunately precluded me from FAANG level jobs. They give me panic attacks. It took over a year of searching in SV for me to find my current job because of it. Why is this the only industry in existence with such an accepted process?
I'd say the two are related.
Find some lawyer friends, ask them about the bar exam.
Find some doctor friends, ask them about what it took to become a full doctor.
Etc.
Software Engineers don't have those hoops to jump through. Anyone can call themselves a software engineer (in the US at least, other countries have legal requirements around the title). As a result it's up to the employer to do the weeding out of people who are no good.
Is it fair? Not at all. Is it always necessary? Def not. Does it make sense when software runs the world? Yes.
Ask employers and they'll tell you that over 50% of software engineer applicants can't even write a for loop. We're not talking "serious coding" here, we're talking "count to 5".
I know I can program. You don't know I can program. Do you want to hire someone who simply can't write a line of code to save their life and then have to deal with the headache of firing them and hiring someone else?
And that's best case scenario, because someone who can't code can do a lot less damage than someone who can code badly.
False negatives suck for the employee because they don't get a job. False positives suck for the employer because it's a massive headache and money sink. Since employers are the gatekeepers, they're often going to try to minimize false positives, even at the cost of false negatives.
And it should be asked, why is spending hours and hours building open source software outside of your day job a reasonable requirement? Doing open source well is incredibly difficult and requires a different skill set than working as a developer.
If you want to sit in front of a computer for several hours, then go home and do it all over again for free for the community, that's great. Sincere thanks are in order for that. But requiring it from all your candidates is unreasonable IMO.
1. A homework assignment where you have to write some code for given requirements, use a specific design pattern they require, write tests and document.
2. Have a 1 hour phone call to discuss your assignment.
3. Have a face-to-face meeting with some of their devs to discuss behavioral stuff (what motivates you, what you want out of work, how you give and take feedback).
4. A full day of technical interviews.
I did the first three steps and I thought I was done, because they never bothered to describe the whole process clearly. Then they contacted me to schedule a full day interview round. Since I didn't know about that beforehand, I had used up all of my PTO on interviews with other companies. I explained that I couldn't do a full day because of my work and they offered to do two consecutive half-day interview rounds from 4 pm to 8 pm.
Now, let that sink in: they were willing to make their devs stay and interview me until 8 pm, two days in a row. That's when I decided to thank them for the opportunity and politely bail.
Are you sure? At my company we have very flexible time, and due to city traffic, many people come in around 11-noon, meaning they choose to leave around 7-9. This is much more convenient for them because of the traffic, and sometimes it better matches a spouse's schedule, or allows them to do something in the mornings they wouldn't normally be able to do. It may have been an indicator of a really good place to work. (Which isn't to say you're wrong. It very well may have been a warning sign.)
Although it's my own conjecture, it's based on numerous other signals I got from them during the interview process. As an example, any team member A can point out that any other team member B isn't pulling their weight and shouldn't be working there. That initiates a discussion about whether B should be fired.
...with zero feedback in case process doesn't go through, thus losing all the time invested
Obligatory reference: https://www.youtube.com/watch?v=3XGAmPRxV48
Feel free to send me an email if you need career advice.