Thanks, this really helps as well.

I need the reverse of this. How do I determine whether I want to work with someone over the course of a mere 20-30 minute phone interview or 40 minute live interview?

I usually try to do 1 coding question (with test case), 1 design question, and 1 easy unix question.

e.g. "find unique elements in a list", "how would you design a poker game?", "how would you find all files in a directory that contain an email address?"

But still I feel like it's not enough time to make a solid decision about a candidate. I'd ideally like to ask more questions that determine whether someone will organize code well, as opposed to asking harder "puzzle" type questions.

Anyone have any tips for interviewing people?

Replying to your post from before apparently jinxed me as I had to deal with a huge merge conflict today (someone combined two files together while another person was making changes to those same files)

i think my current employer does it pretty well and it mostly consists of 2-3 people doing the things that you're doing. i'm not sure there's anything that sucks less.

as to your code org question, do you ask candidates to do a longer form, at-home coding problem? i sort of have mixed feelings about them as a candidate but they can be quite illuminating.

What about: "Tell me about a project that you built, and if you were to do it again today, how would you do it differently (ie. design, algos, etc)?" This would take no real preparation from the candidate and would reveal quickly what his or her level of coding is, I would think.

... At what level do you stop regretting decisions you made 6 months ago?

wonder how many front end interviews would be ended by "how would you center something that is absolute positioned?"

if you could give me the answer to that question I would appreciate it actually

edit: eh, well, I just googled. I don't know why I didn't look it up using those exact terms before. Now I can write slightly less ******ed CSS. thanks for that

1) clone, pull or init (make a new) repository

*code changes happen here

2) add

*once you're ready to save your work

3) commit

*git commit -m "add stuff that is funny or will help you remember points later"

4) push

