Prep for the next one and come up with some questions, it's a pretty googlable thing. "how profitable are you?" "What kind of growth plans do you have?" "What kind of team building to you guys do?" Stuff like that. If you are afraid of forgetting them in the moment write them down in a notebook and bring it with you.

I stuck to ideas about the general job and the immediate goals. "What do you mean by scripting and automation?" which brought up some interesting topics that covered "what is now and what is (hopefully) next."

I tried to mind-map the job and the issues they face and tried to figure out how I could help in this. This is pretty tough balance. I've been to a few interviews where they were obviously attempting to pick my brain for my knowledge and essentially get free advice and consultation. This probably comes across more harsh than I mean it.

I wouldn't be comfortable asking about profit or anything dealing with money. It is usually pretty obvious once I walk in the door.

After 3 years of talking about CI/CD, we have 6 protractor test files working in our CI environment and pinging hipchat to tell devs if they fail (we don't want to block the builds because the tests are so slow). It's been a journey to say the least. Now we just have 1000s of more tests to write.

Tell me a bit about your typical day / past projects you've worked on are good fall back questions.

They're open ended, you learn useful stuff, and you can ask them to each person that interviews you.

Yea, I think I'd be more interested in someone who appeared interested in the work environment than someone who was trying to solve my companies problems in an interview.

Do the tests have to pass before a deploy can be promoted?

I use to work with a guy that over used the 'lean into the pain' line way too often but blocking builds because of slow/failing tests might be a place where it applies. Or it might not be...

The 'hopefully next' can make an interesting discussion.

I had a guy ask me about what the worst part of my job was. It lead to an interesting discussion but I'm not sure everybody could pull off asking it.

I now despise linked-list recursion sort assignments.
Professor is madly in love with recursion in C++ and will settle for nothing else.

It wasn't.

If an interviewee asked me this, I'd say "Everything" just to see how they react.

The other question that I really can't stand is "Why do you want to leave your current job?"

I just follow the whole script about how I programmed for the past few years and I would like to do this for a living, seeking new challenges, etc. I say I feel like I've gotten as far as I can where I am, but that seems to get an eye of skepticism even though it is the truth so I think I'm going to strike this line.

I just don't ask this question in an interview. Obviously the person is unhappy: he or she is taking a "sick" day to see me, which says a lot.

I think I'll be honest next time and say straight-out that I'm absolutely miserable and it's either find a new job or become a full-blown alcoholic.(Poe's Law)

"What do you do at your current job?" is hard to answer because it is such a cluster**** of disjoint responsibilities that, even as I'm saying it, I barely believe it myself. I've managed to tamp it down to a single sentence that covers less than half my job, which I did today, but they were like "Oh, but you probably don't do a ∈ B, right?"

But overall, it was a great experience. This is my first time at a whiteboard, which I managed to not completely choke on even though it was terrifying. I haven't had many face-to-face interviews with tech companies. Of course I won't nail it.

daveT, maybe you should go into the interview ****-faced so you are not terrified.

"Tell me about your programming background?"

Well, when I first decided I'd like to learn how to program, I bought a computer off of eBay. When I got it, I couldn't figure out how to turn the thing on, so I took it to a friend's house and asked him to help me out.

-- they laughed... hooray!

I then told them that, yeah, I was an utter technophobe until 3 or 4 years ago, and I guess I'm still a technophobe at heart.

I didn't tell them that I learned HTML and CSS by printing out reams of paper at the library and transcribing it by hand because I didn't have a computer yet, and no, I had no clue how to actually create an .html or .css file when I finally got a computer, and no, I had no clue what a file was either. And yes, this is a terrible way to learn JavaScript which I still can't write.

I wish they would ask something about the projects I worked on. I always read this as being the "best interview question," but I've never been asked this. I'm pretty sure I would nail this one, but I suppose that is a gimme and too easy.

"Clojure"
This is the first time I didn't get asked about this. Interestingly, every time an interviewer brings it up, they like to bash into the language and Lisp, so in a way, I'm sort of glad they didn't. One interview said something like "I'm a self-taught programmer. I don't waste my time with academic languages."

They asked you about your programming bsckground! Use that to talk about your projects!!!

Edit: Seriously! You talked about 'bad' things from 'long' ago instead of the awesome stuff you've done more recently.

