Earlier quoted context omitted.
It depends on context as well. Where I currently work, they wouldn't have a chance. The corporate firewall will prevent them talking to Nexus, for example. It just wouldn't be fair to expect them to navigate that sort of thing in an interview. In general, if I'm asking them to code on my (or the company's) hardware, I'd start from an existing project, if only because I wouldn't expect them to be familiar with the ins…
What happens if they can't work from home? They're expected to take time off, AND prepare beforehand? What round is this?
When hiring senior engineers, you’re not buying, you’re selling
661–670 of 694 posts
Re: When hiring senior engineers, you’re not buying, you’re selling
#662Earlier quoted context omitted.
It starts from scratch. Familiarity with one's tooling is important. Setting up a project seems like it should be part of the basics. Would it not be unfair to others who choose a different language if Java gets hand holding in terms of initial classes? For 20% of Java candidates, they do it just fine. Heck, a few echew the IDE and are fine working completely from the terminal (these tend to be particularly very soli…
Do you give them "their" tooling? I can set up a project of the type you describe in about five seconds, because I have a template for it in my IDE. The best defaults for this that I've seen are provided by IntelliJ (do you provide this in interviews? It seems legally challenging to do) and would probably take me 5-10 minutes to navigate. I think Java depends much more heavily on powerful tooling to do the heavy lift…
If it's remote, I'll ask them to share their screen with me with a project set up and ready to go, having emailed them a copy of the interface we're going to implement about 30 minutes before the interview.
Re: When hiring senior engineers, you’re not buying, you’re selling
#663Earlier quoted context omitted.
The higher you go the more compromises you have to make. That said, nobody is talking about disruption, just wisdom. It just so happens, sometimes that wisdom will tell you that shipping shit out the door in the name of delivery focus is going to cost you more than its worth in the long run. Calling them overly idealistic to justify your laziness just makes you look bad. I'd say a truly good senior can tell the diffe…
Who's talking about shipping "shit"? You are overreading by a very wide margin. I also don't appreciate being called lazy, and especially by somebody who knows nothing about my business or my team. Please try to keep your tone civil in future.
I didn't call you lazy, I said that shipping in the name of delivery focus was lazy, or at least your argument about idealism was.
Fact is, shipping quality is the far more optimal solution and always will be. Making the trade off and adding technical debt is never a worthy trade long term. The only people who gain from it are you and your team. The rest of the company eventually grinds to a halt and begins taking more and more shortcuts around the code which just reinforces everything in a viscous cycle.
You might find this useful: https://youtu.be/DngAZyWMGR0
Re: When hiring senior engineers, you’re not buying, you’re selling
#664Earlier quoted context omitted.
> Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview. Like what questions? I'm assuming the work you're looking for is more along the lines of "wonderful solutions" as opposed to "task completion" - is it as simple as asking, "How anal are you guys about code syntax and whatnot?" and, "How hard are your problems actually?" Or is it more subtle than tha…
Here are some I thought of off the top of my head. These are based upon things I actually encountered. What if I were to provide a solution that executes much faster, requires less documentation, passes test automation, and is a quarter of the code but ignores the framework or standard code style? The standard DOM methods perform thousands of times faster than other options for interacting with markup. I can prove th…
There's a great quote from Lou Montulli[1]:
> I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.
Those frameworks and existing components most likely have a lot of hard-won experience embedded in them, and I would be uncomfortable hiring someone who did not appear to understand or appreciate that.
See also: Chesterton's fence[2].
[1]: https://www.joelonsoftware.com/2000/05/26/20000526/
[2]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
Re: When hiring senior engineers, you’re not buying, you’re selling
#665Earlier quoted context omitted.
CS is not programming just like 99% of musicians don't have music theory degree.
Interesting analogy. I bet there's scope to twist it beyond all sensible bounds, and compare the ability of the 99% to the 1%. I suspect there's top level classical, jazz, and session musicians - who're the industry equivalent of 10x programmers. (And all the other stereotypes probably exist too, I bet there are occasional untrained but gifted musicians who can produce 10x output, but who're amazingly difficult to co…
Btw years ago I did work with a top session guitarist (top 10 hits) who after an accident taught himself to program from his hospital bed.
Re: When hiring senior engineers, you’re not buying, you’re selling
#666Earlier quoted context omitted.
If management is rude and naive enough to be bad at hiring, they can be expected to be equally bad at promoting and retaining internal talent. For example, there's the simple pattern of ignoring employee careers and expectations until, after the least patient ones have left, suddenly there's a lack of personnel, and the best remaining people are needed in their current dead-end role.
The mistake I see __consistently__ is that when I'm discussing an opportunity / relationship with someone who is "hiring" is that they don't realize I'm interviewing them as well. Fairly often, those who don't realize this are the same ones who will hint / complain about retention and such. They want better people but that have no idea how better people think / feel and how their approach will never get them the type…
Re: When hiring senior engineers, you’re not buying, you’re selling
#667Earlier quoted context omitted.
It's probably a great analogy because the best musicians all know basic music theory, whether they learned it in school or on the bandstand. As for the advanced theory that they teach in graduate programs, it isn't even applicable to most genres of music.
> the best musicians all know basic music theory Do you have any evidence for such a bold claim or is this just speculation?
Re: When hiring senior engineers, you’re not buying, you’re selling
#668Earlier quoted context omitted.
> but unless it’s time actually working with your team on a real project.. I've ranted about this before on HN, but that's very much illegal in my neck of the woods. As soon as someone does useful work for you, they're an employee. YMMV but you can't expect new candidates to do actual work until you've hired them. There are plenty of programming assignments, exercises or questions you can have them do instead.
So have a basic filter, hire based on who meshes well with the team and have a trial period during which they actually get evaluated for competence. They’re technically an employee during the trial period, but with the understanding (and contractual agreement) that they will be evaluated at the end of the period and that the employment will be terminated if they do not meet the criteria.
Of course, the net result is that self-employed contracting is on the rise. Especially the kind where people are self-employed only in name, but really work for a single employer. The only difference is that they send an invoice at the end of the month, and the employer can terminate the contract at any point (depending on the terms in the contract, of course).
Hiring is hard. Especially so when hiring the wrong person can cost you two months' wages.
Re: When hiring senior engineers, you’re not buying, you’re selling
#669Earlier quoted context omitted.
So have a basic filter, hire based on who meshes well with the team and have a trial period during which they actually get evaluated for competence. They’re technically an employee during the trial period, but with the understanding (and contractual agreement) that they will be evaluated at the end of the period and that the employment will be terminated if they do not meet the criteria.
Trial periods, too, are no longer allowed over here. They used to be permissible up to 6 months (which was an insanely long time to essentially live with the knowledge that you could basically be sacked any day). But now they're gone. Firing people isn't terribly easy either, might need to give two months notice! Of course, the net result is that self-employed contracting is on the rise. Especially the kind where peo…
Ouch. That does make it really hard, impossible even, to make sure you get a good fit.
Re: When hiring senior engineers, you’re not buying, you’re selling
#670Earlier quoted context omitted.
I’ve got a friend who is a lot like you. I’ve worked with him, so genuinely know he’s good, but he sucks at interviews. He freezes up and can’t answer simple technical things, things he knows and has successfully done often. Some people simply suck at interviews.
I think practice help with this "Some people simply suck at interviews". If you practice at home, after work, try with other companies before applying the ones you really wants and you will improve your interview skills by a lot.