Usually to master. After this you get into branching and merging, which is a more advanced topic. Merge conflicts are marked and you can through and accept a preferred version. Also useful are git log (go and look all commits with comments) and git checkout (take out the code at a particular point without deleting or overwriting where you're at now).

I'm really liking the git wiki for adding docs as well.

Interesting idea. Short coding exercises definitely don't reveal how well someone will be able to keep things organized in a large code base.

My manager / his manager both ask a question like this and they say that often candidates can tell you all about what the project was, but can't explain what they actually did for the project.

I'll give this question a shot, but I'm a little afraid it will take up too much time if I let candidates go on and on. I'll lead off with it and say "give me the 2 minute explanation".

That makes sense. Obviously, if you are working as a member of a team on a large project, you don't have an eagle-eyed view. I was thinking along personal projects. I could tell you in disgusting detail about that site I built a few months ago and enumerate quite a few mistakes I made. Two bother the hell out of me to this date but I'm too lazy fix them. Regardless, that kind of question is perhaps too tunnel-visioned since its perhaps kind of lame to expect an applicant to have sizable personal projects laying around.

That's what makes it a poor interview question, really. It's a trick that takes 30 seconds to look up.

Agreed. All you care about is if someone can figure it out quickly. I (and I think the majority of developers) don't memorize stuff like that. Every time you need it, you do a 30 seconds google search and re-find the answer.

The amount of times I've stumbled upon certain stackoverflow questions is embarrassing.

"How do I I think I must have hit that one at least 15 times before I memorized some of the tricks.

I really do live in the rails API doc since I can't ever remember the names of methods anymore.

I dunno though, if you can find a project for someone to do that isn't super easy to google, but does have some direction if you're good at finding stuff on the web... that's a lot of what development is. I like to consider myself resourceful, and think I'm able to figure out stuff pretty quickly... but a lot of what I do has been done by people who are way smarter at programming than me. I often just try to find the best example done by someone who works at google or has done big projects I'll never do.

Also, what do people here consider their threshold for # of hours they can code during a work week? I am super ADD and actually enjoy coding, so I'll often crank out a solid 8 hours straight of coding during a day then come home and crash, mentally exhausted. I haven't been staying at my job for more than 8 hours in the office except on rare occasions (it's a start up, hours are more about getting things done).

That being said... it's my first real programming job, and 2 months in I'm starting to burn out. I don't have any mental energy after coding all day, and I don't like the way it makes me feel when I get home. I actually asked my boss if I could just pencil in 2 days a week from home, since I am still productive at home, and not having to get up and shower and commute 40 minutes each way is a mental boost.

Instead, they offered me a 20% raise. I think I'd rather have the 2 days a week from home. Some first world problems here.

I don't think there's steady state for me. Sometimes I could code for 12 hours straight. Other days I take a break after 10 minutes, take the dog for a walk and never go back to it.

That's pretty damn near close. I like not commuting but for a 20% raise I think it's worth it.

Sorry if unclear; I meant that apparently many candidates have a pretty good eagle eye view but can't explain how they actually contributed.

I would definitely want people working on a large project to have some idea of the bigger picture and where they fit in.

It may sound really strange but use mindmaps for stuff like that. Rule of thumb...once you look something up for the second time it has to go in there.

It's really an amazing tool for remembering and organizing stuff.

For the love of god take the work from home and insist on it. Tell your boss the reason it is very much in their interest to grant that request.

This brings up one of the interesting topics we were talking about at the interview I had, and I got educated pretty good on this one.

He asked me if I knew what a trigger is, and I do, so I explained to him what one is (not concerning the esoterica of Postgres vis-a-vis et.al), and then he asked me if I could name any problems with triggers.

My response was something like: "Triggers are a) very difficult to get write, b) very hard to debug and most importantly, c) there is no errors. They can blow up and you have no idea, which can quickly degrade the integrity of the database and before you know it, you have mess on your hands."

Then he asked me: "What is the issue that could happen on a team?"

IDK...

The gist:

The team may not know that a trigger even exist. In fact, you can't even expect a team to really know it if a DBA created one, so the team is just going along, and they know there are tables, but they don't know there are triggers, so you can end up with a bunch of bugs, duplicate data, over-writing, and things like that. His solution (and it makes perfect sense) is to not use triggers at all, just have the team program in what the database is supposed to do inside of the language. <-- Note that there are other constraint-based solutions that make more sense, so the conversation was more nuanced than this.

This kind of situation is what I am saying about "bird's eye view" of the project. Sure, the PM may know about what the DBA did, but the team (assuming triggers and other constraints are programmed into the database) wouldn't necessarily know what is happening on that layer, and they don't need to know. Suppose the DBA masterfully made it so that the team only has to update data in one table that data gets pushed up into other tables, then the programmers wouldn't know or care about this process. It seems highly unlikely that a large team of ,say, 6 or more programmers would know about the minutiae of the entire system design. These "knowledge abstractions" can be pushed up and up, to where even the javascript programmer only knows that something on the HTML layer happens and is affected, and surely she would have no clue what is happening on the DB level.

I wouldn't expect someone to be able the answer the question I proposed from a team perspective. I only meant it as something like "I build x SOLO project and after pondering it a bit, I know that y was a total hack and I that happened because I didn't consider what would happen when I did z. I should have done a, b, c and that would have saved me, idk, 75 LOC and made the entire program more elegant."

I kind of agree that triggers are best avoided for medium projects upwards because they are so hidden, and it's very, very, very easy to start creating infinite transactional loops by mistake with them.

(trigger on updating table A updates table B, say....then a few months later someone puts in a trigger on Table B to update table C, then someone else later puts in trigger on table C updates table A....voila, foreverloop time).

I really only ever use triggers for archiving/logging, and they are are very good for that...ie strictly only one way to (as far as the main system is concerned) write-only tables.

Any other logic that updates/changes your main tables in a way that's anything other than basic CRUD is best done within stored procedures imo.

You've totally lost me. I'm saying that ideally everyone on the team knows how their areas fit into the bigger picture. In simplest terms - what is the point of their work? How does their work produce value?

I'm not saying that everyone should know every minute detail about the other parts of the system.

Going back to your original question "tell me about a project you worked on and what you would do differently now" - I think it is completely reasonable to ask that question about a project where you were part of a larger team.

It takes a lot more mental energy when you're still learning how to code as a professional. You'll build more stamina and the work will become less draining over time.

I've had a pro job for um.. 7 years and I can't even do 7*5 = 35 hours a week solid.

I guess it depends too, because I enjoy learning... and felt like I was learning a lot the first 4 weeks. Since then, it has been a lot of regularity. We're about to go live, so that'll be a big change of pace, and hopefully make the job a bit more fun.

I love learning new stuff.

I can do 80 hours a week for short bursts, 60 hours for a long time if I had to. Kids these days

I think I actually enjoy making things work and seeing them go live over learning new stuff. I like to play with the tools I have, and find learning a little more painful the older I get. Luckily my job constantly forces me to learn new technologies whether I like it or not.

Somehow I missed this before. This is pretty close to what I was looking for. But what's a little disconcerting in this thread is that every poster seems to have a different method for resolving git conflicts.

The thing is, maybe I've just gotten used to subversion, but I haven't had a merge conflict resolution problem in years. Here's how the flow usually goes:

1. Subversion get - notifies you have conflicts
2. Launch tortoise merge tool
3. Scan down conflicts using red arrow
4. Select 'Use mine' or 'Use Theirs' for each conflict (there might be an option to use both, but that's almost never needed)
5. Mark resolved
6. Subversion commit

Often in a file with conflicts there will be some you know you worked on (use mine) and some areas you know you didn't touch (use theirs). Git seems to have all use mine or use theirs, but no mix. Here's how my git flow usually goes:

1. Git pull - says pull didn't exit cleanly, says you have conflicts and need to commit first (should I always commit then pull?)
2. Git commit - says need to merge and resolve conflicts
3. Edit conflicts in SourceTree, or TortoiseGit - very unclear how to pick a block or if anything is happening at all - SourceTree has 'stage hunk' option which doesn't seem to do anything
4. Get my saved version of conflicted file, manually merge all my stuff back in
5. Mark resolved
6. Git commit again (necessary?)
7. Git pull again (necessary?)
8. Git push
9. Pray you didn't mess up anyone else's code

Anything glaring that I'm doing wrong in that list? I need an external merge tool. But hooking it up to SourceTree seems complicated. I know I need to get more comfortable with the command line on Mac. But if I can find a GUI tool that does the job I'd rather use that.