Both interviews highly biased towards interviewing skills: bs and basic algo. Judging if someone has the skill to build large system based on a conversation is silly. You cannot make an informed decision.
You should look for people with the portfolio. If someone has made a project in TensorFlow to paint in Picasso style then you should hire them regardless of education.
This is an unpopular opinion. You cannot become good in software engineering if you only read HN and work 9-5.
My ideas for interview:
1. Ask the candidate to bring a laptop, people running Linux +1
2. Pick random testing framework and ask if the candidate can setup and run some tests for fizzbuzz.
3. Ask a difficult question on system design, CAP theorem, compilers and OS internals. They should not be able to answer these.
4. If they lasted so far, make them comfortable before the finale. Pat theirs ego a bit.
5. Confront the candidate, essentially troll them a bit. For example: Describe fictional homemade crypto system build in PHP. Judge their response.
Instead of comfy 30 min BS talk about their previous experience you will have a better picture of the person if you put them in the hot seat. Above is just an opinion as I do not have interviewing experience.
Are you serious with your ideas for an interview? You have:
1. Someone running linux? What about gamers who dual boot or VM into linux? What about people using the new windows+ubuntu thing? What about people who do windows/android/whatever dev that can be done completely fine in windows?
2. Fine, but extremely easy. Not much more than a small filter
3. You don't expect an answer? What are you getting out of this?
> You cannot become good in software engineering if you only read HN and work 9-5.
Yes, you can. I know several people who are and do.
> Ask the candidate to bring a laptop
Which would screw people with desktop PCs or do not own their own laptops (some do not; it's expensive for some).
> people running Linux +1
Ew. Checking for Linux skills is fine; judging someone based on their personal setup is elitist and arbitrary.
> Ask a difficult question on system design, CAP theorem, compilers and OS internals. They should not be able to answer these.
Then why ask?
I would absolutely not be able to get a clear picture of a candidate from these questions. There's no strategy; no context. And not to get too personal, but, yeah -- you do need some interviewing experience.
> Confront the candidate, essentially troll them a bit. For example: Describe fictional homemade crypto system build in PHP. Judge their response.
I would respond I have no idea about your fictional system if I had never heard of it before. What would be your takeaway from my response? Please do not ever interview if you want to just "troll" candidates and waste their time.
> Instead of comfy 30 min BS talk about their previous experience you will have a better picture of the person if you put them in the hot seat.
Oh boy, I bet you believe in those high pressure interviews designed to see how the candidate performs under difficult conditions.
The BEST way to figure out if someone has built large systems is to ask them about it - how it was designed, who initiated which part, edge cases, people involved, etc. The candidate will often start talking more than they would if asked a simple yes or no answer. BS sniffing here is fairly simple.
It also tests soft skills - if the candidate can communicate to others (engineers even); often, large systems cannot be built and maintained by a single developer, hence communication to build and scale a team is another sign of large systems (people and tech) experience.
How would a portfolio demonstrate large system experience, unless the system was completely online? It's much more difficult to put a large system into a portfolio than small code samples. And if the large system is of value - why interview at all!? =P
For pure programmer/tech chops, sure, the interview ideas are fine. However, that's only one aspect of finding the right person for the right position at a company.
The hotseat approach is not right for all companies.
>If someone has made a project in TensorFlow to paint in Picasso style then you should hire them regardless of education.
Hmm, I definitely don't agree. Once the Style Transfer paper was released, it's pretty trivial to implement it in a DL framework. Certainly a good indicator that someone knows how to implement deep learning algorithms, but it's a pretty small facet of someone's skill. You can implement Style Transfer while still writing ugly, buggy, mediocre code. You can also copy most of the code from different open source DL repos, even before anyone had implemented Style Transfer.
That said, someone taking the time to implement Style Transfer does show that they're reading recent research and are curious about deep learning, which are definitely good signals.
You should look for people with the portfolio. If someone has made a project in TensorFlow to paint in Picasso style then you should hire them regardless of education.
This is an unpopular opinion. You cannot become good in software engineering if you only read HN and work 9-5.
My ideas for interview:
Instead of comfy 30 min BS talk about their previous experience you will have a better picture of the person if you put them in the hot seat. Above is just an opinion as I do not have interviewing experience.