> Employee writes a ton of really fancy Haskell, delivers fantastically and in about 1000 lines of code. Everyone is very impressed. The project grows in scope.
>
> Boss: It’s time to hire another Haskeller. What are the job requirements?
The job requirements should be the same as the ones the original engineer was hired for. Then they can mentor the newbie. After all, they're not an expert if they've done this, they're still able to explain why they pulled in a shit ton of libraries to do their work.
Asking that person what the new requirements are is doomed to fail because they moved the goal posts. Give them a junior and let them learn.
It's like when you're a kid and you think adults have everything figured out.
When you pull on the thread, you find that a lot of successful developers don't really have that clear a picture of what it is they did and how they did it. It gets covered with bluster and bluffs. Impugning the other person for not 'getting it' and getting defensive about the 'documentation' they wrote and how everything you need is in the code.
Fifteen years ago we were still talking about 'cave trolls', the people who work in isolation, and often on their own schedule. Most of those people still exist. They've just had makeovers.
I've been through that stage (grumpy defensive programmer). On the other side is a deep humbleness when as a programmer you realise you know nothing, you never really knew.
You just knew how to research and fix the problem really fast.
I take pride in making mistakes and misunderstanding, because it means I'm ready to accept something else, and I personally find power in exposing my flaws and my vulnerability. I don't have a problem with doing something wrong because I'm happy to own it and then ask questions.
Those managers or startups that expect perfection have got it all wrong. The people who fuck up and recover are more valuable.
If you are supremely confident that you've solved many problems with "no experience" you know you can solve many more.
It helps with bringing the interviewer with you also. It's actually important to stay humble and think out loud. Don't aim to have all the answers. Aim to find the answers "as a team" and give them a positive preview of how working with you is pleasant.
I've aced every interview, perhaps because I only interview for roles I am intellectually curious about and I do a lot of research beforehand "for fun."
No one learns Haskell quickly. "the fundamentals of how to write software" are very different in Haskell from other languages, even other functional or functional-ish languages.
>
> Boss: It’s time to hire another Haskeller. What are the job requirements?
The job requirements should be the same as the ones the original engineer was hired for. Then they can mentor the newbie. After all, they're not an expert if they've done this, they're still able to explain why they pulled in a shit ton of libraries to do their work.
Asking that person what the new requirements are is doomed to fail because they moved the goal posts. Give them a junior and let them learn.