21–30 of 56 posts
My father-in-law made a wise suggestion, as a company, to always be in hiring mode. You don't want to hire someone because you need them at that very moment but always be hiring so you have redundancy.
Slightly surprised -- and a little diappointed -- to see "academic programmer" as the least desirable archetype. Also, not sure these archetypes do a great job of capturing the process-oriented/results-oriented divide that shows up in the opening anecdote (and which I agree is quite real).
Which is interesting to me because if you go through the triplebyte process the impression you'll get is that they are looking for a very academic/textbook CS student who can balance a binary tree on a whiteboard while verbally explaining the operational complexity of an unladen swallow. From my perspective, there is an impedance mismatch between the triplebyte process (heads-down algorithm nerd) and the findings tha…
This doesn't describe academic programmers. In my experience, academic programmers tend to be glorified essay writers who can just barely produce parseable syntax if left alone for a few hours.
Earlier quoted context omitted.
I'm afraid I'm getting stereotyped as an enterprise dev against my will. I've been on interviews where that was certainly the vibe I got. No matter how much I stress that I'm interviewing while I have a job for the purpose of getting away from that culture, I can't shake that opinion it seems. Trust me I would gladly program in anything other than corporate Java if given a chance. I think I've got the worst of both w…
Your best bet is a side project. Do something fun in a language you enjoy, and talk about that in the interview instead of the work you do. Make it big enough that it warrants an entry on your resume. Or contribute to a well known open source project.
Slightly surprised -- and a little diappointed -- to see "academic programmer" as the least desirable archetype. Also, not sure these archetypes do a great job of capturing the process-oriented/results-oriented divide that shows up in the opening anecdote (and which I agree is quite real).
Slightly surprised -- and a little diappointed -- to see "academic programmer" as the least desirable archetype. Also, not sure these archetypes do a great job of capturing the process-oriented/results-oriented divide that shows up in the opening anecdote (and which I agree is quite real).
Which is interesting to me because if you go through the triplebyte process the impression you'll get is that they are looking for a very academic/textbook CS student who can balance a binary tree on a whiteboard while verbally explaining the operational complexity of an unladen swallow. From my perspective, there is an impedance mismatch between the triplebyte process (heads-down algorithm nerd) and the findings tha…
I've seen quite a bit of 'discrimination' against enterprise devs by startups over the past ten years as a recruiter (and JUG president for 15 years), and the data in this piece regarding Java/C# devs failing more interviews than counterparts is at least a little surprising. I generally attributed the discrimination to be more about dev culture than tech skills, whereas the enterprise dev maybe with a few years at a…
they said enterprise devs are failing more interviews because of cultural filtering by the hiring company, not that they are failing the technical assessments more than other devs.
I might be reading that wrong, but I took that as "Java/C# devs failed company interviews 2x Ruby/JS devs".
No?
Do you have an anonymous data set of resumes, interviews, and offers that someone could run some clustering against?
While parts of it have self-description bias, it seems like the analysis would be a little more interesting than what you've provided. Possibly you may even uncover what companies really want, rather than what they say they want. Kaggle contest!!!!
Slightly surprised -- and a little diappointed -- to see "academic programmer" as the least desirable archetype. Also, not sure these archetypes do a great job of capturing the process-oriented/results-oriented divide that shows up in the opening anecdote (and which I agree is quite real).
Which is interesting to me because if you go through the triplebyte process the impression you'll get is that they are looking for a very academic/textbook CS student who can balance a binary tree on a whiteboard while verbally explaining the operational complexity of an unladen swallow. From my perspective, there is an impedance mismatch between the triplebyte process (heads-down algorithm nerd) and the findings tha…
Having not got into programming by pursuing CS in university and instead kind of taking the old "hacker" route, that kind of thing always hangs around my neck when job hunting.
I agree that it is quite different at startups. The startup environment felt basically a glorified college environment compared to the large company culture. With that said, I would image eventually all startups have to grow up and embrace enterprise-style processes. Facebook is the example that comes to mind. When they first started, the followed the "Move fast and break things" mantra, but as they aged and took on more and more users, they had to change and become a company that valued reliability over new features. I believe their current mantra is "Move Fast With Stable Infra."?
Earlier quoted context omitted.
Which is interesting to me because if you go through the triplebyte process the impression you'll get is that they are looking for a very academic/textbook CS student who can balance a binary tree on a whiteboard while verbally explaining the operational complexity of an unladen swallow. From my perspective, there is an impedance mismatch between the triplebyte process (heads-down algorithm nerd) and the findings tha…
> looking for a very academic/textbook CS student who can balance a binary tree on a whiteboard while verbally explaining the operational complexity of an unladen swallow. This doesn't describe academic programmers. In my experience, academic programmers tend to be glorified essay writers who can just barely produce parseable syntax if left alone for a few hours.