It would also breach the work contract of many developers. Most work contracts tend to (1) prohibit you from taking on other paid work (2) claim copyright of the work you do while under employment (which is why the FSF & Apache foundation require employer waivers from contributors).
Do you have a source for this claim? None of my contracts in the US have ever had something like this. It's in fact illegal in most jurisdictions, including California.
You want to check the small print of your contract but it depends on how related to you day job it is - the real point is could you afford to fight your employer.
And if you get caught using any of employers code like Sergey Aleynikov you are SOL
My experience has been that with a client, the universe of potential questions is much smaller than the universe of potential questions in an interview. An interviewer can go almost anywhere. . .that's not usually the case with the client. As you said, the client is asking about the software you are developing, not - typically - details about how you would handle their business need in a different language or on a di…
I've had the polar opposite experience. I guess we have very different clients. Clients generally ask questions that don't make a lot of sense or that show a fundamental misunderstanding of how the system works. They may introduce new constraints and requirements on the fly that you've never heard of before. It's generally a lot more difficult. The "universe of potential questions" is basically limitless. Interviewer…
But with clients (at least the ones I've dealt with) it is part of your job to educate them.
Question doesn't make sense? Let them know (gently, of course). Fundamental misunderstanding? Same thing. You are speaking from a position of authority.
I suppose you could try to take that posture in an interview but you are gambling on the interviewer being receptive to that approach.
Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients? Of course not. Interview situations are very, very different than the others. Meetings and code reviews are with co-workers, whom you know and trust. Meetings with clients could be nerve-wracking for other reasons, but the…
Can I offer you some advice? An interview is a negotiation. The rules aren't fixed. If you're asked to do something that won't give a reliable measurement of your ability, say so and offer the interviewer a better option. You'll probably get what you want. In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working styl…
If an interview is a negotiation, then why interview somewhere that I'm going to have to start off at a weak negotiating standpoint?
Obviously this is predicated on the dev job market being as good as it is, but still. I can just go elsewhere.
Can I offer you some advice? An interview is a negotiation. The rules aren't fixed. If you're asked to do something that won't give a reliable measurement of your ability, say so and offer the interviewer a better option. You'll probably get what you want. In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working styl…
It may be a negotiation but it is a very asymmetrical one. That by itself might be the root cause of a lot of the anxiety.
True. But it's not nearly so asymmetrical as most people seem to believe. Most interviewers aren't great at interviewing and know it. They're usually open – surprisingly open – to changes that will help them conduct a more reliable interview.
Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…
Would you be kind enough to explain further why knowledge of closures is a priority...?
IMO, it's because they're abstract enough to be completely opaque to someone who doesn't understand the concept of them, but ridiculously simple once you do. Also, if you're doing a lot of front-end/javascript work you're bound to have run into them, even if you don't realize what they actually are at the time. For me it was just one of those "a-ha" moments where you realize there's an easier/better way to do something. And if the interviewee doesn't know about them before the interview, hopefully s/he has learned something from the interview (I learn a lot from interviews just from looking up all the stuff I didn't know).
Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…
I used to work at Google. I saw a lot of good candidates get rejected. I myself was rejected multiple times before I got an offer. I was talking to my manager who was on the Hiring Committee about this dilemma, and at the end of the day the fact is that good companies don't give a shit about their false negative rate - only their net positives. By having an efficient technical interview process, yes, you let good can…
I think Google's hiring is less about finding a few good engineers and more about collecting impressive specimens of humanity for a dream team. They're playing a different game than most, and that's their prerogative.
The problem is that interviews are high stress affairs. Stress produces adrenaline. One of adrenaline's known effects is to prepare us for "fight or flight", meaning that higher order logic is shut off, digestion is shut off, our senses sharpen, reactions improve. This is great when you've got to climb a tree to get away from a tiger. This is horrible if you are trying to demonstrate your ability to function mentally…
Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview. Stressful situations happen a lot more than never in the real world (and sometimes they even involve talking to people, like customers) -- I don't want to have coworkers who can't handle that.
But it is different stress.
Stress in a job situation is like building a fortress over many months and getting invaded. You know the layout of the terrain like the back of your hand and you can focus on the problem.
Stress in an interview is like being air dropped into an enemy fortress. It is hard to know where to turn and you spend as much energy trying to suss out the layout of your new environment as you do reacting to your adversary.
It seems to me that software engineering is one of the only fields with people arrogant enough to assume that employers should hire folks without being able to see what they've actually accomplished. A "portfolio" does not have to, and should not , consist of side projects. Don't have any real code that you are allowed to share? Obviously, many employers won't hire engineers without reviewing existing code or having…
> A "portfolio" does not have to, and should not, consist of side projects. I agree with this > If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem. I disagree with this. If you require this to be true, you've instantly excluded everyone's experience in either government (particularly defense), o…
If you're in an industry where it's typical for candidates to be limited in what they can share, then ostensibly the hiring criteria and process would reflect this.
Can I offer you some advice? An interview is a negotiation. The rules aren't fixed. If you're asked to do something that won't give a reliable measurement of your ability, say so and offer the interviewer a better option. You'll probably get what you want. In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working styl…
If an interview is a negotiation, then why interview somewhere that I'm going to have to start off at a weak negotiating standpoint? Obviously this is predicated on the dev job market being as good as it is, but still. I can just go elsewhere.
You're missing the point. Regardless of the circumstances in which an interview takes place, you can ask for changes. And usually get them. The only way to be guaranteed not to get the changes you want is not to ask.
So, if you ever find yourself in an interview about to go the wrong way, ask.
Basic computer science knowledge (and yes, B-Trees qualifies) cannot be learned in 20 seconds. Most of this knowledge is actually a prerequisite to being able to search Google properly.
how often does a normal software developer find himself in a situation where he has to know about B-Trees in depth?
Basic computer science problems creep up often enough (about once a month) at my mostly normal job. We had to implement a prefix trie (specifically a modified radix trie with extra caching) to solve an interesting problem.
If you don't know about these data structures or algorithms, you won't even know where to look.