Hopefully, this is constructive criticism...<p>"What port does ping work over?"<p>Seriously, don't ask trick questions in interviews. You put the candidate in the impossible position of having to correct the interviewer, and the reaction to that tells you absolutely nothing about what the candidate knows or will do in a real-world situation.<p>"at least access to one, even if it's not at home."<p>And yet, this candidate will often simply answer "None" because you didn't ask about access to a network, even if the candidate maintains multiple complex networks at family members' homes.<p>"Are open-source projects more or less secure than proprietary ones?"<p>Don't ask yes/no questions if what you really want are pros and cons. Ask for pros and cons instead. Interviewing shouldn't involve mindreading. A lot of people will respond to a question like this by stating a thesis and then defending that thesis.<p>A lot of your questions have that problem. You're asking specific things, hoping that the interviewee will catch on and give you general answers. That seems to be testing interview skills more than anything else.
These are not IS questions, they are ITS questions. There is a very serious difference between the two.<p>ITS without IS governance, policy, and management is worthless. It is chasing <i>ménaces du jour</i>, not actually managing security.<p>Were I interviewing someone for a serious and senior IS role, I would start with social questions, asking them to describe what organizations they consider to be the most threatening in general and to businesses in my country and field specifically, and why.<p>I would describe (hypothetically, without saying so) an organization like mine (but different enough to give away little), its flaws and concerns, and ask them how they would address those flaws.<p>Were I to hire that senior IS person, I would let them build an IS organization, which would include an ITS component.<p>Without policy, governance, and management, you do not have security, you have techno farce - and your organization will remain perpetually reactive, never really knowing how secure it is, never really being able to assess risk reasonably.
"Encoding is designed to protect the integrity of data as it crosses networks and systems"<p>Your blog entry has encoding problem. Indeed, it protects me from reading it.
"How would you implement a secure login field on a high traffic website where performance is a consideration?"
....
"wanting to serve the front page in HTTP, while needing to present the login form via HTTPs"<p>Maybe. There will still be a link on the HTTP page that takes you to a HTTPS page with a login form. Someone with MITM access could alter that link. A better way would be to serve all pages via HTTPS
Is it really true that you should compress before you encrypt? IT seems to me that the encrypted message should have the same amount of "information entropy" as the original message, so it should compress equally well.
This stuff is basically at the CISSP CBK level, i.e. essentially worthless except as screening questions. Maybe it's ok as a baseline, but you really want something deeper and more relevant to your specific position.