Programming

Interviewed a guy for a position on my team about a month ago. He seemed OK but there was just… something, some kind of feeling. He talks to 3 other people on my team as well.

We have our post interview meeting, everyone goes around, every one is a yes, I say my concerns and that I’m a no, I get overruled and he’s hired.

Well guess. Fucking. What.

2 Likes

Need horror stories.

1 Like

I mean, if someone was in a post-interview debrief with me and they said “ya there’s just some sort of feeling about the candidate that I don’t like.” I’d dig a little deeper, like something technical, soft skills, their responses sound like those generated by GPT-3, what specifically are you not liking? If you couldn’t point to anything concrete, then I’d probably discount your opinion.

Honestly just didn’t know anything, barely could work git much less javascript, asked for “help” (me to do his work) all the time.

Was just let go now 5 minutes ago. If only someone told them a month ago. :thinking:

I’m not sure, I had a feeling we might be getting snowed here and we were, I’m not sure where he got his “answers” from but clearly didn’t have the technical skills to do the job. It was a contractor role at least. Not sure how to assure that doesn’t happen again.

No doubt sounds like a good read. The whole process is hard enough that it’s difficult to balance the proper weighting of a more subjective evaluation like you’re describing, especially if it’s all YES vs a single NO. Not like interview processes are that great and objective evaluations either, but it’s just so murky.

We had a dude like that that no one could even figure out who hired him. Unfortunately he was not a contractor. He lasted two years - one where he got passed around from team to team, then another year for my lazy boss to finally put him on the PIP and do all the steps and paperwork.

Dude just hung on until the bitter end, milking the system, being totally worthless and not even trying. It’s such a huge drag on the team when you have someone like that.

My first contract where I’m working I had a greenfield project and I was the main person doing the work. It was hard because it was in a language I’d essentially never used and lots of other stuff I’d never used, but I got it and produced a lot. After that I’ve been working on a large existing project and it’s a bit like I can’t do anything. Everything that takes me an hour takes everyone else like 10 minutes. And they’re bouncing me around all kinds of places to get the general feel, so it’s constantly a bunch of new stuff. Was getting worried, but today they talked about cutting my current contract short so they can hire me permanent.

3 Likes

Not that I’m that great at stuff, but I’ve never been put in a situation where everyone around me is so much better. I’m sure I’ll catch up though. Luckily everyone is super supportive and patient.

1 Like

Obviously they didn’t expect you to know everything coming in, and are thrilled with how fast you’re picking up the stuff you don’t know.

In this business if someone is conscientious and shows real aptitude, that’s usually enough to want to hold on to them for dear life.

Everything is perfect, except pay is at the lowest end of the scale for developers in SF. The principles of the company don’t even make that much. Clients are non-profits, environment is great and flexible and it just goes with that territory. Hopefully before I get in a position where I’m tempted to work at a crappy place for more money, I won’t have much need to do it.

Something it took me 10 years to learn - don’t try to build the perfect abstraction. Instead of DRY - Don’t Repeat Yourself, ascribe to WET - Write Everything Twice (I stole this from HackerNews). Then on the third instance of a thing that shares a lot of commonalities with the other two things - maybe it’s time to worry about abstracting the shared code out.

Obviously there’s also an art to it. Sometimes you’ll know there are going to be tons of similar pieces of functionality from the get go. But often you don’t know how the app is going to evolve.

Sometimes factoring out now is easier. But in general I find it a lot easier to add a layer of abstraction later as requirements evolve or become clear vs. trying to remove a layer of abstraction you thought you might need, but didn’t. The latter can become extremely difficult and risky in a complex app.

This guy is great and this is probably my favorite of his videos. Not exactly the same subject, but similar concept about not trying to predict the future.

1 Like

Very often this is a better solution imo. Worth tolerating a decent degree of redundancy. I’ve done shared libs and frameworks every which way and my ultimate takeaway is avoid if possible. Either have a monorepo or completely independent repos.

Little atomic shared libs are probably fine. But if they need to be upgraded very often they’re a pain to push out to all the projects. And even if you’re big enough to have an internal NPM-like thing - it still turns into a pain.

The key to programming is to change paradigms often enough that you always have work.

COBOL guys probably still out there making good money.

Bluefeet was/is a COBOL programmer.

Buddy’s wife is apparently always in demand for her COBOL skills since hardly anyone knows COBOL.

      $ SET SOURCEFORMAT"FREE"
IDENTIFICATION DIVISION.
PROGRAM-ID.  Conditions.
AUTHOR.  Michael Coughlan.
* An example program demonstrating the use of 
* condition names (level 88's).
* The EVALUATE and PERFORM verbs are also used.

DATA DIVISION.
WORKING-STORAGE SECTION.
01  Char               PIC X.
    88 Vowel           VALUE "a", "e", "i", "o", "u".
    88 Consonant       VALUE "b", "c", "d", "f", "g", "h"
                             "j" THRU "n", "p" THRU "t", "v" THRU "z".
    88 Digit           VALUE "0" THRU "9".
    88 ValidCharacter  VALUE "a" THRU "z", "0" THRU "9".

PROCEDURE DIVISION.
Begin.
    DISPLAY "Enter lower case character or digit. No data ends.".
    ACCEPT Char.
    PERFORM UNTIL NOT ValidCharacter
        EVALUATE TRUE
           WHEN Vowel DISPLAY "The letter " Char " is a vowel."
           WHEN Consonant DISPLAY "The letter " Char " is a consonant."
           WHEN Digit DISPLAY Char " is a digit."
           WHEN OTHER DISPLAY "problems found"
        END-EVALUATE
    END-PERFORM
    STOP RUN.

First time I’ve ever looked at it. I would have expected it to be very low level, but it’s very high level. Aside from the ALL CAPSing it doesn’t seem that weird and like it was going for being expressive like Ruby or Python.

If you want to do a * b you do COMPUTE a * b. That’s kind of cute. It’s like you are pretending to be a robot.

Google have a single source code repo. It works if all your devs are good. Like most “best practice” programming guidelines, the real world frequently demands compromises. Knowing how and when to compromise is a big part of the job of being a programmer.

Google also has a ton of in-house tools written around that thing to get it to function like a separate repo when they want it to.

https://medium.com/@Jakeherringbone/you-too-can-love-the-monorepo-d95d1d6fcebe