Just for the record 'past projects' is basically the first question I always ask.

It was an attempt to be funny...

I stuffed a lot into the past 3 1/2 years and morphed into all sorts of angles. I love the learning more than anything, but... although I'm often mistaken for under 30, I am 36, so it's not like I was wiping snot off my hands while typing QBasic. The "newness" of me learning feels like an elephant.

I do bring those things up, but I feel like I always run into walls when I try to dive into it further. If the interviewer doesn't respond to any of the classes I've taken, books I've read, or any of my projects, then why would I beat a dead horse while its still in the gate? This time, I only brought up my most recent project which was pretty much met with a shrug.

Ok, fair enough. That makes me feel better.

new c++ teacher, new class structure. Gone are the days of our teacher showing us some new concept, how to use it, and then giving us assignments to use that concept a few times until we're comfortable with it. Farewell!

Now, we sort of discuss concepts we've already covered, then the teacher shoves a mix of 50 videos, .cpp files, and possibly assignments online and we have to figure out wtf to do because he sure as **** isn't telling us. Good luck!

ugh

Not to be too narcissistic but I've been really successful in interviews and I can't help but wonder if its my technical skills, or the fact that I'm a white male in my 30s without visible tattoos or long hair who can look someone in the eye and talk about programming.

Do you have facial hair? I hear that helps.

How many C++ courses does your school offer and if it is more than one is this the introductory course? Without knowing much about your assignment this appears to be a problem that could be solved with just C as C++ isn't required. Just curious.

I'm inclined to state that your pay demands are inline with other developers that claim to have a similar background. If so you might want to push the envelope a little. Just my view.

It is absolutely crazy right now in the job market and seemingly the best is yet to come.

Yeah coming across as a normal person helps. I'd add speaking English fluently to that list as well - I'm pretty sure that's the case for you. Overall, having strong technical skills and being even average socially in a business setting is a hard combination to find.

It's also possible your expectations are too low relative to your abilities, kind of like what adios was getting at.

Checked out ReactJS due to the ZOMG ReactJS native keynote. Not bad, I dig components, makes sense overall. Might use it in the future.
Only waded through the tutorial and read up on selected stuff that sounded interesting.

I'll definitely look at the native github repo when it's up.

My school's main classes are as followed.
The first two programming courses are in java.
There is two mobile courses, android and iOS programming.
Object-Oriented Design is taught by a professor that loves small talk.
C++ intro, C++ intermediate, C++ Networking, C++ Data structures and C++ Algorithms Design and Analysis.
Also there is a nodejs class offered randomly that i want to take instead of the php course.

The sorts with linked lists have to be done with pointers and recursion only which is cool but I would rather just use loops instead of having to debug constantly. He has shown qucksort yesterday and wants us to do a radix sort as an assignment.

I'm not super with recursion and profs motto is treat recursion zen like and write as it should just work which i'm like 0.o half the time he is writing on chalk board.

You are allowed to write in C for assignments, quizzes and tests.

Not sure I have posted it in here before but my sole technical goal for this year is get good a JS, get better at HTML/CSS in general and do some design related stuff to be less scared of anything design/layout.
DOM is ugly/scarry as hell but can be avoided for the most part, JS-OOP is very sexy imo (lol classes)

iosys: I think "getting" recursio is pretty valuable. Quick sort specifically is a good example. Once you know it and are comfortable with thinking recursively you'll see a lot of problems that can be tackled with the same divide and conquer recursive ideas. I think the Zen-like comment is prett valuable. It helped me a bit to mentally link recursion with mathematical induction so yeah you can pretty much assume something works magically and build from that.
[alas loops are usually faster but I tihnk recursion is a better problem solving tool in general]

If you can get over the "lol noone uses this you silly academic" this is actually +EV imo. Small Talk and Eiffel are pretty much the nuts for teaching OOP concepts. I suppose one could use Ruby instead of Small Talk these days.
Object Oriented Software Construction (Meyer) + Object Oriented Design Heuristics (Riel) + a book on patterns would be my recommended OOP selfstudy bookshelf.

I'll also +1 your prof's comment about "write as it should just work". A lot of people psych themselves out because the function they're calling is the function they're already in - but in many cases you can just treat it like any other function call and Bob's your uncle.