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?
How ridiculous! You should just be thankful for the opportunity to be part of their incredible journey! Think of all the exposure and experience you're getting! /s
The sentiment they are trying to get across is that they want someone who won't let problems lie and who will proactively execute on fixes without waiting for permission or being assigned the work by a tech lead or manager.
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 sentiment they're getting at is "We want people who are as dedicated as owners, but without the incentives" and this translates to "We are only interested in gullible people who don't know their own value."
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.
> The sentiment they are trying to get across is that they want someone who won't let problems lie and who will proactively execute on fixes without waiting for permission or being assigned the work by a tech lead or manager.
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.
> The sentiment they are trying to get across is that they want someone who won't let problems lie and who will proactively execute on fixes without waiting for permission or being assigned the work by a tech lead or manager.
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.
> 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.
It can mean different things, no? For example, a team was switching to git from a different vcs. Devs who actually gave a crap then researched best practices and wrote up an internal how-to for everyone else to follow. Not because they were "business owners" or told by the management, but just because they knew there would be total chaos if they didn't. Other people - who somewhat cared - followed the internal manual. Finally, people who should be fired started shitting right into master without reading anything on git, internal or otherwise.
In my mind, the first set of devs really acted like owners here. Nobody exploited them, or even pushed them to overwork, they just knew to do the right thing.
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:
I think it's valid question, the issue is just in the presentation.
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.
So why isn't the question phrased "What are your expectations of how we work here?" or something along those lines? If the goal of the question is to address the motivations of the person applying for the job to determine if there's any mismatch with the companies mission than "why do you want to work here" is absolutely the wrong test.
>> "why are you looking to leave your current job and why does this one interest you"
> 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.
In the limited amount of recruiting I did it was a very very low bar to filter out people who didn't even spend 5 minutes reading the company website about what we do. (Didn't always ask this question literally, I'm lumping it together with "Do you already know what we do? Where did you hear about us, etc.pp")
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.
Joining a company isn't a marriage. If you were on a date and you were asked, "so what made you decide to go out with me?" that would be a totally reasonable question. As long as you realize turnabout is fair play.
And if the company said: "so what made you decide to interview with us?" that would be a totally reasonable question as well.
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.
It all depends on their general attitude and the way they ask the question. Most of the time, the question is delivered properly and it comes across as "what interests you about our company", which is a perfectly reasonable question. But then there are those companies that make it sound like you're being tested on creative sucking-up and if you're not creative enough, you don't get the job.
Compensation seems to be surprisingly missing from this list. If I work at a FANG company, and you're just getting started, chances are you won't be able to compete nearly as well as compensation. That's not to say that compensation is the only thing people work for -- though it is a large part -- but you must offer something especially unique to set yourself apart.
It wasn't a part of the numbered list of things. The author didn't even treat it as a first-class thing to be talking about when considering "trouble hiring developers".
It was a preface to that list, as in "if you don't solve this one, don't bother reading the rest of the list." That makes it the most important thing...that's how I read it anyways.
Yes, I believe that is definitely what the author was going for. If you don't pay market rate for development, you're 9 out of 10 times going to regret it.
Missing is "your torturous interview process that consists of a worthless online test, a 10 hour homework assignment, and a grueling whole day interview with whiteboard trivia unrelated to your day to day work has a high rate of false negatives".
This: closely followed by "people have heard of your torturous interview process and assume developers willing to both submit to it AND continue to administer it to others must be a bunch of egotistical assholes (who they'd rather not work with)".
I bet they don't like folks posting on Glassdoor and Indeed company reviews, interview processes, etc. It's amazing how many bad companies I filtered out just using those two resources.
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.
It's not called an IQ test legally. But it has precisely zero to do with your job unless you need to predict the next shape in a sequence of shapes, write essays on grammar, word association, or do head math within ~30s.
Here's another kind with (broken) word association problems from FirstBank looking to hire developers: https://imgur.com/a/QXlKC
> Wait, aren't IQ tests during hiring illegal in the US?
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 might be the weird one here but I actually enjoy IQ 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.
Accurate. I was trying to focus on personality traits and how companies are perceived from the outside rather than process, which I feel like I could fill a book on.
Don't get me wrong, I liked your article. To me, these types of interviews are personality traits and do affect my perception of a company. If I see a company's job posting mention any of these things my opinion of the company lowers even if I don't want to or wasn't considering applying (I look at job descriptions sometimes to figure out what tech a given company uses). How they treat prospective employees matters to me as it also indicates how they'd treat full employees.
One of the reasons I stay away from full time jobs and prefer to freelance where "client" is more interested in my skills to do the job than testing, interviewing and evaluating me based on some weird criterion.
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.
You're missing the adjectives. Worhtless online test, 10 hour homework, and whiteboard trivia. The point is that an interview shouldn't require a ton of a candidate's off-time outside of the interview The interview itself should be a worthwhile measure of the developers skill while pertaining to the actual job. The amount of piano tuners in Chicago is probably irrelevant to 99.9% of jobs.
>Missing is "your torturous interview process that consists of a worthless online test, a 10 hour homework assignment, and a grueling whole day interview with whiteboard trivia unrelated to your day to day work has a high rate of false negatives".
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?
> 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?
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".
Because, as devil's advocate, most programming candidates can't write FizzBuzz in a single programming language.
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.
Resuming my role as devil's advocate: How do you know they wrote them? How do you know I didn't write your new candidate's project for them?
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.
I can't stress this one enough. I've been through a whole bunch of different interviewing processes, but there was one that stood out as the worst:
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.
> they were willing to make their devs stay and interview me until 8 pm, two days in a row.
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.)
To be honest, I'm not sure. The only way to be 100% sure would be to ask them and it's not easy to ask that in a diplomatic way.
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.
It should really be re-phrased why you’re having trouble hiring developers at the rates you want because if for example you paid double market rates you would most likely be rejecting a lot of good developers. Money isn’t the only thing but it’s definitey a very big issue.
Exactly. Every single problem can be worked around with more money. Market rates are simply tables stakes to hire, and how much I require goes up from there.
Money is THE biggest issue. The companies I work for are motivated by money, so I am too. All the warm fuzzy, "we're family" BS is only good for lunches and bagels. When the company no longer is hitting numbers, engineering will be cast out faster than they can say resume.
I recently overheard a "startup mentor" telling a CEO that developers are very smart and sometimes persuasive, but that they don't have a clue what is going on and need to be told exactly what to do.
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.
Technical debt is also more costly to pay in terms of morale. Slogging through painful refactors for weeks on end can pretty quickly make me start to resent my job and question whether this is a product I want to work on.
My morale goes up if I ever get to actually repay some of that debt. More often than not developers are discouraged from paying it back, having to add new features or quick hacks instead, making it worse. In my company we can't spends weeks refactoring because there is no new business functionality to tie it to and IME that is the norm.
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.
I see these every single day in my inbox, the amount of bad indicators in job specs is impressive, I nope out within the first few lines on 95% of the specs. At least they are being upfront about the mess they are in and it is going to be a bad place to work. The alternative is nothing other than a very basic technical list and those are worse as they give me no reason to enquire either, hiding the bad is even worse. One yesterday contained so many little nope moments in it:
"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"
Compensation simply and purely. I'm taking a risk coming to join your start-up that has a high likelihood of failure. Pay me as such. You as the founder likely aren't taking as much of a risk as me an employee would be, especially if you didn't put your own money and are mostly operating on other's money. Not only do I lose the opportunity cost of a big-co with a safe job and stable hours, but I also have almost no control of decisions or outcome despite how much you the owner want me to feel like an "owner". Don't delude yourself into thinking your special and deserve more compensation than any of your early employees. A lot start-ups seem to forget this and tend to offer senior skilled people paltry "stock options" that are points of a percentage.
At 30% equity I'm guessing they're very early on and expect you to build the whole thing. Probably not a good role for a junior unless you really know what you're doing.
Feel free to send me an email if you need career advice.
77 comments
[ 4.7 ms ] story [ 88.8 ms ] threadThis 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.
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
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.
"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"
Feel free to send me an email if you need career advice.