I interview many developers that speak about the latest javascript tech and code styles
Seems like you are asking the wrong questions. I'm a technical founder myself and I've interviewed a lot of developers. Nobody told me about the "latest code styles".
Seriously, nobody cares about your fancy perfect ES-linted code, especially not your users.
"Seriously", their team mates will absolutely care about the code they write.
I don't really care how you do it, use machine code or no code.
You should care how it's done. Technical debt is not to be taken lightly.
You don't need Jira or other fancy software to communicate well.
Jira is not fancy, or are you just throwing around some jargon? Jira is literally as far from fancy as it gets.
I think the right balance is to hire competent developers who are able to produce high quality code, and who also understand the business need of shipping “MVP” code on occasion. I wouldn’t trust a technical person who got the direction to “get it done fast” and didn’t ask “Why?”
I worked with too many developers that will get on a task without awareness of timeline. I woulndn't prioritize speed to over quailty, but I think speed is underated quality
I can understand the touch feedback you're receiving here :)
You assumed JS is the only language around? Better to rephrase your title: "How to hire JS developers".
How would you expect your candidate to know about your product? And how come that something is fast, scalable and usable is done fast? What is your definition of fast?
You don't really care how the dev does it, well sure. But don't ask for more customised features, code generation doesn't work well with those.
If by Jira you mean tickets to manage the product, then you don't need it if you're working alone but if you have even one developer in your team how do you communicate and keep communication to a specific task in one place? Have you gone through the pain of searching emails/slack/wiki to find a peace of information? How about the PM? where do they track the progress or know if something is blocked?
Haha, nice job taking the feedback on board with a good attitude. Taking a decisive tone is risky, but looks like you've stirred up some good discussions on dev hiring :)
Having worked as the technical lead on a few teams and going through the hiring process, the main thing I'm thinking about is how will this new person affect the team's cadence.
That is, will this person slow the team down or speed it up in the long run and by how much.
A few of the things you mentioned there are red flags:
You should care if the developer knows the latest language tech, new tech (syntax) usually means the ability to write code more efficiently and less time training them up. You don't want to hire a dev who is still using jQuery (technical debt)
You should care how it's done. Every technical project should have some convention in how features are implemented if you steer from those conventions you are adding technical debt
My own thoughts on how to hire devs I would say the main things to looks to look for are:
communication
actively interested in learning
show some sign of self-reliance, you don't need to handhold them (this will really slow you down)
that they can take initiative to do things that aren't asked for (this is where you really speed up)
The last 2 are pretty hard to screen for but something simple like going out of their way to fix technical debt or point out real problems in code is a good sign.
You should care if the developer knows the latest language tech, new tech (syntax) usually means the ability to write code more efficiently and less time training them up.
I disagree strongly with this one. The strongest hire I've ever worked with didn't know the language (Obj C, in our case) at all when he was interviewing. If you're a good dev who has solid fundamentals and has worked with each of the major paradigms picking up a new language is trivial.
Worrying about not even that but just familiarity of some syntax recently added to a language is insane from my POV.
I agree with your sentiment but an anecdotal example isn't really an argument.
My point, and I could have worded it better: they should be up to date with industry standards, not actively using legacy languages and libraries. Also, I listed this as a red flag, an indicator to inform your decision to hire.
If they don't know the framework or language they'll be working on beforehand, it's not a deal-breaker, but it's very situational to the role you're hiring for.
A tech lead position, for example, would be a massive red flag if they don't know the language. On the other hand, for a junior who will be supported by a more senior developer, there isn't much to worry about.
It comes back to if this person will speed up or slow down the team in the long run.
Also your point:
If you're a good dev who has solid fundamentals and has worked with each of the major paradigms picking up a new language is trivial.
Learning a language in terms of syntax is trivial. Understanding the nuances of a language and framework to architect it so that will be around for many years is another story.
I'm afraid I have to disagree still further. I shared an anecdote and made an argument. The latter didn't rest on the former.
A tech lead position, for example, would be a massive red flag if they don't know the language. On the other hand, for a junior who will be supported by a more senior developer, there isn't much to worry about.
Ironically, the very anecdote I shared was our tech lead and I was the junior! He had to lean on the team for the first few weeks, but after a couple of months was by far the most productive one of us and often the only one capable of solving some problems. Not having prior experience with Obj. C was barely an impediment at all. He's successfully founded and sold two tech companies and is now CTO of another that's already raised its A round.
In my experience, it's exactly the opposite from your claim above—the more skill someone has, the less experience with a specific language or framework is an issue. In contrast, it can be a much larger task for a junior to have to pick up a new stack.
Plenty of top-rate devs use "legacy" languages and libraries. It's because they're focusing their efforts on other issues and the languages and libraries are getting the job done.
Hmmm, I gotta say I don't agree with you on a lot of these points. Getting shit done over doing it right might work initially, but will kill your productivity in the long run.
I'd rather have developers who write code that is understandable and maintainable over ones who hastily throw something together.
I think this is a bit too simple to think it works for everyone. I'd rather take someone who finishes 2 features with high quality versus someone who does 5 features with low-med quality in the same amount of time.
Getting things done fast is not something to get stuck on. It can lead to a lot of headaches down the line if the quality is low (worked with 15+ developers on Upwork/Fiverr who can slap code together quickly with piss poor quality).
Nah.
Seems like you are asking the wrong questions. I'm a technical founder myself and I've interviewed a lot of developers. Nobody told me about the "latest code styles".
"Seriously", their team mates will absolutely care about the code they write.
You should care how it's done. Technical debt is not to be taken lightly.
Jira is not fancy, or are you just throwing around some jargon? Jira is literally as far from fancy as it gets.
This comment has been voted down. Click to show.
As someone who hires developers and even built a product to screen for competent candidates, I think this misses the mark. Fast is only half the picture.
I think the right balance is to hire competent developers who are able to produce high quality code, and who also understand the business need of shipping “MVP” code on occasion. I wouldn’t trust a technical person who got the direction to “get it done fast” and didn’t ask “Why?”
Agreed.
I worked with too many developers that will get on a task without awareness of timeline. I woulndn't prioritize speed to over quailty, but I think speed is underated quality
I can understand the touch feedback you're receiving here :)
I'm absolutely loving the harsh feedback here :)
Make me understand I need to write more coherently and less decisive
Haha, nice job taking the feedback on board with a good attitude. Taking a decisive tone is risky, but looks like you've stirred up some good discussions on dev hiring :)
Having worked as the technical lead on a few teams and going through the hiring process, the main thing I'm thinking about is how will this new person affect the team's cadence.
That is, will this person slow the team down or speed it up in the long run and by how much.
A few of the things you mentioned there are red flags:
My own thoughts on how to hire devs I would say the main things to looks to look for are:
The last 2 are pretty hard to screen for but something simple like going out of their way to fix technical debt or point out real problems in code is a good sign.
I disagree strongly with this one. The strongest hire I've ever worked with didn't know the language (Obj C, in our case) at all when he was interviewing. If you're a good dev who has solid fundamentals and has worked with each of the major paradigms picking up a new language is trivial.
Worrying about not even that but just familiarity of some syntax recently added to a language is insane from my POV.
That said, I totally agree with your list.
I agree with your sentiment but an anecdotal example isn't really an argument.
My point, and I could have worded it better: they should be up to date with industry standards, not actively using legacy languages and libraries. Also, I listed this as a red flag, an indicator to inform your decision to hire.
If they don't know the framework or language they'll be working on beforehand, it's not a deal-breaker, but it's very situational to the role you're hiring for.
A tech lead position, for example, would be a massive red flag if they don't know the language. On the other hand, for a junior who will be supported by a more senior developer, there isn't much to worry about.
It comes back to if this person will speed up or slow down the team in the long run.
Also your point:
Learning a language in terms of syntax is trivial. Understanding the nuances of a language and framework to architect it so that will be around for many years is another story.
I'm afraid I have to disagree still further. I shared an anecdote and made an argument. The latter didn't rest on the former.
Ironically, the very anecdote I shared was our tech lead and I was the junior! He had to lean on the team for the first few weeks, but after a couple of months was by far the most productive one of us and often the only one capable of solving some problems. Not having prior experience with Obj. C was barely an impediment at all. He's successfully founded and sold two tech companies and is now CTO of another that's already raised its A round.
In my experience, it's exactly the opposite from your claim above—the more skill someone has, the less experience with a specific language or framework is an issue. In contrast, it can be a much larger task for a junior to have to pick up a new stack.
Plenty of top-rate devs use "legacy" languages and libraries. It's because they're focusing their efforts on other issues and the languages and libraries are getting the job done.
Hmmm, I gotta say I don't agree with you on a lot of these points. Getting shit done over doing it right might work initially, but will kill your productivity in the long run.
I'd rather have developers who write code that is understandable and maintainable over ones who hastily throw something together.
Martin Fowlers graph describes this best => https://prop.to/nffYxuueCU/1
I think this is a bit too simple to think it works for everyone. I'd rather take someone who finishes 2 features with high quality versus someone who does 5 features with low-med quality in the same amount of time.
Getting things done fast is not something to get stuck on. It can lead to a lot of headaches down the line if the quality is low (worked with 15+ developers on Upwork/Fiverr who can slap code together quickly with piss poor quality).